In this guide you will learn how to implement ISO 27001 Annex A 8.34 Protection of Information Systems During Audit Testing and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.
ISO 27001 Annex A 8.34 Protection of information systems during audit testing is an ISO 27001 control that requires you to plan and agree audit tests and to not impact operational systems or business processes.
Table of contents
- Purpose & Definition
- ISO 27001 Annex A 8.34 Requirements and Guidance
- How to Audit ISO 27001 Annex A 8.34
- What an auditor looks for
- ISO 27001 Templates
- Top 3 Mistakes and How to Fix Them
- List of relevant ISO 27001:2022 controls
- ISO 27002:2022 Control 8.34
- Further Reading
- ISO 27001 Annex A 8.34 Attributes Table
Purpose & Definition
The purpose of ISO 27001 Annex A 8.34 is to minimise the impact of audit and other assurance activities on operational systems and business processes.
The ISO 27001 standard defines ISO 27001 Annex A 8.34 as:
Audit tests and other assurance activities involving assessment of operational systems should be
planned and agreed between the tester and appropriate management.
ISO27001:2022 Annex A 8.34 Protection of information systems during audit testing
ISO 27001 Starter Kit
Instant download of mandatory ISMS core policies and documentation. Verified by Lead Auditors and used by 5,000+ businesses worldwide to pass Stage 1 certification first time.
ISO 27001 Annex A 8.34 Requirements and Guidance
The requirement here really comes from the premise that when auditors and testers perform the audit of information security, they shouldn’t break anything. Some of the tests, especially the technical test can be dangerous and cause a lot of harm and damage.
When implementing you want to make sure that:
- Agreements are in place, across the board, that agree to the audit and the tests.
- That appropriate access controls are in place and access control processes are followed to access the thing being audited.
- That anything that is accessing and auditing, specifically technology, is meeting your information security and technical standards and requirements such as patching and antivirus levels before they get access.
- That tests involving data only test read only versions of data where possible and where that is not possible that experienced administrators perform the test under the direction and observation of the auditor.
- That the running of any tools or technology to facilitate the audit are agreed and documented as agreed.
- That audits and tests are conducted outside operational peak operating times such as out of business hours.
- That all audit and tests are monitored and logged.
Fast track your ISO 27001 build with the ISO 27001 Templates Pack.
How to protect information systems
The following are technical techniques to effectively protection information systems during audit and testing.
- Access Control: Restricting access to information systems during audit testing is crucial.
- Read-Only Permissions: Implementing read-only permissions for auditors when feasible can prevent accidental or malicious changes to data.
- Secure Auditor Devices: Auditor devices should be secured with appropriate controls to prevent unauthorised access or data leakage.
- Audit Trails: Maintaining comprehensive audit trails of all activities during testing is essential for accountability and investigation purposes.
How to Minimise Disruption & Prevent Operational Downtime
The following are techniques to minimise disruption during audit and testing.
- Impact Assessment: Before any testing, an assessment should be conducted to identify potential impacts on operational systems and business processes.
- Test Environments: Using dedicated test environments, rather than production systems, can minimise the risk of disruption.
- Data Masking/Removal: Sensitive information used in test environments should be masked or removed after testing is complete.
- Who is responsible for approving audit and testing requests (usually a manager or a system owner).
- The steps for defining the scope of the test (what systems, what time, which users).
- How you’ll ensure read-only access is used, or who will supervise if “write” access is needed (like a system admin).
- What must be done to secure the auditor’s devices before they connect to your systems.
- What the plan is for monitoring and logging all the auditor’s actions during the test.
- The steps for backing up systems before a test that could cause issues.
- The plan for deleting any copies of your data the auditor needed after the test is finished.
How to Audit ISO 27001 Annex A 8.34
Review the Audit Policy and Procedures
Verify the existence of a formal governance framework that dictates how information systems are protected during audit activities.
- Policy Check: Confirm that the Information Security Policy explicitly requires management authorisation and scoping for all technical audit activities.
- Procedure Validation: Check for a documented procedure that outlines the requirements for “Rules of Engagement” (ROE) and restrictions on testing tools.
Verify Audit Authorisation and Scoping
Select a sample of recent technical audits (e.g., penetration tests or vulnerability scans) and request evidence of prior approval.
- Signed Agreements: Look for a signed “Rules of Engagement” document or Statement of Work (SoW) that explicitly defines the testing window, target IP addresses, and excluded systems.
- Management Sign-Off: Confirm that a senior stakeholder authorised the test before any tools were executed against the live environment.
Inspect Auditor Access Rights
Examine the specific user accounts and privileges granted to auditors during the testing window to ensure the Principle of Least Privilege was enforced.
- Read-Only Verification: Request evidence (screenshots or IAM logs) showing that external auditors were granted “Read-Only” or “Viewer” roles rather than full administrative access.
- Supervised Access: If administrative actions were required, verify that they were executed via “Proxy Execution” by an internal administrator or supervised via screen-sharing.
What an auditor looks for
For ISO 27001 Protection of Information Systems During Audit Testing the auditor will check:
1. That you have planned and agreed the audit
The audit will look for the audit plan and for formal, documented approval.
The auditor will check the information security requirements of the Information Security Management System (ISMS) and the Annex A Controls that you have recorded as in scope. They will check these against the in-scope environment.
2. That you have defined the scope of audits and tests clearly
The auditor will check based on the defined scope that you have agreed and should not venture outside that scope.
3. Their own engagement with you
Ironically for this control the auditor will in effect audit their own audit engagement and break the Segregation of Duty requirements covered in ISO 27001 Annex A 5.3 Segregation of duties. Don’t worry though, they are highly unlikely to highlight this as an issue.
ISO 27001 Templates

