NIST Special Publication 800-115 provides guidance for planning and conducting technical security tests and examinations, analyzing findings, and developing mitigation strategies. It describes techniques including review, target identification and analysis, vulnerability validation, and penetration testing. Each technique has different strengths, limitations, resource needs, and potential impact. A scan can identify a possible weakness without proving exploitability; a penetration test may demonstrate impact but can create operational risk.
\n\nNIST organizes an assessment into planning, execution, and post-execution phases. Planning includes developing a policy, prioritizing and scheduling work, selecting and customizing techniques, managing logistics, identifying constraints, and establishing rules of engagement. Execution collects and validates data. Post-execution analyzes root causes, recommends mitigation, reports results, and supports remediation.
\n\nRules of engagement establish authority and boundaries for the assessment. Relevant subjects include purpose, scope, assumptions and limitations, risks, personnel, schedule, locations, equipment, communication, incident handling, target data, allowable and prohibited activities, data handling, and reporting. Because testing can look malicious, coordination with monitoring and incident-response functions must be intentional without unnecessarily defeating the exercise.
\n\nName the sponsoring executive, system owner, test lead, provider, and person authorized to stop the work. State the objective in terms of the question the test must answer. List approved domains, addresses, applications, accounts, facilities, cloud tenants, interfaces, dates, and time zones. List exclusions just as precisely. Resolve shared hosting, supplier systems, subsidiaries, and dynamic cloud resources before execution.
\n\nConfirm that the authorizing party has authority over every target and technique. Obtain separate written permission where a carrier, cloud provider, software supplier, landlord, or customer environment is involved. An internal contract cannot grant rights over someone else’s system.
\n\nRequire testers to report critical safety or active-compromise findings immediately through the agreed channel. At completion, remove accounts, payloads, persistence, files, firewall changes, test data, and temporary infrastructure; then have the system owner verify cleanup. Record any artifact that cannot be removed.
\n\nReports should separate confirmed exploitation from inferred exposure, state the tested path and conditions, preserve evidence provenance, describe business consequence without overstating it, and identify limitations. Assign remediation owners and acceptance authority. Retest the corrected path and verify that the fix did not merely block one tool signature.
\n\nClose with a joint review of unexpected effects, detection and response performance, communication failures, scope gaps, and assumptions. Retain authorization, final rules, activity logs, evidence index, findings, cleanup confirmation, and retest results under controlled access. Track the disposition of every copied credential or sensitive record and obtain written confirmation when the testing provider completes required deletion. Good rules do not make a test timid; they make its risk deliberate and its conclusions defensible.
\n\n