From Assurance to Evidence: Seven Controls That Must Survive an ICO Request

Regulatory scrutiny seldom opens with a demand for every policy. It opens with a narrow question: show us how this control operated for a particular system, dataset or request. An ICO audit, information rights request or breach follow-up is therefore an evidence exercise. The controls that fail are rarely absent from the policy library. They are the ones that cannot be tied to an owner, a date, a system, a decision and an exception.

In 2026, UK data governance teams should assume that a control will be tested by sample, not by description. The seven controls below often look assured in committee papers but weaken when the regulator asks for proof. For each, the practical question is the same: would the evidence pack survive an information request without reconstruction after the event?

1. Retention schedules without disposal evidence

A retention schedule can be approved, published and still be little more than an aspiration. The audit question is not whether a schedule exists, but whether it is applied in systems and whether departures are recorded. Common failures include schedules that are not mapped to live applications, deletion jobs that are switched off, and legal holds that are managed informally.

A defensible evidence pack should include the current schedule and approval record, a mapping from schedule classes to systems, configuration evidence for automated deletion with dates, a sample of disposal logs, an exceptions log and a legal hold procedure. The test is simple: choose a dataset that should have been deleted last quarter and show what happened to it.

2. Processor oversight that stops at the contract

A signed data processing agreement is necessary but not sufficient. Oversight fails when subprocessor changes are not tracked, assurance reports are filed without review, and issues are not closed. The evidence gap is usually between procurement, legal and the business owner.

Evidence should show a processor inventory with risk tiers, due diligence dates, contract clauses, subprocessor notification records, assurance review notes and a remediation tracker. A useful test is to select a high-risk processor and trace the relationship from contract to assurance review to issue closure. If the trail depends on one person's inbox, the control is not yet defensible.

3. DSAR logging without an audit trail

A subject access log can look complete while omitting the decisions that matter. Regulators may ask how a request was received, how identity was verified, what searches were run, which exemptions were considered and who signed off the response. A spreadsheet that records only the response date is a status tracker, not an evidence system.

Build the log around the lifecycle: receipt, clarification, identity verification, search scope, third-party data, exemption rationale, review, response and closure. Sample three requests, including one complex case, and reconstruct the timeline. If the log cannot show why a search was considered adequate, it will not withstand scrutiny.

4. Breach triage that cannot explain decisions

Breach registers often record notifiable incidents well and near-misses poorly. That creates an evidence gap: the organisation can show what it reported, but not how it decided what not to report. Triage needs a recorded risk assessment, DPO advice, containment actions, notification reasoning and lessons learned.

A defensible pack includes the incident ticket, the triage decision, the risk assessment, the 72-hour clock evidence, notification assessments and closure actions. Test one notifiable incident and one near-miss. The near-miss is often the more revealing sample because it shows whether judgement was documented before the event became visible.

5. DPIA screening treated as a formality

A DPIA template is not a control. The control is the screening process that identifies projects requiring assessment, records DPO advice and tracks mitigations to completion. Failures appear when every project is deemed low risk, when screening is completed after procurement, or when residual risk is never reviewed.

Evidence should include screening decisions, trigger criteria, DPIA versions, DPO advice, sign-off, residual risk acceptance and review dates. Select a recent project involving monitoring, profiling or AI and ask for the screening record. If the first substantive data protection discussion happened after the contract was signed, the control was not operating.

6. AI vendor due diligence that relies on assurance

AI suppliers introduce a familiar problem in a new form. A questionnaire may confirm that security certifications exist, but it may not explain what personal data enters the model, whether data is used for training, which subprocessors are involved or how model changes are notified. The evidence gap is often the data lineage, not the certificate.

A defensible pack links the use case to a vendor risk assessment, a data flow, contract terms on model improvement and subprocessors, audit or information rights, change notification and revalidation triggers. Test a generative AI tool now in use and trace a realistic prompt containing personal data. If the organisation cannot show where that data goes and on what contractual basis, the control is paper-thin.

7. ROPA reconciliation that never leaves the spreadsheet

A record of processing activities can be complete on its own terms and still be disconnected from reality. Stale owners, missing systems and absent links to retention, DPIAs and processors are common. The regulator may not ask for the ROPA in isolation; it may ask for the evidence behind a specific processing activity.

Evidence should include the ROPA version, owner attestations, a reconciliation sample against live systems, a change log and linkage identifiers to related controls. Choose three business units and compare the ROPA with the tools actually in use. If the comparison has never been done, the ROPA is a document rather than a control.

Building an evidence pack that holds

An evidence pack should be assembled before it is requested. Five attributes make the difference: source, date, owner, linkage and exception. Source shows where the evidence came from. Date shows when the control operated. Owner shows accountability. Linkage connects the control to the system, request or decision. Exception shows that deviations were identified and managed.

Keep evidence in a controlled repository with version history and access controls. Avoid the temptation to create retrospective narratives. A short, dated system log is stronger than a polished explanation written after the request arrives. Evidence should be proportionate to risk, but it must be sufficient for an independent reviewer to follow the trail without interviewing the original team.

Testing before the regulator does

Run a 90-minute evidence drill for each control. Ask a colleague who does not own the control to request the pack and reconstruct one sample. Record gaps, assign an owner and set a remediation date. Repeat for the highest-risk business unit rather than the most cooperative one.

The strongest controls are often unglamorous: an owner, a date, a system link, a sample and an exceptions log. In 2026, defensibility is not a documentation project. It is an operating discipline that assumes the question will come.