Step 7
How you show it: evidence, approvals and report
By the end you will have an organised evidence file, every decision with its approval recorded and a dated status report.
What this step is
The earlier steps produce documents: the appointment of the person responsible, the inventory, the role criterion, the classification record, the vendor files, the policy with its acknowledgements and the record of AI literacy measures. This step brings them together, puts them in order and makes them demonstrable: anyone can tell what was decided, who decided it, when, and that the document has not changed since.
That is the difference between a checklist and evidence. The checklist says what is missing. The evidence says what you did, with a date and an author, and it stands up to an awkward question a year later, when nobody remembers why a system was classified the way it was.
The work does not end here: its upkeep begins, and what comes next runs along two separate tracks. The data protection impact assessment (DPIA) is required by Article 35 of the GDPR where the processing calls for one, whatever the system’s classification under Regulation (EU) 2024/1689. The fundamental rights impact assessment (FRIA) applies from 2 December 2027, and only if your organisation falls within the scope of Article 27(1). They are independent of each other, and neither replaces the other.
Why
For personal data, being able to show it is not optional. Article 5(2) of the GDPR makes the controller responsible for the principles in paragraph 1 and requires it to be able to demonstrate compliance with them: this is accountability, a legal obligation with an explicit mandate that reaches every AI system processing personal data.
The shape of the file —categories, links, recorded approvals, a periodic report— is an internal methodological control, not a format laid down by any rule. Practice is what justifies it: a decision with no date or author cannot be reviewed, and a decision that cannot be reviewed cannot be defended before a client, an auditor or an authority.
On the FRIA, the scope is narrow and worth reading before you treat it as needed or as ruled out: Article 27(1) requires it of deployers that are bodies governed by public law or private entities providing public services, and of deployers of systems referred to in points 5(b) and (c) of Annex III, always for high-risk systems referred to in Article 6(2), and with the exception of the area listed in point 2 of Annex III.
The SHA-256 integrity hash lets you check that a document has not changed since it was recorded. It does not identify who issued it, nor does it replace a legal review: it says the file is the same, not that its content is right.
How, in three actions
Bring every document into one place, with a category and a link
For each document from the earlier steps, one entry: title, category, date, the system or step it belongs to and how long it is kept. The data processing agreements and the vendors’ documentation, the policy acknowledgements, the training records. The link is what makes the evidence easy to find later; a file with no link is just one more file.
Record the approval of each decision and keep its hash
The decisions that matter —the classification of a system, the policy, what to do about a vendor that did not reply— carry their approval recorded: who, in what role and when. Each PDF is kept with its SHA-256 integrity hash recorded, so that anyone can calculate it again and check that the file has not been altered. Earlier versions are not deleted: they are kept.
Issue a status report and repeat it on a fixed date
Close day 30 with a dated report: what applies under the classification of your systems, from when, and what is pending recording or review. No percentages or overall scores: it reflects the recorded state, not a rating. Repeat it on a fixed cadence, quarterly for instance, and compare each report with the previous one.
The typical mistake
Confusing having the documents with being able to show them.
A shared folder with everything in it does not answer the questions that matter: which version applied on a given date, who decided a system’s classification, whether the PDF you are showing is the same one that was recorded. Without a date, an author and a hash, every document depends on someone remembering its history. You avoid it by recording the decision when it is taken, not by reconstructing it on the day someone asks for it.
The template
A completed sample evidence file, with fictitious data: six pieces of evidence for a dental clinic’s high-risk system, with their retention and each PDF’s integrity hash. It shows what a file that answers those questions looks like.
Evidence file, completedEstimated time
Two or three days between days 25 and 30 to gather and organise what has been produced, and ongoing after that: each new decision is recorded when it is taken, and the status report is repeated on the cadence you set.
What you take away
The evidence file, with every document categorised and linked, its approvals recorded and its PDFs hash-stamped, and the first dated status report.
How it works in Alethexis
In Alethexis, Evidence brings together in a single repository your training records, contracts, vendor documentation and the documents the platform itself generates, each with its category, its links and its retention date, and the audit log records every action with its author, its time and a SHA-256 integrity hash chained to the previous one, checked every day.
The status report brings together on one page what applies under the classification of your systems, from when, and what is pending recording or review, in a hash-stamped PDF; with M1 you have from day one what you need for Steps 1 to 7: the inventory, the classification, the policy with its acknowledgements, the vendors and the evidence.
A checklist tells you what is missing. Evidence shows what you did.
14-day free trial