A.8.34 Protection of information systems during audit testing

Control objective

This control ensures that assessment activities on operational information systems, such as audits, vulnerability assessments, penetration tests, and technical compliance reviews, are planned in advance and carried out within an agreed scope so they do not cause service disruption, data corruption, or exposure of sensitive information. It requires agreeing the target, timing, method, and access rights with the owner of the system under test, limiting access to read-only where possible, and recording and managing test accounts/tools and access activity during the test. The aim is to minimize the risk that the assessment activity itself undermines operational stability and information protection.

Key checkpoints

Are audit/vulnerability assessment/penetration test activities on operational systems planned in advance, with scope/timing/method/access rights agreed with the system owner?
During testing, is access to operational systems and data limited to the minimum needed for the purpose, and are read-only access or isolated copies used where possible?
Are the privileges granted to temporary test accounts and testing tools limited to the purpose, and are accounts/temporary access rights/tools revoked and removed after the test?
Are access and activity during testing logged and monitored so they can be verified afterward?
Are tests that may affect performance/availability/integrity (load generation, scanning, change-inducing actions) performed under controlled conditions (such as off-peak windows) after impact assessment and approval?
Are data/results/evidence obtained from testing stored securely under access control and disposed of once the retention period has passed?

Implementation guidance

Agree and document in advance the request, scope, schedule, access rights, responsible parties, and emergency contact arrangements for assessment activities on operational systems (internal/external audits, vulnerability assessments, penetration tests, compliance checks).
Use least privilege and read-only access by default, and run write/change tests on isolated copies or test environments where feasible. Where production testing is necessary, obtain explicit system-owner authorization and define scope limits, monitoring, stop criteria, and recovery procedures.
Assign a validity period and usage scope to temporary test accounts and tools, and revoke/delete them immediately after the test so no account or tool remains on operational systems.
Log and monitor access and executed commands during testing (A.8.15, A.8.16), and establish a procedure to immediately halt/roll back on anomalies or incidents.
Perform tests that may affect performance/availability (load tests, large-scale scans, vulnerability exploitation) after impact assessment and approval, during off-peak hours or an agreed testing window.
Keep acquired operational data, results, and evidence to the minimum needed in restricted storage. At retention expiry, check legal holds and necessary investigation preservation; securely delete and record disposal once no basis remains.

Related controls and attributes

Evidence

Audit/test plans and records of scope/schedule/access-rights agreement with the system owner
Temporary test account issuance/privilege grant and post-test revocation/deletion records
Access/activity logs and monitoring records during testing
Impact assessment and approval records for load-inducing/change-inducing tests
List of testing tools and confirmation of tool removal after testing
Test result reports and records of obtained-data storage/disposal

Nonconformity examples

Vulnerability assessment or penetration testing on operational systems is carried out without prior agreement/approval, causing a service outage.
Temporary accounts issued or testing tools installed for a test remain on operational systems because they were not revoked/removed after the test.
Excessive write/change privileges on operational data are granted during testing, resulting in data corruption.
Access and activity during testing are not logged, so what was tested cannot be verified afterward.
A load-inducing test is run during business hours without impact assessment, causing performance degradation or a service outage.
Acquired data/results lack access controls or remain after their retention basis ends, leaving disclosure risk.