ISO 27001 Protection of Information Systems During Audit Testing mandates that any audit and testing must be planned and it must be agreed with senior management. In ISO 27001 this is known as ISO27001:2022 Annex A 8.34 Protection of Information Systems During Audit Testing. It is one of the 93 ISO 27001 Annex A controls.
The requirement is that audit tests and other assurance activities involving assessment of operational systems should be planned and agreed between the tester and appropriate management. It’s purpose is to minimise the impact of audit and other assurance activities on operational systems and business processes.
Key Takeaways
- Audits and tests need to be planned and agreed
- The control is called ISO 27001:2022 Annex A 8.34 Protection of Information Systems During Audit Testing
- It is part of the audit and testing process
- Independent and qualified auditors should be used for ISO 27001 audits, following a documented audit methodology.
Table of contents
- Key Takeaways
- What is it?
- Applicability to Small Businesses, Tech Startups, and AI Companies
- Why do you need it?
- When do you need it?
- Where do you need it?
- How do you write it?
- How do you implement it?
- How to implement ISO 27001 Annex A 8.34: Step-by-Step
- Examples of using it for small businesses
- Examples of using it for tech startups
- Examples of using it for AI companies
- How can the ISO 27001 toolkit help?
- Information security standards that need it
- List of relevant ISO 27001:2022 controls
- How do you protect information systems?
- How do you minimise disruption?
- How do you comply?
- What an auditor looks for
- How to audit ISO 27001 Annex A 8.34
- Top 3 ISO 27001 Annex A 8.34 Mistakes and How to Fix Them
- ISO 27001 Annex A 8.34: Protection of Information Systems During Audit Testing FAQ
- ISO 27002:2022 Control 8.34
- Further Reading
- ISO 27001 Annex A 8.34 Attributes Table
What is it?
ISO 27001 Protection of Information Systems During Audit Testing, found in ISO 27001:2022 Annex A Control 8.34, is a fancy name for simply making sure your computer systems and data stay safe and sound while they’re being checked out by an auditor or a security tester. Audits and tests, like vulnerability scans or penetration tests, are super important for finding weak spots, but they can also put your systems at risk if you don’t handle them carefully.
This control requires you to plan and agree on all testing activities with your management and the testers beforehand. You want to make sure the testing doesn’t mess up your systems, corrupt your data, or expose sensitive information to anyone who shouldn’t see it.
Applicability to Small Businesses, Tech Startups, and AI Companies
This information security control is useful for businesses of all sizes, including small businesses, tech startups, and AI companies. Examples of using this control include:
- Small Businesses: You need this! Even if you only have a few computers, you likely hold customer data or important business files. Testing needs to be controlled so it doesn’t accidentally crash your server or leak your client list.
- Tech Startups: You’re probably moving fast, but a careless security test could break your main application or expose your secret sauce (source code). You must protect your live systems.
- AI Companies: You handle large amounts of data, often highly sensitive. A poorly managed audit test could compromise your AI models, training data, or proprietary algorithms, causing huge problems.
Why do you need it?
You need this control for a few simple reasons:
- Stop System Crashes: Audits can be intense. You need to plan to avoid tests that could accidentally shut down your website or core services, which would lose you money and trust.
- Keep Data Private: Auditors and testers need access, but you must ensure they only see what’s necessary and that sensitive data (like customer info) is protected, maybe by only using read-only access.
- Prove You’re Responsible: It shows your auditors and clients that you take security seriously and have a formal, controlled process for even your testing activities.
- Stay Compliant: To get or keep your ISO 27001 certification, you have to show that you’ve implemented this control.
When do you need it?
You need this control to be fully implemented before your certification auditor comes to visit for your Stage 2 audit. However, the actual planning and agreement for a specific audit or penetration test must happen before that test begins. You should:
- Have the policy or procedure ready as part of setting up your overall Information Security Management System (ISMS).
- Use this procedure to plan and agree with the tester every time you do an internal audit, external audit, vulnerability assessment, or penetration test on live or testing systems.
Where do you need it?
This control mainly applies to your operational (live) systems and any testing or development environments that contain sensitive data or code that, if compromised, could hurt your business. Think about:
- Your live web servers and databases.
- Your internal network infrastructure.
- Environments where you store customer or employee data.
- Testing systems that use real or realistic (but de-sensitized) data.
How do you write it?
A good procedure doesn’t need to be long, just clear. You should outline:
- 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 do you implement it?
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.
How to implement ISO 27001 Annex A 8.34: Step-by-Step
In this step by step implementation checklist to ISO 27001 Protection of Information Systems During Audit Testing I show you, based on real world experience and best practice, the best way to implement Annex A 8.34.
1. Conduct Risk Management
Identifying and mitigating all potential risks, especially within complex IT environments, presents a significant challenge.
Solution
- Conduct thorough risk assessments tailored to the specific audit context.
- Implement strict access controls for audit-related activities. Ensure that access is granted only to authorised personnel on a “need-to-know” basis.
- Deploy and maintain robust monitoring systems that provide real-time alerts for any unusual activity or anomalies.
2. Ensure System Integrity
Maintaining system integrity during audits poses significant challenges. Audit procedures often require interaction with live systems, increasing the risk of inadvertent disruptions or instability.
Solution
- Develop and enforce strict guidelines for auditors, outlining permissible actions and limitations to minimise the risk of unintended system modifications.
- Conduct audits within controlled environments or on system replicas whenever feasible.
- Continuously monitor systems during audits to detect any unauthorised changes. Ensure that any necessary changes are reversible and properly documented with appropriate approvals.
3. Safeguard Data Protection and Confidentiality
Safeguarding sensitive data during audits is crucial, especially when dealing with personal information, intellectual property, or other confidential material.
Solution
- Encrypt all sensitive data accessed during audits.
- Utilise role-based access controls to limit data access to authorised auditors.
- Regularly train internal staff and external auditors on confidentiality and data protection protocols.
- Maintain detailed logs of data access activities, ensuring a comprehensive audit trail.
4. Ensure Audit Preparation and Planning
Challenge
Preparing for and executing an audit effectively requires meticulous planning and coordination across the organisation, especially in complex environments.
Solution
- Create a detailed plan that includes risk assessments, system readiness checks, and inter-team coordination.
- Conduct audits during periods of low system activity to minimise potential disruption.
- Ensure the availability of backup systems and robust recovery plans to maintain business continuity during the audit.
- Ensure all relevant teams are prepared and coordinated.
5. Put in place Monitoring and Response
Continuous monitoring during audits is crucial for timely incident detection and response. This can be difficult due to limited resources, extensive audit scope, and the need to minimise false alarms.
Solution
- Utilise tools for real-time system activity tracking and immediate alerts on suspicious behaviour.
- Configure automated alerts for potential risks and breaches to enable rapid response.
- Ensure the incident response team is trained and ready to effectively handle security incidents.
- Analyse the effectiveness of monitoring and response protocols and identify areas for improvement .
Examples of using it for small businesses
A small marketing firm needs an audit. You should:
- Scope: Limit the audit to checking the configuration of your main email server and your shared client file drive.
- Access: Create a temporary, generic Audit user account with read-only permission to those two systems.
- Agreement: Document that the auditor is not allowed to run any code or software on your systems without explicit, on-the-spot permission from your IT contact.
Examples of using it for tech startups
A startup is getting a penetration test on its new mobile app’s backend. You should:
- Environment: Insist the test is run against a non-production, dedicated Test Environment that mimics the live one but holds no real customer data.
- Protection: Have a backup and restore procedure ready for the Test Environment. If the test causes a problem, you can reset it instantly without impacting your users.
- Logging: Ensure you are actively monitoring the Test Environment during the audit and have detailed logs of the tester’s IP address and activities.
Examples of using it for AI companies
A company building a healthcare AI model is being audited for data privacy. You should:
- Data Masking: Provide the auditor with a completely de-identified or masked subset of the training data, so they can review access controls without seeing protected health information (PHI).
- System Admin Proxy: Instead of giving the auditor direct access to the secure cloud environment, have your Data Engineer perform any necessary system commands or data pulls while the auditor watches (acting as a proxy).
- Out-of-Hours Testing: Schedule any high-impact system scans to run over the weekend to protect the availability of your production inference API.
How can the ISO 27001 toolkit help?
An ISO 27001 toolkit is a great shortcut. It often includes pre-written policies, procedures, and forms that you can use right away. It saves you the hassle of writing everything from scratch and helps you make sure you don’t miss any important details.
Information security standards that need it
This control is a key part of ISO 27001, which is an international standard for managing information security. Other standards that need it include:
- GDPR (General Data Protection Regulation)
- CCPA (California Consumer Privacy Act)
- DORA (Digital Operational Resilience Act)
- NIS2 (Network and Information Security (NIS) Directive)
- SOC 2 (Service Organisation Control 2)
- NIST (National Institute of Standards and Technology)
- HIPAA (Health Insurance Portability and Accountability Act)
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
How do you 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 do you minimise disruption?
The following are techniques to minimise disruptionduring 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.
How do you comply?
To comply withISO 27001 Annex A 8.34 you are going to implement the ‘how’ to the ‘what’ the control is expecting.
1. Joint Planning
The plan will be a collaborative plan between the auditor and management that sets out clearly what the scope and nature of the audit tests will be and how they will be conducted. This should be documented, signed and approved.
2. Access Management
Access management and access will be agreed ahead of time that covers the specific systems and data that is to be assessed.
Access will be limited and where possible read only access will be provided to minimise risks of unauthorised or accidental changes to systems and data.
Administrative rights should not be granted and where required the auditor should observe an actual administrator perform under their direction.
3. Auditor Device Security Check
Before the auditor is allowed any access, their device will be tested thoroughly to ensure it meets the security requirements of the organisation. If it does not, access will not be granted.
4. Limit Access To Live Data
Where possible and practical the auditor should be provided copies of data and systems, not actual live data and systems.
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.
How to audit ISO 27001 Annex A 8.34
To conduct an internal audit of ISO 27001 Annex A 8.34 Protection of Information Systems During Audit Testing use the following audit checklist which sets out what to audit and how to audit it.
1. Review the existence and effectiveness of Risk Management
- Check if a thorough risk assessments tailored to the specific audit context has been performed and if it considered identifying and addressing potential vulnerabilities and threats.
- Review access controls as they apply to audit-related activities and ensure that access is granted only to authorised personnel on a “need-to-know” basis.
- Walkthrough monitoring systems and gain evidence that they provide real-time alerts for any unusual activity or anomalies
2. Assess System Integrity is maintained
- Check for guidelines for auditors and that they are outlining permissible actions and limitations to minimise the risk of unintended system modifications.
- Look for the existence of controlled environments or system replicas whenever feasible.
- Review evidence of Continuous Monitoring during audits to detect any unauthorised changes and that any necessary changes were reversible and properly documented with appropriate approvals.
3. Ensure Data Protection and Confidentiality
- Review Data Encryption and that they encrypt all sensitive data accessed during audits.
- Check role-based access controls and that they limit data access to authorised auditors.
- Assess that they regularly train internal staff and external auditors on confidentiality and data protection protocols.
- Review Audit Logs and detailed logs of data access activities, ensuring a comprehensive audit trail.
4. Evidence Audit Preparation and Planning
- Check the audit plan and if it includes risk assessments, system readiness checks, and inter-team coordination.
- Review audit schedules and if audits are conducted during periods of low system activity.
- Check for contingencies and the availability of backup systems and robust recovery plans to maintain business continuity during the audit.
- Asses inter-team collaboration and are all relevant teams are prepared and coordinated.
5. Monitoring and Response
- Review the use of Advanced Monitoring Tools for real-time system activity tracking and immediate alerts on suspicious behaviour.
- Walkthrough Automated Alerts and check if they are configured for automated alerts for potential risks and breaches.
- Asses if they prepared the Incident Response Teams and the team is trained and ready to effectively handle security incidents.
- Analyse the effectiveness of monitoring and response protocols.
Top 3 ISO 27001 Annex A 8.34 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.
ISO 27001 Annex A 8.34: Protection of Information Systems During Audit Testing FAQ
The protection of information systems during audit, in particular ISO 27001:2022 Annex A 8.34 is important for serveral reasons including:
Preventing Compromise of Confidentiality, Integrity, and Availability (CIA)
Confidentiality: Audits often involve accessing sensitive data. Without proper controls, there’s a risk of unauthorised disclosure of this data during the audit process, whether accidentally or intentionally.
Integrity: Technical audit tests (e.g., vulnerability scanning, penetration testing) can potentially alter or corrupt data or system configurations. Protection measures ensure the integrity of the information and systems remains intact.
Availability: Some audit activities can be resource-intensive or involve actions that could disrupt operational systems. Protection ensures that critical business processes and system availability are not negatively impacted by the audit.
Maintaining Trust and Credibility
An organisation undergoing an ISO 27001 audit aims to demonstrate its commitment to information security. If the audit itself compromises security, it undermines the very purpose of the certification and damages trust with customers, partners, and stakeholders.
This control reinforces the idea that the organisation has thought through and implemented security at every stage, including during reviews of its security posture.
Reducing Risks of Data Breaches and Incidents
The audit process, while necessary, introduces a temporary increase in access to systems and data. Without specific controls, this increased access could inadvertently create vulnerabilities or expose sensitive information to risks like theft, accidental deletion, or unauthorised modification.
By putting safeguards in place, organisations significantly reduce the likelihood of a security incident occurring because of an audit.
Ensuring Accurate and Reliable Audit Results
If information systems are compromised or disrupted during an audit, the audit findings themselves could be skewed or unreliable. Protecting the systems ensures that the audit is conducted in a stable and controlled environment, leading to more accurate assessments of the ISMS effectiveness.
Minimising Business Disruption
Audits, especially those involving in-depth system assessments, can be disruptive. Control 8.34 emphasises planning and agreement between the auditor and management to minimise impact on daily operations. This might include conducting tests outside of business hours or using isolated copies of data.
Compliance with Best Practices
ISO 27001 is a globally recognised standard for information security management. Adhering to its controls, including those related to audit protection, demonstrates that an organisation is following industry best practices.
While the title specifically mentions audit testing, the principles are broadly applicable to any activity involving testing the security of information systems, including internal security assessments, external penetration tests, and technical vulnerability assessments, whether conducted by internal teams or third parties.
Key considerations include:
Defining Scope
Clearly defining the systems, networks, and applications to be tested.
Risk Assessment
Identifying potential risks associated with the testing and developing mitigation strategies.
Authorisation
Obtaining forma authorisation from management and relevant system owners.
Communication
Establishing clear communication channels between testers and system owners/administrators.
Backup and Recovery
Ensuring appropriate backups are in place and recovery procedures are understood.
Test Environment
Ideally, utilising a separate, isolated test environment that mirrors production, if feasible.
ISO 27001 Annex A 8.34 is highly relevant to penetration testing. It mandates that organisations take precautions to protect their systems during the test. This includes ensuring testers have appropriate authorisations, scope is defined, potential impacts are understood, and procedures are in place to address any adverse effects or incidents that may arise from the testing activity.
Typical documentation includes:
Testing Policies and Procedures: Outlining the approach to security testing.
Scope Definition Documents: Detailing what will be tested.
Authorisation Forms/Letters: Formal approval for testing.
Communication Plans: How stakeholders will be informed.
Incident Response Plans (specific to testing): How to handle unexpected issues during tests.
Test Reports: Documenting the testing activities and results.
Failure to protect systems during audit testing can lead to:
System Downtime or Outages: Unplanned disruptions to services.
Data Corruption or Loss: Damage or loss of critical information.
Security Breaches: Accidental or intentional exploitation of vulnerabilities during testing that could lead to unauthorized access.
Reputational Damage: Loss of trust from customers or stakeholders.
Legal or Regulatory Non-compliance: Penalties for failing to protect sensitive data.
While a separate, non-production environment that mirrors the production system is the ideal scenario for minimising risk, it’s not always feasible or realistic for all testing. If testing must occur in production, more stringent controls, communication, and risk mitigation strategies are required, including scheduling during low-impact periods and having robust rollback plans.
Communication is critical. Before, during, and after testing, clear and timely communication between the testers, system owners, IT operations, and management is essential. This includes notifying relevant personnel of testing schedules, expected impacts, and any incidents that occur, as well as providing post test reports and remediation plans.
Yes, any test that touches an operational (live) system must be planned and agreed upon by the tester and the appropriate management person.
It means the auditor can look at files or configurations but can’t change, delete, or upload anything, which massively reduces the risk.
Then your own trained administrator should make the change on the auditor’s behalf, or you should supervise the process very closely and document it.
That’s a great idea! If you can set up a segmented or isolated network area for the auditor, it limits what they can accidentally or intentionally impact.
You should verify that their device has up-to-date security protection (like anti-malware) before you allow it to connect to your systems.
If you followed this control, you should have planned for this by having a recent backup and an agreed-upon recovery plan ready to go.
You can, but you should only test during off-hours if the test might affect the system’s availability, like a heavy load test.
They’ll look for your Audit Testing Procedure and the specific Agreement or Scope Document for the test they are reviewing.
Yes, especially if that development or testing environment has sensitive data or source code in it.
Often, it’s the CISO (Chief Information Security Officer), IT Manager, or the system owner who signs off on the agreement.
You should make sure that the temporary isolated copies of your system files or data are deleted immediately after the audit is complete.
Absolutely. Internal audits should follow the same rules to protect the integrity and availability of your systems, even if the auditor is an employee.
It’s important for everyone, but it’s extremely important if you handle highly sensitive data (like in healthcare or finance) or have mission-critical systems where downtime is costly (like e-commerce).
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
Record Of Processing Activities (ROPA) Template
ISO 27001 Data Asset Register Template
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 |
