Resources · Scope and authorisation

The last human action of the engagement, written down

In the fully autonomous model, scope sign-off is the last thing a person does. Everything B-52 does afterwards is checked against that document rather than against anybody’s reading of the situation — so what the document names is the whole of what the engagement is permitted to do.

Below: the eight clauses such a document has to carry, what each one has to name, which of the three approval gates it can settle in advance, how the requirement changes across the eleven coverage classes, and what amending it mid-engagement takes. Take what applies and put it into whatever your procurement and legal teams already use.

Request a scoping call The autonomy boundary

The clauses

Eight things the document has to name

In the order a scope document sets them out. The first four bound what may be touched, the next two bound how far the run may go, and the last two decide what the report is worth once it arrives.

The eight clauses of a penetration testing scope and authorisation
Clause	What it has to name	What a loose version of it costs
The targets	Named the way the class is bought: hostnames and applications for web work; address ranges and domains for a perimeter; a repository and a branch or tag for a code review; a population by group for social engineering; accounts, subscriptions or projects for cloud.	A target written as “the production estate” either stops the run at the first host nobody can place, or authorises something nobody intended. Discovery can propose what answers on a range — only the document can authorise it.
Who is authorising, and on what authority	A named person, their role, and the authority under which they can commit the systems listed. Where a target is operated by somebody else — a hosting provider, a parent company, a customer’s own tenancy — that party’s authorisation is a separate document rather than a line in this one.	Signed by somebody who does not own what it names, and the engagement is testing systems nobody with the standing to permit it has permitted. That is a defect in the assessment, not a formality.
The window	The dates the engagement may run between, and the hours where those are constrained. On social engineering the window is load-bearing rather than administrative.	Without one, your own monitoring team works the run as an incident — and a genuine incident inside the same period gets filed as ours, which is the more expensive direction of the same mistake.
Credentials supplied, and for which roles	One credential per role whose boundary matters, and what each role is meant to reach. Where none are supplied, say so: a run given nothing answers a different question from a run given a standard user account, and both are legitimate scopes.	An authorisation defect is found by holding one role and reaching for another role’s data. A single credential cannot do that, so a scope that names one role has decided in advance which class of defect the report will not contain.
The movement boundary, where the class needs one	Which segments, hosts, domains or trusts may be crossed from the position the run starts in, and which may not. Internal network, Active Directory and external network engagements carry one. A cloud or application engagement carries one where a proved finding may be used to reach further than the thing it was found in.	The second approval gate then gets decided during the run, which means it is decided by whoever is reachable rather than by whoever is accountable. In the fully autonomous model there is nobody in the run to decide it at all, so the run stops.
Which of the three gates are pre-authorised	Each of the three, marked released or held, with the boundary of any release written into it. An approval names a boundary and an engagement rather than a single action — and silence is not a release.	Not a risk of overreach — a gate nobody clearly released stays held. It is a hard limit on what the engagement reaches, set by a sentence nobody read closely at signing rather than by anybody deciding to narrow the work.
The delivery model	Fully autonomous, autonomous expert verified, or human led. All three cover all eleven coverage classes, so this clause settles assurance and whose signature the report carries, never what gets tested.	Chosen after the engagement, and the report that arrives may not be the one the filing needs. Where the assessment is going to an Indian regulator, a CERT-In empanelled auditor has to have been inside the engagement — and that is a scoping decision, not a reporting one.
What changing it requires	A written amendment signed by the same authority, naming what changed and the boundary around it, in place before the run acts on it. Not a reply in a thread, and not a decision taken on a call.	A scope amended in conversation leaves a report describing an engagement that no document authorised. That is the version an auditor reads back to you, and there is nothing to read back with it.

The eight clauses of a penetration testing scope and authorisation

The targets

What it has to name: Named the way the class is bought: hostnames and applications for web work; address ranges and domains for a perimeter; a repository and a branch or tag for a code review; a population by group for social engineering; accounts, subscriptions or projects for cloud.
What a loose version of it costs: A target written as “the production estate” either stops the run at the first host nobody can place, or authorises something nobody intended. Discovery can propose what answers on a range — only the document can authorise it.

Who is authorising, and on what authority

What it has to name: A named person, their role, and the authority under which they can commit the systems listed. Where a target is operated by somebody else — a hosting provider, a parent company, a customer’s own tenancy — that party’s authorisation is a separate document rather than a line in this one.
What a loose version of it costs: Signed by somebody who does not own what it names, and the engagement is testing systems nobody with the standing to permit it has permitted. That is a defect in the assessment, not a formality.

The window

