The ultimate audit guide to ISO 27001 Annex A 8.34 Protection of information systems during audit testing
Table of contents
- 1. Check for Audit Testing Scope and Schedule Formalisation
- 2. Evidence Audit Tool Access Restriction
- 3. Validate Read-Only Access Preference for Audit Testing
- 4. Look for an Impact Assessment and Monitoring During Tests
- 5. Review Independent Audit Logging of Audit Activities
- 6. Check the Secure Disposal of Audit Test Data
- 7. Confirm Production Environment Hardening Integrity
- 8. Ensure Recovery and Back-out Plan Availability
- 9. Evidence Third-Party Audit Tool Vetting
- 10. Confirm Post-Audit Review of System Integrity
1. Check for Audit Testing Scope and Schedule Formalisation
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. Evidence Audit Tool Access Restriction
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. Validate Read-Only Access Preference for Audit Testing
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.
DO IT YOURSELF
ISO 27001
All the templates, tools, support and knowledge you need to do it yourself.
4. Look for an Impact Assessment and Monitoring During Tests
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. Review Independent Audit Logging of Audit Activities
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. Check the Secure Disposal of Audit Test Data
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. Confirm Production Environment Hardening Integrity
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. Ensure Recovery and Back-out Plan Availability
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. Evidence Third-Party Audit Tool Vetting
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. Confirm Post-Audit Review of System Integrity
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.
About the author
