A.8.34 ISO 27001

ISO 27001 A.8.34: Protection of information systems during audit testing

What This Control Requires

Audit tests and other assurance activities involving assessment of operational systems shall be planned and agreed between the tester and appropriate management.

In Plain Language

Penetration tests and vulnerability scans against production systems are essential - but they can also bring production down if handled carelessly. An aggressive scan during peak hours, a pen tester who accidentally trips a denial-of-service condition, or a config audit that locks out a service account can all cause real business disruption.

This control is about making sure audit and security testing activities on operational systems are properly planned, authorised, and coordinated. Everyone involved needs to know what is happening, when, and what the boundaries are.

Just as importantly, the results of these tests need protection. A penetration test report is essentially a roadmap for attacking your systems - it must be treated as confidential and restricted to authorised personnel only.

How to Implement

Set up a process for planning and authorising all audit and security testing on production systems. Nothing runs against production without formal sign-off from the system owner or appropriate management.

Create a formal test plan or rules of engagement document for each engagement. It should cover: scope (which systems, networks, and applications are in play), timing and duration (agreed windows for invasive tests), permitted methods and restrictions, escalation contacts if something goes wrong, data handling requirements for results, expected deliverables, and who owns remediation of findings.

Minimise risk during testing. Schedule invasive tests like penetration testing and vulnerability scanning during low-traffic periods. Notify system owners and operations teams before testing starts. Set up real-time communication between testers and ops so issues can be caught immediately. Have rollback and recovery procedures ready.

Protect the results. Security test reports contain detailed vulnerability information that would be gold for an attacker. Classify them as confidential. Restrict access to authorised personnel. Transmit results over secure channels. Define retention periods and delete reports when they are no longer needed.

Apply specific controls by test type. For vulnerability scanning: schedule during agreed windows, tell the SOC so they do not mistake it for an actual attack, use authenticated scanning with appropriate credentials, and avoid destructive scan types on production. For penetration testing: define clear scope boundaries, get written authorisation (the formal "permission to test" letter), establish stop conditions, and monitor for unintended impacts throughout.

After testing, run a post-test review. Confirm all activities stayed within agreed scope. Verify no unintended damage occurred. Walk through findings with system owners. Agree on remediation priorities and timelines. Clean up every test artefact - temporary accounts, tools, data - from production systems.

Evidence Your Auditor Will Request

Test planning and authorization documentation
Rules of engagement for penetration testing
Communication records showing notification to operations teams
Test result classification and access control records
Post-test review records confirming cleanup and no unintended impacts

Common Mistakes

Security testing is conducted on production without formal authorization
Operations teams are not notified before testing begins causing confusion with real incidents
Test results containing vulnerability details are not classified and protected
Penetration testing scope is not clearly defined leading to unintended impacts
Test artifacts such as temporary accounts and tools are not cleaned up after testing

Related Controls Across Frameworks

Framework	Control ID	Relationship
SOC 2	CC4.1	Partial overlap
SOC 2	CC7.1	Partial overlap

Frequently Asked Questions

Should penetration testing be done on production or test environments?

Ideally both, for different reasons. Production gives the most realistic results but carries more risk. A production-equivalent staging environment is safer but may miss production-specific configurations and data. The best approach is to do initial testing on staging, then run targeted validation on production with proper controls in place. For production testing, always have written authorisation and a clear communication plan with your ops team.

How should we handle findings from audit testing?

Classify reports as confidential and lock down access. Share findings with system owners and the technical teams responsible for remediation. Prioritise fixes based on severity and real-world risk. Track remediation through your vulnerability or risk management process and verify fixes through re-testing. Report aggregate findings and progress to management. Keep reports for the defined retention period, then securely delete them.

Track ISO 27001 compliance in one place

AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.

Start Free Assessment