What auditors will ask for: the 9 areas

One line in the proposed rules shapes everything else: auditors may not base findings primarily on assertions, attestations, or a review of policies and procedures alone. An auditor will want to see what happened in each cycle, not only what your policy says should happen. The rules are not final yet; check the current text before you plan around them.

1. Deletion list selection. Which list types you selected, when, and why they cover every identifier you hold; any later changes.
2. DROP access. A timestamp for every access and download, showing the access cycle was never missed.
3. Standardization. The rule set and version you applied, and test results against the published examples.
4. Hashing. The algorithm and encoding used, and spot checks that your hashes reproduce DROP's.
5. Matching. How matches were computed, counts per list, and how one identifier linked to several consumers was handled.
6. Actioning. What was deleted or opted out for each match, and the reason recorded for each exemption.
7. Status reporting. Every status file you uploaded, the acceptance confirmations, and any corrections.
8. Suppression list. How newly acquired data is screened against past deletion requests.
9. Service providers and contractors. The notices you sent them and their confirmations.

Keep it as you go

Reconstructing a year of cycles the week before an audit rarely works. Record each step when it happens, with file hashes and approvals, in a log that shows any later edit.

How BrokerShield records it

BrokerShield writes every cycle step to an append-only, hash-chained log with a signed checkpoint per cycle, and exports an audit packet organized by these areas. It stores counts, file hashes and metadata only, never consumer data.