Skip to main content

Free register

ISO 27001 evidence register

The evidence an ISO 27001 auditor will actually ask for, mapped control by control, so you stop guessing what to collect.

XLSX and PDF

Get your copy

Three fields. No follow-up sequence unless you ask for one.

We record the page and campaign you arrived from. See our privacy policy.

What is inside

  • Annex A control to evidence mapping
  • Owner, frequency and retention per artefact
  • Common non-conformities and how to avoid them
  • Internal audit checklist

Who it is for

ISMS managers preparing for certification. It is written to be usable on its own, without a consultant sitting next to you. If you want one anyway, that is what the consultation is for.

Why evidence is the hard part of ISO 27001

Most organisations approaching ISO 27001:2022 for the first time assume the difficulty is the controls. It is not. Annex A controls are largely things a competent security team either already does or can implement. The difficulty is proving they operated, consistently, across the period the auditor is looking at.

An auditor does not accept an assertion that access is reviewed quarterly. They ask for the last four reviews, look at who signed them, check whether anything was actually revoked as a result, and notice if all four are dated in the same week because somebody caught up before the audit.

That is the gap this register exists to close. It maps the evidence an auditor will genuinely ask for against the control it satisfies, so you find out in month two rather than in the closing meeting that a control you believed was covered has nothing behind it.

The evidence that is usually missing

Across certification readiness work, a consistent set of gaps appears.

Access review records that show a decision. Reviews where every entitlement was approved in one click are worse than no review at all, because they manufacture evidence that a control operates when it does not. Give the reviewer a last used date next to each entitlement and watch the approval rate fall.

Supplier assessments with a conclusion. Plenty of organisations send a questionnaire and file the response. Almost none record what they decided as a result, which is the part the standard actually cares about.

Risk treatment that traces. A risk register is easy. A risk register where each accepted risk has a named accepter, a date and a review point, and each treated risk traces to the control that treats it, is the thing that survives scrutiny.

Management review minutes that record decisions rather than attendance. This one costs nothing and is failed constantly.

Evidence of change: a control that was implemented and never tested is a control you are asserting, not demonstrating.

How to run the register

Assign an owner per control, not per section. Sections have no owners in real organisations; controls do.

For each control, record the evidence artefact, where it lives, how often it is produced, and who produces it. If the artefact is produced only when someone asks, it will not exist when the auditor asks.

Automate the collection where the artefact is machine generated, which is most of the access and logging evidence. Manual collection of evidence that a system already produces is the single largest waste of effort in a certification programme.

Review the register monthly in the run up to certification and quarterly thereafter. The failure mode after certification is drift: controls keep operating and evidence quietly stops being kept, which surfaces at the first surveillance audit.

The 2022 revision, and what changed for evidence

ISO 27001:2022 restructured Annex A from 114 controls into 93, grouped into four themes, and introduced eleven new controls. For evidence purposes the new ones matter disproportionately, because nobody has years of accumulated artefacts behind them.

Threat intelligence, information security for cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering and secure coding. If your programme was built against the 2013 standard, these are where your register will be thinnest.

Information deletion and data masking are worth particular attention because they overlap directly with DPDP Act obligations. Evidence collected once can satisfy both, and organisations that run their privacy and ISO programmes in separate rooms end up producing it twice.

What an auditor will ask you to produce

  • The Statement of Applicability, with justifications for every exclusion
  • The last four access reviews, with evidence of what changed as a result
  • Risk register entries with named owners, dates and review points
  • Management review minutes recording decisions, not attendance
  • Supplier assessments with the conclusion recorded, not just the response
  • Incident records with timeline, decisions and post incident actions closed

Keeping the register alive after certification

The failure mode after certification is drift. Controls keep operating and evidence quietly stops being kept, which surfaces at the first surveillance audit as a set of findings that feel unfair because nothing actually got worse.

Two habits prevent it. Attach evidence collection to the process that produces it rather than to a compliance calendar, so the artefact is a by-product of the work rather than an extra task. And review the register quarterly against what was actually collected, not against what was supposed to be.

The other post-certification risk is scope creep in the estate rather than in the certificate. New systems, new cloud accounts and new suppliers arrive continuously, and a Statement of Applicability that described the organisation accurately at certification describes a different organisation eighteen months later. Tie the register to your change process so additions arrive with their evidence requirement attached.

Running ISO 27001 alongside your other obligations

Most organisations pursuing ISO 27001 in India are also within scope of the CERT-In Directions and the DPDP Act, and frequently SOC 2 as well. The evidence overlap is substantial: access reviews, logging and retention, incident records, supplier assessments and continuity testing serve all of them.

Build each control once and evidence it once, then map the same artefact to every framework that requires it. Organisations that run separate programmes produce the same evidence two or three times and still have gaps, because effort goes into duplication rather than coverage.

Where the frameworks genuinely differ is reporting and retention specifics. Keep the controls unified and the reporting paths separate.