NIST SP 800-115 Explained: Security Testing Methodology

Contracts, authorisation packages and audit questionnaires still name NIST SP 800-115 as the testing methodology, yet the document dates from September 2008 and many teams cite it without knowing what it actually requires. SP 800-115, the Technical Guide to Information Security Testing and Assessment, is a NIST Special Publication that explains how to plan, run and follow up technical security assessments: review techniques, target identification, vulnerability validation, assessment logistics and data handling. This guide walks through its structure, shows where it is still formally required (FedRAMP rules of engagement are the best known case), explains what it does not cover because of its age, and sets out which modern methods to pair it with. It is for security testing leads, assessors, compliance owners and anyone writing a statement of work that cites it. For pen test types, provider selection and scoping in general, see the Penetration Testing Guide; this page stays with SP 800-115 itself.

Key takeaways

It is a final, unrevised 2008 publication. The NIST CSRC page lists SP 800-115 as Final, published 30 September 2008, superseding SP 800-42, with no later revision or draft shown.
It is a methodology overview, not a programme. NIST states it is not intended to present a comprehensive information security testing and examination programme; it describes techniques, their benefits and limits, and how to plan and handle assessments.
Its planning and handling sections age best. The assessment policy, rules of engagement template (Appendix B), legal considerations and data handling guidance remain sound; the tool lists and technology examples do not.
FedRAMP still requires it directly. The FedRAMP Penetration Test Guidance (v3.0, 30 June 2022) requires rules of engagement developed according to SP 800-115 Appendix B.
Pair it with modern sources. Use OWASP WSTG for web applications, cloud provider testing policies for cloud, adversary emulation based on MITRE ATT&CK for detection testing, and NIST SP 800-53 CA-8 and SP 800-53A for control requirements and assessment procedures.

What it is and who it applies to

SP 800-115 was written by Karen Scarfone and Murugiah Souppaya of NIST with Amanda Cody and Angela Orebaugh of Booz Allen Hamilton. Its stated purpose is to help organisations plan and conduct technical information security tests and examinations, analyse findings and develop mitigation strategies. Like other NIST Special Publications in the 800 series, it is guidance: it is not mandatory on its own for private organisations, but it becomes binding when a contract, an authorisation scheme or an internal policy adopts it.

Context	How SP 800-115 is used	What to check
FedRAMP cloud services	Rules of engagement must follow Appendix B and be approved by the authorising official before testing	Use the FedRAMP guidance for attack vectors, frequency and report content, which SP 800-115 does not define
US federal systems under RMF	Common methodology reference for CA-8 penetration testing and technical assessments supporting CA-2	Organisation-defined parameters in CA-8 set frequency and scope, not SP 800-115
Commercial contracts and supplier questionnaires	Named as "testing to be performed in line with NIST SP 800-115"	Agree in writing which sections apply and which modern methods supplement it
Internal testing programmes	Template for an assessment policy, planning and data handling	Update the tool and technique sections locally

Assessment methods: the publication defines three methods. Testing exercises objects under specified conditions to compare actual and expected behaviour. Examination checks, reviews or analyses objects to gain understanding or evidence. Interviewing holds discussions with individuals or groups to clarify understanding or find evidence. This vocabulary is the same one SP 800-53A uses for assessment procedures, which is why the two documents sit well together.

Structure and key requirements

Section	Content	Still useful today?
2 Security Testing and Examination Overview	Assessment methodology, technique types, comparing tests and examinations, testing viewpoints	Yes: the internal versus external and overt versus covert viewpoints are still how scopes are agreed
3 Review Techniques	Documentation, log, ruleset and system configuration review; network sniffing; file integrity checking	Yes, conceptually; configuration review now usually means cloud posture and infrastructure-as-code review
4 Target Identification and Analysis	Network discovery, port and service identification, vulnerability scanning, wireless and Bluetooth scanning	Partly: principles hold, but asset discovery now spans cloud APIs, SaaS and identity providers
5 Target Vulnerability Validation	Password cracking, penetration testing (phases and logistics), social engineering	Partly: the four-phase model (planning, discovery, attack, reporting) is still widely recognised
6 Security Assessment Planning	Assessment policy, prioritising and scheduling, selecting techniques, assessor skills, location, tools, plan, legal considerations	Yes: the strongest part of the document
7 Security Assessment Execution	Coordination, assessing, analysis, data handling (collection, storage, transmission, destruction)	Yes: data handling is often missing from modern statements of work
8 Post-Testing Activities	Mitigation recommendations, reporting, remediation and mitigation	Yes, combined with a plan of action and milestones (CA-5)
Appendices A to F	Live CD distributions, rules of engagement template, application testing, remote access testing, resources, glossary	Appendix B yes; Appendix A and the resource lists are dated

