Framework

NIST SP 800-115
the federal technical guide to security testing and assessment

NIST Special Publication 800-115, the Technical Guide to Information Security Testing and Assessment, is the United States government reference for how to plan, execute, and report on technical security testing. Run NIST SP 800-115 aligned engagements with structured planning, review evidence, target analysis, validation, exploitation, and reporting tracked on one record.

Get Started Free

No credit card required. Free plan available forever.

NIST SP 800-115: the federal reference for technical security testing

NIST Special Publication 800-115, the Technical Guide to Information Security Testing and Assessment, is the United States National Institute of Standards and Technology reference for how to plan, execute, and report on technical security testing. The publication covers review techniques, target identification, target vulnerability validation, security assessment planning, execution, and reporting in eight numbered sections. NIST SP 800-115 is widely cited in federal contracts, FedRAMP authorisations, CMMC scopes, and the statements of work that flow through the Defense Industrial Base, because it gives compliance reviewers a stable definition of what a technical security assessment looks like.

NIST SP 800-115 sits comfortably alongside more specific catalogues. The OWASP Top 10 and OWASP ASVS cover the web-application phase in depth. The MITRE ATT&CK framework is the language for tagging what attackers do during the engagement. Compliance frameworks like FedRAMP, NIST SP 800-53, and CMMC require penetration testing as a control, and NIST SP 800-115 is the technical methodology most commonly cited by reference to satisfy that requirement.

The four assessment phases

NIST SP 800-115 frames a technical security assessment as four phases: planning, discovery, attack, and reporting. The phases run in order, and each one feeds the next. The standard is unambiguous that an attack phase that is not preceded by a defensible discovery record, or that is not followed by a structured report, is not a 800-115 aligned assessment.

Planning

Identify the rules of engagement, the assessment objectives, the scope, the schedule, the assessment team, the legal and management approvals, the data handling rules, and the post-test reporting structure. NIST SP 800-115 is explicit that planning is where most assessment failures originate, and it dedicates Section 6 to the Security Assessment Plan (SAP) precisely for that reason.

Discovery

Gather information about the target environment using passive review techniques (Section 3), active target identification (Section 4), and the early steps of vulnerability validation (Section 5). Discovery feeds the attack phase rather than substituting for it: a clean discovery record makes the attack phase faster, more focused, and easier to defend in the report.

Attack

Validate vulnerabilities through targeted exploitation, password cracking, and social engineering where in scope. The standard frames the attack phase as validation of discovery rather than a free-form red team operation, so each exploitation attempt traces back to a discovery finding with severity, evidence, and rationale.

Reporting

Produce a technical report covering scope, methodology, findings, evidence, and remediation, alongside an executive summary for non-technical stakeholders. NIST SP 800-115 treats reporting as a structured deliverable in Section 8, not an end-of-engagement afterthought, and expects mitigation tracking to follow the report.

Section 3: review techniques (the cheapest findings)

Review techniques are non-intrusive, evidence-driven, and frequently produce more findings per hour than active testing. Section 3 of NIST SP 800-115 names six review techniques that should be in scope before any active scan is launched. The matching review record lives on the engagement itself so the assessor can show what was reviewed, by whom, and when.

Documentation review of policies, procedures, security plans, and architecture diagrams against the documented assessment objectives
Log review covering operating system logs, application logs, network device logs, and authentication records, with the time window and source systems captured on the engagement
Ruleset review of firewalls, routers, intrusion detection sensors, and web application firewalls against the documented network architecture and the data flows the assessment covers
System configuration review against an authoritative baseline (CIS Benchmarks, vendor hardening guides, agency-specific configuration baselines) with deviations recorded as findings
Network sniffing in defined network segments to confirm encryption posture, identify clear-text protocols, and validate segmentation evidence
File integrity checking against an authoritative baseline to detect unauthorised changes to critical system, configuration, or application files

Section 4: target identification and analysis

Section 4 covers active target identification: network discovery, port and service identification, vulnerability scanning, and wireless scanning. NIST SP 800-115 treats this as a discrete phase from validation, so unverified scanner output never becomes a published finding. The external scanning capability and attack surface management produce the asset, subdomain, and exposed-service inventory the section expects, and retain the raw output per scan window for evidence purposes.

