Auditing Protection of Information Systems During Audit Testing is the technical verification of safeguards preventing operational disruption during compliance assessments. The Primary Implementation Requirement is the restriction of audit tool access and mandatory read-only configurations, providing the Business Benefit of ensuring continuous service availability while maintaining rigorous security oversight.
ISO 27001 Annex A 8.34 Protection of Information Systems During Audit Testing Audit Checklist
This technical verification tool is designed for lead auditors to establish the security of operational systems during testing activities. Use this checklist to validate compliance with ISO 27001 Annex A 8.34.
1. Audit Testing Scope and Schedule Formalisation Verified
Verification Criteria: Audit tests involving operational systems are formally planned, scoped, and scheduled to minimise the risk of service disruption.
Required Evidence: Approved Audit Plan or Technical Assessment Schedule with defined start/end times and identified target systems.
Pass/Fail Test: If technical audit testing (e.g., vulnerability scanning) is performed on production systems without a pre-approved schedule, mark as Non-Compliant.
2. Audit Tool Access Restriction Confirmed
Verification Criteria: Access to audit tools (e.g., scanners, debuggers, or scripts) is restricted to authorised personnel and removed immediately after the test concludes.
Required Evidence: IAM role reports or temporary account logs showing the revocation of “Audit” or “Scanner” privileges post-test.
Pass/Fail Test: If audit service accounts or specialised scanning tools remain active and accessible on production servers outside of active audit windows, mark as Non-Compliant.
3. Read-Only Access Preference for Audit Testing Validated
Verification Criteria: Technical audit tests are configured for “Read-Only” access wherever possible to prevent accidental modification or corruption of operational data.
Required Evidence: Configuration logs from the audit software or database service account settings showing ‘Read-Only’ or ‘SELECT’ permissions only.
Pass/Fail Test: If an automated audit tool is found running with ‘Write’ or ‘Delete’ permissions on a production database, mark as Non-Compliant.
4. Impact Assessment and Monitoring During Tests Confirmed
Verification Criteria: Operational systems are monitored during audit testing to detect and mitigate performance degradation or service failure in real-time.
Required Evidence: Performance monitoring logs (e.g., CPU/RAM usage) from the time of the audit test showing zero critical resource exhaustion alerts.
Pass/Fail Test: If the organisation cannot provide evidence of monitoring system health while a high-impact audit test (e.g., load testing or aggressive scanning) was in progress, mark as Non-Compliant.
5. Independent Audit Logging of Audit Activities Verified
Verification Criteria: All actions performed by auditors or audit tools are captured in an immutable central log that is segregated from the auditor’s control.
Required Evidence: SIEM logs or Syslog exports showing the activity of the specific IP or User ID assigned to the audit task.
Pass/Fail Test: If an auditor has the technical ability to delete the logs recording their own testing activities on operational systems, mark as Non-Compliant.
6. Secure Disposal of Audit Test Data Validated
Verification Criteria: Any sensitive operational data extracted during the audit (e.g., configuration files or data samples) is securely deleted once the audit report is finalised.
Required Evidence: Certificates of Erasure or documented witness sign-off confirming the destruction of temporary audit data sets.
Pass/Fail Test: If sensitive production data samples from an audit conducted six months ago are still found on an auditor’s unencrypted laptop or a shared drive, mark as Non-Compliant.
7. Production Environment Hardening Integrity Confirmed
Verification Criteria: Security controls (e.g., Firewalls, EDR, IDS) are not disabled or bypassed to “facilitate” the audit unless specifically authorised and risk-accepted.
Required Evidence: Firewall rule-base history or EDR status logs showing zero unauthorised “Exceptions” created for the duration of the audit.
Pass/Fail Test: If a production firewall rule was opened specifically to allow an auditor’s scan and was not closed immediately after the test, mark as Non-Compliant.
8. Recovery and Back-out Plan Availability Verified
Verification Criteria: Procedures exist to restore operational systems to a known-good state if audit testing causes a system failure or data corruption.
Required Evidence: Pre-audit checklist showing a verified “Success” backup status for all target systems within 24 hours of the test start.
Pass/Fail Test: If an aggressive vulnerability scan is performed on a critical production asset that has not had a successful backup in the last 7 days, mark as Non-Compliant.
9. Third-Party Audit Tool Vetting Recorded
Verification Criteria: Any third-party tools used for audit testing are vetted for safety and security to ensure they do not introduce malware or vulnerabilities.
Required Evidence: Approved Software List or Security Assessment report for the specific version of the audit tool used (e.g., Nessus, Burp Suite).
Pass/Fail Test: If an external auditor runs an unverified “open-source script” from a public repository directly against production infrastructure, mark as Non-Compliant.
10. Post-Audit Review of System Integrity Confirmed
Verification Criteria: A technical review is conducted following the audit to ensure that system configurations remain in the desired state and no “backdoors” were left behind.
Required Evidence: Post-audit sign-off form or system integrity scan (e.g., FIM) comparing pre-audit and post-audit configuration hashes.
Pass/Fail Test: If there is no record of a post-test verification to confirm that temporary audit accounts or firewall bypasses were removed, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Audit Scheduling | Tool records “Audit is planned” in a task list. | Verify Operational Notification. Did the NOC/SOC receive the schedule? A task in a GRC tool doesn’t prevent an admin from killing a scan they think is a DDoS. |
| Access Revocation | Platform marks account as “Deleted” in HR records. | Check the Direct Config. GRC tools miss “Service Accounts” created manually on the server by an auditor for local checks. |
| Resource Protection | Tool assumes the scanner is “Safe” because it’s a known brand. | Verify Throttling. An auditor must see the technical configuration that limits scan threads to prevent crashing legacy production hardware. |
| Data Sanitisation | SaaS tool records “Auditor NDA Signed”. | Demand Destruction Proof. An NDA is legal; Annex A 8.34 is technical. Prove the auditor wiped the data from their environment. |
| Read-Only Verification | Tool identifies “Audit Account” role. | Audit the Effective Permissions. Check if that “Audit Role” has ‘sudo’ rights. GRC tools often miss overly permissive inherited rights. |
| Bypass Monitoring | Platform reports “Zero firewall changes”. | Verify Temporary Rules. Check the actual firewall CLI for rules added and deleted between GRC sync intervals. |
| System Restoration | Tool assumes “Backups are always on”. | Verify Pre-Test Integrity. The auditor must see the specific “Restore Point” created immediately before a high-risk technical audit. |
About the author