What it has to name: The dates the engagement may run between, and the hours where those are constrained. On social engineering the window is load-bearing rather than administrative.
What a loose version of it costs: Without one, your own monitoring team works the run as an incident — and a genuine incident inside the same period gets filed as ours, which is the more expensive direction of the same mistake.

Credentials supplied, and for which roles

What it has to name: One credential per role whose boundary matters, and what each role is meant to reach. Where none are supplied, say so: a run given nothing answers a different question from a run given a standard user account, and both are legitimate scopes.
What a loose version of it costs: An authorisation defect is found by holding one role and reaching for another role’s data. A single credential cannot do that, so a scope that names one role has decided in advance which class of defect the report will not contain.

The movement boundary, where the class needs one

What it has to name: Which segments, hosts, domains or trusts may be crossed from the position the run starts in, and which may not. Internal network, Active Directory and external network engagements carry one. A cloud or application engagement carries one where a proved finding may be used to reach further than the thing it was found in.
What a loose version of it costs: The second approval gate then gets decided during the run, which means it is decided by whoever is reachable rather than by whoever is accountable. In the fully autonomous model there is nobody in the run to decide it at all, so the run stops.

Which of the three gates are pre-authorised

What it has to name: Each of the three, marked released or held, with the boundary of any release written into it. An approval names a boundary and an engagement rather than a single action — and silence is not a release.
What a loose version of it costs: Not a risk of overreach — a gate nobody clearly released stays held. It is a hard limit on what the engagement reaches, set by a sentence nobody read closely at signing rather than by anybody deciding to narrow the work.

The delivery model

What it has to name: Fully autonomous, autonomous expert verified, or human led. All three cover all eleven coverage classes, so this clause settles assurance and whose signature the report carries, never what gets tested.
What a loose version of it costs: Chosen after the engagement, and the report that arrives may not be the one the filing needs. Where the assessment is going to an Indian regulator, a CERT-In empanelled auditor has to have been inside the engagement — and that is a scoping decision, not a reporting one.

What changing it requires

What it has to name: A written amendment signed by the same authority, naming what changed and the boundary around it, in place before the run acts on it. Not a reply in a thread, and not a decision taken on a call.
What a loose version of it costs: A scope amended in conversation leaves a report describing an engagement that no document authorised. That is the version an auditor reads back to you, and there is nothing to read back with it.

Coverage is not one of the eight, because it is not a clause a scope negotiates. Physical, hardware and wireless testing are out of scope for the platform entirely, in every class, and that holds whatever the document says. Everything else is a scoping question, and the eleven coverage classes state what each of them needs before a run can start.

The gates

Three actions wait for you. The scope decides which of them already have an answer

The same three hold on every coverage class and in all three delivery models, including the one with nobody in it after sign-off. What a scope document can do is release a gate in advance, for a named boundary — which is how the movement gate is handled on an internal or directory engagement, where movement is the thing being bought.

The three approval gates and what a scope document has to name to release each one
Held action	What it covers	What the scope has to name to release it
Destructive or state-changing actions	Anything that alters a production system rather than observing it. A scope can name a production host without anybody having decided that data inside it may be changed — two permissions, and not necessarily the same signature.	Released in the scope only where the scope names the systems it applies to. Held otherwise, and the run stops and asks.
Persistence and movement past the entry host	Holding what has been reached, and moving from the first host to the next. On an internal or directory engagement this is the thing being bought, so it is settled in the scope rather than raised mid-run.	Released in the scope with its boundary written into it. The release covers that boundary for that engagement, and reaching past it is a new decision.
Live credentials or real customer data	A test account is your decision to make in advance. A real one belongs to somebody who is not in the conversation, and reaching it changes who is exposed by the test rather than only what the test finds.	Released in the scope only by naming what may be touched and whose it is. Held otherwise, and the run proves the permission exists and stops at proving it.

Key

Settled in the scope document itself, with a named boundary written into it
Held unless the scope names what the release applies to

Silence is not a release. B-52 does not take a gated action on an implied permission, on a scope that could be read as covering it, or on a verbal yes in a call — so a vague gate clause never produces overreach, it produces a stop. In the two models with a senior auditor inside the engagement that stop costs an exchange of messages. In the fully autonomous model it is the limit of the engagement, because there is nobody to send the message to.

Where a gate was never released, that absence is on the record as plainly as what was allowed, which is the half a reviewer actually reads. Approvals and audit trail sets out the records an engagement leaves behind.

Per class

What each class’s authorisation names that the others do not

The eight clauses are constant. What fills them is not: a target is a hostname on one class, an address range on another, a repository and a commit on a third, and a group of people on a fourth. Each line below is the requirement that class’s own page states, in the same words.

