Security Assessment Scope Definition Workbook
Security assessment scope is a testable inventory of authorised boundaries. It prevents accidental work against a wrong tenant, shared service, third-party platform, or production system that looks similar to an approved target. NIST testing guidance treats planning as part of technical assessment; scope workbook turns planning into fields that an assessor, asset owner, and operations team can check before discovery starts.
Identify assets beyond hostnames
For every target, record stable asset identity, hostname or URL, IP range where relevant, cloud account or tenant, environment, business service, data classification, owner, and change window. State whether dynamically discovered subdomains, containers, APIs, mobile builds, or external integrations are included. An address list without an owner and environment is incomplete: addresses are reused, CDN routes are shared, and a name can resolve differently from each test location.
Separate in-scope assets from context-only dependencies. A payment processor endpoint may be necessary to understand a transaction but remain excluded because it is third party. Record evidence of authority before including any provider-managed service. When uncertain, exclude and ask owner; no inferred authority exists because a target references a service.
Use an environment and credential matrix
Credentials are controlled test material, not a convenience. Provide only roles needed for approved cases. The matrix should show tenant, environment, account identifier or secure reference, role, authentication method, expiry, reset owner, permitted data, and allowed test actions. Never put plaintext passwords or API tokens in this workbook. Link to approved secure transfer instead.
| Asset or service | Environment | Owner | Test identity and role | Included actions | Result |
|---|---|---|---|---|---|
| Customer portal | staging tenant | product owner | reader and standard user | auth and workflow tests | Ready |
| Admin API | production | platform owner | no credentials issued | configuration review only | Restricted |
| Payment provider | external | vendor | none | none | Excluded |
10.20.0.0/24 | lab | infrastructure owner | lab admin | approved service discovery | Ready |
This completed example is illustrative. “Ready” requires owner confirmation, working login or access path where applicable, and a clear permitted method. “Restricted” must state what remains allowed, not merely what is unavailable.
Define exclusions and safety limits
List denied actions and target classes: service disruption, destructive changes, persistence, production data export, social engineering, third-party systems, wireless, physical premises, or load testing unless explicitly authorised. Add rate limits, testing hours, notification requirements, and stop conditions. Scope document should link to rules of engagement rather than repeat emergency contacts inconsistently.
For each ambiguity, write resolution and evidence. Example: wildcard *.example.test is limited to DNS records owned by named tenant; a vendor CDN is excluded; an unfamiliar record triggers stop and owner confirmation. This is stronger than “all subdomains” because it yields a pass/fail decision during testing.
Approve, test, and update
Before work, assessor validates target resolution and access from approved test source without conducting unauthorised enumeration. Owner checks asset list and environment labels. Operations confirms window and monitoring contact. Pass requires all three and a signed or otherwise recorded authorisation. Fail includes expired credential, missing owner, contradictory environment label, unknown cloud account, or missing third-party authority. Failed scope blocks work, not only a report note.
When scope changes, create a dated amendment with changed asset, method, owner, authoriser, safety impact, and expiry. Do not overwrite original workbook. Final package links scope, ROE, activity log, evidence inventory, findings, remediation owner, and any agreed retest. This preserves a clear answer to what was tested, what was deliberately not tested, and why.
Evidence handoff
Give each scope row a stable identifier and link it to authorisation evidence, owner confirmation, and test results. This avoids ambiguity when an asset name changes during the engagement. Record failed access separately from excluded access: failure may require remediation or credential correction, while exclusion means no test should occur. At close, reconcile activity-log targets against approved rows and investigate any mismatch before report delivery. A clean reconciliation is evidence that scope controls operated, not evidence that every target was secure. Retain amendments with the final package so later reviewers can understand decisions made during work.
Scope closure test
Before authorizing first request, trace one completed row from approval to action: SC-14 names api.staging.example, tenant stg-14, product owner, test role, permitted authorization checks, source IP, window, and stop contact. DNS resolving to a different tenant, a missing test role, or a target absent from the activity log is a stop condition. At closure, the engagement lead signs the reconciliation or records every unmatched row with owner and resolution; unresolved mismatch leaves scope control open.
Final scope control reconciles every logged action to approved asset, role, source address, time window, and activity type. Expected result: no observation or test action lacks authorization context. Edge case: asset ownership transfers during engagement; pause affected work until record changes. Close only when owner accepts reconciliation and unresolved items remain explicitly open.