ISO 27001 Statement of Applicability (SoA): Complete Evidence Guide

ISO 27001 certification hinges on your Statement of Applicability (SoA)—the document defining which Annex A controls apply to your organization. However, simply listing controls is not enough; auditors demand concrete evidence that these controls are operational. While policies can be drafted once, implementation evidence—such as access logs, configuration screenshots, and change management tickets—must be collected continuously. Automating ISO 27001 evidence collection ensures your ISMS documentation is audit-ready and eliminates the manual scramble before Stage 2 audits.

What Is ISO 27001 Statement of Applicability (SoA) Evidence?

Answer: ISO 27001 SoA evidence is the tangible proof that the controls listed in your Statement of Applicability are actually implemented and operating effectively. Unlike policies (which describe what you do), evidence proves that you did it.

For a typical SaaS company, the SoA usually includes 90+ controls from ISO 27001:2022 Annex A. Evidence for these controls falls into three categories:

Documentation: Policies, procedures, and the SoA document itself.
Records: Logs, tickets, meeting minutes, and signed agreements.
Observations (Visual Evidence): Screenshots of system configurations, physical security walkthroughs, and workflow recordings.

The Complete SoA Evidence Checklist (ISO 27001:2022)

The ISO 27001:2022 standard groups controls into four themes. Below is a breakdown of the specific evidence artifacts auditors expect for common controls in your SoA.

1. Organizational Controls (Theme A.5)

Controls related to policies, cloud services, and identity management.

Control ID	Requirement	Required Evidence (Artifacts)	Automation Method
A.5.15	Access Control	Screenshots of role definitions, "Access Denied" errors for unauthorized users, and user access lists.	Screenata / Workflow Recorder
A.5.23	Cloud Services	Screenshots of cloud provider dashboards (AWS/Azure) showing security configurations and shared responsibility matrices.	API + Console Screenshot
A.5.7	Threat Intelligence	Screenshots of threat feeds, newsletters, or automated vulnerability alerts being received and reviewed.	Workflow Recorder
A.5.12	Classification of Info	Visual proof of data labeling (e.g., "Confidential" tags in Jira, SharePoint, or email headers).	Console Screenshot

2. People Controls (Theme A.6)

Controls related to HR, onboarding, and training.

Control ID	Requirement	Required Evidence (Artifacts)	Automation Method
A.6.2	Terms of Employment	Sample of signed employment contracts containing confidentiality clauses (redacted).	HRIS API / Workflow
A.6.4	Screening	Tickets or reports confirming background checks were completed prior to access provisioning.	Workflow Recorder
A.6.8	Reporting Events	Screenshots of the internal ticketing system used to report security incidents (e.g., Jira Service Management).	Console Screenshot

3. Physical Controls (Theme A.7)

Controls related to equipment and secure areas.

Control ID	Requirement	Required Evidence (Artifacts)	Automation Method
A.7.10	Storage Media	Screenshots of MDM dashboards showing BitLocker/FileVault encryption status across fleet devices.	API Monitor
A.7.12	Clear Desk/Screen	Photos of clean desks (if physical) or screenshots of auto-lock settings (e.g., "Screen locks after 5 mins").	MDM API / Screenshot

4. Technological Controls (Theme A.8)

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

Control ID	Requirement	Required Evidence (Artifacts)	Automation Method
A.8.9	Configuration Mgmt	Screenshots of "Golden Image" baselines, CI/CD pipeline configs, or drift detection alerts.	API + Screenshot
A.8.25	Secure Dev Lifecycle	Screenshots of branch protection rules, code review approvals, and SAST/DAST scan results.	API + Workflow Recorder
A.8.12	Data Leakage	Screenshots of DLP configurations preventing sensitive data exfiltration (e.g., blocking USBs or personal email).	Console Screenshot
A.8.24	Cryptography	Screenshots of TLS certificate settings, database encryption-at-rest configs, and key management policies.	API Monitor

Where Traditional ISO 27001 Automation Stops

Most organizations rely on Governance, Risk, and Compliance (GRC) platforms like Vanta, Drata, or Secureframe to manage their ISO 27001 journey. While these tools are essential for policy management and high-level monitoring, they have distinct limitations when it comes to deep evidence collection.

The "Observation" Gap: ISO 27001 auditors often require "observation" evidence—seeing a process in action.

GRC Tool Capability: Checks an API to say "MFA is enabled."
Auditor Requirement: "Show me the user experience when MFA fails," or "Show me the configuration screen for your custom internal admin panel that doesn't have an API."

What GRC Tools Miss:

Custom Application Logic: They cannot verify role-based access controls (RBAC) inside your proprietary product.
Workflow Validation: They cannot prove that a manual change request was discussed in a Slack thread before approval.
Negative Testing: They cannot generate a screenshot showing "Access Denied," which is often the strongest proof of effective access control.
Complex Configurations: They often miss granular settings in SaaS tools (e.g., specific repository settings in GitHub beyond basic branch protection).

