Should the test scope match the certificate scope exactly?

It should be derived from it and should not be narrower without a written justification. It can legitimately be smaller where controls are not applicable, where systems belong to a provider, or where a component was tested separately within the same cycle. Say which of those applies.

Do we need internal network testing as well as external?

It depends on which controls you declared applicable. If A.8.22 on segregation of networks is in your Statement of Applicability, an external test cannot evidence it. If your ISMS scope is a cloud-hosted service with no corporate network in scope, internal testing may be irrelevant.

How long before the audit should the report be dated?

Recent enough to describe the current estate, and old enough that remediation and retest have happened. Six to ten weeks before Stage 2 works for most organizations. The hard rule is that the report must postdate your last significant change.

Can we reuse a customer-mandated test as ISO 27001 evidence?

Yes, if the scope covers the certified scope and the date is current. Add a short mapping note stating which Annex A controls the report evidences and how the findings entered your risk treatment plan. Without that note the auditor has to do the mapping themselves.

How to scope an ISO 27001 penetration test

Scope is the only part the auditor can check

An auditor cannot evaluate the quality of your penetration test. They are not going to re-run it, and most of them could not. What they can do, in about ninety seconds, is compare the scope statement in the report against the scope of your certificate and the controls in your Statement of Applicability. That comparison is where reports fail.

The failure is nearly always the same shape. The certificate covers “the provision and operation of the platform”, and the report covers one hostname. Or the certificate covers three offices and a cloud tenant, and the report covers an external network range that has not included the cloud tenant since the migration. Nothing in the test was wrong. It was simply evidence about a different thing from the thing being certified.

So scope is not a commercial formality to settle after the technical conversation. It is the part of the engagement that determines whether the output is evidence at all. Write it first, write it from your own documents, and make the tester quote against it rather than the other way round.

The five inputs

Everything you need is already written down somewhere in the ISMS. Pull these five documents into one place before you talk to anybody.

The ISMS scope statement. Clause 4.3 output. The exact sentence on your certificate. It defines the boundary of everything that follows, including which findings are relevant and which are interesting but out of scope.
The Statement of Applicability. Which Annex A controls you declared applicable. This is what tells you whether you need application testing, infrastructure testing, both, or neither. A.8.29 applicable means you develop software and need release-relevant testing. A.8.22 applicable means segmentation claims that should be tested rather than diagrammed.
The asset inventory. A.5.9 output. Cross-check it against reality: an inventory that has not been reconciled with your cloud accounts is the usual source of the asset nobody tested.
The external interface list. Every internet-reachable service, API, admin panel, file transfer endpoint and third-party integration inside the ISMS scope. Most organizations underestimate this by a factor of two, which is a finding in itself.
The identity and role model. Who can log in, at what privilege, through which channel. Authenticated testing against real role boundaries produces evidence for A.8.2 and A.8.5; unauthenticated scanning does not.

Deciding what kind of test you need

The Statement of Applicability answers this more reliably than any vendor questionnaire. Read the applicable controls and let them select the instrument.

From applicable control to test type
If this is applicable	The instrument that produces evidence	What it does not cover
A.8.8 management of technical vulnerabilities	External and internal infrastructure testing, plus authenticated scanning between engagements	Application logic and privilege boundaries inside a product
A.8.29 security testing in development and acceptance	Application and API testing tied to releases, ideally gated in the pipeline	The lifecycle itself, which is evidenced by its own gate records
A.8.22 segregation of networks	A segmentation test that deliberately attempts each claimed boundary crossing	Whether the segmentation design is appropriate in the first place
A.8.5 secure authentication	Authenticated testing of session handling, account recovery and MFA enforcement	Whether MFA is deployed everywhere, which is a coverage report
A.5.23 use of cloud services	A configuration review of your own tenant against a hardening baseline	The provider platform, which you are not permitted to test
A.6.3 awareness and training	A social-engineering assessment or phishing exercise, as a separate engagement	Anything a network or application test produces

The full control-by-control mapping, including the controls where a test proves nothing, is on the home page as the Annex A evidence mapper.

Exclusions you can defend, and one you cannot

Excluding things from a test is normal and often correct. What matters is that the exclusion is written down with a reason, in the report, and that the reason survives being read aloud in an audit.

Provider infrastructure. You cannot test a hyperscaler platform, and their terms say so. Exclude it, and replace it with a configuration review of your own tenant and, where relevant, the provider assurance reports you rely on.
Denial-of-service testing. Almost always excluded, for good operational reasons. Say so explicitly rather than leaving a silence that looks like an oversight.
Systems outside the ISMS scope. Legitimate by definition, but state it. A reader who cannot tell whether something was out of scope or simply missed will assume the latter.
Third-party SaaS you consume. Not yours to test. It belongs in supplier assurance under A.5.19 to A.5.22, not in your test scope.

