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

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 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, 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 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.

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