What a real ISO 27001 evidence map looks like

Most organisations preparing for ISO 27001 Stage 2 know they need evidence. Fewer have a clear picture of which evidence maps to which control, where that evidence currently lives, and what the gap looks like when it is missing. An evidence map fixes that. It is the document that turns a generalised sense of readiness into an auditable position.

This post explains what an evidence map is, why it matters, and shows a worked example of what one looks like in practice.

What an evidence map is

An evidence map is a structured document - usually a spreadsheet or a table - that lists every control in scope from your Statement of Applicability, and for each one records:

• The expected artefact or artefacts that demonstrate the control is operating.
• Where that artefact actually lives (which system, folder, or record).
• The current status: does the evidence exist, is it current, and is it in good enough shape to present to an auditor.

It is not a policy document. It is not a risk register. It is the translation layer between your SoA and your audit evidence folder, and it is the tool that lets you answer "do we have evidence for this control" without spending three days searching.

Why teams skip it - and why that costs them

The most common reason evidence maps do not exist is that teams assume the work of implementing controls and the work of evidencing them are the same thing. They are not.

A team can have a functioning change management process and still fail to produce the pull request approval records that demonstrate it. A team can run genuine access reviews and still have nothing to show an auditor because the reviews happened in a Slack thread with no output document. Implementation and evidencing are separate activities that both require deliberate attention.

Without an evidence map, audit preparation becomes an emergency. Someone is handed a list of controls three weeks before Stage 2 and asked to find proof that each one is operating. The resulting frantic search surfaces gaps that could have been addressed months earlier, and sometimes surfaces gaps that cannot be addressed in time.

The structure of a useful evidence map

A workable evidence map does not need to be elaborate. The essential columns are:

• Control reference - the Annex A number or ISO 27001:2022 clause.
• Control area - a plain-language label for what the control covers.
• Expected evidence - specifically what artefact or record demonstrates this control is operating. Not "we have a policy" but "signed Acceptable Use Policy with version date, staff signature log, and evidence of annual review."
• Common gap - the most frequent reason this evidence is absent or insufficient. This column is particularly useful during gap review because it lets the team self-assess before an external review.
• Where it lives - the specific location: a named folder in SharePoint, a Confluence page title, a Jira project, a system-generated log location.
• Status - current, needs update, missing.

Worked example: a partial evidence map

The table below shows six control areas with this structure applied. This is illustrative of what an evidence map entry looks like in a real programme.

Control ref	Control area	Expected evidence	Common gap	Where it lives
5.9	Asset inventory	Spreadsheet or CMDB export listing all information assets with owner, classification and review date	Assets added but never reviewed; shadow IT assets absent; review date column empty	IT asset register in SharePoint - Assets folder
5.15 / 8.2	Access control	Role matrix, joiners/movers/leavers procedure, access provisioning tickets with approval	No approval trail; generic accounts not covered; no evidence of leavers actioned within stated SLA	Jira - Access requests project; HR system leaver export
6.1.3	Statement of Applicability	Current SoA signed by management, with applicability decisions and justifications for each control	SoA version is from gap assessment, not updated post-risk treatment; unsigned	ISMS folder - Governance subfolder
8.8	Vulnerability management	Scan results from the last cycle, evidence of triage decisions, remediation tickets with closure dates	Scans run but results never reviewed formally; no record of who triaged findings	Qualys/Tenable export folder; Jira - Security project
8.13	Backup and restore	Backup schedule and policy, recent backup completion logs, restore test records with RTO/RPO comparison	Backup logs exist but restore tests undocumented; no comparison to stated RTO	AWS Backup console logs; restore test record in ISMS - Operations folder
8.24	Cryptography	Cryptography policy, key management procedure, evidence of approved cipher configurations	Policy exists but no evidence it is being followed; key rotation undocumented	ISMS - Technical controls folder; key management runbook

Each row is a decision-ready piece of information. A programme manager can look at this table, see the status column, and know exactly where to focus remediation effort before Stage 2.

How to build one

Building an evidence map is a two-step process: first, define what you expect; second, verify what you have.

For the first step, work through your SoA control by control. For each control marked as applicable, write down in concrete terms what an auditor would need to see to be satisfied. This forces specificity. "We have a process" is not an evidence type. "Monthly export of user accounts with access levels, cross-referenced against HR active employee list, signed off by the IT manager" is.

For the second step, go and find the actual artefact. If it exists, record where it lives. If it is out of date, note what needs to happen to bring it current. If it does not exist, mark it as a gap.

The gaps column is the output your programme needs most. A complete map with honest status entries is the most useful pre-audit document you can have.

Keeping it current

An evidence map built once and never updated has limited value. Build in a review cycle that tracks your internal audit schedule. If your ISMS internal audit runs every six months, the evidence map should be refreshed in the month before, so the internal audit findings can be reconciled against it.

Where new controls are introduced - through system changes, new suppliers, or changes to the SoA - update the map at the same time. A map that is six months stale on a control area will send your audit preparation in the wrong direction.

Where Kellwick fits

Building an evidence map from scratch, or reviewing whether an existing one is complete, is a core part of pre-certification advisory work. Kellwick, an independent advisory practice, works independently of any certification body, which means the review is focused entirely on your readiness, not on any commercial outcome. See what the evidence pack service includes to understand how a structured evidence map is built for your specific SoA.