Security

How DropAudit protects your data.

What we host, where, how it's protected, who can touch it, and where our certifications actually stand.

Status: DropAudit is pre-launch and is not yet accepting customer data. Where this page says a detail will be published before launch, that detail is genuinely undecided — we would rather say so than publish a specification we cannot yet stand behind.

We never access DROP

DropAudit does not log in to DROP, does not hold your DROP credentials, and does not connect to DROP on your behalf. You authenticate to DROP, download your deletion lists, and upload status reports yourself. DropAudit processes only the lists and records you send us.

The DROP regulations require a data broker to restrict access to its DROP credentials, and to information derived from DROP, to persons authorized to act on its behalf, and make the broker responsible for all actions taken through its DROP account (11 CCR §7610(a)(1)). Keeping credentials entirely inside your team keeps that boundary simple.

Where data is hosted

Customer data hosting is not yet in production. The hosting provider and region(s) will be named here before DropAudit accepts any customer data.

The public dropaudit.co website is served by Cloudflare.

Encryption in transit and at rest

  • In transit: the public dropaudit.co website is served over HTTPS by Cloudflare. The TLS floor and scope for the application, ingestion API, and SFTP will be published before launch.
  • At rest: the encryption algorithm, the storage layers it covers, and the key-management service will be published before launch.

Identifier hashing

DropAudit is designed to work with hashed consumer identifiers rather than raw identifiers. Before comparison, identifiers are standardized as the DROP regulations require (11 CCR §7613(a)(1)(A)).

  • Hash function: the algorithm and the normalization steps applied before hashing will be published before launch.
  • Where hashing happens: DropAudit is designed for identifiers to be hashed in your environment before upload. The final specification will be published before launch.
  • Raw identifiers: the service is designed not to receive raw consumer identifiers. Any exception, and any retention that would follow, will be published before launch.

Access controls

  • Customer users: authentication and MFA, and which plans offer SSO, SCIM provisioning, or custom roles, will be published before launch.
  • DropAudit personnel: our production access model — who can reach customer data, and how access is granted, reviewed, and logged — will be published before launch.

Data retention and deletion

  • Uploaded deletion lists and match results: the retention period, and whether it is customer-configurable, will be published before launch.
  • Audit logs and evidence packs: the retention period will be published before launch.
  • On termination: the deletion window (including backups) and the export window will be set in the customer agreement and published before launch.

Note that the DROP regulations require brokers to keep unmatched deletion lists to screen newly collected records (11 CCR §7613(c)). Confirm with your counsel which system of record holds that list for your program.

Subprocessors

Third parties that process customer data on DropAudit's behalf: none today. DropAudit does not yet process customer data. This section will list each subprocessor, its purpose, and its location before any customer data is accepted.

Website only (no customer data): Cloudflare, Inc. serves dropaudit.co; Google Fonts serves the site's typeface.

SOC 2 status

DropAudit is not SOC 2 certified and does not currently hold a SOC 2 Type I or Type II report. We will update this page if that changes.

Security questionnaires and DPA requests are welcome at security@dropaudit.co.

Reporting a vulnerability

Email security@dropaudit.co with details and steps to reproduce. Please do not access or modify data that isn't yours while investigating.