Testing viewpoints

External: conducted from outside the security perimeter, usually as seen from the internet.
Internal: conducted from inside the network, taking the role of a trusted insider or an attacker who has already breached the perimeter.
Overt: performed with the knowledge and consent of IT staff, suited to finding as many weaknesses as possible.
Covert: performed without IT staff knowledge but with management approval, focusing on the impact an adversary could achieve and on whether the organisation detects and responds.

What its age means

A 2008 document cannot address cloud control planes, identity provider federation, container orchestration, CI/CD pipelines, API-first applications or AI systems. Treat SP 800-115 as the process skeleton and select technique guidance from current sources. The table shows a reasonable pairing.

Testing need	Gap in SP 800-115	Current source to add
Web applications and APIs	Appendix C is brief	OWASP Web Security Testing Guide (latest release v4.2, with test IDs such as WSTG-INFO-02); OWASP ASVS 5.0 for requirements. See the API Penetration Testing Guide.
Cloud and SaaS	No cloud coverage	Provider testing policies, and for FedRAMP the six mandatory attack vectors. See the Cloud Penetration Testing Guide.
Detection and response testing	Covert testing only at a high level	Adversary emulation mapped to MITRE ATT&CK; threat-led schemes. See the Threat-Led Penetration Testing Guide.
Control requirement and assessment procedure	Not a control catalogue	NIST SP 800-53 Rev. 5 CA-8 and SP 800-53A procedures
OT and industrial systems	Not covered	See the OT Penetration Testing Guide.
UK government	Not referenced by UK schemes	NCSC guidance and CHECK scheme testers for HMG systems

Identity and NHI requirements

SP 800-115 predates the current focus on non-human identity, but three of its themes apply directly, and they are where modern assessments most often fall short.

Password cracking (section 5.1): the publication treats credential strength testing as a validation technique. Today the larger exposure is static secrets: API keys, service account passwords and tokens in configuration, repositories and CI variables. Include secret discovery in documentation and configuration review, and test whether a discovered credential grants more than its documented scope. See the Secrets Management Guide.
Internal viewpoint: testing as a trusted insider should include testing as a trusted workload. A realistic internal scenario starts from a compromised pipeline identity or cloud role, not only a domain user. See the Service Account Security Guide.
Data handling (section 7.4): credentials captured during testing are assessment data. Agree how they are collected, stored, transmitted and destroyed. FedRAMP goes further: passwords must not appear in the report even in encrypted form, or must be masked so they cannot be recreated or guessed.
Tester accounts: accounts and keys issued to testers are themselves non-human or temporary identities. Create them with expiry, scope them to the rules of engagement, log their use and revoke them at close. The Penetration Testing Guide covers tester credential handling in more depth.

In mapping terms this sits under CSF 2.0 PR.AA-05 (access permissions defined, managed and reviewed with least privilege) and SP 800-53 IA-5 Authenticator Management and AC-6 Least Privilege: a test that finds an over-scoped token is evidence against those controls.

Implementation steps

Write or refresh the assessment policy (section 6.1). Define who may authorise testing, required frequency by system category, acceptable techniques, data handling rules and reporting lines.
Prioritise and schedule (section 6.2). Rank systems by impact and exposure; align schedules with change windows, authorisation cycles and contractual dates such as FedRAMP's annual test.
Select and customise techniques (section 6.3). Choose review, identification and validation techniques per system, adding the modern sources listed above for cloud, web and identity.
Agree logistics (section 6.4). Confirm assessor skills and independence (CA-8(1) Independent Penetration Testing Agent or Team where required), location, tools and approved test accounts.
Produce the assessment plan and rules of engagement (section 6.5, Appendix B). Include scope, viewpoints, schedule, contacts with backups, stop conditions and escalation for critical findings. For FedRAMP, include the clause that the CIO, CISO, ISSO and authorising official are informed of critical or high-impact vulnerabilities as soon as they are found.
Clear legal considerations (section 6.6). Written authorisation from the system owner and, for third-party hosted systems, the provider's permission or policy.
Execute with coordination (section 7). Keep a contact channel open, log tester activity with timestamps so defenders can separate it from real attacks, and pause on stop conditions.
Report, remediate and retest (section 8). Feed findings into a plan of action and milestones (CA-5), track to closure and retest fixes.

