Find the gaps now. Not in the room.

Audit preparation goes wrong in one specific way: an answer is given in good faith, evidence is requested, and the evidence disagrees. Everything here is aimed at making that happen weeks early instead.

01 · What you will be asked

Six questions, and where the answers come from.

What personal data do you hold?The classified field list, from the code, not from memory.

Where does each field go?The data map: every store, log and sub-processor it reaches.

Who are your processors?The recipients found in code, including any missing from your written list.

Is it encrypted at rest?Per store, with the ones that assert nothing named by file and line.

Can you delete on request?Erasure coverage per field, and the fields with no delete path.

How do you know this is current?It regenerates on every commit, so the answer has a date on it.

02 · The order to do it in

Map, then triage, then assemble.

FIRST, THE MAP

Scan and classify. Until you know which fields count as personal data and where they go, every other answer is a guess with a confident tone.

THEN THE QUEUE

Sort findings by the obligation they touch. Auditors are far less troubled by an open finding with an owner than by one nobody had noticed.

LAST, THE PACK

Export the evidence once the picture is stable. Assembling it first just means assembling it twice.

03 · What you hand over

One record, generated, with a date on it.

The Record of Processing overview with data categories, recipients, special-category count and policy field completion. — Pre-filled from the code. The policy fields stay yours, and the export carries both halves.

See the evidence pack See the RoPA

04 · Try itPUBLIC REPOSITORIES

Start with the map.

A public repository, read once and not kept. You get the data map: every personal-data field, where it lands, and who receives it. Or run the container on your own runner, and the source never reaches us.