Privacy, Security & Compliance

How ScrubHits 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

ScrubHits 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 ScrubHits 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

ScrubHits 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 ScrubHits’ 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

ScrubHits provides enrollment verification only to verified customers — data furnishers verifying accounts they report, and the debt settlement companies whose enrollments the network carries — and only for permissible purposes under the FCRA. Every customer certifies the purposes for which information is sought, in the terms of FCRA §607(a): users must “certify the purposes for which the information is sought, and certify that the information will be used for no other purpose,” and search activity is audited against that certification. The strongest basis is the consumer’s own enrollment instructions: verification runs “in accordance with the written instructions of the consumer to whom it relates” (§604(a)(2)), given in the enrollment paperwork that names the registry, the data, the recipients, and the purposes. 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. ScrubHits 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.

Operated as a consumer reporting agency

The platform is operated with the duties of a consumer reporting agency under the FCRA designed in from the first day, because an enrollment verification is a consumer report: it bears on a consumer’s credit standing and is furnished to third parties for a fee. That posture drives concrete machinery, not language:

• Accuracy procedures (§607(b)). Reasonable procedures “to assure maximum possible accuracy of the information concerning the individual about whom the report relates” — implemented as the evidence grading, as-of dating, and currency controls described on the evidence standard page.
• Purpose certification (§607(a)). No account is provisioned without verified identity and certified permissible purposes; no anonymous or self-serve access exists.
• Consumer file disclosure (§609). A consumer may obtain the information in their file — enrollment records, statuses, and the recipients of verifications — through an identity-verified request to contact@scrubhits.com.
• Dispute reinvestigation (§611). A consumer dispute triggers a reinvestigation on the statutory clock — “conduct a reasonable reinvestigation to determine whether the disputed information is inaccurate” — with notices to the contributor, correction or deletion of anything that cannot be verified, and suppression of unverified reinsertions.
• Retention with the litigation tail in view. FCRA actions may be brought up to five years after a violation; dispute, disclosure, and verification records are retained on that horizon, and adverse enrollment history is treated with the §605 obsolescence rules in view.
• Excluded by design. No medical information, no employment-purpose reports, no prescreened lists, and no full payment-card numbers are accepted at intake — each exclusion removes a statutory regime the platform never enters.

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@scrubhits.com.