---
title: "ISO 27001 Annex A 8.34: keep audit testing from breaking production"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-8-34-protection-of-information-systems-during-audit-testing
published: 2023-08-21
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.8.34 Protection of information systems during audit testing"
journeyStage: implementation
---

# ISO 27001 Annex A 8.34: keep audit testing from breaking production

## Key takeaways

Annex A 8.34 makes audits and technical tests safe for live systems. Management agrees scope, access, timing and tools first, assessors get read-only, time-boxed access, and everything is logged and closed out. At 25–250 staff, a procedure page, an engagement checklist and light automation cover it.

- **Purpose** — Annex A 8.34 requires management to agree scope, access, timing and tools before any audit or technical test touches live systems, so assurance activity does not cause outages.
- **Access model** — Every assessor gets read-only, time-boxed, MFA-protected, named access. Where a privileged step is unavoidable, your administrator runs it while the assessor observes, which is proxy execution.
- **Rules of engagement** — Signed rules of engagement set targets, exclusions, permitted tooling, testing windows and an emergency-stop contact on each side, with intrusive scans scheduled out of hours.
- **Close-out** — Revoke assessor access the day testing ends, review session logs for the window, and obtain written confirmation that extracts were deleted or retained under agreed protection.

The penetration test is booked for Thursday, the testers want a login, and nobody has written down what they may touch. ISO 27001 Annex A 8.34 turns that gap into a short, repeatable procedure that keeps assessors useful and production up.

This guide covers the access model, rules of engagement, device checks, close-out and the evidence an auditor samples. It is written for security managers and IT leads at 25–250-person firms who host external audits and tests on live systems.

## Why does ISO 27001 Annex A 8.34 require management agreement before testing starts?

ISO 27001 Annex A protection of information systems during audit testing exists because assessments touch live systems. A.8.34 requires management to agree scope, access, timing and tools before any audit or technical test starts, so assurance activity reduces operational risk instead of causing outages, over-broad credentials or data leaving with the tester.

Audits and tests are meant to lower risk, yet a scan can flatten a live service and a broad auditor account is one more route into production. The internal audit programme under Clause 9.2 and the independent reviews of Annex A 5.35 make assurance happen. A.8.34 makes it safe.

The failure stories are mundane and expensive:

- A penetration test overloads the platform in the middle of a business day.
- An auditor account with domain admin rights is never disabled.
- A database extract leaves on a consultant's laptop and becomes a breach notification.

A firm of 25–250 people collects more of this traffic than it expects. Certification audits, internal audits, penetration tests, customer security reviews and insurer scans each put an outsider, or a quasi-outsider, in front of production.

The [ICO Guide to Data Security](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/) describes vulnerability scanning and penetration testing as stress tests of your network and information systems. Stress is the point, which is why the boundaries must be agreed first.

Auditors spot the irony fast. A firm that hands its assessor open production access fails an access-control test in the act of being assessed.

Handled cleanly, the same test signals a mature firm. A buyer who sees scope, windows and close-out in your test paperwork has more reason to trust every other control you claim.

## What does ISO 27001 protection of information systems during audit testing require?

The control requires six things for any assessment touching live systems: agreed scope, read-only access, verified tester devices, disruptive tests kept out of business hours, logged activity, and protected, destroyed extracts. Internal audits, penetration tests, certification audits and customer reviews all qualify.

Each requirement gets its own section below. In short:

1. **Agreed scope.** Management signs off targets, exclusions, timing and tools before work starts.
2. **Read-only access.** Assessors get the least access that answers their question.
3. **Verified tester devices.** The assessor's laptop is checked before it connects.
4. **Disruption kept off peak.** Intrusive or bandwidth-heavy tests run out of hours or against a staging mirror.
5. **Logged activity.** Assessor sessions are captured like any privileged session.
6. **Protected, destroyed extracts.** Copies are secured while held and deleted afterwards.

The control is preventive: it stops audit-induced incidents before they happen. It protects availability from overloaded systems, integrity from write access in the wrong hands, and confidentiality from data leaving with the tester.

Most of this matches practice you already want. It leans on the access management and logging a certified firm runs anyway, so the new work is joining those up for outsiders.

At this scale, the whole control is one page in your internal audit procedure plus a per-engagement checklist. The page states that any assessment touching live systems needs management to agree scope, access, timing and tools first. That is hours of effort, not weeks, and it belongs in place before your first external assessment cycle.

## Which safeguards does Annex A 8.34 protection of information systems during audit testing expect?

Annex A 8.34 safeguards default every assessor to read-only, time-boxed, MFA-protected, named access. When a privileged step is genuinely needed, proxy execution applies: your own administrator runs the commands while the assessor directs and observes, so the assessor gets the answer without ever holding the credentials.

