Evidence by Design: Building Audit Trails into Everyday IT Operations
Updated: Oct 7
Most organisations don't discover their evidence gaps during normal operations. They discover them when an auditor asks for proof.
An ISO surveillance audit, a customer's due diligence questionnaire, a cyber insurance renewal or a question from the board often exposes the same problem: the work was done, but the evidence that the control worked is incomplete, inconsistent or hard to find.
That is rarely a lack of effort. It's a design problem: evidence is gathered after the event instead of being produced by the work itself. The answer is evidence by design.
Why This Matters
For regulated organisations, showing that a control works is now as important as having it. ISO/IEC 27001, ISO/IEC 20000-1, Cyber Essentials and the UK GDPR accountability principle all come back to the same question: can you prove it? The standards are specific about what that proof looks like:
Change management (ISO/IEC 20000-1 clause 8.5.1; ISO/IEC 27001 Annex A 8.32): a record showing each change was assessed, approved, tested and reviewed.
Incident management (ISO/IEC 20000-1 8.6.1; ISO/IEC 27001 A.5.24 to A.5.27): incidents logged, prioritised by impact and urgency, resolved and learned from.
Patching (ISO/IEC 27001 A.8.8): proof that security updates are applied on time. Cyber Essentials requires critical and high-risk updates to be installed within 14 days of release, and missing that timescale fails the assessment.
Backup (ISO/IEC 20000-1 8.7.2; ISO/IEC 27001 A.8.13): proof that backups run and that data can be restored.
Access (ISO/IEC 27001 A.5.18 and A.8.2): admin rights that are granted, reviewed and removed, with a record of each step.
Suppliers (ISO/IEC 20000-1 8.3.4; ISO/IEC 27001 A.5.19 and A.5.22): regular, recorded reviews of the suppliers your service depends on.
Accountability (UK GDPR Article 5(2)): being able to demonstrate compliance, not just claim it.
Boards ask the same questions in plainer language. How do we know changes are controlled? Can we show supplier oversight? Are incidents reviewed and learned from? How quickly could we answer an audit request?
Where Organisations Go Wrong
Many organisations still treat evidence as a project. As an audit approaches, teams hunt for change records, incident logs, supplier reviews and service reports, and rebuild what they can't find.
The result is the same every time: missing records, inconsistent detail, reliance on what one person remembers, and hours of management time. Worse, leadership only finds out whether controls were working long after the fact, so assurance rests on assumptions rather than facts.
Under scrutiny, "we do this regularly" quickly becomes "can you prove it?"
What Evidence by Design Looks Like
Organisations with consistently good audit outcomes don't collect evidence for auditors. They design their processes so the evidence is produced as the work is done. Here is what that looks like in practice.
Change: the record comes before the work
Before any work starts, the change record holds the scope, the business reason, a risk assessment, each step with its rollback, a backup check, a test plan and how affected users will be told. Changes that reach many users are tested first, then applied to a pilot group before wider rollout.
Each change closes with one recorded outcome: successful, partially successful, unsuccessful, delayed, cancelled or rolled back. That shows an auditor what actually happened, not just that someone approved it. Those outcomes should be reviewed every month (how many changes succeeded, how many were emergencies, how many were rolled back), which turns the records into management information.
Emergency changes are no exception. The record is raised first, even if it only says what is being done and why, and completed once the service is stable. Emergency should never mean undocumented.
Incidents: every alert has an outcome
Every incident and monitoring alert is logged against the system or device it affects, with the time it was raised, its priority and what was done. No alert should close without a recorded outcome, so you can see which were real faults, which were false alarms and which need tuning.
Repeats should be caught by design. When the same alert recurs three or more times in 30 days, it should become a problem record so the underlying cause is found and fixed. That is the lessons-learned evidence auditors look for, produced without anyone having to write a report.
Patching: measured monthly, exceptions recorded
Patch status is reported every month against a defined timescale, with critical and high-risk updates measured against the 14-day Cyber Essentials requirement. Devices that have stopped reporting should be listed separately rather than quietly dropped from the figures.
When a patch can't be applied, the exception should be recorded with the reason, a compensating control and a review date. If it affects Cyber Essentials, the record should say so plainly, because Cyber Essentials has no exception route, and anyone whose certification could be affected should be told in writing.
Backup: checked, not assumed
A backup failure should raise a ticket that stays open until the next successful backup is confirmed. Backup results should be reviewed every month as a scheduled task with its own record. Restores should be checked too: a restore nobody asked for is a possible sign of compromise, not routine activity.
Service reporting: nothing missing is ever green
Service reviews draw their figures straight from the operational records: service levels, incidents, changes, security posture and device health. Two rules should keep them honest. Where data is missing, the report should say "not rated" and why, rather than defaulting to green. And every action agreed at a review should be logged with an owner and a date, so the next review shows what was done, what is late and what was dropped.
What Good Evidence Looks Like
Whatever the process, evidence holds up under scrutiny when it is:
Complete: it shows what was planned, approved, done and checked.
Timestamped: it records when each step happened, automatically.
Attributable: it shows who carried out and who approved each step.
Linked: it connects to the system, device or service it relates to.
Retrievable: it can be found in minutes, not days.
Controlled: the procedures behind it have an owner, a version and a review date.
If an activity matters enough to govern, it matters enough to evidence.
The 24-Hour Audit Test
A quick way to see where you stand: could you produce each of these within 24 hours, without anyone having to rebuild it?
The records for your last three changes, showing approval, testing and outcome
Last month's patch compliance report, including any exceptions and their review dates
Evidence of last month's backup checks and your most recent restore test
The timeline of your last significant incident, and what changed as a result
A list of who has admin access to your key systems, and when it was last reviewed
Proof that last quarter's leavers had their access removed
Your most recent review of a key IT supplier
The actions agreed at your last service review, and their status
If any of these would take more than a day, or depend on one person's memory, your evidence is being gathered after the event rather than designed in.
How cyberISMS Helps
We are building our own managed service this way. Our processes are mapped to the clauses of ISO/IEC 20000-1 and ISO/IEC 27001, and each is designed so the evidence is produced in the course of normal work. We hold BSI certification to both standards, so we know what audits ask for because we go through them ourselves.
We help regulated organisations do the same: governance-led IT service management where change, incident, patching, backup and supplier records are built into daily operations, so audit preparation becomes a check rather than a project.
Next Step
Run through the eight checks in the 24-hour audit test. If any would take more than a day, talk to cyberISMS about building evidence by design into your IT operations.
Comments