NIST Guidelines for Penetration Testing

NIST's published guidance for penetration testing establishes the foundational methodology, scoping standards, and assessment classifications that govern how US federal agencies and compliance-driven private sector organizations structure authorized security testing. The primary document in this framework, NIST SP 800-115, defines terminology, phases, and techniques that have been adopted across PCI DSS, FedRAMP, and FISMA compliance programs. This page covers the definition and regulatory scope of NIST's penetration testing framework, its phased structure, the scenarios in which it applies, and the decision boundaries that determine which testing approach applies to a given environment.

Definition and scope

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, published by the National Institute of Standards and Technology, defines penetration testing as "security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network." This formal definition places penetration testing in a distinct category from vulnerability scanning: scanners enumerate weaknesses; a penetration test demonstrates exploitability through active, human-driven attack simulation.

The scope of NIST's penetration testing guidance covers four primary target categories:

  1. Network infrastructure — firewalls, routers, switches, VPN concentrators, and segmentation controls
  2. Host-based systems — servers, workstations, and operating system configurations
  3. Web applications — HTTP/HTTPS attack surfaces, authentication logic, and injection vectors
  4. Wireless networks — 802.11 configurations, encryption protocols, and rogue access point detection

NIST SP 800-115 operates within the broader NIST Cybersecurity Framework and is cross-referenced by NIST SP 800-53, Security and Privacy Controls for Information Systems and Organizations (csrc.nist.gov), which lists penetration testing under the CA (Assessment, Authorization, and Monitoring) control family, specifically CA-8. Organizations subject to FISMA — which covers all US federal agencies and their contractors — must align their security assessments with SP 800-53 controls, making NIST's penetration testing methodology a compliance obligation rather than an advisory preference.

The legal boundary separating authorized penetration testing from criminal intrusion is defined by the Computer Fraud and Abuse Act (18 U.S.C. § 1030). NIST SP 800-115 directly addresses this distinction by requiring written authorization and formally documented rules of engagement before any test activity begins.

How it works

NIST SP 800-115 structures penetration testing as a four-phase process. Each phase produces discrete outputs that feed the next, forming an auditable chain of evidence.

Phase 1 — Planning
The planning phase establishes the rules of engagement, scope boundaries, legal authorization documents, and success criteria. NIST identifies three scope dimensions: target identification (IP ranges, application URLs, physical locations), technique constraints (passive vs. active exploitation, social engineering inclusion or exclusion), and timing windows (business hours vs. off-hours testing). The output is a written test plan reviewed and signed by the authorizing official.

Phase 2 — Discovery
Discovery encompasses two sub-phases: passive reconnaissance (open-source intelligence, DNS enumeration, public record analysis) and active scanning (port scanning, service fingerprinting, vulnerability enumeration). NIST distinguishes passive discovery, which generates no traffic to the target, from active discovery, which does — a distinction material to network penetration testing in sensitive production environments.

Phase 3 — Attack
The attack phase is the active exploitation stage. NIST SP 800-115 categorizes attack techniques across four dimensions: gaining access (exploiting vulnerabilities to establish an initial foothold), escalating privilege (privilege escalation techniques to achieve higher system access), system browsing (enumerating data and network paths post-compromise), and installing additional tools (establishing persistence or pivoting to secondary targets). The attack phase is bounded entirely by the authorized scope defined in Phase 1.

Phase 4 — Reporting
The reporting phase documents findings with three required components: executive summary (risk impact in non-technical terms), technical findings (vulnerability details, evidence, and reproduction steps), and remediation recommendations. NIST SP 800-115 specifies that findings must be classified by severity and linked to specific control gaps within the system's security plan.

Common scenarios

Federal agency assessment under FISMA
Federal agencies conducting Authorization to Operate (ATO) processes under FISMA must include penetration testing as part of their security assessment packages. The assessment follows SP 800-115 methodology and feeds directly into the system security plan reviewed by an Authorizing Official. FedRAMP penetration testing requirements for cloud service providers extend this framework to commercial entities seeking federal cloud authorization, mandating testing against all 17 FedRAMP-designated attack surface categories.

PCI DSS compliance testing
PCI DSS v4.0, Requirement 11.4 (PCI Security Standards Council), mandates penetration testing at least once every 12 months and after any significant infrastructure or application changes. Organizations in scope for PCI DSS commonly align their methodology to NIST SP 800-115, as the standard satisfies the "industry-accepted penetration testing methodology" language in Requirement 11.4.1.

SCADA and critical infrastructure
NIST SP 800-82, Guide to Industrial Control Systems (ICS) Security, extends penetration testing guidance to operational technology environments. Testing of SCADA and ICS systems requires modified discovery and attack phases to avoid disrupting physical processes — a constraint that compresses the active exploitation window and limits tool selection compared to IT network testing.

Internal red team operations
Large federal and enterprise environments use NIST SP 800-115 as a baseline for red team operations that simulate advanced persistent threat behavior. These engagements layer MITRE ATT&CK tactics over the SP 800-115 phase structure, allowing teams to map findings directly to known adversary techniques documented in the ATT&CK knowledge base (attack.mitre.org).

Decision boundaries

NIST SP 800-115 vs. PTES
The Penetration Testing Execution Standard (PTES) provides more granular technical guidance than SP 800-115 — seven phases versus four — and includes detailed pre-engagement and exploitation sub-categories that SP 800-115 leaves to tester discretion. SP 800-115 is the controlling document for FISMA and FedRAMP compliance; PTES is widely used in commercial engagements where no federal mandate applies.

NIST SP 800-115 vs. OWASP Testing Guide
The OWASP Testing Guide addresses web application attack surfaces at a level of specificity (over 90 individual test cases in OTGv4) that SP 800-115 does not attempt. SP 800-115 governs the overall assessment process; the OWASP Testing Guide governs technique selection within the web application scope of that process. Compliance-driven engagements in healthcare and financial services routinely combine both frameworks.

Black-box vs. white-box testing under NIST
SP 800-115 recognizes three knowledge-level variants of penetration testing — zero knowledge (black-box), full knowledge (white-box), and partial knowledge (gray-box). Full-knowledge testing, where testers receive system architecture documentation and credentials before the engagement, produces higher coverage of internal control gaps and is the recommended approach for FISMA system assessments where completeness of coverage takes priority over simulating an external attacker. The tradeoffs across these models are addressed in detail at black-box, white-box, and gray-box testing.

When NIST guidance does not apply
NIST SP 800-115 does not govern bug bounty programs, continuous automated scanning, or red team exercises that operate under separate program charters. Organizations using automated vs. manual penetration testing combinations should assess whether automated tooling satisfies the "exploitation" requirement in CA-8 — NIST and most auditors classify automated scanning as vulnerability assessment, not penetration testing, under SP 800-115 definitions.

References

📜 2 regulatory citations referenced  ·  🔍 Monitored by ANA Regulatory Watch  ·  View update log

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator