How to Audit ISO 27001 Annex A 8.34 Protection of Information Systems During Audit Testing

Auditing ISO 27001 Annex A 8.34 is the verification process to ensure that information systems are protected during audit testing activities to prevent operational disruption. Auditors must confirm that audit requirements and technical tests are planned, agreed upon, and monitored to minimize risk, ensuring the availability and integrity of business-critical systems.

Auditing Annex A 8.34 requires a focus on the intersection of compliance activities and operational stability. The primary objective is to confirm that the organisation treats audit testing as a high-risk change event, requiring formalised planning and technical safeguards to ensure that “security checking” does not itself become a “security incident.”

1. Provision Formal Rules of Engagement (ROE) Documents

Verify that every audit or technical test is governed by a signed Rules of Engagement document. This ensures that the scope, methodology, and constraints are legally and operationally defined before any testing begins.

• Inspect ROE documents for specific exclusions of sensitive technical assets.
• Confirm that both the auditor and the asset owner have signed the agreement.
• Verify that the ROE includes emergency contact details for immediate session termination.

2. Formalise Scheduling and Operational Time Windows

Audit the scheduling process to ensure that tests are conducted during periods of low business impact. This prevents technical scans or manual testing from degrading service performance during peak hours.

• Cross-reference audit logs with the organisational change calendar.
• Confirm that high-traffic or critical processing windows are explicitly excluded from testing.
• Check for evidence of coordination between the audit team and the Network Operations Centre (NOC).

3. Audit Restricted Access Levels for Testers

Examine the Identity and Access Management (IAM) roles provisioned for auditors. Testers should only possess the minimum level of access required to satisfy the audit objective, following the principle of least privilege.

• Verify that auditors are not granted “Global Admin” or “Superuser” status by default.
• Confirm that MFA is enforced for all temporary auditor accounts.
• Check the Asset Register to ensure auditor access is limited to the defined scope.

4. Verify Read-Only Permissions for Production Datasets

Assess the technical controls used to protect data integrity during testing. Auditors should typically be restricted to read-only access to prevent accidental modification or deletion of live data.

• Inspect database permissions for auditor service accounts.
• Confirm that “Write” or “Delete” permissions are only granted under exceptional, monitored circumstances.
• Review the use of data masking or anonymisation where live data must be sighted.

5. Monitor System Performance During Active Testing

Evaluate the monitoring tools used to track system health during an audit. Real-time observation ensures that any performance degradation caused by testing is identified and mitigated instantly.

• Inspect dashboard logs for CPU and memory usage during known testing windows.
• Verify that automated alerts are configured to trigger if testing activity exceeds performance thresholds.
• Confirm that the technical team has the authority to suspend testing if stability is compromised.

6. Revoke Temporary Auditor Accounts Post-Testing

Audit the offboarding process for temporary testing credentials. Stale auditor accounts are a significant security risk if they are not decommissioned immediately after the engagement concludes.

• Sample recent audit completion dates and compare them to account deactivation logs.
• Verify that temporary VPN or SSH keys have been deleted or rotated.
• Check the IAM system for any “Auditor” roles that remain active beyond their intended duration.

Annex A 8.34 Audit Execution Framework

Table 1: Technical Audit Steps and Evidence Requirements for Information System Protection

Audit Step	Audit Execution Method	Common Examples of Evidence
1. Rules of Engagement	Review signed agreements for recent penetration tests or internal audits.	Signed ROE PDF, Scope Definition Document.
2. Testing Schedules	Compare audit dates against the corporate holiday and peak-transaction calendar.	Outlook Calendar invites, Change Management Logs.
3. Privileged Access Review	Inspect auditor account settings in the IAM console during an active test.	IAM Role screenshots, Active Directory group memberships.
4. Read-Only Verification	Verify database role configurations for auditor service accounts.	SQL Role definition, “SELECT” only permission logs.
5. Performance Monitoring	Verify that a system admin was monitoring the NOC during a vulnerability scan.	CloudWatch logs, Datadog dashboards, NOC shift logs.
6. Credential Decommissioning	Perform a spot check on accounts created for auditors who finished in the last 30 days.	Deactivated account status in Okta/AD, Deleted SSH keys.
7. Data Sanitisation	Inspect the data used in the “Staging” environment to ensure it is not live production data.	Anonymisation scripts, Data Masking Policy.
8. Log Integrity	Confirm that auditors do not have “Delete” access to the logs tracking their actions.	WORM storage settings, SIEM log integrity reports.
9. Management Sign-off	Review board or steering committee minutes where audit plans were approved.	ISMS Committee Minutes, Signed Audit Charter.
10. Risk Exclusion	Confirm that “Year-End” or “Black Friday” windows were blocked out in the audit tool.	Blackout period configuration in Vulnerability Scanners.

Common SaaS and GRC Platform Audit Failures

Table 2: Analysis of Automated Platform Failures for Annex A 8.34 Compliance

Failure Mode	SaaS / GRC Platform Bias	Technical Audit Consequence
Lack of Contextual Planning	Platforms often trigger automated scans based on a fixed timer regardless of business load.	Operational downtime caused by scans running during peak transaction windows.
Persistent Auditor Accounts	Automated platforms often keep “Auditor” roles active indefinitely to facilitate “Continuous Auditing.”	Major finding for stale credentials and breach of least privilege.
No Human ROE Oversight	Software assumes consent for all connected assets without verifying specific Rules of Engagement.	Testing of out-of-scope or sensitive legacy systems that cannot handle aggressive scanning.
Performance Monitoring Gaps	GRC tools track that a test “happened” but do not integrate with performance monitoring data.	Inability to prove that the system remained stable during the testing window.
Automated Privilege Escalation	Platforms often request “Full Admin” APIs to simplify data collection.	Violation of least privilege; a compromised GRC token grants full control of production.
Ghost “Sign-offs”	Platforms use digital “acknowledgements” that often bypass real management risk review.	Lack of evidence that Top Management understood the technical risks of the test.
Data Privacy Blindness	Automated tools may pull full production records into the GRC platform for “evidence.”	Data leakage and non-compliance with UK GDPR during the audit process.
Inflexible Testing Windows	Cloud-native GRC tools often lack the ability to respect local timezone “blackout” windows.	Scans hitting UK systems during critical 8 AM processing starts.
Opaque Testing Logic	Proprietary platform “bots” perform tests that cannot be manually reviewed or paused by the IT team.	Failure to maintain control over the ISMS environment during assurance activities.
False Positive Confidence	Platforms report “Security Green” because the scan finished, ignoring system errors caused by the scan.	The audit process itself obscures underlying operational instability.

About the author