Annex A 5.28: Collection of Evidence

Most ISO 27001 programs fail audits for a simple reason: controls exist on paper, but teams cannot prove they ran, when they ran, who approved them, and what the result was. Annex A 5.28 targets that gap by pushing you to treat evidence as an operational output of the ISMS, not an afterthought.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to standardize evidence collection the same way you standardize policies: one system of record, clear ownership, and a repeatable cadence tied to each control’s operating rhythm. Evidence should be easy to locate, hard to tamper with, and mapped to the control statement and scope. Your goal is “audit-ready by design” so internal audits, certification audits, and customer due diligence requests do not trigger disruptive data hunts.

This page gives requirement-level implementation guidance you can hand to control owners tomorrow: a step-by-step build, the artifacts you must retain, common auditor questions, and a practical execution plan. Source references include the ISO/IEC 27001 overview and a public Annex A control index summary. ¹

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.28 implementation expectation (Collection of Evidence).” ¹

Operator interpretation: You are expected to systematically collect and retain evidence that demonstrates Annex A controls are implemented and operating. That means:

• Evidence requirements are defined (what to capture, from where, and by whom).
• Evidence is collected consistently (not ad hoc, not only during audit season).
• Evidence is protected and retrievable (integrity, access control, and organization).

This control is tightly coupled to auditability: if you cannot produce credible evidence, your controls may be treated as “not implemented” during assessment even if teams believe they do the work.

Plain-English interpretation (what this really requires)

Annex A 5.28 is a proof discipline. For each control you say you operate, you need:

1. A claim (the control description and how it applies in scope).
2. A repeatable activity (the process or technical mechanism that runs).
3. A record (evidence) that the activity happened and what it produced.
4. A trail that links the record back to the control, time period, system, and owner.

Evidence can be automated (system logs, configuration snapshots, tickets) or manual (sign-offs, meeting minutes). Auditors usually trust system-generated evidence with strong integrity controls more than screenshots and email threads, but you’ll often need a mix.

Who it applies to

Entity types: Any organization operating an ISO 27001 ISMS, including service organizations providing services to customers that request ISO-aligned assurance. ²

Operational contexts where 5.28 becomes high-friction:

• Fast-changing cloud environments (evidence needs automation and timestamps).
• Distributed ownership (IT, Security, Engineering, HR, Legal all produce evidence).
• Heavy third-party reliance (you need to store third-party assurance artifacts and map them to your controls).
• Small compliance teams (collection must be built into workflows or it collapses).

What you actually need to do (step-by-step)

Step 1: Create an Evidence Collection Standard (one page, enforceable)

Write a short internal standard that answers:

• What qualifies as acceptable evidence (system record preferred, screenshots limited, ticket history required, etc.).
• Minimum metadata fields (control ID, control name, owner, period covered, system of record, date collected, reviewer).
• Storage requirements (central repository, access controls, retention, naming convention).
• Review expectations (who checks completeness and quality).

Keep it short so control owners follow it.

Step 2: Build an Evidence Register mapped to Annex A

Create a register (spreadsheet, GRC tool, or Daydream) with one row per control operation. Minimum fields:

• Annex A control reference (5.28 plus the control being evidenced)
• Control statement and scope note
• Evidence description (what artifact proves operation)
• Source system (IdP, ticketing, CI/CD, endpoint manager, HRIS, SIEM, cloud account)
• Collection method (API export, report, scheduled job, manual upload)
• Owner (role + name)
• Frequency (aligned to the control activity)
• Quality checks (what makes it “pass”)
• Retention location (link)

Practical tip: separate control design evidence (policy, procedure, configuration baselines) from operating evidence (monthly access reviews, change tickets, incident postmortems).

Step 3: Define “evidence acceptance criteria” per artifact

Auditors reject evidence that is incomplete or ambiguous. For each artifact type, define acceptance criteria, for example:

• Access review: shows population, reviewer, date, actions taken, completion status.
• Backup test: shows restore attempt, system/app scope, result, and approver.
• Vulnerability management: shows scan date, scope, findings, remediation tickets, closure evidence.

If you do not define criteria, teams will upload screenshots that don’t prove anything.

Step 4: Engineer evidence collection into operations

Tie evidence to the tools people already use:

• Ticketing: require change tickets include approvals and links to testing results.
• IAM: schedule exports of group membership and admin role assignments.
• Endpoint management: scheduled compliance reports.
• Cloud: configuration snapshots and policy change logs.

Where possible, make evidence creation the default output of the process (reports, exports, immutable logs). This is the difference between “audit-ready” and “audit scramble.”

Step 5: Establish a monthly evidence close (lightweight)

Run a recurring “evidence close” meeting or async workflow:

• Owners confirm required evidence for the period is uploaded.
• GRC reviews for completeness, naming, and traceability.
• Exceptions are logged with a due date and remediation plan.

A consistent close prevents end-of-year backfilling, which auditors often flag as unreliable.

Step 6: Control the evidence repository like a compliance system

Evidence needs basic security controls:

• Access control (least privilege; audit reviewers get read-only).
• Versioning and immutability where feasible.
• Clear folder structure by control and period.
• Documented retention and disposal rules.