Network discovery to identify reachable hosts inside the assessment boundary, including unmanaged or undocumented systems that often emerge during this phase
Network port and service identification to enumerate listening services, banner-grab service versions, and feed those into vulnerability scanning and target analysis
Vulnerability scanning with authenticated and unauthenticated scans against in-scope assets, including web application scanning behind authentication where the scope and the credentials allow
Wireless scanning to identify rogue access points, unmanaged wireless networks, and weak encryption postures inside the documented assessment boundary
Asset categorisation against the documented system boundary so anything outside the boundary is flagged for de-scoping or scope-change discussion before active testing continues

Section 5: target vulnerability validation

Section 5 covers password cracking, penetration testing, and social engineering. The standard breaks penetration testing into four sub-phases (planning, discovery, attack, reporting) that mirror the overall assessment structure, and is explicit that the attack sub-phase is preceded by validated discovery and followed by structured reporting. The findings management feature carries CVSS 3.1 scoring, 300+ remediation templates, and Nessus or Burp Suite imports so validation output flows in without manual re-entry. Authenticated workflows live in the authenticated scanning capability which covers configuration and patch evidence behind login.

For deeper background on retesting and validating fixes after the attack phase, see the pentest retesting workflow, which keeps the original validated finding paired to the retest evidence so the post-test mitigation record stays complete.

Section 6: the Security Assessment Plan (SAP)

Section 6 is the part of NIST SP 800-115 that decides whether the rest of the engagement is defensible. The Security Assessment Plan captures objectives, scope, rules of engagement, schedule, deliverables, and the named contacts on both sides. The matching free rules of engagement template provides the operational ROE document that 800-115 expects to be signed before any active testing starts, and the pentest statement of work template gives a drop-in clause set covering most of the SAP scope and deliverables in writing.

Assessment objectives stated in language the system owner can validate (for example, validate the boundary controls protecting the CUI environment) rather than a generic vulnerability list goal
Scope: in-scope systems, applications, networks, IP ranges, accounts, physical sites, and any third-party services that have been authorised in writing for testing
Out-of-scope items called out explicitly, including any inherited services from a cloud provider that require their own authorisation under the provider acceptable use policy
Assumptions and constraints (testing windows, change-freeze periods, denial-of-service posture, social engineering posture, exploitation depth, data handling, evidence retention) named in writing
Rules of engagement with named technical contacts, named escalation contacts, the daily out-brief schedule, and the stop-test conditions
Schedule, milestones, and deliverables, including the executive summary, the technical report, and any interim status briefings
Assessment team roles and qualifications, plus the management approval and legal review records that authorise the assessment

Section 8: reporting and post-test activities

NIST SP 800-115 treats reporting as a structured deliverable, not a wrap-up. The executive summary is written for an audience that will not read the technical body; the technical body is for the engineers and architects who will fix the findings. Both have to exist, and both have to tie back to the assessment objectives agreed in the SAP. Mitigation tracking, lessons learned, and any retests run after the report should attach to the same engagement record so the audit trail is continuous rather than scattered across attachments.

Executive summary written for non-technical stakeholders, summarising scope, posture, the most significant findings, and the strategic recommendations rather than reproducing technical detail
Methodology section restating the assessment objectives, the scope, the techniques used, and the evidence types collected, so the report is reproducible by another assessor
Findings with severity, affected asset, root cause, evidence, business impact, and recommended remediation, structured so each finding can be tracked through to closure
Mitigation recommendations grouped into tactical (immediate fixes), strategic (programme-level changes), and procedural (process and policy adjustments) so the system owner can plan a response
Appendices for raw scanner output, evidence files, screenshots, and supporting artefacts retained alongside the engagement record for chain-of-custody purposes
Lessons learned section capturing what changed in the environment, what changed in the assessment process, and what should be adjusted before the next assessment cycle

For a deeper write-up on report structure and how to balance executive and technical sections, see how to write a pentest report and the matching pentest executive summary guide. The AI report generation feature composes the Section 8 deliverable from the underlying engagement, discovery, validation, and exploitation evidence rather than from a blank page.

Where NIST SP 800-115 turns up in federal compliance

