Scope and authorise a security test

A scope is an agreement about what the test may do and what its results will mean. It should let a tester, service owner and incident contact answer the same practical questions without making assumptions.

Write the objective before listing hostnames. Then connect every system and activity to that objective. The NCSC's penetration-testing guidance recommends involving the risk owner, people who understand the system and the testing team in that conversation.

Establish who can authorise each activity

Record the person or organisation responsible for each asset and the basis on which the testing is permitted. A customer account, domain name or hosting subscription does not automatically establish permission to assess every connected supplier system.

Check applicable supplier terms and obtain any additional authorisation needed before the test. The GOV.UK Service Manual specifically addresses third-party consent when third-party systems are part of an assessment. Requirements depend on the actual service and proposed activity; do not assume another organisation's permission covers yours.

Worked scope: a fictional customer portal

Harbour Workshop wants to check that customers can access only their own job records. The following is a worked planning example, not a ready-to-sign authorisation.

The exact addresses, dates, contacts and approval records belong in the organisation's private engagement document. Do not publish that operational document with an external project portfolio.

Resolve these questions before work begins

The worked example still contains decisions that a real organisation must make:

1. Environment equivalence: which controls differ between staging and production? If the authentication gateway or storage permissions differ, explain which conclusions can transfer.
2. Supplier boundary: does the first-party API call a supplier service during a test? Agree how to prevent an authorised check from extending into an unauthorised system.
3. Data lifecycle: who creates the test records, retains necessary evidence and removes the temporary accounts afterwards?
4. Availability risk: which signals identify harmful impact, who monitors them and who can stop the work?
5. Unplanned discovery: what happens if the tester encounters real personal information, an unexpected system or evidence of a separate incident?

For each open question, record an owner and resolution. A note saying “confirm later” is useful during drafting, but should not survive into an approved test if it affects permission or safety.

Agree stop and restart conditions

Use conditions people can recognise. Examples include unexpected access to live customer data, a service-health threshold agreed with operations, loss of the emergency contact, an unapproved destination, or indications that a real incident is in progress.

The procedure should identify how the tester stops, whom they contact, what limited records they retain and who authorises a restart. Separate “pause this activity” from “end the engagement”. A pause may simply require correcting an account; a scope change needs a recorded decision.

Do not invent a universal request rate or acceptable outage duration. The platform team and provider should agree values that fit the service. Systems with safety or availability constraints need appropriate specialist input before active testing.

Protect the evidence and the report

Agree how credentials and reports will be exchanged, which people may access them and how retained evidence will be handled. Minimise collection of sensitive data: proving an access-control issue with an authorised synthetic record may be sufficient for the objective.

State what a usable report must identify: tested release, coverage, excluded areas, reproducible evidence, impact and recommended next steps. Describe any required retesting separately from the initial test so its effort and timing are understood.

Approval and completion checklist

• The agreed assets and actions have clear ownership and recorded authorisation.
• Scope exclusions and supplier dependencies are understood by both parties.
• Test accounts, environment and emergency contacts have been checked.
• Stop, escalation and scope-change procedures are usable.
• Evidence handling, reporting and retest arrangements are agreed.
• A named person will confirm test-account removal and other cleanup after the work.

Use the security-test scope worksheet to draft the document. Take the completed scope into the provider comparison so quotations describe comparable work.