Rollback: the rules of engagement should name who can halt testing and how systems are restored. Agree backups or snapshots for fragile systems before any validation technique runs.

Evidence and assessment

Artefact	SP 800-115 basis	Who relies on it
Assessment policy	Section 6.1	Auditors checking that testing is governed, not ad hoc
Assessment plan	Section 6.5	Authorising officials and system owners
Signed rules of engagement	Appendix B	Legal, providers, FedRAMP authorising officials (copy included in the Security Assessment Plan)
Test logs and evidence	Sections 7.2 to 7.4	SOC (to deconflict alerts), assessors validating findings
Report with mitigation recommendations	Sections 8.1 and 8.2	Remediation owners; for FedRAMP the report goes into the Security Assessment Report with scope, attack vectors, timeline, tests and results, findings and evidence, and access paths
Remediation and retest record	Section 8.3	Plan of action and milestones owners, auditors
Data destruction confirmation	Section 7.4.4	Data protection and contract owners

Metrics

Coverage: percentage of high-impact systems tested within the policy interval.
Time to remediate: median days from report to verified fix, by severity.
Repeat findings: share of findings that reappear in the next test of the same system.
Detection rate: for covert tests, the proportion of tester actions the SOC detected and escalated.
Credential exposure: number of valid secrets or over-scoped machine identities found per test, trending down.

Mapping to other frameworks

Framework	Where SP 800-115 activity provides evidence
NIST SP 800-53 Rev. 5	CA-8 Penetration Testing (CA-8(1) independent team, CA-8(2) Red Team Exercises); CA-2 Control Assessments; RA-5 Vulnerability Monitoring and Scanning; CA-5 Plan of Action and Milestones; PM-14 Testing, Training, and Monitoring
NIST CSF 2.0	ID.RA-01 vulnerabilities identified, validated and recorded; ID.IM-02 improvements identified from security tests and exercises
NIST SP 800-171 Rev. 3	03.12.01 Security Assessment; 03.11.02 Vulnerability Monitoring and Scanning
CIS Controls v8.1	Control 18 Penetration Testing. See the CIS Control 18 Penetration Testing Guide.
ISO/IEC 27001:2022 Annex A	8.8 Management of technical vulnerabilities; 8.29 Security testing in development and acceptance; 5.35 Independent review of information security
FedRAMP	Penetration Test Guidance: rules of engagement per Appendix B, initial test by a 3PAO no more than six months before the SAR, then at least every 12 months during continuous monitoring

The ISO and CIS rows are NHI Mgmt Group's indicative mapping; the FedRAMP row is taken from the FedRAMP guidance itself. For combining these in one evidence set see the Control Mapping Guide.

Common pitfalls

Citing SP 800-115 as the whole scope: "test in line with SP 800-115" without naming targets, viewpoints and techniques leaves scope to the tester. Specify sections and supplementary methods.
Using the 2008 tool lists: Appendix A and the resources appendix are historical. Tool selection belongs in the assessment plan, reviewed for each engagement.
Using pen testing as the main way to find vulnerabilities: NCSC guidance is clear that penetration testing gives assurance in vulnerability management; it is not primary discovery and not ongoing assurance. See the Vulnerability Scanning Guide for the continuous layer.
No data handling clause: captured hashes, tokens and personal data sit on tester laptops after the engagement. Section 7.4 exists to stop this; write destruction into the contract.
Ignoring machine identities: scopes list hosts and applications but not service accounts, CI runners and cloud roles, so the most likely real attack path goes untested.
Outsourcing the risk decision: the tester's severity is an input. The system owner rates risk in context and documents deviations, as NCSC also advises.

Practitioner checklist

Confirm which contracts and authorisations cite SP 800-115 and what each one actually requires.
Maintain an assessment policy covering authority, frequency, techniques and data handling.
Use Appendix B as the base for rules of engagement, adding stop conditions and critical finding escalation.
Name the testing viewpoint (internal, external, overt, covert) for every engagement.
Add current technique sources for web, API, cloud, identity and OT targets.
Include non-human identities and secrets in scope and in the internal viewpoint scenario.
Issue tester accounts with expiry and scope, log their use and revoke them at close.
Require evidence destruction confirmation and masked credentials in reports.
Track every finding to a plan of action and milestones entry and retest the fix.

NIST SP 800-115 Security Testing and Assessment Guide: Using the 2008 Method Today