Scoping and authorisation

Purpose

Many tests go wrong before the first request. The wrong build is deployed, the second tenant has no data, the admin account arrives on day three, or nobody can say whether the payment sandbox is safe to exercise. Scoping exists to remove those failures and to produce two documents everything else depends on: a scope record that says exactly what will be tested, and a written authorisation from someone entitled to give it.

No testing starts from an enquiry, a scoping call or a completed worksheet. Testing starts when the scope record is agreed and the system owner has signed the authorisation.

The scope record

The scope record is a versioned document, not an email thread. It carries an identifier and a date, and every later artefact (test plan, coverage record, report) refers to the version it was built from.

Field	What is recorded
Assets	Hostnames, API base paths, mobile build numbers, repositories if source-assisted
Boundaries	What is explicitly out of scope, and why
Inventory source	OpenAPI or GraphQL schema, collection or route list, with its date
Workflows	The business actions that matter: sign-up, invite, export, refund, approval
Data	Sensitive data categories held, and whether test data is synthetic
Dependencies	Third-party services the application calls, and who owns each

The inventory source matters more than buyers expect. A schema that is six months stale under-counts endpoints and misses the ones most likely to be unprotected. Where the supplied inventory and observed traffic disagree, the difference is logged and raised with the customer, not silently absorbed.

Roles, tenants and accounts

Access-control testing is only as good as the accounts available. The minimum useful set for a multi-tenant product is two accounts per role in each of two tenants. That supports horizontal checks inside a tenant, vertical checks across roles, and cross-tenant checks, without the tester relying on a single identity.

The customer supplies a draft role matrix: each role, what it should be able to do, and anything unusual such as support impersonation, delegated administration, scoped API keys or service accounts. The tester refines it during testing (see chapter 3).

Credentials move through a separately agreed channel, never in the scope record or a ticket. MFA factors for test accounts are part of the account request, because a blocked MFA step on the first morning costs a day.

Environments

The record names the environment and the build or commit under test. It also lists material differences from production: a WAF that is disabled in staging, SSO replaced with local passwords, feature flags in a different state, a payment provider in sandbox mode. Those differences go into the report’s scope section so a reader knows what the results do and do not describe.

Two practical requirements are easy to forget. Outbound email and SMS should land in a sink the tester can read, so password reset and invite flows can be tested end to end. And there should be a known way to reset seed data if a test leaves records in a broken state.

Rules of engagement

Rules of engagement turn intent into limits a tester can follow under time pressure:

• the test window, with timezone, and any freeze periods
• source IP addresses, so the customer can recognise test traffic in logs
• permitted techniques and named exclusions; denial of service, social engineering and physical access are excluded unless separately scoped
• automation ceilings: request rates and concurrency for scanners and fuzzers
• actions with side effects: real emails, payments, webhooks into other systems, deletion
• named contacts on both sides, with a route for urgent findings

Stop conditions

Testing pauses and the customer contact is called if any of these occur: service degradation that may be caused by testing; data that appears to be real personal or payment data in a supposedly synthetic environment; signs of a prior compromise by someone else; access to a system outside the agreed scope; or a finding that the agreed process says must be reported immediately. Testing resumes only on the customer’s instruction, and the pause is recorded.

Written authorisation

The authorisation is signed by someone with authority over the systems. It names the assets by reference to the scope record version, gives the dates and lists the permitted techniques. A purchase order or a chat message saying “go ahead” is not a substitute.

Agency client projects

When an agency commissions a test of a client’s application, the agency usually cannot authorise testing of systems it does not own. The end client, as system owner, signs. Hosting and platform providers may also need to be covered.

Cloud and third-party providers

AWS, Microsoft Azure and Google Cloud each publish penetration testing policies. In general they allow customers to test their own resources on many services and prohibit some activities, such as denial-of-service testing, without separate arrangement. The current text is checked during scoping rather than assumed. Third-party services the application relies on (identity providers, payment processors, email delivery) are out of scope unless the provider has given permission. How the application uses them is in scope; the provider itself is not.

Data handling

The scope record states where evidence is stored, who can access it, how long it is kept and how it is deleted. Evidence is minimised: a screenshot proving that another tenant’s record was returned does not need every field visible. If real personal data turns up, the tester stops collecting it, keeps the minimum needed to describe the issue and notifies the customer.

Synthetic illustration

Synthetic example. Example Ltd is fictional. Example Ltd asks for a test of app.example.com and api.example.com before an enterprise customer’s security review. The supplied OpenAPI file lists 140 operations, but the front-end bundle references a route prefix, /internal/v2/, that the file does not mention. Scope record version 1.1 adds the prefix as “in scope, inventory gap”, notes that staging uses local passwords where production uses SAML single sign-on, and permits the payment sandbox with test cards only. The system owner signs the authorisation against version 1.1.

What evidence looks like

• A scope record with a version number, date and change log
• A signed authorisation that references that version and the test dates
• An account register (account names, never passwords) giving the role and tenant of each account
• A log of pauses, stop-condition events and scope changes, each with a timestamp and the customer contact who approved the next step
• A report scope section that reproduces the boundaries and environment differences