NIST SP 800-115 is rarely the only standard cited in a federal assessment. It is, more often, the technical reference that other compliance regimes point to when they need a stable definition of how testing is performed. The four cases below cover the most common citations a service provider sees in commercial proposals and contracts.

NIST SP 800-115 is the technical reference behind NIST SP 800-53 control CA-8 Penetration Testing and RA-5 Vulnerability Monitoring and Scanning. Federal agencies and their contractors point to 800-115 when an authorisation reviewer asks how testing is performed
CMMC Level 2 and Level 3 contractors handling Controlled Unclassified Information rely on NIST SP 800-171 Rev. 2 controls that draw heavily on the 800-53 baselines, so 800-115 is the practical reference for technical testing methodology in the Defense Industrial Base
FedRAMP authorisations require an annual penetration test executed by an accredited third party assessment organisation (3PAO). The FedRAMP Penetration Test Guidance is built on top of NIST SP 800-115, so the methodology a 3PAO follows ultimately points back to this publication
Many agency-specific assessment frameworks and statements of work cite NIST SP 800-115 by reference, even where the operational standard the testers follow internally is PTES or OSSTMM. Citing 800-115 in the SAP keeps the engagement aligned with federal expectations regardless of internal practice

How NIST SP 800-115 compares to PTES, OWASP, OSSTMM, and ATT&CK

NIST SP 800-115 is rarely used in isolation. The strongest pentest programmes layer it with at least one operator-shaped methodology and one threat-informed catalogue. The contrast below is a working view, not a buyer comparison: the practitioner question is which standard to combine with 800-115, not which to pick instead of it. For a broader side-by-side view of the major pentest methodologies, see the penetration testing methodology guide.

NIST SP 800-115 vs PTES

PTES is community-authored and engagement-shaped, with heavy emphasis on pre-engagement, threat modelling, and reporting. NIST SP 800-115 is federally authored, lighter on pre-engagement detail, and stronger on review techniques and target identification. They compose well: use NIST SP 800-115 to satisfy federal and compliance references, and PTES to give the engagement an operator-first scaffold for threat modelling and reporting.

NIST SP 800-115 vs OWASP Testing Guide

The OWASP Testing Guide (and OWASP ASVS) are web-application-specific and prescriptive about test cases per category. NIST SP 800-115 is methodology-shaped and applies across infrastructure, applications, and wireless. For a web-application engagement under a federal contract, the practical pattern is to scaffold with NIST SP 800-115 and reach for the OWASP Testing Guide and ASVS for the web-application phase.

NIST SP 800-115 vs OSSTMM

OSSTMM (Open Source Security Testing Methodology Manual) is metrics-driven, centred on the Risk Assessment Values calculation, and prescriptive about reproducible measurements across engagements. NIST SP 800-115 is workflow-shaped and easier to teach to new assessors. OSSTMM tends to fit programmes that want quantifiable security values across repeated engagements; NIST SP 800-115 fits programmes that need a federally aligned methodology.

NIST SP 800-115 vs MITRE ATT&CK

ATT&CK is a knowledge base of adversary tactics and techniques, not a testing methodology. NIST SP 800-115 describes how to plan, execute, and report on a security assessment; ATT&CK describes what attackers do during one. The strongest federal pentest programmes use NIST SP 800-115 as the methodology and tag exploitation findings with the ATT&CK techniques they evidence.

For a full operator-first read of the Penetration Testing Execution Standard alongside 800-115, see the PTES framework page. For the UK and European equivalent that bundles methodology with assessor accreditation, see the CREST penetration testing framework, which leaves the methodology choice to the CREST member firm and is often satisfied by a 800-115 aligned approach.

Where SecPortal fits in a NIST SP 800-115 aligned engagement

SecPortal is the operating layer for a NIST SP 800-115 aligned assessment. The platform handles the SAP, the rules of engagement, the discovery record, validated findings, exploitation evidence, and the Section 8 deliverable so the engagement runs as a single workflow rather than a long email thread with attachments. For consultancies running federally aligned engagements on behalf of multiple clients, the security consultants workspace bundles that with branded client portals and findings deduplication across engagements.

