Privacy, Security & Compliance

How EnrolledHits handles, protects, and accounts for personally identifiable information (PII). This page is the complete treatment, written to support customer security reviews and compliance audits. Last updated: October 2026.

The data we work with

EnrolledHits operates a network of debt settlement enrollment data. To do that, we receive and store personally identifiable information — including Social Security numbers submitted by customers for matching, and enrollment records that identify the debt settlement company associated with a consumer, their enrollment status, and relevant dates. We collect only the data the service requires. We never request full payment card numbers or full creditor account numbers.

How matching works — SSNs are hashed, not exposed

Matching is performed on cryptographic hashes (HMAC-SHA-256), not on plain-text values. When a customer submits accounts for matching, the values are hashed and compared against the network’s hashed identifiers. Plain-text SSNs are not displayed to users, and results never show a complete SSN. Raw SSNs are never stored in the network: batch files are processed into hashes on arrival and the raw file is then securely destroyed; API submissions are hashed on receipt and never written in raw form.

How stored data is protected

• Encryption in transit: all transfers — API and SFTP alike — are encrypted. There is no unencrypted intake channel.
• Encryption at rest: stored data is encrypted, with encryption keys held in managed key storage (KMS) and separated from the data they protect.
• Tokenization: retained sensitive values are stored as tokens in an isolated vault, separate from the matching environment. The network itself holds hashes and enrollment facts, not raw identifiers.
• Network isolation: the network sits on a private network with no public database endpoint. The client portal and the transfer service are the only doors in.
• Per-client segregation: each customer’s submissions, results, and credentials are isolated to that customer. No customer can see, search, or infer another customer’s data.
• Data minimization: we request and retain only what matching and reporting require.

Access control & authentication

• Provisioned accounts only. There is no self-service sign-up. Every customer account is created by EnrolledHits after verification, with named users and assigned roles.
• Multi-factor authentication is required for portal access.
• Role-based, least-privilege access — users and internal staff alike see only what their role requires.
• SFTP access is by per-client SSH key, jailed to that client’s own folders, with no shell access. There are no shared file credentials.
• API access uses per-client keys that are scoped, rotatable, and rate-limited.
• Access is reviewed periodically and revoked promptly when a user’s role ends or a customer relationship closes.

Audit logging & monitoring

Every login, upload, search, download, and administrative action is written to an append-only audit log: who acted, when, and what was returned. Logs are protected against alteration, retained to support customer audits and dispute resolution, and monitored for anomalous activity, with alerting on patterns such as unusual volumes or repeated failed access.

How data is used

Submitted data is used to perform the matching a customer requested and to maintain the accuracy of the network. Search traffic is private: a customer’s queries are never exposed to other customers, and submitted lists are never sold or shared as lists. Match results name the debt settlement company associated with an enrollment, and that company receives the match information for its own enrolled clients.

Retention & secure disposal

Enrollment records are retained while they remain current and are refreshed as often as daily; superseded statuses are kept as history because a record’s history — including a dropped date — is part of the data customers rely on. Customer-submitted search files are processed into hashes on arrival and the raw files are securely destroyed once results are delivered; results themselves expire from the retrieval area and are securely deleted. For monitoring customers, a submitted inventory is retained in hashed form for as long as the monitoring runs, so each monthly check can run against it; it is deleted when monitoring ends.

Infrastructure

EnrolledHits is built on Amazon Web Services (AWS). AWS maintains SOC 2, ISO/IEC 27001, and PCI DSS Level 1 certifications covering its cloud infrastructure — the same foundation used across financial services. Those certifications belong to AWS; the controls described on this page are EnrolledHits’ own, applied on top of that foundation. Security in the cloud is a shared responsibility, and this page describes our half of it.

Backups, redundancy & recovery

Data is stored redundantly across multiple physical locations, with encrypted backups on a scheduled cycle. Restore procedures are tested, so recovery is a practiced operation rather than a hope.

Incident response

We maintain an incident-response process covering detection, containment, investigation, and remediation. If an incident ever affected a customer’s data, that customer would be notified without unreasonable delay, with the facts we know, the data involved, and the steps being taken — and we would cooperate with the customer’s own compliance obligations and any regulator inquiries that follow.

Vulnerability management

Systems are patched on a managed cycle, dependencies are reviewed for known vulnerabilities, and the platform undergoes periodic independent security testing, including penetration testing, with findings remediated by severity.

Sub-processors

Amazon Web Services is our infrastructure sub-processor: the platform runs there, and no other third party processes customer-submitted data. Customer data is never sold.

Permissible purpose & compliance posture

EnrolledHits sells enrollment data only to verified customers in the collection space, and only for permissible purposes. Every customer warrants that it has a lawful basis and a permissible purpose for each search it runs, and search activity is audited against that warranty. The platform was designed with the obligations of the GLBA Safeguards Rule and federal consumer-reporting law in view from the first day — data minimization, access controls, encryption, auditability, and accountable retention are architecture decisions, not add-ons. EnrolledHits does not claim certifications it has not been audited against; where a standard is named on this page, it is named as the framework the controls were built to, or as a certification held by our infrastructure provider, and this page says which.

Your responsibilities as a customer

Security is shared on your side too. Customers are responsible for keeping their portal credentials, SSH keys, and API keys confidential; for submitting only data they are entitled to submit; for using returned data only for the permissible purpose for which it was obtained; and for protecting data after download with the same care described here. Suspected compromise of a credential should be reported to us immediately so it can be revoked and reissued.

Changes & contact

Material changes to this page will be noted here with a revised date. Questions about privacy, security, or compliance — including security questionnaires and audit requests — go to contact@enrolledhits.com.