NIST SP 800-115: the four phases, technique categories and Rules of Engagement

What NIST SP 800-115 is

NIST published the guide in September 2008 through its Computer Security Resource Center. The authors are Karen Scarfone, Murugiah Souppaya, Amanda Cody and Angela Orebaugh. It replaced SP 800-42 on network security testing. As of 29 August 2026, NIST still lists SP 800-115 as the final published version and has not announced a replacement schedule.^[1]

The guide serves both testers and customers. For testers it provides a repeatable process and a catalogue of techniques. For organizations commissioning an assessment, it provides a basis for scoping, authorization, communication and acceptance criteria. For operations teams, it explains what the testing team may do to production or test infrastructure and what evidence should remain afterwards.

Its value lies less in specific tools than in process discipline. A port scan is still a port scan even if the product used to perform it changes. Planning, discovery, controlled attack and reporting remain relevant even when the target has moved from a 2008 server to a modern cloud environment.

What the guide does not cover well

Technology has moved far beyond the environment of 2008. The guide does not provide detailed methods for modern cloud control planes, containers and orchestration, GraphQL and gRPC APIs, modern mobile ecosystems, OT/ICS environments or machine-learning systems. Its phases may still be used, but specialist techniques should come from more current sources. The annual ENISA threat review shows the direction of travel.^[14]

Useful complementary references include NIST SP 800-53 for security controls^[9], SP 800-53A for assessment procedures, SP 800-30 for risk assessment^[10], SP 800-218 for secure software development, NIST CSF 2.0^[12], OWASP WSTG^[2], MITRE ATT&CK^[11], and technology-specific guidance.

The four penetration-testing phases

SP 800-115 presents penetration testing as a sequence of planning, discovery, attack and reporting. Reporting is not only a final activity: evidence and material findings should be documented and communicated throughout the engagement.^[1]

Planning

Planning determines the value and safety of the assessment. The parties should define the objective, scope and exclusions, choose suitable techniques, prepare Rules of Engagement (ROE), obtain authorization, identify communication channels and escalation paths, and agree how critical findings will be handled.

A weak planning phase produces predictable problems: findings cannot be prioritized because the objective is unclear, systems outside the intended scope are touched, or a critical issue waits in a mailbox because no escalation path was agreed.

Discovery

Discovery begins with passive reconnaissance and may proceed to active identification of hosts, services, versions, operating systems and application entry points. In web applications this includes mapping authentication mechanisms, roles, parameters, interfaces and exposed technologies.

The result is a set of hypotheses about possible weaknesses. A scanner finding is not yet proof that a vulnerability is exploitable in the assessed environment.

Attack

The attack phase verifies whether identified weaknesses can be exploited within the authorized scope. Activities may include obtaining access, privilege escalation, limited lateral movement, and demonstrating impact. Data exfiltration should normally be simulated or minimized rather than performed merely to prove that it would be possible.

The test should end with cleanup: accounts, tools, implants and persistence mechanisms introduced by the assessment must be removed or explicitly transferred to the client for controlled handling.

Reporting

Evidence collection starts during the test. Screenshots, requests and responses, command output, timestamps and logs are most reliable when captured at the time of verification. Critical findings should be communicated without waiting for the final document.

The final report should allow the client to understand scope, methodology, limitations, attack paths, evidence, business relevance and remediation. Length is not a quality metric. A concise reproducible finding is more valuable than pages of raw scanner output.

Three categories of techniques

SP 800-115 groups techniques by their level of interaction with the target environment.^[1]

Review techniques are useful for comparing intended and actual states, and often reveal more than a scan. Validation techniques carry greater operational and legal risk and therefore require particularly clear authorization and ROE.

Rules of Engagement and authorization

ROE is the project document that records the operating rules before testing begins. A useful ROE defines at least:^[1]

• systems and addresses in scope and explicitly excluded;
• source infrastructure used by the testers;
• time windows and maintenance constraints;
• permitted and prohibited techniques;
• conditions for stopping or suspending the test;
• contacts and escalation paths;
• handling of sensitive and personal data;
• evidence retention and destruction;
• cleanup responsibilities;
• communication of critical findings.

Written authorization should come from a person who actually has authority over the systems and activities covered by the test. A signature from someone who does not control the relevant infrastructure does not automatically create permission to test third-party or shared systems.

Authorization is important both technically and legally. It defines the limits within which the tester is expected to act and reduces the risk of exceeding permitted access. Polish criminal-law implications depend on the concrete conduct, scope of consent and circumstances; they should not be reduced to the claim that the absence of a particular ROE form automatically makes every test a crime.

Black box, gray box and white box

Black-box testing provides minimal prior information and better reflects the initial perspective of an external attacker, but more time may be spent on discovery.

White-box testing provides architecture, credentials, documentation and sometimes source code. It can increase coverage and efficiency when the objective is to find as many weaknesses as possible, but it does not simulate the information constraints of an external attacker.

Gray-box testing provides partial knowledge, such as ordinary user credentials and a basic architecture description. It can represent a compromised-user or insider scenario while preserving testing efficiency.

The model should follow the assessment objective. Completeness reviews may justify white or gray box access; adversary simulations may deliberately restrict what the offensive team knows. There is no universal mapping such as "compliance equals gray box".

Vulnerability scanning and penetration testing

These are different services and they answer different questions. In procurement they are often confused because both can use some of the same tools, but their purpose, evidence and cadence are different.

Vulnerability scanning is largely automated. It identifies hosts, services, versions and configuration indicators and compares them with databases of known weaknesses. SP 800-115 discusses vulnerability scanning in section 4.3. A scan can be repeated frequently and is useful for maintaining visibility of known exposure, but a scanner normally does not prove whether a reported weakness is exploitable in the exact configuration of the target or what business consequence successful exploitation would have.

A penetration test adds controlled exploitation and human reasoning. The tester validates weaknesses, combines them where appropriate and demonstrates an attack path under agreed Rules of Engagement. SP 800-115 discusses penetration testing in section 5.2. The output should therefore be more than a CVE list: it should include reproducible evidence, impact, limitations and remediation guidance.

The two activities complement each other. Scanning without deeper validation can create an unverified queue of findings. A penetration test without continuous or periodic vulnerability management gives only a point-in-time picture of an environment that keeps changing. The appropriate frequency of each should follow exposure, change rate, criticality and applicable requirements rather than a universal calendar rule.

Reporting: the durable product of the assessment

SP 800-115 addresses reporting as part of post-testing activities.^[1] The report is the durable output of the engagement and determines whether testing changes anything after the offensive work ends.

A useful structure starts with an executive summary written without unnecessary technical jargon. It should state scope, objective, the most consequential attack paths, material limitations and the main remediation priorities. The technical part should then explain methodology, test period, knowledge model, tools where relevant and the evidence behind each finding.

Each technical finding should be reproducible. A strong entry identifies affected systems, describes the weakness, provides evidence and reproduction steps, explains technical and organizational impact and proposes remediation. CVE and CWE references can support classification, while CVSS can help communicate technical severity, but the business context of the organization remains necessary for prioritization.

Remediation deadlines are not prescribed by SP 800-115. A rule such as "critical in seven days, high in thirty days" is an organizational or contractual policy, not a NIST requirement. The report should therefore distinguish the technical severity assessment of the tester from the remediation SLA and risk-acceptance process of the client.

The report itself is sensitive. It can contain credentials, internal addresses, attack paths and evidence that would materially help an attacker. Delivery should use an appropriately protected channel, with access limited to the intended recipients. Where files are transferred separately, integrity checks and agreed retention or destruction rules are sensible controls.

A management debrief and a technical remediation workshop often produce more value than simply emailing the document. The first translates findings into decisions and ownership; the second helps system owners understand reproduction, root cause and safe remediation.

Legal and authorization issues in the Polish context

Technically, an unauthorized penetration test can look exactly like an attack. Good intentions are not a substitute for permission. Written authorization and Rules of Engagement are therefore central controls, but their legal effect depends on the actual authority of the person granting permission and on whether the tested systems are within that authority.

