How to Automate ISO 27001 Evidence Collection in 2026

ISO 27001 certification audits demand rigorous evidence for all applicable Annex A controls defined in your Statement of Applicability (SoA). While traditional GRC tools automate policy management, they often leave application-level control evidence—like access control screenshots, change management workflows, and configuration settings—to manual collection. Automating ISO 27001 evidence collection ensures your ISMS documentation is audit-ready, consistently formatted, and sufficient for Stage 2 certification.

What Evidence Do ISO 27001 Auditors Actually Require?

Answer: ISO 27001 auditors require three distinct types of evidence to verify your Information Security Management System (ISMS): documentation (policies and procedures), records (logs, tickets, and meeting minutes), and observations (screenshots and walkthroughs).

For Annex A controls specifically, auditors look for "implementation evidence." It is not enough to have an Access Control Policy (A.5.15); you must prove it is operational. This requires screenshots of user access lists, logs of access reviews, and visual proof of restricted areas within your applications and infrastructure.

How Do You Automate ISO 27001 Annex A Control Evidence?

To fully automate your ISO 27001 Annex A evidence, you need a workflow that captures both the state of your systems and the processes used to manage them.

Step 1: Define Your Scope (SoA)

Ensure your Statement of Applicability (SoA) is finalized. Map each applicable control to a specific evidence source (e.g., "A.5.15 evidence comes from the Admin Panel User Settings page").

Step 2: Deploy AI Evidence Agents

Use an automation tool like Screenata to record the workflows for controls that APIs miss.

Scenario: Proving A.8.9 (Configuration Management).
Action: The AI agent logs into your application, navigates to the settings page, and captures a timestamped screenshot of the configuration.
Result: The screenshot is hashed, timestamped, and converted into a PDF.

Step 3: Schedule Recurring Collections

ISO 27001 requires evidence of ongoing compliance, not just a one-time snapshot. Set your automation tool to run these checks monthly or quarterly to build a history of compliance for the surveillance audit.

Step 4: Map to Your ISMS

Upload the generated evidence packs to your GRC platform or internal ISMS repository, tagged with the specific ISO control ID (e.g., "Evidence_A.8.9_Q1_2026.pdf").

Where Traditional ISO 27001 Automation Stops

Most organizations use GRC platforms like Vanta, Drata, or Secureframe to manage their ISMS. These tools are excellent for:

Hosting policy documents.
Tracking employee training completion.
Monitoring infrastructure via API (e.g., "Is MFA enabled in Google Workspace?").

The Gap: GRC tools cannot "see" inside your custom applications or SaaS tools that lack robust APIs. They cannot verify:

That a specific user role in your internal admin panel cannot delete data.
That a manual change management ticket in Jira was actually reviewed before merging.
That a backup restoration test was successfully performed and validated.

This "Last Mile" of evidence—often 20-30% of the audit—is usually collected manually via screenshots, which is time-consuming and prone to error. This is where automated evidence capture becomes essential.

What Specific Annex A Controls Can Be Automated?

The ISO 27001:2022 standard reorganizes controls into four themes. Below is a checklist of common controls that require visual or screenshot-based evidence.

1. Organizational Controls (Theme A.5)

Controls related to policies, roles, and cloud services.

Control ID	Requirement	Required Evidence (Artifacts)	Automation Method
A.5.15	Access Control	Screenshots of role-based access configurations (RBAC) and "Access Denied" errors for unauthorized users.	Screenata / Workflow Recorder
A.5.23	Cloud Services	Screenshots of cloud provider dashboards showing security configurations (e.g., AWS Security Hub, Azure Policy).	API + Console Screenshot
A.5.12	Classification of Info	Screenshots of data labeling in tools (e.g., "Confidential" tags in Jira or Google Drive).	Console Screenshot

2. People Controls (Theme A.6)

Controls related to human resources and screening.

Control ID	Requirement	Required Evidence (Artifacts)	Automation Method
A.6.2	Terms of Employment	Screenshot of HR system showing signed confidentiality agreements (redacted).	Workflow Recorder
A.6.4	Screening	Evidence of completed background checks (tickets or redacted reports) linked to user accounts.	Workflow Recorder
A.6.8	Reporting Events	Screenshots of the incident reporting interface (e.g., Jira Service Desk) showing ease of access.	Console Screenshot

3. Physical Controls (Theme A.7)

Controls related to secure areas and equipment.

Control ID	Requirement	Required Evidence (Artifacts)	Automation Method
A.7.2	Physical Entry	Logs of badge access (if digital) or screenshots of visitor management system dashboards.	Log Export / Screenshot
A.7.10	Storage Media	Screenshots of encryption settings on laptops (BitLocker/FileVault) and USB control policies.	MDM API / Screenshot

