What the conversation should produce.
- A decision statement naming the single question the assessment must answer.
- A scope and authority document listing systems, techniques, times and exclusions.
- A findings review record with ownership, timelines and evidence links.
Frame one decision and agree what evidence would help
Every assessment starts with a single decision: which risk or control question matters most right now. Vague ambitions produce vague evidence. The team should write one sentence stating the decision, then list the minimum evidence that would make that decision defensible. This forces the engagement to answer a real question instead of collecting data that looks impressive but cannot guide action.
Agreeing on evidence also means naming what will not be collected and why. A decision about external-facing systems, for example, does not automatically require testing internal network segmentation. Stating the boundary up front prevents scope creep and keeps the assessment focused on the decision that stakeholders actually need to make before the work begins.
Make the scope, authority and exclusions explicit
Record the scope as part of the engagement agreement: included systems and environments, permitted activities, assumptions and operating conditions. Confirm that the people authorising the work have the relevant authority for those assets and activities. Scope describes the boundary; authorisation establishes the permission within it. Neither should be inferred from a sponsor’s interest alone, and written permission does not remove the need for operational controls or eliminate the possibility of unexpected effects.
Exclusions are equally important and often neglected. Certain systems, third-party services or data types may be deliberately left out because they are too sensitive or too critical to touch during the assessment window. Recording exclusions prevents later disputes about why something was not tested and clarifies where the evidence simply does not extend.
Prepare communications, accounts and exercise controls
Before any testing begins, the team should confirm how alerts will be routed, who receives them, and which contacts can authorise an immediate pause. A short communication plan prevents panic when a monitoring system flags legitimate activity as an incident. The plan should also name the escalation path if a test reveals an active compromise that must be handled separately.
Accounts and exercise controls require their own preparation. Test accounts must be provisioned in advance, with documented permissions and a clear expiry date. Exercise controls such as rate limits, maintenance windows and rollback procedures should be confirmed with the operations team to reduce avoidable disruption and give temporary access a clear lifecycle.
Conduct the agreed assessment with proportionate evidence collection
The assessment proceeds by collecting only the evidence needed to address the decision stated in chapter one. Each observation should be recorded with the time, the system involved, the technique used and the raw result. This discipline keeps the evidence traceable and prevents the report from drifting into speculation or unverified inference.
Agree what evidence is sufficient for the question and avoid collecting additional sensitive material without a purpose. If an activity produces no observed result, record the conditions and limits rather than interpreting absence as proof of safety. Unexpected observations may justify a discussion with the agreed contact, a change in emphasis or a separately authorised extension. Proportionality means preserving useful evidence while keeping the work within its objective, not following every possible lead simply because it has become visible.
Review findings with the people who must act on them
Findings should be reviewed with the engineers and managers who will implement the remediation, not only with executives who approve the budget. The review meeting must separate observed facts from hypotheses, and it should explicitly mark areas that were not tested. This distinction prevents the audience from assuming that a gap in testing is a gap in security.
A useful review also assigns ownership and a realistic timeline for each finding. Without ownership, findings become a shared responsibility and therefore nobody's responsibility. The team should leave the meeting with a short list of actions, the people accountable for them and the evidence each action is intended to address.
Close out, retain agreed records and define any follow-up
Close out temporary access, accounts and assessment artefacts according to the agreed responsibilities. Confirm what was removed or revoked and record anything that must remain temporarily for an owned reason. Keep the report and supporting records in the agreed locations with clear access and retention arrangements. Closure should provide a traceable status, including unresolved items, rather than a blanket statement that every possible artefact has disappeared. Confirm the remaining follow-up with the relevant owners before treating the engagement as complete.
Follow-up is defined at close-out, not discovered later. If a remediation requires a retest, the engagement should state whether that retest is included, what it will cover and what evidence it will collect. A clear follow-up plan prevents the assessment from ending with a list of open findings and no agreed path to closure.
Illustrative scenario: external web application assessment
An organisation in this example plans to assess a customer-facing web application before a public launch. The decision to be made is whether the application can be released without known authentication weaknesses. The scope covers the application and its authentication service, excludes the payment processor hosted by a third party, and authorises only non-destructive testing during a defined maintenance window. This scenario is illustrative and does not describe any real engagement.
- Decide whether the authentication weakness is acceptable given the business risk, based on evidence collected from the application and its authentication service only.
- Decide whether to exclude the payment processor from scope because it is managed by a third party and falls outside the agreed authority.
- Decide whether a retest is needed after remediation, and if so, specify which findings the retest will cover and what evidence it will collect.
This scenario establishes that a single decision drives scope, authority and evidence collection. It shows how exclusions are recorded and how follow-up is defined at close-out. It does not prove the application is secure, nor does it address areas outside the agreed scope.
Useful decision table for engagement scoping
| Question | What to establish | Useful output |
|---|---|---|
| Which decision must the assessment answer? | One sentence stating the decision and the minimum evidence that would make it defensible | A decision statement and evidence list |
| What systems and techniques are covered? | Named systems, permitted techniques, and the times when testing may occur | A scope and authority document |
| What is excluded and why? | Each exclusion with a reason, such as third-party ownership or sensitivity | An exclusion register |
Scroll the table horizontally on smaller screens.
Useful questions.
What happens if testing reveals an active compromise?
Use the agreed pause and escalation procedure, share the relevant context with the designated contact and avoid conflating exercise activity with the possible incident. Preserve appropriate evidence within the handling arrangements. The organisation can then decide how its response process should proceed and whether assessment work remains paused, changes scope or ends. Record the effect on coverage without making unsupported conclusions about the incident.
Can the assessment prove the system is secure?
No. An assessment collects evidence about the systems and techniques covered within the agreed scope and time window. It cannot prove the absence of every weakness, nor can it address areas that were excluded or not tested. The report should state what was observed, what was not tested, and what evidence would be needed to answer a different question.
Further reading: NIST SP 800-115: testing and assessment guidance. This independent resource provides background; no affiliation, certification or endorsement is implied.