What the authorisation names, by coverage class
Coverage class	What its authorisation names that the others do not
Web application	The hostnames and the applications, written down and signed off; the roles that will be tested with a credential for each; the ASVS level the assessment is worked to, which sets depth rather than breadth; and whether a production system is in scope, which decides how the first gate applies.
Mobile app	The signed release build exactly as you publish it — an APK or an IPA, at a stated version — and whether the backend it calls is in the same engagement or scoped separately as an API. One scan is one application or target, so those are two scopes.
API	The base URL and the environment, because a production interface and its staging twin do not always enforce the same things; a credential for every role whose boundary matters; and the current specification where one exists, read as a starting point rather than accepted as the inventory.
Thick client	The installer or package exactly as you distribute it, at a stated version; a test account per role; which platform and runtime versions are supported, because a client still running on an older one is still in scope for whoever is running it; and whether the server side is inside the same engagement.
External network	The address ranges and the domains. Discovery reconciles what announces, what resolves and what actually answers, and hands that back as a scope proposal — then the authorisation decides what is in, including the hosts the asset list never had.
Internal network	Where the deployed position sits and what it is routed to — every sentence in the report is relative to that position — and the movement boundary: which segments may be crossed from there and which may not.
Cloud	The accounts, subscriptions or projects in scope, named, because an organisation with a management hierarchy has a boundary inside it; a read-only principal and what it is permitted to see; and the benchmark and version the run is measured against, so a rerun measures the same thing.
Active Directory	Which account the run starts from and at what privilege, which is the decision that most changes the answer; whether the scope is one domain, a forest, or more than one with trusts between them, and for a trust, which side is authorised; and which administrative tier may be reached.
Social engineering	The target population by group; the window; the permitted pretexts and the ones that are not; where the engagement stops, at the credential being entered or at what the credential opens; and who inside your organisation knows it is happening.
Secure code review	The repository and the branch or tag, named; which parts of the repository are in scope where one holds more than the application under review; the ASVS level; and whether the deployed system is in the same engagement.
LLM applications	The application and which of its interfaces are in scope; what it retrieves and treats as trustworthy, and who can write into each of those sources; which tools it can invoke and what each is permitted to do; and what the run may cause it to actually do, agreed separately from what it may be asked.

What the authorisation names, by coverage class

Web application

What its authorisation names that the others do not: The hostnames and the applications, written down and signed off; the roles that will be tested with a credential for each; the ASVS level the assessment is worked to, which sets depth rather than breadth; and whether a production system is in scope, which decides how the first gate applies.

Mobile app

What its authorisation names that the others do not: The signed release build exactly as you publish it — an APK or an IPA, at a stated version — and whether the backend it calls is in the same engagement or scoped separately as an API. One scan is one application or target, so those are two scopes.

API

What its authorisation names that the others do not: The base URL and the environment, because a production interface and its staging twin do not always enforce the same things; a credential for every role whose boundary matters; and the current specification where one exists, read as a starting point rather than accepted as the inventory.

Thick client

What its authorisation names that the others do not: The installer or package exactly as you distribute it, at a stated version; a test account per role; which platform and runtime versions are supported, because a client still running on an older one is still in scope for whoever is running it; and whether the server side is inside the same engagement.

External network

What its authorisation names that the others do not: The address ranges and the domains. Discovery reconciles what announces, what resolves and what actually answers, and hands that back as a scope proposal — then the authorisation decides what is in, including the hosts the asset list never had.

Internal network

What its authorisation names that the others do not: Where the deployed position sits and what it is routed to — every sentence in the report is relative to that position — and the movement boundary: which segments may be crossed from there and which may not.

Cloud

What its authorisation names that the others do not: The accounts, subscriptions or projects in scope, named, because an organisation with a management hierarchy has a boundary inside it; a read-only principal and what it is permitted to see; and the benchmark and version the run is measured against, so a rerun measures the same thing.

Active Directory

What its authorisation names that the others do not: Which account the run starts from and at what privilege, which is the decision that most changes the answer; whether the scope is one domain, a forest, or more than one with trusts between them, and for a trust, which side is authorised; and which administrative tier may be reached.

Social engineering

What its authorisation names that the others do not: The target population by group; the window; the permitted pretexts and the ones that are not; where the engagement stops, at the credential being entered or at what the credential opens; and who inside your organisation knows it is happening.

Secure code review

What its authorisation names that the others do not: The repository and the branch or tag, named; which parts of the repository are in scope where one holds more than the application under review; the ASVS level; and whether the deployed system is in the same engagement.

LLM applications

What its authorisation names that the others do not: The application and which of its interfaces are in scope; what it retrieves and treats as trustworthy, and who can write into each of those sources; which tools it can invoke and what each is permitted to do; and what the run may cause it to actually do, agreed separately from what it may be asked.

Changing it