4. Technological Controls (Theme A.8)

Controls related to IT systems, networks, and secure coding.

Control ID	Requirement	Required Evidence (Artifacts)	Automation Method
A.8.9	Configuration Mgmt	Screenshots of "Golden Image" settings or configuration baselines in CI/CD pipelines.	API + Screenshot
A.8.24	Cryptography	Screenshots of TLS/SSL certificate configurations and database encryption settings.	API Monitor
A.8.25	Secure Dev Lifecycle	Screenshots of pull request approvals, SAST scan results, and branch protection rules.	API + Workflow Recorder
A.8.12	Data Leakage	Screenshots of DLP tool configurations blocking sensitive data transfer.	Console Screenshot

Example: Documenting Access Control (A.5.15)

Control Objective: To ensure that access to information and other associated assets is limited in accordance with access control policies.

Manual Evidence Collection:

Admin logs into the system.
Navigates to "User Management."
Takes a screenshot of the user list.
Takes a screenshot of a specific role's permission set.
Pastes images into a Word doc, adds a date, and saves as PDF.

Automated Evidence Collection:

Trigger: Scheduled task runs "A.5.15 Access Review."
Execution: Screenata records the browser session, capturing the user list and the permissions modal for the "Viewer" role. It also attempts a restricted action (like "Delete User") to capture the error message (Negative Testing).
Output: A structured PDF containing:
- Control ID: A.5.15
- Timestamp: 2026-01-05 14:00:00 UTC
- Evidence: High-res screenshots of the user list and the "Access Denied" toast notification.
- Tester: System Automation (Verified).

What's the Difference Between ISO 27001:2022 and ISO 27001:2013 Evidence?

If you are transitioning from the 2013 standard to the 2022 version, your evidence requirements have shifted slightly.

Feature	ISO 27001:2013	ISO 27001:2022
Control Count	114 Controls (14 Domains)	93 Controls (4 Themes)
New Controls	N/A	11 New Controls (e.g., Cloud Services, Threat Intel)
Evidence Focus	Implementation	Implementation + Effectiveness
Attributes	N/A	Controls have attributes (Preventative, Detective, Corrective)

Impact on Automation: The 2022 standard emphasizes Cyber Threat Intelligence (A.5.7) and Information Security for Cloud Services (A.5.23). These require dynamic evidence—screenshots of threat feeds and cloud dashboards—rather than static policy documents.

Frequently Asked Questions

What is the difference between Stage 1 and Stage 2 audits?

Stage 1 is a "documentation review." The auditor checks your ISMS policies, SoA, and risk assessment methodology. Stage 2 is the "certification audit," where they check evidence. They will ask, "Show me proof that you actually performed the backup restoration test defined in your policy." Automation is critical for Stage 2.

Can I use SOC 2 evidence for ISO 27001?

Yes, there is significant overlap. For example, SOC 2 control CC6.1 (Logical Access) is nearly identical to ISO 27001 A.5.15 (Access Control). Automated evidence collected for one can often be mapped to the other, provided the control objectives match.

Does automated evidence satisfy "Observation" requirements?

Yes. Auditors accept screen recordings and timestamped screenshots as "observation" evidence, especially for remote audits. It proves the system state existed at that specific time without requiring a live demo during the audit interview.

Key Takeaways

✅ ISO 27001 Annex A requires visual evidence (screenshots) for controls like access management, configuration, and secure development.
✅ Stage 2 Audits focus on implementation evidence, not just policies.
✅ GRC Tools cover policy and API-based evidence but miss application-level workflows.
✅ Automation Tools like Screenata capture the "Last Mile" of evidence—screenshots and negative tests—essential for A.5.15, A.8.9, and A.5.23.
✅ Consistency is key; automated evidence ensures every screenshot has the correct timestamp, URL context, and tester metadata.

Related ISO 27001 Guides

Explore our detailed guides on specific ISO 27001 certification topics:

ISO 27001 Statement of Applicability (SoA) Evidence Guide — Complete guide to documenting your SoA with automated evidence
ISO 27001:2022 vs 2013: Evidence Requirements — How to automate evidence for the new 2022 standard requirements
ISO 27001 Risk Assessment Evidence — Automate your risk assessment documentation
ISO 27001 A.7 Physical Controls Evidence — Evidence best practices for physical security controls
ISO 27001 Incident Response Evidence — Automate incident management evidence collection
ISO 27001 Supplier Security Evidence (A.5.19-A.5.23) — Third-party and cloud service evidence automation
ISO 27001 Annex A Control Evidence — Comprehensive guide to automating Annex A evidence