Security-test scope worksheet
Prepare a clear test scope with blank fields, a fictional worked example and editable downloads covering permission, boundaries and reporting.
Use this worksheet before agreeing a security assessment. It makes the intended business question, test boundaries, permissions and deliverables explicit so that the service owner and provider can resolve gaps together.
The NCSC's commissioning guidance treats scope and communication as part of an effective engagement. This is an original planning template informed by that principle. It is not a contract, legal opinion or authorisation to test. The people entitled to authorise each affected system must agree the actual engagement separately.
Download or print
The Markdown file includes the full worksheet. The CSV uses separate prompt, response and fictional-example columns. Print this page for a paper copy. Completed copies stay in your own files; the website has no submission or saving facility.
How to complete it
Start with the service owner and the person commissioning the test. Ask the prospective provider to challenge the scope before agreeing time and cost. Resolve assets by exact identifiers and environment, not by a vague instruction such as “our website”.
Keep passwords and access tokens out of the worksheet. Refer to the agreed secure delivery method instead. Mark unknown items as unresolved and give each an owner; an unexplained blank can be mistaken for an approval. Revisit the scope when systems, dates or objectives change.
Blank worksheet: purpose and ownership
| Field | Prompt | Your response |
|---|---|---|
| Reference and version | Identify this draft, its date and its owner | |
| Business question | What decision should the assessment support? | |
| Service owner | Who understands and accepts the service's operational risk? | |
| Commissioning contact | Who agrees the work, cost and deliverables? | |
| Provider and test lead | Who will perform and supervise the assessment? | |
| Included assets | List exact hostnames, addresses, applications, versions or account boundaries | |
| Environment and data | State production, staging or lab; identify the data classification and permitted test data | |
| Exclusions | State systems, activities, accounts and data that must not be accessed |
Blank worksheet: authority and operation
| Field | Prompt | Your response |
|---|---|---|
| Authority to approve | Identify the owner or controller of each affected asset and the approval record | |
| Third-party dependencies | Identify hosting, SaaS, suppliers and other services; record their permissions or exclusions | |
| Access arrangements | Record roles, accounts, source addresses and secure credential delivery | |
| Test window | Give calendar dates, time zone and permitted working hours | |
| Allowed methods | Agree the kinds of activity the provider may carry out | |
| Prohibited methods | Record destructive, availability-affecting or other excluded actions | |
| Stop conditions | Define observable circumstances requiring a pause | |
| Emergency contact | Name the reachable roles and agreed out-of-band contact route | |
| Restart authority | State who can approve continuing after a stop |
Blank worksheet: evidence and completion
| Field | Prompt | Your response |
|---|---|---|
| Evidence handling | Agree what may be captured, how it is protected and who may access it | |
| Reporting | Specify audience, finding detail, delivery route and urgent escalation | |
| Retest | Agree scope, timing, evidence and any commercial limits | |
| Clean-up | List account removal, test-data deletion and other agreed restoration work | |
| Retention and deletion | State the agreed retention period, deletion process and any required exceptions | |
| Open questions and approvals | Assign each unresolved item and record the final approval/version before work begins |
Worked example: an isolated order-service assessment
Entirely fictional example. Merefield Supply wants to examine access boundaries in an isolated training deployment of an order service. The .test hostname, people represented by roles, dates and approvals below are invented. This example grants no authority over any real system.
| Field | Completed example |
|---|---|
| Reference and version | MS-TRAIN-01, version 1, example prepared 2 November 2026; commissioning owner: IT lead |
| Business question | Can the two defined staff roles access only the synthetic orders their permissions allow? |
| Service owner | Operations manager for the training order service |
| Commissioning contact | IT lead, responsible for agreeing the written engagement |
| Provider and test lead | Named provider and lead recorded in the fictional engagement; substitutions require written agreement |
| Included assets | Only https://orders.merefield.test/ in the isolated lab, and the two supplied test-role accounts |
| Environment and data | Lab deployment on company-owned infrastructure; generated customers and orders only |
| Exclusions | Production systems, real customer accounts, email delivery, payment processing and any host outside the named lab service |
| Authority to approve | Fictional service owner and infrastructure owner sign off version 1 of the scope before access is released |
| Third-party dependencies | Payment and email are local stubs with no external connection; provider confirms this with the infrastructure owner |
| Access arrangements | Two named test accounts with different roles; credentials provided through an agreed secure channel; no secrets in this document |
| Test window | Invented window: 12 November 2026, 10:00–14:00, Europe/London |
| Allowed methods | Manual review of the agreed role boundaries and controlled requests within the lab; method details agreed with the lead |
| Prohibited methods | Availability stress, destructive changes, persistence, social engineering and requests to external systems |
| Stop conditions | Unexpected connection to production, discovery of real customer data, loss of service or contact availability, or an unexplained environment mismatch |
| Emergency contact | Test lead calls the IT lead through the pre-agreed telephone route; operations manager is the backup contact |
| Restart authority | Both service owner and test lead must record approval after the cause of the pause is understood |
| Evidence handling | Capture only the minimum synthetic records needed to explain a finding; encrypted transfer and access limited to the agreed recipients |
| Reporting | Short management summary plus reproducible findings with affected roles, evidence, limitations and suggested fixes; critical discoveries escalated during the session |
| Retest | One agreed review of corrected access boundaries within the same lab; expanded scope requires a new agreement |
| Clean-up | Remove test accounts, delete generated test artefacts and confirm the lab returns to its documented state |
| Retention and deletion | Example agreement: evidence kept for 30 days after report acceptance, then deleted unless the parties document an exception |
| Open questions and approvals | Confirm the external stubs are disconnected and the emergency contacts are reachable; record the check before the fictional start time |
The example deliberately narrows the question. It would not support a claim that the entire business or all order-service functionality had been tested. The selected retention period is an invented engagement term, not a universal rule.
Check the draft with the provider
Ask the provider to explain what can realistically be established with the agreed access and time. Confirm that the reporting detail is sufficient for the people who will implement fixes. Make the intended retest explicit so that the final report does not become the last interaction.
Before work begins, verify that the parties are referring to the same final version, approvals are recorded, contacts work and the environment still matches the scope. If an asset or dependency remains ambiguous, resolve it before allowing activity on that asset.
The scoping and authorisation guide explains the decisions behind these fields. Follow it with provider selection and retesting when planning the full engagement.
Sources and further reading
- NCSC: Penetration testing — checked 2 November 2026