ISO 27001 A.8.34: audits on live systems, explained for startups

A.8.34 Protection of information systems during audit testing

Audits and tests are planned so they do not disrupt or expose live systems. What proves it: approval and limits for audit or test access to live systems, such as read-only access for set dates.

A certification auditor samples audit access approvals. A file that usually does the job: signed rules of engagement for a penetration test, or a ticket granting an auditor read-only access for set dates.

How to put it in place

Each step leaves a record, and the record is what the auditor samples rather than the step itself. Inside Polara, the control card for A.8.34 walks you through it in this order.

1. Agree scope, timing and access in writing before any audit or test.
2. Give read-only access where possible and remove it afterward.
3. Schedule tests that could disrupt service outside busy hours.

No question in the readiness assessment covers A.8.34 directly, so the control card is its whole evidence path.

Policies, connectors and the SOC 2 overlap

In the ISO 27001 policy pack, the Operations Security Policy covers A.8.34. An auditor reads the policy for the rule, then samples the records to see the rule was followed.

The same evidence counts toward SOC 2. The Trust Services criterion that cover this ground: CC4.1, control monitoring.

Technological controls

A.8.34 is one of the 34 technological controls in Annex A. The controls built into your systems: access, devices, malware, vulnerabilities, backups, logging, networks, encryption and secure development. Exports and settings screenshots prove most of them.

Nearby controls in the same theme:

• A.8.31, separate environments
• A.8.32, change management
• A.8.33, test data

Before it: A.8.33, test data. Every control, by theme, is on the Annex A controls page.