Auditing ISO 27001 Annex A.8.34 validates that information systems are protected during audit testing to prevent operational disruption or data compromise. The audit confirms the Primary Implementation Requirement that testing activities are planned, authorized, and monitored to minimize risk. The Business Benefit is the assurance that security assessments do not inadvertently cause downtime or data breaches.

Use this pass/fail checklist to strictly validate compliance with ISO 27001 Annex A 8.34 (Protection of information systems during audit testing). For a detailed methodology on how to conduct the interviews and system tests required to generate this evidence, refer to our Annex A 8.34 Audit Guide.

1. Audit Testing Plan & Scope Formally Defined

Verification Criteria: A documented plan exists for every technical audit (e.g., Pentest, Vulnerability Scan) explicitly defining the scope, timing, and systems involved.
Required Evidence: The “Audit Plan” or “Rules of Engagement” (RoE) document signed by both the Auditor and the System Owner.

Pass/Fail Test: If a vulnerability scan was launched against the production network without a pre-agreed scope document defining the boundaries, mark as Non-Compliant.

2. Operational Impact Risk Assessment Verified

Verification Criteria: Before testing begins, an assessment is conducted to determine if the audit activities could disrupt business operations or system availability.
Required Evidence: A “Pre-Audit Risk Assessment” or email thread confirming that performance impacts (e.g., latency from scanning) were considered.

Pass/Fail Test: If heavy load testing was scheduled during peak business hours (e.g., Black Friday sales) without a risk acceptance sign-off, mark as Non-Compliant.

3. Read-Only Access Restrictions Enforced

Verification Criteria: Auditors are granted “Read-Only” access by default; write/edit permissions are strictly prohibited unless specifically required for the test (e.g., exploiting a vulnerability).
Required Evidence: Access Control Lists (ACLs) or Role assignments showing the Auditor account belongs to a “View Only” or “Auditor” group.

Pass/Fail Test: If the external auditor was given “Domain Admin” or “Super User” rights just to make access easier to provision, mark as Non-Compliant.

4. Audit Activity Logging Verified

Verification Criteria: All activities performed by the auditor/tester are logged and monitored to ensure they stay within the agreed scope.
Required Evidence: System logs (SIEM or Application Logs) identifying the specific IP address or User ID of the auditor during the testing window.

Pass/Fail Test: If the auditor performed a test but there is no log record of their actions (i.e., they were effectively invisible), mark as Non-Compliant.

5. Audit Timing & Scheduling Minimised Disruption

Verification Criteria: Technical audit activities are scheduled outside of peak operational hours to minimise impact on availability.
Required Evidence: The “Audit Schedule” compared against system performance graphs (CPU/Latency) showing testing occurred during maintenance windows.

Pass/Fail Test: If an automated scan ran at 10:00 AM on a Monday and caused the Customer Portal to slow down, mark as Non-Compliant.

6. Third-Party Rules of Engagement (RoE) Validated

Verification Criteria: External testers (pentesters) have signed a legal agreement indemnifying the organisation and strictly defining “Out of Scope” targets to prevent damage.
Required Evidence: A signed “Rules of Engagement” document or Statement of Work (SoW) with specific “Do Not Touch” clauses.

Pass/Fail Test: If an external pentester brings down a legacy server because it wasn’t listed as “Fragile/Out of Scope” in the agreement, mark as Non-Compliant.

7. Vulnerability Scanning Configuration Verified

Verification Criteria: Automated scanning tools are configured to “Safe Mode” or “Non-Destructive” mode to prevent accidental denial of service (DoS).
Required Evidence: Configuration screenshots of the scanning tool (e.g., Nessus, Qualys) showing “Safe Checks” enabled.

Pass/Fail Test: If the scanner was configured to use “Aggressive” flooding techniques against a production firewall without specific authorization, mark as Non-Compliant.

8. Availability Monitoring During Testing Confirmed

Verification Criteria: The operations team actively monitors system health during the audit execution to immediately detect and respond to disruptions.
Required Evidence: Incident Response logs or Monitoring Dashboard snapshots taken during the audit window.

Pass/Fail Test: If the system crashed during the audit and IT only noticed because users complained (no proactive monitoring), mark as Non-Compliant.

9. Data Copying & Extraction Controls Verified

Verification Criteria: Auditors are prohibited from copying live data (e.g., exporting customer DBs) to their own laptops unless strictly authorised and encrypted.
Required Evidence: DLP logs or a signed “Data Destruction Certificate” from the auditor confirming no data was retained.

Pass/Fail Test: If an auditor took a screenshot of a production database containing unmasked PII and included it in an unencrypted report, mark as Non-Compliant.

10. Access Revocation Post-Audit Verified

Verification Criteria: All access accounts and firewall rules created for the audit are effectively disabled immediately upon completion of testing.
Required Evidence: Ticket closure logs showing “Account Disabled” or “Firewall Rule Reverted” timestamped within 24 hours of audit completion.

Pass/Fail Test: If the “Auditor_Temp” account is still active 3 months after the audit report was delivered, mark as Non-Compliant.

**ISO 27001 Annex A 8.34 SaaS / GRC Platform Failure Checklist**
Control Requirement	The “Checkbox Compliance” Trap	The Reality Check
Read-Only Roles	Tool has a generic “Auditor” role.	Auditor must verify Export permissions. Often, “Read-Only” users can still click “Export to CSV” on the customer list. If they can extract bulk data, the control fails.
Pentest Authorization	“We run pentests on our SaaS instance.”	Auditor must check for Vendor Permission. Scanning Salesforce or AWS without prior authorization (if required) violates the Terms of Service. Check the “Permission to Test” email.
Audit Trail Integrity	Auditor logs in as “admin” to save licenses.	Auditor must check Attribution. If the logs show “System Admin” performed the check, you cannot prove who did it. Auditors must have unique IDs.
Availability Impact	Tool claims “Zero Downtime Audit.”	Auditor must check API Limits. Did the audit tool’s aggressive scanning hit the SaaS API rate limit, locking out real users? Check the API consumption logs.
Automated Scans	Scheduled scans run “weekly.”	Auditor must check the Schedule Time. If the weekly scan runs at 9:00 AM on Monday (peak login time) causing latency, it violates Annex A 8.34.
Snapshot Access	Auditor granted access to “Backups” for review.	Auditor must check Encryption Keys. If giving access to backups gives the auditor access to all historical data unencrypted, it is an excessive scope breach.

About the author

Stuart Barker

ISO 27001 Ninja

Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, he combines academic rigor with extensive operational experience, including a decade leading Data Governance for General Electric (GE).

As a qualified ISO 27001 Lead Auditor, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. His toolkits represent an auditor-verified methodology designed to minimise operational friction while guaranteeing compliance.