How to plan an authorized security assessment

Choose a decision the assessment can actually support

Start by writing the decision in one sentence. “Assess security” is not specific enough to choose systems, methods, or evidence. “Determine whether the proposed access change exposes the approved application beyond its intended users” gives the team a narrower question to investigate.

Separate the business consequence from the technical observation. A test might establish that a control behaved a particular way under particular conditions. The business owner still decides whether that result is acceptable. Naming both responsibilities prevents a report from implying more assurance than the work supports.

Define coverage before estimating effort

List the systems and boundaries that could affect the decision. Record which are included, excluded, inaccessible, or dependent on another owner. An inventory is not authorization: a system appearing in a diagram does not automatically become a permitted test target.

Then agree the depth of review. Document review, authenticated checks, and hands-on validation can produce different evidence. A useful scope states what will not be concluded as well as what will be attempted. If a critical dependency is excluded, explain how that limits the final answer.

Assign the decisions that can stop or change work

Identify an engagement owner, an operator, an operational contact, and someone who can approve a scope change. One person may hold several roles, but those decisions should remain distinguishable in the record.

Before starting, establish the operating window, a reachable stop contact, and how urgent findings will be communicated. If the owner is unavailable or the environment changes materially, the agreement should say whether work pauses. Do not let silence become authorization.

Prepare the report while preparing the scope

Decide what evidence the recipient needs to act. For each question, specify the observation, context, limitation, and proposed follow-up. A long tool output is not a substitute for an explanation of what was tested and what it means.

Use the worksheet below during scoping. Add an evidence reference and a status to each row in your working copy. Unresolved scope questions belong in a pre-start decision list, not in a private assumption held by the testing team.

Your working record

Adapt these criteria to the engagement. The CSV includes blank evidence, status, owner, and review-date fields. Nothing is pre-marked as passed. Scroll the table horizontally on small screens.

Worked example: a branch-network change

Illustrative scenario: a company plans to change access between two branch services. The business question is whether the approved application remains reachable only by the intended group. The scope includes those services and the relevant access boundary; a separately operated third-party service is excluded.

The brief records the exclusion and states that the assessment cannot conclude anything about that third party. The customer owns the change decision; the testing lead owns the evidence record. If the actual network differs from the approved diagram, work pauses for clarification rather than extending to newly discovered systems. The useful output is a bounded answer and an explicit limitation—not a claim that the branch is secure.

Source context & further reading

Background on planning technical assessments, understanding technique limitations, analyzing findings, and mitigation. The worksheet here is an original planning aid, not a NIST checklist.

NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment