ISO 27001 A.8.34: Protect systems during audit and assurance tests

What A.8.34 requires in practice

Annex A control A.8.34 states that when an audit test or other assurance activity touches operational systems, it should be planned and agreed in advance between the tester and the right level of management. It protects the systems being examined. The people checking them, whether internal staff, a client or an outside specialist, do not receive unlimited licence to run tools, read any record or alter a live service.

Planning means defining the objective, the systems, the information and the methods involved. Agreement means the appropriate manager understands the planned activity and accepts it. The two together set an authorised boundary that both sides can recognise.

The outputs are a defined scope for each test, recorded approval, consideration of effects on confidentiality, integrity and availability, and arrangements for handling anything unexpected. Where existing evidence or read-only access can answer the question, the more intrusive route is unnecessary. Applicability follows risk treatment and the Statement of Applicability.

Agree what the test must establish

Define the objective, systems, information and methods involved. Identify which observations can be made through existing evidence or read-only access and which proposed activities could affect operation. The scope should be specific enough that the tester and system owner understand the authorised boundary.

Consider the consequences for confidentiality, integrity and availability. A harmless-looking query may expose more information than needed, while an automated assessment can place load on a sensitive service. The appropriate owner should understand the planned activity before authorising access or scheduling the test.

Use proportionate access and controlled equipment

Prefer access that provides the necessary evidence with limited capability to alter the system. Where a direct read-only route cannot answer the question, an appropriately authorised administrator may be able to perform a defined action for the assessor. The method should preserve both assurance and accountability.

Check relevant security requirements for devices or tools used to access the environment. A tester's equipment should not become an unexamined entry point. Connect access with privileged access control and powerful tools with utility-program restrictions.

Why protecting systems during assurance tests matters to the business

Assurance work is meant to reduce risk, yet a careless test can cause the very incident it was meant to prevent. An automated scan can overload a sensitive service, and an innocent query can reveal more information than anyone needed. Agreed scope protects customers, keeps live operations steady and avoids awkward disputes about who authorised what. It also makes the results more trustworthy, since everyone knows what was and was not examined. Managers who agree plans in advance can schedule around busy periods. At audit, planned and approved tests show that assurance is conducted responsibly.

How to implement A.8.34

Make planning and approval a normal part of any assessment of live systems. A sensible approach follows. Treat the plan as a short working agreement, not a long document, so that it is actually used. Involve the system owner early, so that timing and safeguards are realistic and nobody is surprised.

1. Define what each test must establish and which systems and information it will touch.
2. Identify which questions can be answered through existing evidence or read-only access, and which proposed activities could affect operation.
3. Describe the methods and tools to be used and the times they may be used.
4. Agree the plan in writing with the manager responsible for the system.
5. Consider effects on confidentiality, integrity and availability, and set safeguards such as limiting load or access to information.
6. Set out how the tester will stop, report and escalate if something unexpected happens.
7. Limit the tester's access to what the plan permits and remove it afterwards.
8. Keep the plan and results together, and review the process after significant tests.

Illustrative BPO example: an audit request for a complete export

Illustrative manufacturing example: a technical test during production support

A hypothetical manufacturer plans an assurance test on a system supporting production scheduling. The proposed tool may generate enough activity to affect service responsiveness. The assessor initially assumes that the general audit authorisation covers immediate execution.

The system owner and tester agree a suitable scope, timing, operational observation and a clear stop condition. They consider whether an appropriate non-production environment or another method can answer part of the question safely. The resulting record explains both the evidence obtained and any limits of the test, rather than trading operational stability for an unqualified assurance claim.

Plan communication and interruption decisions

Identify the contact who can resolve a question or stop the activity if unexpected effects occur. Relevant operational staff should know the agreed schedule and the distinction between authorised testing and unrelated suspicious activity. This coordination should support protection without unnecessarily disclosing sensitive test detail.

Agree additional processing or tools explicitly when they are needed. A tester should not expand a live assessment informally because a new question arises. Review the proposed extension, its impact and authority before proceeding. Record material deviations so the final assurance conclusion reflects what was actually performed.

Protect evidence and close temporary access

Common nonconformities with A.8.34

Findings generally show assurance activity running ahead of agreement. They usually arise because assessment is seen as inherently safe, so an auditor asks to see the agreed plan for a recent scan or test and compares it with what was actually done.

• Technical scans or tests run against live systems with no recorded scope or approval.
• Approval given in general terms without naming systems, methods or timing.
• Testers holding broad access that continued after the activity ended.
• No consideration of load or information exposure before automated assessments.
• No stated route for stopping a test and escalating if something unexpected occurs.