Top 3 Mistakes and How to Fix Them
The top 3 mistakes that people make for ISO 27001 Protection of Information Systems During Audit Testing are:
1. Inadequate Device Security Checks for Auditors
Issue
You allowed the auditor access to your systems without conducting proper security checks on their devices.
Explanation
Before an auditor or tester gains access to your systems, a thorough security check on their devices is crucial. This may include checks for malware, unauthorised software, and adherence to your organisation’s security policies.
Consequence
Neglecting this step can expose your systems to potential risks.
2. Lack of Defined and Agreed-Upon Scope
Issue
You did not formally agree and document the scope of the audit or test.
Explanation
Allowing audits or tests based on vague terms like “best practice” creates ambiguity and potential for disagreement later.
Recommendation
Establish a clear and concise scope of work, outlining the specific objectives, methodologies, and deliverables. This scope should be formally documented and signed by all parties involved.
3. Uncontrolled Granting of Administrative Access
Issue
You granted the auditor administrative access to your systems without proper authorisation and controls.
Explanation
Granting administrative access should never be done without a rigorous approval process and adherence to established access control procedures.
Recommendation
If administrative access is absolutely necessary, follow all established procedures, document the request and approval process thoroughly, and ensure all access controls are strictly enforced.
Check Your Work?
You buit it yourself. Maybe with AI. But will it pass the audit?
Don’t gamble – let a trained ISO 27001 auditor check your work.

List of relevant ISO 27001:2022 controls
The ISO 27001:2022 standard has specific controls that relate to protection of systems in audit and testing:
- ISO 27001:2022 Clause 9.2 Internal Audit
- ISO 27001:2022 Annex A 8.31 Separation of Development, Test and Production Environments
- ISO 27001:2022 Annex A 8.32 Change Management
- ISO 27001:2022 Annex A 8.33 Test Information
- ISO 27001:2022 Security Testing in Development and Acceptance: Annex A 8.29
ISO 27002:2022 Control 8.34
ISO 27002:2022 Control 8.34 provides implementation guidance for Protection of Information Systems During Audit Testing
Further Reading
ISO 27001 Annex A 8.34 Attributes Table
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Preventive | Confidentiality | Protect | System and Network Security | Governance and Ecosystem |
| Integrity | Information Protection | Protection | ||
| Availability |