The default model has four properties:

- **Read-only.** A viewer role in your cloud console covers most certification-audit needs.
- **Time-boxed.** The account expires when the engagement window closes.
- **MFA-protected.** No shared or single-factor logins for outsiders.
- **Named.** One account per person, so the log shows who did what.

Proxy execution suits the odd request for something only an admin can run, such as a config export. The assessor sees the output, your administrator keeps the credential, and the session is captured. Assessor activity is logged like any privileged session, and someone watches it during the window.

The commonest failure is handing over admin credentials because it is quicker than scoping a role. In certification-body grading, an outsider left with standing privileged production access reads as an access-control failure and grades major.

Offering an auditor more access than they need isn't hospitality. It's a finding.

## How do rules of engagement and out-of-hours windows keep intrusive testing safe?

Signed rules of engagement fix targets and exclusions, permitted tooling and intensity, testing windows, and an emergency-stop contact on each side before any technical test begins. Intrusive or bandwidth-heavy scans run out of hours, so a misjudged test cannot take a live service down mid-business-day.

The [NIST definition of rules of engagement](https://csrc.nist.gov/glossary/term/rules_of_engagement), taken from SP 800-115, describes them as the detailed guidelines and constraints for a test, set before it starts. A usable document covers four things:

- **Targets and exclusions.** Name the systems in scope and those that are off limits.
- **Tooling and intensity.** State which scanners run, at what rate, and whether denial-of-service style checks are barred.
- **Testing windows.** Fix dates and hours, with heavy work placed out of hours.
- **Emergency-stop contact.** Name one person on each side who can halt the test.

Any competent testing firm brings a template. Read it, amend it for your environment, and sign it.

A rules-of-engagement document that is filed rather than read isn't a control.

The [NCSC Penetration Testing Guidance](https://www.ncsc.gov.uk/guidance/penetration-testing) says scoping should surface anything that affects testing, including the need for out-of-hours work and critical systems needing special handling. It also expects a technical point of contact on your side who is available at short notice throughout the test, so the testers can raise critical issues as they find them.

Two pitfalls are self-inflicted. Vague scoping, such as "test the platform" with no exclusions or kill-switch contact, leaves nobody able to say whether the tester overstepped. Heavy scans against production at peak are downtime with an invoice attached.

Before any intrusive test, confirm that in-scope systems have a recent backup that has been restored at least once. If a misjudged test corrupts data, recovery then takes hours rather than days.

Match the approval friction to how intrusive the test is. A routine read-only certification audit does not need the controls a full-strength external test does. The signed statements of work from your recent penetration tests usually satisfy much of this control already.

## How do you verify an assessor's laptop before it connects?

Ask the assessor for an attestation that the device is patched, encrypted and running endpoint protection before it touches your network or console. At 25–250 staff that is proportionate: a written attestation per engagement, recorded on the checklist, closes the gap where a tester's laptop becomes the weakest link.

A tester's laptop holds session tokens, credentials and extracts from several clients. If an attacker owns it while it is connected to you, your network is the way in. The attestation costs the assessor minutes.

Make it a gate on the engagement checklist:

1. **Request it with the rules of engagement.** The assessor confirms patch level, disk encryption and active endpoint protection in writing.
2. **Hold the account until it arrives.** Access is set up only once the attestation is filed.
3. **Keep the record.** The attestation sits with the signed scope as device evidence.

Where the assessor works remotely, route the session through a VPN or a virtual desktop you control, rather than opening services to the internet for the test. The attestation then covers their device, and your own access controls cover the path in.

## Does Annex A 8.34 cover staging and development environments?

Yes. Development and test systems carry real risk because they hold source code and, too often, copies of production data. Point heavy tests at a staging mirror with masked data, and apply the same access limits, logging and sign-off as production wherever an assessor can read code or sensitive records.

Two exposures make non-production worth scoping. Confidentiality suffers when code or unmasked data copies leave with the tester. Integrity suffers when write access in a test environment corrupts data or code that later ships.

For any non-production environment an assessor can reach, apply these rules:

- **Mask the data.** Replace names, emails and IDs with realistic fakes before a mirror is built.
- **Read-only by default.** Grant write access only where the test genuinely needs it, and name it in the scope.
- **Repositories read-only.** Assessors rarely need push rights to source code.
- **Same logging.** Capture assessor sessions here as you would in production.

A staging mirror holding unmasked production records takes on production's duties, whatever it is called. The pitfall is treating staging as fair game because "it's only staging", and handing it over with no rules of engagement. Scheduling for heavy tests sits with the windows set in the rules of engagement. The question here is what the assessor can read and change.

## What should assessor close-out look like after testing ends?

Revoke the temporary assessor access the day testing ends, review the session logs for the window, and obtain written confirmation that the tester has deleted extracts, or agreed protected retention. Put revocation and destruction on the engagement checklist so both are closed deliberately.

Close-out has four steps:

1. **Revoke the same day.** Disable the account on the last day of the window and confirm it in the identity provider or console.
2. **Review the logs.** Read the session record for the window and check activity stayed within scope.
3. **Chase destruction.** Get written confirmation that extracts were deleted, or the terms of any protected retention agreed in the rules of engagement.
4. **File the record.** Revocation entry, log review note and confirmation sit with the signed scope.

Orphaned assessor accounts are the usual casualty. They survive for months and are found by the next access review, or by the next attacker. Without written proof of deletion, sensitive copies stay outside your control for good.

A revocation that depends on someone remembering isn't a revocation.

A clean close-out is the evidence an auditor goes looking for. At this scale, four ticked items per engagement prove the assessor left no footprint.

## What will an auditor ask about Annex A 8.34 and what evidence do they sample?

Auditors sample your most recent technical engagement end to end: the rules of engagement agreed beforehand, the assessor account trail from creation to revocation, device attestation, session logs, and close-out confirmations. They also ask what your internal auditor can actually touch in production.

Expect questions in this shape:

- "Your last penetration test: show me what was agreed before it started."
- "What access did the testers have, and who approved it?"
- "How did you make sure their laptops weren't the weak point?"
- "What happened to the accounts and the data they pulled once the engagement ended?"
- "When your internal auditor reviews production systems, what can they actually touch?"

The auditor checks the account trail (created, scoped, revoked) against the rules of engagement, then looks for close-out confirmations. Certification auditors also notice what you hand them, because unscoped admin access offered to the audit team is itself a data point.

An unrevoked tester account, a missing device check or a missing destruction confirmation each grades minor. As a pattern, they aggregate to major. Standing privileged access, covered in the safeguards section, is the direct route to a major.

| Evidence artefact | What it proves | If it is missing |
| --- | --- | --- |
| Audit-testing page in the internal audit procedure | Management agreement on scope, access, timing and tools | Evidence gap on the mandate |
| Signed rules of engagement or statement of work | Scope, exclusions, windows and approvals agreed before testing | Evidence gap on scoping and approval |
| Assessor access records | Read-only role, time-boxed creation and revocation, MFA | Unrevoked account: minor. Standing privileged access: major |
| Device attestation | Tester kit verified before connection | Minor, aggregating to major as a pattern |
| Session logs for the window | Assessor activity captured and, ideally, reviewed | Evidence gap on monitoring |
| Revocation and destruction confirmations | Access ended and extracts deleted or protected | Minor, aggregating to major as a pattern |

## How can you automate assessor access and engagement checklists?

Three light automations cover most of the control: an IdP request that provisions a time-boxed, read-only, MFA-protected assessor account that expires on its own; a ticket template that creates the engagement checklist; and session capture routed through your existing privileged-access logging.

Each one removes a dependency on memory:

- **Assessor access as a workflow.** A standard "external assessor" request provisions the account and sets its expiry. The provisioning record doubles as evidence.
- **Checklist as a ticket template.** Rules of engagement signed, device attestation received, access expiry set, destruction confirmation received. Unclosed items chase their owner.
- **Session capture by default.** Assessor activity follows the same path as any privileged session, so monitoring is reused, not built from scratch.

The result is assurance that is safe by default, with the evidence an auditor samples produced as a side effect of doing the work. If you would rather not build it alone, GRCMANA's internal audit and fractional CISO services run engagements to these rules.

## Frequently asked questions

### Does Annex A 8.34 require a separate standalone policy for audit testing?

No. A section in the internal audit procedure covers it. What matters more is that the section names who approves each engagement, usually the ISMS owner, so the management agreement the control asks for has a signature on it. Add a standalone policy only if a customer contract demands one by name.

### What did the ISO 27001:2022 revision change for Annex A 8.34?

It made checking the tester's device security before connection a stated expectation. It also widened the focus beyond production to development and test systems. If your procedure predates 2022, add device attestation to the checklist and name non-production systems in scope.

### Do the A.8.34 rules apply to our certification auditor too?

Yes. Raise the access model in the audit planning call, before the auditor asks for anything. Scoped read-only access for an audit team is normal practice, so the request rarely causes friction. Agree in the plan which evidence you will show on screen and which, if any, needs a login at all.

### Does A.8.34 cover customer security reviews and insurer scans, or only certification audits?

It covers any assessment that touches live systems. A customer who wants a login or a live scan gets the same rules of engagement as a penetration tester. A questionnaire that touches no system does not engage the control.