Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.34 — Protection of Information Systems During Audit Testing

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.34 ISO 27001ISO 27002BSI DER.3.1

An external auditor runs a vulnerability scan against the production database server at 10 AM on a Monday. The scan generates 50,000 requests in 30 seconds, triggering the intrusion detection system and causing the database connection pool to exhaust. The application returns errors to all users for 15 minutes. A.8.34 ensures that audit and assurance activities are planned and managed to minimize their impact on operational systems.

Audits are essential for verifying security. Poorly conducted audits can themselves cause security incidents or operational disruptions. This control balances the need for thorough audit testing with the need to protect production systems.

What does the standard require?

  • Agree on scope and approach. Coordinate with management on what auditors can access, which systems they can test and what methods they may use.
  • Prefer read-only access. Use read-only access to configuration files, logs and data wherever possible. Limit write access and intrusive testing.
  • Protect audit tools. Ensure audit tools (scanners, data extraction software) are authorized, verified and removed after the audit.
  • Schedule intrusive tests carefully. Activities that could affect system performance or availability should take place during maintenance windows.
  • Monitor audit activities. Log all audit access and actions for accountability.
  • Handle system files carefully. Protect critical system files during audits and control access to sensitive configuration data.

In practice

Create an audit coordination process. Assign a coordinator who manages audit access, scheduling and communication. Every audit engagement starts with a scoping meeting that defines what will be tested, how and when.

Grant time-limited, scoped access. Provide audit access through dedicated, temporary accounts with read-only permissions where possible. Revoke access immediately when the engagement ends. Log all activities through these accounts.

Schedule performance-impacting tests. Vulnerability scans, penetration tests and load tests on production systems should be scheduled during low-traffic periods. Notify operations and incident response teams in advance.

Verify and control audit tools. Before allowing auditors to deploy tools on your systems, verify the tools’ integrity and approve their use. Remove all audit tools and temporary accounts immediately after the engagement.

Typical audit evidence

Auditors typically expect the following evidence for A.8.34:

  • Audit engagement protocol — documented procedures for managing audit access and activities (see Secure Software Development Policy in the Starter Kit)
  • Access authorization records — evidence of time-limited, scoped audit access
  • Schedule coordination — documented scheduling of intrusive tests
  • Activity logs — evidence of monitoring audit access and actions
  • Tool authorization records — approval and removal of audit tools

KPI

Percentage of audit tests conducted with documented IS protection measures

Measured as a percentage: how many audit engagements followed the documented audit engagement protocol with appropriate protection measures? Target: 100%.

Supplementary KPIs:

  • Number of operational incidents caused by audit activities (target: zero)
  • Mean time between audit engagement end and access revocation (target: under 24 hours)
  • Percentage of audit engagements with documented scoping agreement

BSI IT-Grundschutz

A.8.34 maps to BSI modules for audit and assurance:

  • ISMS.1 (Security Management) — overarching requirements for managing audit activities within the ISMS.
  • DER.3.1/DER.3.2 (Audit and Revision) — specific requirements for planning, conducting and following up on information security audits.

Sources

Frequently asked questions

Who is responsible for protecting systems during audit testing?

Both parties share responsibility. The auditor must minimize their impact and follow agreed procedures. The organization must define the rules, provide appropriate access and monitor audit activities.

Can auditors access production systems directly?

Yes, if agreed in advance and appropriate safeguards are in place. Prefer read-only access. If the audit requires intrusive testing (vulnerability scans, penetration tests), schedule these during maintenance windows and coordinate closely.

Should audit tools be controlled?

Yes. Audit tools (vulnerability scanners, network sniffers, data extraction tools) are privileged utilities. They should be approved before use, verified for integrity and their access should be revoked immediately after the audit.