This 20-30% gap is where teams spend weeks manually taking screenshots. Evidence automation tools like Screenata fill this void by recording the actual workflows and capturing the visual evidence auditors need.

How to Automate SoA Evidence Collection

Automating your SoA evidence involves moving from "periodic sampling" to "continuous verification." Here is the workflow:

Step 1: Map SoA Controls to Evidence Sources

Review your SoA. For every control marked as "Applicable," identify the source of truth.

A.5.15 (Access Control): Source = Okta Dashboard + Internal Admin Panel.
A.8.9 (Config Mgmt): Source = AWS Console + Terraform Cloud.

Step 2: Configure Workflow Recorders

For controls that cannot be monitored via simple API checks (the "Gap" controls), set up an AI workflow recorder.

Action: Train the agent to log into the Internal Admin Panel, navigate to the "User Roles" page, and capture a screenshot.
Frequency: Schedule this to run monthly.

Step 3: Automate Negative Testing

Auditors love negative evidence. Configure the agent to attempt a restricted action using a low-privilege account.

Scenario: A "Viewer" tries to "Delete" a record.
Capture: The agent records the click and the resulting "Permission Denied" toast message.
Result: Definitive proof for A.5.15 and A.8.2.

Step 4: Centralize in ISMS

Automatically upload these generated PDF evidence packs into your GRC platform's evidence library, tagged with the specific ISO control ID. This creates a "perpetual audit-ready" state.

Example: Documenting Secure Development (A.8.25)

Control Objective: Ensure information security is an integral part of the information systems development lifecycle.

Manual Evidence Process:

Developer logs into GitHub.
Finds a recent Pull Request (PR).
Takes a screenshot of the "Review Required" check.
Takes a screenshot of the SAST scan result.
Pastes into a document: "Evidence for A.8.25 - Jan 2026."

Automated Evidence Process:

Trigger: Screenata detects a merged PR to the main branch.
Execution: The system captures the PR interface, highlighting the "Changes Requested" history, the specific reviewer's approval, and the passing status of the security check pipeline.
Output: A PDF report named A.8.25_Secure_Dev_Evidence_[Date].pdf is generated and attached to the control in Drata/Vanta.

Time Saved: ~15 minutes per sample. Audit Value: High (Standardized, tamper-evident, timestamped).

Do Auditors Accept Automated SoA Evidence?

Yes. In fact, many auditors prefer it.

Automated evidence provides better integrity than manual screenshots because:

Chain of Custody: The metadata shows exactly when the evidence was captured and by which system.
Consistency: The formatting is identical every time, making it easier for the auditor to review.
Timeliness: Evidence is collected closer to the actual event, rather than weeks later during "audit prep week."

To ensure acceptance, ensure your automated evidence includes:

Timestamps: Visible system time or server time.
URL/Context: Browser address bar showing the source system.
Identity: Indication of the user account used to view the evidence.

Frequently Asked Questions

What is the difference between the SoA and the Risk Treatment Plan?

The SoA (Statement of Applicability) lists which controls apply to your organization and the justification for inclusion/exclusion. The Risk Treatment Plan (RTP) explains how you will implement those controls to mitigate specific risks. Evidence is required to prove the SoA controls are functioning as described in the RTP.

Can I exclude Annex A controls from my SoA?

Yes, but you must provide a valid justification. For example, if you have no physical offices and are fully remote, you might exclude A.7.4 (Physical security monitoring). However, you still need evidence for the controls you do include.

How often should I collect SoA evidence?

ISO 27001 requires evidence of "continuous improvement" and operation.

Continuous: Cloud configurations (daily/weekly).
Periodic: Access reviews, restoration tests (quarterly).
Event-driven: Onboarding/offboarding, incidents (as they happen). Automating this prevents the "evidence gap" that often leads to non-conformities.

Does ISO 27001:2022 require different evidence than the 2013 version?

The 2022 version merged 114 controls into 93 and added 11 new ones (e.g., Cloud Services, Threat Intel). While the types of evidence (screenshots, logs) remain similar, you need to ensure your evidence maps to the new 4-theme structure and covers the new topics specifically.

Key Takeaways

✅ The SoA is your audit roadmap: If a control is in your SoA, you must have evidence for it.
✅ Evidence types: Auditors need documentation, records (logs), and observations (screenshots).
✅ The Automation Gap: GRC tools handle policy and API checks well but struggle with application-level workflows and negative testing.
✅ Visual Proof: Controls like A.5.15 (Access) and A.8.9 (Config) often require screenshots to prove specific settings or user experiences.
✅ Automation ROI: Automating SoA evidence collection reduces Stage 2 audit preparation time by 75% and eliminates human error.

Learn More About ISO 27001 Certification Evidence Automation

For a comprehensive overview of streamlining your certification journey, see our guide on automating ISO 27001 evidence collection, including detailed strategies for Stage 1 and Stage 2 audit preparation.