The exclusion you cannot defend is the one made for price. Removing the busiest interface, the admin panel or the customer-facing API to fit a budget produces a report that costs the same in audit credibility as no report at all. If the budget will not cover the scope your Statement of Applicability implies, narrow the ISMS scope or narrow the certificate. Do not narrow the evidence quietly.

Writing the scope statement

A usable scope statement is four short paragraphs, and it belongs in both the engagement contract and the report. It should be readable by someone who has never seen your network.

The subject. Name the systems the way your ISMS names them, then give the technical identifiers: hostnames, address ranges, cloud accounts, mobile application bundle identifiers, API base paths.
The perspective. Unauthenticated from the internet, authenticated as each defined role, from inside a specific network segment, or from a compromised endpoint. State which roles were provisioned and whether the tester received credentials for each.
The exclusions. Listed with the reason for each, as above.
The link back. One sentence naming the ISMS scope statement and the Annex A controls this test is intended to evidence. This is the sentence that turns a technical document into audit evidence, and almost nobody writes it.

That last line does a disproportionate amount of work. When an auditor picks up a report that says, in its own words, that it was scoped to evidence A.8.8, A.8.22 and A.8.29 against the certified scope, half the conversation has already happened.

Timing against the certification cycle

Accredited certification runs on a three-year cycle, and the audit time inside it is not arbitrary. IAF MD 5:2023, the mandatory document accredited bodies use to calculate audit duration, states that during the initial three-year certification cycle the total time spent annually on surveillance is “about 1/3 of the audit time spent on the initial certification audit”, that the initial audit is Stage 1 plus Stage 2, and that recertification is “normally approximately 2/3” of what a fresh initial audit would take at that point. It also notes that a surveillance audit is unlikely to be shorter than one audit day.

That gives you a fixed calendar to schedule testing against. The recommendations below are practice, not requirements; no clause of ISO/IEC 27001 sets a testing date.

Where testing fits in the certification cycle
Cycle point	Test	Reason
Before Stage 1	No	Stage 1 reviews documentation and readiness. Findings you cannot yet treat only create open items to explain.
Six to ten weeks before Stage 2	Yes	Long enough to remediate and retest, recent enough that the report is current at the audit.
Stage 2	Report in hand	The evidence pack should show findings, decisions, owners, dates and a dated retest.
Surveillance year 1	Yes	Demonstrates that A.8.8 is a running process rather than a push before certification.
Surveillance year 2	Yes	Trend matters here. Two reports should show severity falling and repeat findings disappearing.
Recertification, year 3	Yes, wider	The whole ISMS is re-examined. A scope written three years ago will not match the estate.
After a significant change	Scoped to the change	New product, new region, new interface, acquisition, migration. Record the decision either way.

What moves the price

Nobody can quote a credible number from a web page, and this one will not try. What is worth knowing is which variables actually move a quote, so you can tell a proportionate proposal from a padded one.

Number of distinct applications, not pages. A hundred-page application with one role model is smaller work than three small applications with three role models.
Number of roles to test from. Each authenticated role multiplies the access-control testing surface. Two roles is usually the minimum that evidences A.8.2 and A.8.5 meaningfully.
API surface. Endpoint count and whether machine-readable definitions exist. A current OpenAPI specification measurably reduces effort and is worth producing before the test.
Live hosts in scope for infrastructure work, and whether internal testing needs on-site presence or a deployed device.
Segmentation boundaries to prove. Each claimed boundary is a separate set of attempts.
Retest. Ask for it in the original quote. Retest bought later is always more expensive than retest scoped up front, and it is the single item that most improves the audit value of the report.

One structural point about the cycle. Because the certificate renews annually through surveillance, this is recurring work, and a supplier who knows the estate from last year should be cheaper and faster than a first engagement. If a renewal quote is not lower than the first, ask what changed.

The traps

Five scoping mistakes that show up repeatedly in evidence packs.

Scoping to the network diagram. Diagrams describe intent. Scope from an asset list reconciled against what actually resolves and responds.
Forgetting non-production. If a staging environment holds production data or is reachable from the internet, it is in scope for the risk even when it is out of scope for the certificate. That is an A.8.31 conversation before it is a testing conversation.
Testing only from outside. Unauthenticated external testing is the cheapest engagement and the weakest evidence for the controls most Statements of Applicability declare applicable.
Letting the vendor set the scope. A package priced by number of IP addresses will produce a report priced by number of IP addresses. Your Statement of Applicability is not organized that way.
Scheduling into the audit week. A report that arrives two days before Stage 2 has no remediation window and no retest, which converts a solvable set of findings into a set of open items you have to explain.

Once the scope is right, the next question is what the report has to contain to be usable as evidence. That is covered in the report specification, and the underlying question of what the standard requires at all is in does ISO 27001 require a penetration test.