Engagement management captures the SAP, the rules of engagement, the team roles, and the assessment objectives as a structured record so Section 6 of NIST SP 800-115 becomes a single source of truth rather than a separate document attached to a contract
External and authenticated scanning produce the raw discovery data Sections 4 and 5 depend on, with output retained per scan window and linked to the validated finding it supports
Findings management with CVSS 3.1 scoring, 300+ remediation templates, and Nessus or Burp Suite import turns Section 5 vulnerability validation into evidence-backed records with severity, asset scope, and owner
Attack surface management covers Section 4 target identification: subdomain enumeration, fingerprinting, exposed services, and cloud exposure are tracked with the engagement so the discovery record survives the engagement
AI-generated reports compose the Section 8 deliverable from the underlying engagement, discovery, validation, and exploitation evidence, producing executive summary, technical body, and mitigation guidance rather than a thin export
Compliance tracking lets the same engagement satisfy NIST SP 800-115 alongside framework mappings to NIST SP 800-53 (CA-8 Penetration Testing, RA-5 Vulnerability Monitoring), FedRAMP, and CMMC without rebuilding the evidence bundle

Looking for the engagement workflow itself, end-to-end? The penetration testing use case captures how SecPortal turns a NIST SP 800-115 shaped engagement into a structured record covering scope, methodology, validated findings, retests, and the deliverable.

Need to scope a federal engagement before writing the SAP? The free pentest scoping calculator and the penetration testing RFP template give buyers and providers a shared starting point that maps cleanly onto the NIST SP 800-115 SAP structure.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Review techniques (documentation, log, ruleset, configuration)

Section 3 of NIST SP 800-115 covers passive review of documentation, system logs, rulesets, system configurations, network sniffing, and file integrity checking. Reviews are non-intrusive, evidence-driven, and frequently the cheapest way to find findings before any active testing begins. Capture review notes, the artefacts inspected, and the findings produced against the engagement so the audit trail shows what was reviewed, by whom, and when.

Target identification and analysis (network discovery, port and service identification)

Section 4 covers active target identification: network discovery, network port and service identification, vulnerability scanning, and wireless scanning. NIST SP 800-115 separates discovery from validation deliberately, so unverified scanner output never reaches the report as-is. Schedule recurring external and authenticated scans, retain raw output per scan window, and let analysts validate findings before they are published to the client.

Target vulnerability validation (password cracking, penetration testing, social engineering)

Section 5 covers password cracking, penetration testing, and social engineering. The standard treats penetration testing as a four-phase process (planning, discovery, attack, reporting) and is explicit that the attack phase is preceded by validated discovery and followed by structured reporting. Capture validated findings with CVSS 3.1 vectors, evidence, and remediation guidance from a 300+ template library so analyst output is consistent across engagements.

Security assessment planning (rules of engagement, logistics, legal)

Section 6 covers the Security Assessment Plan (SAP), the rules of engagement (ROE), legal considerations, logistics, data handling, and the assessment policy. NIST SP 800-115 expects the ROE to be signed before any active testing starts, with named technical and management contacts, escalation paths, and stop-test conditions. Store the SAP and ROE on the engagement record so the legal artefact and the operational record never drift apart.

Security assessment execution and analysis

Section 7 covers execution coordination, evidence handling, and analysis of results. The standard expects a daily out-brief with the asset owner during longer engagements, evidence retention with chain of custody, and analysis that turns raw test output into validated findings with severity, root cause, and recommended remediation. Track each finding on the engagement so analyst notes, evidence files, and remediation guidance live in one place rather than scattered across drives and email.

Post-testing activities (mitigation, technical reporting, lessons learned)

Section 8 covers mitigation tracking, the technical report, and lessons learned. The standard requires both an executive summary written for non-technical stakeholders and a technical body that is reproducible for the engineers who will fix the findings. Generate executive and technical sections from the live findings, deliver through a branded client portal, and keep the engagement record open so retests, mitigations, and the lessons learned review attach to the same audit trail.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

AI-powered reports in seconds, not days

Vulnerability scanning tools that map your attack surface

Test web apps behind the login

Map your attack surface before attackers do

Compliance tracking without a full GRC platform

Run NIST SP 800-115 engagements without spreadsheet sprawl

Plan, execute, validate, and report on technical security testing from one workflow. Start free.