How should a store document its consent setup for a privacy audit?
A privacy auditor wants proof of one thing: that no tracking fired before the visitor consented. The documentation that proves it has three parts: a snapshot of the consent configuration, a complete inventory of tags and trackers, and timestamped test records showing what fired and when. Assemble it before the audit is announced, because reconstructing it afterward is guesswork.
What auditors actually ask for
Privacy audits, whether from a regulator, a partner, or an enterprise customer doing diligence, converge on the same questions. What is your lawful basis for each tracker. Show that consent is obtained before tracking begins. Show that withdrawal works. Show how long you keep consent records. The stores that struggle are not the ones with bad practices; they are the ones with good practices and no proof. The audit grades the documentation, not the intention.
Start by assuming the auditor knows nothing about your stack and is professionally skeptical. Every claim needs an artifact. "We block tags until consent" needs the configuration screenshot and the test recording. "Users can withdraw" needs the withdrawal flow documented with timestamps. Build the file as if you are proving it to a stranger, because you are.
The consent configuration snapshot
Document the consent setup as it exists today: which consent management platform, which version, the exact banner configuration, the categories defined, the default states, and the Consent Mode settings. Screenshot the configuration screens and export the settings where the platform allows it. Date the snapshot. Configurations drift, and an undated snapshot is just a rumor about the past.
Include the logic, not just the settings. How does the banner decide what to show: geolocation rules, returning-visitor rules, the re-consent interval. An auditor will ask why a visitor in one region saw a different banner than a visitor in another, and "the platform handled it" is not an answer. Write down the rules in plain language.
The tag inventory
List every tag, pixel, and tracker on the store: what it is, who operates it, what category of consent gates it, and what happens when consent is refused. This inventory is the document most stores do not have, and it is the one auditors ask for first. Build it by scanning the live site, not by asking the marketing team what they remember installing. The two lists will differ, and the scan is the truth.
For each tag, note the firing condition in the tag manager: which consent state triggers it, and what blocks it. Tags that fire on "consent granted" for their category are correct. Tags that fire on page view with no consent condition are findings. The inventory should make the correct ones boring to verify and the wrong ones impossible to miss.
Test records with timestamps
The strongest evidence is a recording of the behavior itself. Quarterly, run the consent flow in a clean browser with the network panel open: load the site, refuse all, and capture which requests fire. Then accept all and capture again. Save the recordings with dates. This is the proof that the configuration does what the snapshot says it does, and it is the artifact auditors find most convincing because it is the hardest to fake.
Test the withdrawal path the same way. Consent, withdraw, and show the tracking stopping. Most stores test the grant path and never the withdrawal path, and withdrawal is where the findings hide. A dated withdrawal test with clean network output closes the loop.
The reject-all proof
Regulators care disproportionately about the reject path, because that is where dark patterns live. Document that rejecting is as easy as accepting: same number of clicks, no preselected categories, no confusing wording. Screenshot the reject flow. If your banner was ever flagged for a dark pattern, document the fix with before-and-after screenshots and dates.
Also document what "reject all" actually does technically. Which tags are blocked, which strictly-necessary functions continue, and what the visitor experience looks like afterward. An auditor who clicks reject-all and sees the site break has a finding regardless of what your configuration says. Test the rejected state as a user, not just as a technician.
Keep it current and keep it findable
Documentation rots faster than configurations change. Assign the consent documentation to a named owner and put a quarterly review on their calendar: re-snapshot the configuration, re-run the tag scan, re-record the tests. The review takes half a day. An audit with year-old documentation takes weeks of reconstruction.
Store the file where legal and compliance can find it without asking engineering. A shared folder with a clear name, not a ticket comment, not someone's laptop. When the audit letter arrives, the first 48 hours should be spent reviewing the file, not building it. That is the whole game: preparation that turns an audit from a fire drill into a file transfer.