ISO/IEC 27001:2022 Annex A 8.34 – Protection of Information Systems During Audit and Testing focuses on protecting information systems and information while audits, assessments, security testing, penetration testing, vulnerability assessments, compliance reviews, or other testing activities are being performed.
Audits and security testing are necessary to determine whether controls are working effectively. However, these activities can themselves create security and operational risks.
For example:
- An auditor may need access to sensitive information.
- A penetration tester may scan production systems.
- A vulnerability assessment may generate large amounts of traffic.
- An auditor may request configuration screenshots.
- A tester may receive temporary privileged access.
- Security testing may accidentally affect system availability.
- Audit evidence may contain confidential or personal information.
The objective of A.8.34 is therefore to ensure that audit and testing activities are planned and performed in a way that protects information systems and information.
What Is ISO 27001 Annex A 8.34?
A.8.34 addresses the protection of information systems during audit and testing activities.
This can include:
- Internal audits
- External audits
- ISO 27001 audits
- SOC 2 audits
- Vulnerability assessments
- Penetration testing
- Application security testing
- Infrastructure security testing
- Compliance assessments
- Configuration reviews
- Technical security assessments
- Disaster recovery testing
- Cloud security assessments
- Third-party assessments
The organization should establish appropriate controls so that audit and testing activities do not unnecessarily:
- Disrupt production systems
- Expose sensitive information
- Circumvent security controls
- Create unauthorized access
- Modify production information
- Introduce security vulnerabilities
- Affect system availability
- Expose credentials or secrets
Why Is A.8.34 Important?
Audits and security testing involve access that would normally not be granted to everyone.
That creates a unique risk.
1. Temporary privileged access
An auditor or tester may require elevated permissions.
2. Sensitive audit evidence
Audit evidence can contain:
- Customer information
- Employee information
- System configurations
- Security architecture
- Vulnerability details
- Access-control information
- Logs
- Contracts
- Security reports
3. Production disruption
Aggressive vulnerability scanning or penetration testing can affect production systems.
4. Data modification
Testing may unintentionally create, modify or delete information.
5. Security-control bypass
Testing activities may interact directly with security mechanisms such as firewalls, authentication systems and monitoring tools.
6. Information leakage
Audit reports, screenshots, exports and logs may contain sensitive information.
7. Third-party access
External auditors and penetration testers may receive temporary access to internal systems.
What Types of Audit and Testing Activities Are Covered?
| Activity | Example |
|---|---|
| Internal audit | ISO 27001 internal audit |
| Certification audit | ISO 27001 Stage 1 / Stage 2 |
| Surveillance audit | Annual certification surveillance |
| SOC 2 audit | Controls and evidence review |
| Vulnerability assessment | Automated vulnerability scanning |
| Penetration testing | Application/network penetration test |
| Configuration review | Cloud/IAM/security configuration review |
| Code review | Secure code assessment |
| Compliance assessment | Regulatory or contractual assessment |
| DR testing | Disaster recovery exercise |
| Cloud assessment | Cloud security review |
| Third-party assessment | Customer/vendor security assessment |
What Does A.8.34 Require?
The practical objective is to ensure that audits and testing are performed in a controlled manner.
The organization should consider:
- Planning audit and testing activities
- Defining scope
- Identifying affected systems
- Defining authorized testers
- Controlling access
- Protecting audit evidence
- Protecting production systems
- Avoiding unnecessary disruption
- Monitoring testing activities
- Controlling test data
- Protecting test results
- Removing temporary access afterward
Audit vs Security Testing
These activities are related but not identical.
Audit
An audit generally evaluates whether defined requirements and controls are established and operating.
Examples:
- ISO 27001 audit
- SOC 2 audit
- Internal compliance audit
Security Testing
Security testing attempts to identify weaknesses or validate security mechanisms.
Examples:
- VAPT
- Penetration testing
- Vulnerability scanning
- Application security testing
Both can require access to sensitive systems and therefore need appropriate protection.
How to Implement ISO 27001 A.8.34
Step 1 – Define the Audit or Testing Scope
Before beginning, document what will be assessed.
For example:
Application penetration test
In Scope:
- Web application
- API
- Authentication
- Authorization
Out of Scope:
- Production database
- Third-party payment platform
- Employee laptops
Clear scope prevents accidental testing of systems that were not authorized for testing.
Step 2 – Identify the Testing Environment
Determine whether testing will occur against:
- Development
- Test
- Staging
- Production
Whenever practical, testing should use a controlled environment.
However, some assessments may legitimately require production testing.
For example:
- Production configuration assessment
- Live cloud security review
- External attack-surface testing
- Operational control testing
In such cases, additional safeguards may be required.
Step 3 – Obtain Authorization
Testing should be authorized before it starts.
Authorization should identify:
- Tester
- Organization
- Scope
- Systems
- Testing window
- Approved techniques
- Restrictions
- Contact person
- Emergency contact
- Reporting requirements
For penetration testing, a formal authorization or rules-of-engagement document is particularly useful.
Step 4 – Define Rules of Engagement
Rules of engagement can specify:
- What may be tested
- What must not be tested
- Testing dates
- Permitted techniques
- Rate limits
- Prohibited destructive activities
- Emergency stop procedure
- Contact information
- Evidence handling
- Reporting requirements
Example:
Allowed:
✓ Authentication testing
✓ Authorization testing
✓ API testing
✓ Vulnerability scanning
Not Allowed:
✗ Denial-of-service testing
✗ Destructive database testing
✗ Deleting customer data
✗ Testing third-party systems
The exact rules should depend on the engagement.
Step 5 – Protect Production Systems
When testing production systems, evaluate the potential impact.
Consider:
- Performance
- Availability
- Data integrity
- Customer impact
- Network traffic
- Database load
- Security alerts
- Rate limits
For example, a vulnerability scanner should not be configured to generate unnecessary traffic against a critical production service.
Step 6 – Provide Least-Privilege Access
If an auditor or tester requires system access, provide only the access necessary for the engagement.
Use:
- Individual accounts
- MFA
- Time-limited access
- Role-based permissions
- Temporary privileged access
- Monitoring
Avoid giving permanent administrator access when temporary or restricted access is sufficient.
Step 7 – Protect Audit Evidence
Audit evidence can contain highly sensitive information.
Examples:
- Screenshots
- System logs
- User lists
- Cloud configurations
- Vulnerability reports
- Security architecture
- Contracts
- Customer records
- Incident reports
- Access-control records
Evidence should be stored and transferred using approved secure methods.
Step 8 – Control Sensitive Information
Before providing evidence, determine whether sensitive information can be:
- Redacted
- Masked
- Anonymized
- Minimized
- Replaced with configuration evidence
- Provided through controlled access
For example, an auditor may need evidence that MFA is enabled.
The organization may not need to provide actual user passwords or authentication secrets.
Step 9 – Protect Vulnerability Information
Security testing may identify serious weaknesses.
Penetration-test reports can contain:
- Vulnerable URLs
- System architecture
- Attack paths
- Security weaknesses
- Credentials
- Configuration weaknesses
- Exploitation details
These reports should be treated as sensitive information.
Access should be restricted to authorized personnel.
Step 10 – Monitor Testing Activities
Where appropriate, monitor audit and testing activities.
Examples:
- Authentication logs
- VPN logs
- Cloud activity logs
- Firewall logs
- Application logs
- SIEM alerts
- Privileged access logs
Monitoring can help determine whether testing activity is occurring within the authorized scope.
Step 11 – Define an Emergency Stop Process
Testing should have a method to stop quickly if unexpected impact occurs.
For example:
Testing Activity
↓
Unexpected Production Impact
↓
Notify Emergency Contact
↓
STOP TESTING
↓
Investigate
↓
Assess Impact
↓
Resume Only After Authorization
This is particularly important for production penetration testing and high-volume vulnerability scanning.
Step 12 – Remove Temporary Access
After testing or audit activities are completed:
- Disable temporary accounts
- Remove VPN access
- Remove privileged permissions
- Revoke API keys
- Remove test certificates
- Remove temporary firewall rules
- Delete temporary files
- Remove shared folders
- Review logs
Access should not remain simply because the engagement has ended.
Example – ISO 27001 Audit
An external ISO 27001 auditor requests:
- Employee access list
- Cloud configuration
- Security policies
- Vulnerability scan report
- Backup evidence
- Security incident records
The organization should:
- Confirm the request relates to the audit scope.
- Identify sensitive information.
- Provide only relevant evidence.
- Use an approved secure sharing mechanism.
- Restrict access to authorized audit personnel.
- Avoid sharing unnecessary credentials or secrets.
- Maintain appropriate evidence of what was shared.
Example – Penetration Test
A startup wants a penetration test of its SaaS platform.
A controlled process could be:
Penetration Test Request
↓
Scope Definition
↓
Risk Assessment
↓
Authorization
↓
Rules of Engagement
↓
Testing
↓
Monitoring
↓
Findings
↓
Remediation
↓
Retesting
↓
Access Removal
This allows the organization to test security without treating the test itself as an uncontrolled activity.
Production vs Non-Production Testing
| Environment | Risk | Typical Approach |
|---|---|---|
| Development | Lower | Controlled testing |
| Test | Lower | Security/functional testing |
| Staging | Moderate | Production-like validation |
| Production | Potentially high | Strict authorization and safeguards |
Production testing is not automatically prohibited.
The organization should determine whether production testing is appropriate based on risk, scope and potential impact.
What Events Should Trigger A.8.34 Review?
Consider the control whenever the organization:
- Schedules an internal audit
- Starts an ISO 27001 certification audit
- Begins a SOC 2 audit
- Performs a penetration test
- Conducts vulnerability scanning
- Performs a cloud security assessment
- Performs a configuration review
- Engages an external auditor
- Engages an external penetration tester
- Provides temporary privileged access
- Tests disaster recovery
- Performs major compliance assessments
Startup Quick Summary
For a startup, A.8.34 can be implemented with a straightforward process:
Define scope → Authorize → Control access → Protect systems → Monitor → Protect evidence → Remove access
For penetration testing, add:
Rules of engagement + emergency stop process
For audits, add:
Evidence minimization + secure evidence sharing
Minimum Startup Implementation
A startup should establish at least:
1. Audit and testing procedure
Document how audits and security testing are authorized and performed.
2. Scope definition
Clearly identify systems and information being assessed.
3. Authorization
Ensure testing has appropriate approval.
4. Access control
Provide auditors/testers only the access they require.
5. Evidence protection
Protect audit evidence and security reports.
6. Production safeguards
Assess potential impact before testing production.
7. Monitoring
Monitor privileged and testing activities where appropriate.
8. Emergency stop
Have a method to stop testing if unexpected impact occurs.
9. Temporary access removal
Remove access after the engagement.
10. Documentation
Retain authorization, scope, reports and relevant evidence.
Audit and Testing Engagement Register
A simple register can be maintained:
| ID | Activity | Provider | Scope | Environment | Start | End | Access | Owner | Status |
|---|---|---|---|---|---|---|---|---|---|
| AUD-001 | ISO 27001 Audit | Certification Body | ISMS | All in scope | 01-Oct | 03-Oct | Controlled | ISMS Manager | Closed |
| PT-001 | Penetration Test | Security Firm | SaaS App/API | Staging | 10-Oct | 14-Oct | Temporary | Security | Closed |
| VA-001 | Vulnerability Assessment | Internal | Cloud Infrastructure | Production | 20-Oct | 20-Oct | Controlled | IT | Closed |
Rules of Engagement Checklist
For security testing, document:
| Item | Defined? |
|---|---|
| Testing scope | Yes/No |
| Target systems | Yes/No |
| IP addresses/domains | Yes/No |
| Testing window | Yes/No |
| Permitted techniques | Yes/No |
| Prohibited techniques | Yes/No |
| Production testing restrictions | Yes/No |
| Rate limits | Yes/No |
| Emergency contact | Yes/No |
| Stop-testing procedure | Yes/No |
| Evidence handling | Yes/No |
| Reporting process | Yes/No |
| Data retention | Yes/No |
| Access removal | Yes/No |
Audit Evidence for A.8.34
An auditor may look for:
Governance
- Audit and testing procedure
- Security testing policy
- Rules of engagement
- Engagement approvals
Scope
- Scope documents
- Asset lists
- Testing plans
- Audit plans
Access
- Temporary accounts
- Access approvals
- MFA
- Privileged access records
- VPN access
Testing
- Vulnerability scan reports
- Penetration-testing reports
- Test logs
- Testing records
Protection
- Secure evidence-sharing records
- Data masking/redaction
- Encryption
- Access restrictions
Monitoring
- SIEM logs
- Authentication logs
- Cloud logs
- Firewall logs
Closure
- Access revocation
- Test completion
- Findings/remediation
- Retest reports
- Engagement closure
ISO 27001 A.8.34 Audit Checklist
| # | Audit Question | Evidence |
|---|---|---|
| 1 | Are audit and testing activities appropriately planned? | Audit/test plan |
| 2 | Is the scope clearly defined? | Scope document |
| 3 | Is testing formally authorized? | Approval |
| 4 | Are testing activities restricted to authorized systems? | Rules of engagement |
| 5 | Is access provided to auditors/testers controlled? | IAM records |
| 6 | Is privileged access minimized? | Access matrix |
| 7 | Is MFA used for appropriate access? | IAM evidence |
| 8 | Are production systems protected during testing? | Risk assessment |
| 9 | Are destructive or high-impact activities restricted? | ROE |
| 10 | Is sensitive audit evidence protected? | Secure sharing/access records |
| 11 | Are vulnerability reports protected? | Report access controls |
| 12 | Are testing activities monitored where appropriate? | Logs |
| 13 | Is there an emergency stop process? | Procedure/ROE |
| 14 | Is temporary access removed after testing? | Access revocation |
| 15 | Are audit/testing records retained appropriately? | Engagement register |
Common Mistakes
Mistake 1 – Giving testers permanent access
Testing access should normally be limited to what is required for the engagement.
Mistake 2 – No formal authorization
An organization should not allow external testing simply because someone requested it.
Scope and authorization should be established first.
Mistake 3 – Testing production without impact assessment
A vulnerability scanner or penetration test can affect availability or system performance.
Production testing should therefore be appropriately planned.
Mistake 4 – Sharing unnecessary information
An auditor may require evidence of a control but not necessarily access to every underlying system or sensitive record.
Provide the minimum information necessary.
Mistake 5 – Sending reports through insecure channels
Penetration-test reports and audit evidence can contain sensitive information.
Use approved secure methods for storage and transfer.
Mistake 6 – Forgetting temporary access
After an audit or penetration test, temporary accounts and permissions should be reviewed and removed.
Mistake 7 – No rules of engagement
Security testers need clear boundaries, especially when testing production systems.
Mistake 8 – No emergency contact
If testing causes unexpected impact, the organization should know who can immediately stop or coordinate the activity.
Policy vs Process vs Technical Control
| Area | Example |
|---|---|
| Policy | Audit and testing activities must protect information systems |
| Procedure | Define authorization, scope, access, testing and closure |
| Technical Control | IAM, MFA, logging and network restrictions |
| Process Control | Rules of engagement and testing approval |
| Monitoring | Security and administrative logs |
| Evidence | Test reports, approvals, access records and closure evidence |
Relationship With Other ISO 27001 Controls
A.8.34 works closely with:
| Control | Relationship |
|---|---|
| A.8.29 Security Testing in Development and Acceptance | Security testing before acceptance |
| A.8.31 Separation of Development, Test and Production Environments | Helps isolate testing activities |
| A.8.33 Test Information | Protects information used during testing |
| A.8.2 Privileged Access Rights | Controls elevated tester/auditor access |
| A.8.3 Information Access Restriction | Restricts access to information |
| A.8.5 Secure Authentication | Protects testing/audit accounts |
| A.8.15 Logging | Records relevant activities |
| A.8.16 Monitoring Activities | Detects unusual activity |
| A.8.8 Management of Technical Vulnerabilities | Supports vulnerability assessment and remediation |
| A.5.19 Information Security in Supplier Relationships | Relevant for external auditors/testers |
| A.5.20 Information Security Within Supplier Agreements | Security requirements for external providers |
A.8.33 vs A.8.34
These controls are closely related.
| Control | Main Focus |
|---|---|
| A.8.33 Test Information | Protect information used during testing |
| A.8.34 Protection During Audit and Testing | Protect systems and information while audits/testing are being performed |
Example:
A penetration tester receives a test dataset.
A.8.33: Protect the test dataset.
The tester performs a vulnerability scan against the application.
A.8.34: Ensure the scan is authorized, scoped, controlled and does not unnecessarily disrupt the system.
A.8.29 vs A.8.34
| Control | Main Focus |
|---|---|
| A.8.29 | Security testing as part of development and acceptance |
| A.8.34 | Protection of systems and information during audit/testing activities |
A.8.29 asks:
Are we performing appropriate security testing?
A.8.34 asks:
Are we protecting our systems and information while that audit or testing is taking place?
Practical Implementation Model
AUDIT / TEST REQUEST
|
v
DEFINE SCOPE
|
v
RISK ASSESSMENT
|
v
AUTHORIZATION
|
v
RULES OF ENGAGEMENT
|
v
CONTROLLED ACCESS
|
v
AUDIT / TESTING
|
+----------+----------+
| |
v v
MONITORING INCIDENT / IMPACT
| |
| STOP TEST
| |
+----------+----------+
|
v
FINDINGS / REPORT
|
v
REMEDIATION / RETEST
|
v
REMOVE ACCESS
|
v
CLOSE
Useful Resources
Organizations implementing A.8.34 may benefit from maintaining:
- Draft Audit & Security Testing Policy —
[Insert Document Link] - Audit and Testing Procedure —
[Insert Document Link] - Security Testing Authorization Form —
[Insert Document Link] - Penetration Testing Rules of Engagement Template —
[Insert Document Link] - Audit Evidence Sharing Checklist —
[Insert Document Link] - Temporary Auditor/Tester Access Request —
[Insert Document Link] - Security Testing Emergency Stop Procedure —
[Insert Document Link] - Audit & Testing Engagement Register —
[Insert Document Link] - Tester Access Revocation Checklist —
[Insert Document Link]
Final Takeaway
ISO 27001 Annex A 8.34 recognizes that audits and security testing can themselves create security risks.
A strong implementation therefore follows a controlled approach:
Define the scope → Authorize the activity → Restrict access → Protect systems and evidence → Monitor testing → Stop if necessary → Remove access → Close the engagement.
For startups, the goal is not to make every audit or penetration test complicated.
The practical objective is to ensure that an auditor or tester can obtain the access and information they genuinely need without creating unnecessary exposure, disruption, or unauthorized access.