Daydream (or any capable GRC workflow) becomes valuable here because it can map each Annex A control to recurring evidence tasks, reminders, and an audit-ready evidence room without relying on tribal knowledge.

Required evidence and artifacts to retain

Use this as your baseline checklist. Adjust to your scope and Statement of Applicability.

Program-level artifacts

• Evidence Collection Standard / procedure
• Evidence Register (mapped to Annex A controls)
• Roles and responsibilities (RACI for evidence owners and reviewers)

Operating evidence (examples)

• Access control: access reviews, privileged access changes, joiner/mover/leaver tickets
• Change management: change tickets, approvals, test results, rollback notes
• Incident management: incident tickets, timelines, root cause, post-incident actions
• Vulnerability management: scan reports, exception approvals, remediation tracking
• Training and awareness: completion reports, content/version, new-hire onboarding proof
• Third-party: due diligence artifacts, contracts, security addenda, ongoing monitoring outputs

Integrity and traceability artifacts

• Audit log exports (where applicable)
• Repository access logs (who accessed or modified evidence)
• Evidence index/export (to hand auditors quickly)

Common exam/audit questions and hangups

Auditors and customer assessors tend to probe the same fault lines:

1. “Show me evidence for this control for the full period in scope.”
   Hangup: you have one good example, not continuous operation.

2. “How do you know this evidence wasn’t modified?”
   Hangup: screenshots in shared drives with broad edit rights.

3. “Who reviews evidence for quality and completeness?”
   Hangup: collection exists, but there is no verification step.

4. “How do you ensure evidence aligns to the Statement of Applicability?”
   Hangup: evidence collected for out-of-scope systems while in-scope systems are missed.

5. “Can you reproduce the report?”
   Hangup: manual exports with no query parameters saved, no runbook.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Evidence = screenshots	Low integrity, low context	Prefer system exports, tickets, immutable logs; document acceptance criteria
Backfilling right before audit	Creates gaps and credibility issues	Monthly evidence close; automate recurring pulls
No linkage to scope	Evidence doesn’t prove control in-scope	Add scope tag per artifact (system, BU, environment)
Over-collecting	Noise hides missing critical items	Evidence register with “minimum viable evidence” per control
Unowned evidence tasks	Nobody feels accountable	Assign named owners; add escalation path
Storage sprawl	Evidence exists but can’t be retrieved	Central evidence repository with consistent structure and access controls

Enforcement context and risk implications

ISO 27001 is a certifiable standard, not a regulator, so “enforcement” typically shows up as:

• Certification risk: audit findings for insufficient evidence can drive nonconformities or delayed certification.
• Customer assurance risk: security questionnaires, renewals, and incident inquiries often demand proof of control operation.
• Operational risk: weak evidence usually correlates with weak control execution, because nobody is verifying the work.

Treat 5.28 as a control that protects your ability to make credible security claims.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Appoint an evidence owner in GRC and identify control owners.
• Publish the Evidence Collection Standard (short, enforceable).
• Draft the Evidence Register for your in-scope controls.
• Stand up a central evidence repository with access control and naming conventions.
• Pilot evidence capture for a small set of high-demand controls (access, change, incidents).

Days 31–60 (Operationalize and reduce manual work)

• Expand the register to cover remaining in-scope controls.
• Define acceptance criteria for each recurring artifact.
• Automate exports where feasible (IAM, ticketing, endpoint, cloud configs).
• Start a monthly evidence close workflow with exception tracking.

Days 61–90 (Audit-readiness hardening)

• Perform an internal spot-check: pick a control and request evidence across the full period.
• Fix traceability gaps (missing timestamps, unclear scope, weak reviewer evidence).
• Add repository governance: versioning, review permissions, retention rules.
• If you use Daydream, configure recurring evidence tasks, ownership, and auditor-ready evidence views so evidence is continuously collected and mapped to Annex A.

Frequently Asked Questions

What counts as “evidence” for Annex A 5.28?

Evidence is any reliable record that a control is implemented and operated for the period in scope, such as system reports, logs, tickets, approvals, and review sign-offs. The best evidence is specific, time-bound, and traceable back to the control and system in scope.

Are screenshots acceptable evidence?

Sometimes, but auditors often treat screenshots as weaker because they lack integrity and context. If you must use screenshots, pair them with system-generated exports, ticket references, and a short note that states what the screenshot proves and when it was captured.

How do we set evidence frequency if ISO doesn’t specify it?

Match the evidence cadence to how the control operates and how quickly risk changes. Document the rationale in your evidence register so an auditor sees a deliberate schedule rather than guesswork.

Who should own evidence collection: Compliance or control owners?

Control owners should produce evidence as part of doing the work; GRC should define standards, monitor completion, and perform quality checks. If GRC becomes the evidence “doer,” collection breaks during vacations and reorganizations.

How long should we retain evidence?

ISO 27001 does not give a single universal retention period in the excerpt provided. Set retention based on audit cycles, contractual needs, and internal policy, then apply it consistently and document it in your evidence standard.

How does Daydream help with Annex a 5.28: collection of evidence requirement?

Daydream can map Annex A controls to recurring evidence tasks, assign owners, track completion, and centralize artifacts with review notes. That reduces manual chasing and gives you a clean audit trail that ties each artifact to the control and time period.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview