NIST SP 800-115 Explained

What is NIST SP 800-115?

NIST SP 800-115 is the Technical Guide to Information Security Testing and Assessment, published by the United States National Institute of Standards and Technology. It sets out a four-stage methodology, planning, discovery, attack and reporting, and defines the categories of technical testing technique that other security standards, policies and procurement documents widely reuse.

The publication is available in full from NIST: SP 800-115, Technical Guide to Information Security Testing and Assessment. It was issued in September 2008 and remains the current final version, which is worth knowing before you cite it as the last word on modern infrastructure.

Where SP 800-115 sits among the standards

SP 800-115 belongs to the NIST SP 800 series of computer security publications. Unlike PTES or the OWASP Web Security Testing Guide, which came out of the practitioner and open-source security community, SP 800-115 is a government technical guide, and it reads like one: methodical, technique-focused and organised around repeatable process rather than narrative.

That tone is the point. The guide's purpose is to give an assessor a defensible structure for planning and conducting information security testing, analysing findings and developing effective mitigation strategies, and to supply a shared vocabulary of testing techniques precise enough to write into a contract or an assessment plan.

The four-stage testing methodology

NIST SP 800-115 describes testing as a four-stage process. Each stage feeds the next, and in practice testers often loop between discovery and attack more than once as new access reveals new targets.

Planning

The planning stage sets the rules before any technical work begins: agreeing scope, rules of engagement, objectives, points of contact and how findings will be handled if something sensitive turns up mid-test. NIST treats this stage as essential groundwork rather than administrative overhead, because it is what makes everything that follows authorised and defensible.

The output of planning is an assessment plan specific enough to act on. In practice that means enumerated ranges and exclusions (for example 10.20.0.0/16 in scope with 10.20.9.0/24 excluded), an agreed test window, a named contact who can stop the test, and a stated handling rule for anything sensitive that is discovered along the way.

Discovery

Discovery covers both information gathering and vulnerability analysis. Testers identify live hosts, open ports and running services, then correlate what they find against known vulnerabilities using scanning, banner analysis and manual verification. This stage is where the target environment actually gets mapped out before any attempt is made to exploit anything found within it.

In MITRE ATT&CK terms, the outward-facing half of this stage is Active Scanning (T1595) and the inward-facing half is Network Service Discovery (T1046). The vulnerability analysis that follows is normally anchored to CVSS for severity and to the CISA Known Exploited Vulnerabilities catalogue for whether a weakness is under active exploitation, neither of which existed in their current form when the guide was written.

Attack

The attack stage is where a suspected vulnerability is actually validated by attempting to exploit it. NIST describes this as an iterative process: gaining access, escalating privileges, browsing the compromised system for further targets, and installing additional tools to reach deeper into the environment where authorised. Each successful step commonly feeds back into discovery, because a new foothold usually exposes new targets that were not visible from outside.

That loop maps cleanly onto observed adversary behaviour: gaining access as Exploit Public-Facing Application (T1190), escalating as Exploitation for Privilege Escalation (T1068), and reaching further into the estate as Exploitation of Remote Services (T1210).

Reporting

Reporting runs throughout the engagement rather than only at the end, under the NIST model: findings, risks and recommended mitigations are documented as they are discovered, then consolidated into a final report that gives the organisation both the technical detail needed to fix each issue and the context needed to prioritise the fixes that matter most.

The testing technique categories NIST SP 800-115 defines

Beyond the four-stage methodology, NIST SP 800-115 is also widely referenced for the way it categorises testing techniques themselves, which other standards and RFPs frequently reuse as shared vocabulary. Getting these three terms right is the difference between a scope that buys you an assessment and one that buys you a scan.

• Review techniques examine documentation, configurations, rulesets and logs without actively probing the live environment, evaluating policies, architecture and system configuration against expected baselines. Modern baseline review usually means measuring against a published benchmark such as the CIS Benchmarks rather than against an internally invented standard.
• Target identification and analysis techniques actively probe the environment to find and characterise it: network discovery, port and service identification, and vulnerability scanning fall into this category. This is the category that produces a list of candidate weaknesses, not confirmed ones.
• Target vulnerability validation techniques go a step further and attempt to confirm that an identified weakness is genuinely exploitable, covering penetration testing itself as well as password cracking and social-engineering techniques carried out under agreed authorisation. This is the category most often quietly dropped from a scope, and it is the one that separates a real finding from a candidate.

Testing viewpoints and how much testers are told in advance

NIST SP 800-115 also frames a test by two other dimensions that are worth knowing before you agree a scope with any provider, because they change what a result actually proves.

• Viewpoint: external or internal. An external test is run from outside the organisation's security perimeter, the same vantage point an internet-based attacker starts from. An internal test is run from inside the network, closer to the vantage point of a malicious insider, a compromised device, or an attacker who has already found a foothold. A programme that only ever tests from one viewpoint is only ever answering half the question.
• Prior knowledge: announced or unannounced. An announced test is coordinated in advance with the defensive team, so detection and response are not part of what is being measured. An unannounced test withholds that notice from some or all of the defenders, so the exercise also measures how quickly an intrusion would actually be noticed and acted on. Most routine testing is announced for practical reasons; unannounced testing is typically reserved for organisations that specifically want to exercise detection and response, not just find vulnerabilities.

Who references or mandates NIST SP 800-115

United States federal agencies operate under the Federal Information Security Modernization Act, which requires periodic security testing of federal information systems, and NIST guidance including SP 800-115 is the technical reference agencies commonly draw on to meet that requirement. Beyond government, SP 800-115 is also cited by other standards as one of several accepted testing methodologies, including the penetration testing guidance published by the PCI Security Standards Council, which references it alongside PTES and other recognised methodologies rather than mandating it exclusively.

SP 800-115 is not SP 800-53

It is worth being precise about a common point of confusion. SP 800-115 is a testing methodology guide. SP 800-53 is a completely separate publication: the NIST security and privacy controls catalogue, organised into control families such as access control, incident response and system integrity.

The distinction matters when you are writing a statement of work. SP 800-115 shapes how a test is run. SP 800-53 defines the controls a test's findings get measured against in a compliance report. The two are related in purpose but serve different jobs, and asking for one when you needed the other is a common and expensive scoping mistake.

How NIST SP 800-115 maps to a modern testing programme

SP 800-115 predates widespread cloud adoption, containerised infrastructure and continuous delivery, so it does not speak directly to Kubernetes clusters or CI/CD pipelines. That does not make it dated so much as foundational: its four stages describe a shape that still holds regardless of what technology sits underneath. The table below maps the four NIST stages against where they typically land in a modern seven-phase testing programme.

How PentestOps helps

PentestOps' methodology is aligned to NIST SP 800-115 alongside PTES and OWASP, running the same planning, discovery, attack and reporting shape across external perimeter, internal networks, web applications, APIs, cloud infrastructure and identity in a single platform. Discovery is backed by 24+ external recon modules and 18+ internal modules; attack-stage findings are validated with safe, RoE-gated exploitation rather than left as unconfirmed scanner output, matching the validation NIST expects from its target vulnerability validation techniques.

The review-technique gap that SP 800-115 leaves open on modern infrastructure is covered by a dedicated posture phase: 800+ automated cloud checks across AWS, Azure, GCP and Microsoft 365, and 83 Kubernetes API and RBAC checks over a read-only kubeconfig. See cloud penetration testing and Kubernetes security testing for how those run.

Reports carry the compliance mapping SP 800-115 alone does not provide: findings are mapped to the 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes. Read the full methodology for how the phases run in detail, or start a free demo scan to see discovery run against your own perimeter today.