An amendment is a document, not a conversation

Scopes change during engagements. The procedure is short, and the reason it is written down rather than agreed on a call is that the report has to describe an engagement whose whole permission can be produced afterwards.

Something changes

The run reaches the edge of what was authorised

A host discovery surfaced that the asset list never had. A segment behind the entry host. A second repository the application turns out to depend on. In the fully autonomous model there is nobody inside the run to make that call, and that is the design rather than a gap: the edge of the document is the edge of the engagement.
The amendment

The change is written, not discussed

What is being added or removed, which clause it changes, and the boundary around it. An amendment naming a segment authorises that segment — it does not reopen the scope generally, and it does not carry to the next engagement.
The signature

The same authority signs it

Whoever could commit those systems in the original document is whoever can commit them in the amendment. Where the new targets belong to somebody else, that is a fresh authorisation from that party rather than an amendment to yours.
The run resumes

Everything after that point is measured against the amended document

Not against the original, and not against the exchange that produced the amendment. What makes a report filable is that the whole permission behind it is on paper, and an amendment that only exists in a thread breaks exactly that.

Why the document carries so much of it

In the human-led and expert-verified models a scope is the start of a conversation that runs through the engagement, and an auditor absorbs whatever the document left implicit. In the fully autonomous model it is the whole conversation. Everything the platform may do is in it; everything it may not do is either outside it or behind one of the three gates.

That puts real weight on the document, and it is the honest cost of that model. It is also why the gates exist as a separate mechanism: three actions are held whatever else the document says, and a scope opens one only by naming the systems or the boundary the release applies to. Anything it leaves unnamed is asked for on its own terms rather than inferred from the rest of the document.

What counts as an approval

A written approval, naming a boundary and an engagement rather than a single action.
Given by the authority that could commit the systems it names.
In place before the action it permits, rather than recorded after it.

Deliberately excluded

A verbal yes in a call. B-52 does not act on one.
A scope that could be read as covering the action. Silence is not a release.
An unbounded pre-authorisation, which is an approval written in advance for something nobody had seen yet.

Worked examples

Three authorisations that look nothing like each other

A population, a network position and a commit. Same eight clauses, and almost nothing in common once they are filled in — which is why a single form of words for every class would be the wrong artefact to hand anybody.

Social engineering

A population, a window, and the pretexts you will allow

What the targets clause names: The population, by group rather than by whoever reconnaissance happens to surface. Reconnaissance will find people outside that group, and those people stay outside it.
What the boundary clause names: The permitted pretexts and the ones that are not permitted — a decision that belongs to you, and one worth taking properly rather than inheriting from a previous engagement — plus the window, and who inside your organisation knows it is happening.
The clause that decides the engagement: Where it stops: at the credential being entered, or at what the credential opens. Signing in with a captured credential is the third approval gate under another name, and this one line is the difference between an assessment of the way in and an assessment of what the way in was worth.

Internal network

A deployed position, and how far a foothold may travel from it

What the targets clause names: Where the deployed position sits, what it is routed to, and the ranges it may look at. This is the premise of every sentence in the report, which is why it is agreed before anything else.
What the boundary clause names: Which segments may be crossed from there and which may not. Authorising movement inside a named segment authorises it inside that segment for that engagement: B-52 does not return for a second signature on each host it reaches, and it does not read the release as licence to leave the segment.
The clause that decides the engagement: Whether credentials are supplied, and for which roles. A run given none answers a different question from a run given a standard user account. Both are legitimate scopes, and leaving the clause blank picks the question by accident.

Secure code review

A repository, and the commit the report will still describe

What the targets clause names: The repository and the branch or tag. A review of a branch that keeps moving is a review of something that no longer exists by the time the report does.
What the boundary clause names: Which parts of the repository are in scope where one repository holds more than the application under review — and that nothing is committed, branched or opened as a pull request unless you have asked for that in writing. A review reads.
The clause that decides the engagement: Whether the deployed system is in the same engagement. That settles whether a path from input to vulnerable line is walked or only established in the code, and whether a credential found in a commit may be tried anywhere. Reporting the credential and where it was committed needs no further permission; using it does.

Each of these is its own authorisation rather than a clause inside a wider one, so an estate that crosses more than one class needs more than one scope. On the five application classes the unit is already settled — one scan is one application or target, and what a scan covers sets out where that line falls. For the other six, a scoping call is the faster way to settle it.

Sign it off, and the next thing you read is the report

In the fully autonomous model, the observed median from scope sign-off to report delivery is one to three business days. That is a median observed across engagements and published as one, not a service level. The other two models put a senior auditor inside the engagement, and the model is chosen at scoping — in the same document as everything above.

Request a scoping call Compare the three delivery models