In Poland, computer-related offences in the Criminal Code can become relevant when access, interference or security-tool activity exceeds authorization. The exact legal assessment depends on the conduct and circumstances. This is why a professional engagement should define systems, techniques, time windows, prohibited actions and emergency contacts before testing starts rather than rely on a generic statement that security testing is permitted.

Third-party infrastructure creates a recurring boundary problem. The customer may own an application but not the hosting platform, network, SaaS service or shared cloud substrate. Consent from the application owner does not automatically authorize disruptive testing of infrastructure controlled by another provider. Provider policies and any required authorization should be checked before execution.

Personal data can also appear unexpectedly during testing. Credentials, mailbox content, logs and application records may all contain personal or confidential information. ROE should therefore define minimization, evidence handling, access restrictions, retention and cleanup before the tester encounters such data. The test does not suspend GDPR or confidentiality duties.

Retesting and cleanup

An engagement should end with more than a report. Accounts, test tools, payloads, uploaded files, persistence mechanisms and temporary firewall or application exceptions created during the test should be removed or explicitly transferred to the client. Cleanup evidence is especially important when the test included post-exploitation or red-team techniques.

Retesting verifies remediation rather than repeating the entire engagement. For a corrected finding, the tester should confirm that the original exploit path no longer works and that the fix did not merely hide one symptom while leaving the underlying weakness accessible through another route. A finding should not be marked closed solely because the system owner states that a patch or configuration change was applied.

A retest also provides evidence for audit and risk-management processes. It can distinguish findings that were fixed, accepted, mitigated by compensating controls or remain open. That status is more useful to management than a static list from the original report.

Methodologies used alongside SP 800-115

OWASP WSTG^[2] provides detailed techniques for web applications. PTES^[5] offers an engagement-oriented penetration-testing process. OSSTMM^[4] provides another methodology and measurement model. MITRE ATT&CK^[11] helps describe adversary behavior and detection coverage. For regulated financial threat-led testing, the current TIBER-EU framework^[6] and the DORA TLPT rules are more specific than SP 800-115.

OWASP Top 10^[3] is useful as an awareness and risk-communication catalogue, but it is not a penetration-testing methodology. CIS Controls v8.1^[13] can help connect findings with a broader defensive programme, while ENISA Threat Landscape 2025^[14] can inform threat scenarios relevant to European organizations.

No serious engagement needs to be loyal to only one document. The appropriate method is selected according to the target, objective, legal regime and required evidence.

Relationship with ISO/IEC 27001, DORA and other frameworks

ISO/IEC 27001:2022^[7] requires an organization to manage information security risks and includes controls relevant to security testing. NIST SP 800-115 can be one source for structuring technical testing, but it is not an ISO requirement.

DORA^[8] and its delegated acts establish a specific regime for digital operational resilience testing and TLPT. SP 800-115 may be a useful supplementary methodology, but DORA does not make it the prescribed TLPT standard.

NIST CSF 2.0^[12] operates at a higher level, organizing cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond and Recover. SP 800-115 supports only a part of that broader risk-management system.

Common mistakes

• Running a scanner and calling the result a penetration test.
• Starting without a written scope and explicit exclusions.
• Authorization signed by a person who lacks authority over the tested systems.
• Testing the infrastructure of a provider or a shared platform without checking the rules of that provider and obtaining consent.
• Reporting findings without reproducible evidence.
• Using CVSS alone as the business-risk rating of the organization.
• Leaving test accounts, tools or persistence mechanisms in the environment.
• Treating a one-time result as permanent assurance.
• Skipping retesting after remediation.

Ten questions before commissioning a test

1. What is the objective: compliance evidence, gap analysis, or adversary simulation?
2. What exactly is in scope and out of scope?
3. What knowledge model will be used and why?
4. Which methodologies will guide the work?
5. Are Rules of Engagement agreed before testing begins?
6. Is authorization signed by an appropriately empowered person?
7. What experience do the actual testers have in the technologies in scope?
8. How will personal, confidential and regulated data be handled?
9. What will the report contain and how will it be transferred securely?
10. Will important findings be retested after remediation?