NIST SP 800-115 in 2026: the Technical Guide to Information Security Testing and Assessment

What NIST SP 800-115 is

The publication was issued by the Computer Security Resource Center at the National Institute of Standards and Technology in September 2008. It was written by Karen Scarfone, Murugiah Souppaya, Amanda Cody and Angela Orebaugh; it runs to 80 pages and carries Final status, meaning it is the edition in force. It replaced the earlier SP 800-42 on network security testing.

The guide addresses two audiences at once, and that explains its tone. On one hand it was written for testers and auditors, giving them a process framework and a catalogue of techniques. On the other it was written for those commissioning a test, who learn from it what they can require in a contract and how to recognise work done properly. For the teams that maintain systems it is finally a source of understanding about what happens to their infrastructure during a test.

The document does four things: it organises the process into repeatable phases, catalogues techniques independently of tools, describes good practice in running a test, and names the commonest pitfalls. That last point is often undervalued, yet it is what distinguishes a guide from a set of tool manuals.

How the document is arranged

Eight chapters follow the natural order of the work. After an introduction and a discussion of the approach to testing comes the classification of techniques into three categories, then three chapters devoted in turn to reviews, target identification and analysis, and vulnerability validation. The last two chapters cover assessment planning and execution. Appendices follow, including a template for rules of engagement in appendix B.

That structure has a practical consequence: chapter numbers are often cited in contracts and reports, so they are worth knowing. Vulnerability scanning is section 4.3, penetration testing with its four phases is section 5.2, social engineering is section 5.3, assessment planning and the rules of engagement are chapter 6, and reporting is section 8.2.

Is a document from 2008 still current

The publication is eighteen years old and has never been revised, which given the pace of technological change sounds disqualifying. In practice it still works, for two reasons.

First, the four phases - planning, discovery, attack and reporting - describe a way of thinking rather than a state of technology. The order in which the scope is settled first, then the environment is surveyed, then the exploitability of a weakness is verified, and finally the result is written up, makes just as much sense for a 2008 server as for a container cluster.

Second, the guide consistently talks about categories of technique rather than tools. Port scanning remains port scanning whether it is done with nmap, masscan or anything else. A document that names no software versions has no way to go out of date at that layer.

What it does not contain

The limitations are equally real. Since 2008 whole areas of testing have appeared that the guide does not cover: cloud security including configuration and permission review, containers and orchestration, programming interfaces in their REST, GraphQL and gRPC forms, mobile applications, industrial equipment and - most recently - the security of learning systems. The phases from SP 800-115 still apply in each of those cases, but the techniques have to come from elsewhere. The direction of change is well captured by the annual ENISA threat landscape ^[14].

Other NIST publications fill the gap, and are worth reading in parallel: SP 800-53 with its control catalogue ^[9], SP 800-53A with assessment procedures for those controls, SP 800-30 with a risk assessment method ^[10], and SP 800-218 describing a secure software development lifecycle. At the strategic level the Cybersecurity Framework 2.0 ^[12] ties it all together.

NIST has announced no revision schedule for SP 800-115. Its history in the NIST catalogue contains a single entry - publication on 30 September 2008 - and no announcement of a further edition.

The four phases of a test

The guide describes a penetration test as a sequence of four phases (section 5.2.1), with reporting not a separate stage at the end but running in parallel with the others. The time shares given below do not come from the document - they are our own averages from projects of typical scope, and in any particular test the proportions can look quite different.

Planning

The phase in which every decision that determines the value of the test is taken, and simultaneously the one most often cut short. The objective has to be settled - whether the aim is to demonstrate compliance, to analyse gaps or to simulate a real adversary - because the choice of techniques follows from it. Then the scope is defined, stating outright what is excluded, a methodology is chosen, the rules of engagement are written down and written authorisation is obtained. Finally the schedule, the resources and the communication channels are agreed, along with the escalation path.

Neglecting this phase shows up later in the report: without a clear objective the findings are hard to rank, and without agreed communication channels a critical vulnerability waits in an email queue until Monday.

Discovery

The largest technical part. It begins with passive reconnaissance from public sources and then turns active: identifying address ranges, port scanning, identifying services and their versions and the operating systems. For web applications it adds mapping of entry points, parameters and the technologies in use, and identification of the authentication mechanisms.

The output of the phase is a set of discovered services matched against known vulnerabilities. That is not yet proof - only a hypothesis to be verified in the next step.

Attack

The most spectacular and usually the shortest phase. It covers exploiting weaknesses to obtain access, escalating privileges, surveying the contents of the system, maintaining access and moving laterally to further systems. In Active Directory environments the typical goal is the path from an ordinary account to domain administrator rights. Data exfiltration is performed in simulated form - the point is to demonstrate the possibility, not actually to move the data set.

The phase ends with cleanup: removing the accounts, tools and persistence mechanisms introduced. Skipping that step leaves back doors in the client's environment that nobody remembers.

Reporting

Documentation runs throughout the test rather than starting once it ends. The reason is mundane: evidence in the form of a screenshot or a captured request and response can only be gathered while the vulnerability still exists. Beyond that, critical findings are reported immediately rather than waiting for the final report.

The three categories of technique

The guide divides techniques into three groups according to how deeply they intrude into the environment under test. The division is useful when negotiating scope, because it allows a conversation about the risk of the test rather than about the names of tools.

Review techniques (chapter 3) do not intrude on the system. They include documentation and log review, ruleset analysis, configuration review, network traffic capture and file integrity checking. They are safe for a production environment and often yield more than scanning, because they show the intended state alongside the actual one.

Target identification and analysis techniques (chapter 4) generate traffic but do not attempt to exploit anything: network discovery, port and service identification, vulnerability scanning and wireless scanning. The risk here is moderate and arises mainly from the load placed on devices.

Vulnerability validation techniques (chapter 5) consist of checking whether a weakness can actually be exploited - password cracking, penetration testing and social engineering. These carry real risk to the environment, and it is these that the exclusions in the rules of engagement concern.

The distinction translates directly into cost and time. A test limited to the first two categories is cheaper and safer, but it does not answer the question of whether a discovered weakness is genuinely exploitable.

Rules of engagement and authorisation

The rules of engagement are a document agreed before testing starts, recording everything that should be beyond dispute. SP 800-115 discusses the assessment plan and the rules of engagement in chapter 6 and provides a template in appendix B; chapter 7 assumes their existence and requires departures to obtain separate, normally written, consent.

A well-written set of rules answers several questions. What is in scope and what is expressly excluded - and the exclusions matter more, because they protect both sides. Which addresses the test is conducted from and which it is directed at. What hours it may run. Who is to be notified, in what manner, on finding something critical, through which channels and on what numbers. Whether the monitoring team knows about the test or is to treat it as a genuine incident.

Prohibited techniques are listed separately. Usually these are denial of service attacks, destructive tests, activity in defined time windows and social engineering directed at named individuals. It also has to be settled in advance what to do on encountering personal or financial data: whether it may be recorded as evidence, in what form and for how long. Finally, the stop conditions - when the tester is to halt and pick up the phone.

Written authorisation

Written authorisation is a separate document that the rules of engagement do not replace. Without it, the tester's activity may satisfy the elements of offences under the Polish criminal code: unauthorised access to information (article 267), destruction or alteration of recorded information (articles 268 and 268a), disruption of a system or network (articles 269 and 269a), and producing or supplying tools adapted to committing those acts (article 269b).

The authorisation should name the person entitled to represent the organisation, the specific contractor, the scope, the period of validity and the limitations, with a signature and a date. It is worth holding in a form the tester can produce immediately - hence the industry name get-out-of-jail-free letter. A practical note: authorisation signed by an IT manager is often insufficient if the test covers systems belonging to other organisational units.

Black box, white box and the middle option

How much the tester is told before starting is a separate decision, and it affects the outcome more strongly than is usually assumed.

In the black box variant the tester receives minimal information and reproduces the situation of an outside attacker. The advantage is realism; the drawback is time. Discovery consumes most of the budget, leaving less for the testing proper, and the report is sometimes shorter not because the system is secure.

In the white box variant the tester receives documentation, credentials, network diagrams and sometimes source code. Reconnaissance shrinks to a minimum, so almost all the time goes on testing. It is the most efficient way to find as many weaknesses as possible, but it says nothing about how many of them an attacker working blind would find.

The middle option, grey box, gives the tester partial knowledge - most often an ordinary user account and a general description of the architecture. It matches the situation of an attacker who has already gained a foothold, or of an employee abusing their privileges. In practice it is the most frequent choice, because it gives a reasonable ratio of realism to number of findings.

The choice should follow from the question the test is meant to answer. Demonstrating compliance usually calls for the middle option. A review before a new system goes live is better done with full knowledge. A simulation aimed at a specific adversary, including tests run under a threat-led regime, requires the variant with no prior knowledge.

Vulnerability scanning versus penetration testing

These are two different services, sometimes conflated in proposals, which differ not in level of detail but in the question they answer.

Vulnerability scanning is automated and compares detected software versions against a database of known weaknesses. It takes hours, can be repeated quarterly or more often, and produces a list of items with CVE identifiers. The scanner does not, however, check whether a weakness can be exploited in that environment or what it would mean. Vulnerability scanning is section 4.3 of the guide. More in the article on vulnerability scanning.

Penetration testing is largely manual work and consists of attempting to exploit the weaknesses found. It takes days or weeks, is performed less often, and produces a description of real attack scenarios together with evidence. Penetration testing is section 5.2, and its four phases section 5.2.1. More in the article on penetration testing.

The two services are complementary. Scanning maintains current awareness of the state of things; a penetration test verifies whether the safeguards adopted actually work. Replacing a test with a scan gives a list nobody has verified; replacing scanning with a test gives a one-off picture of an environment that changes weekly.

The test report

SP 800-115 discusses reporting in section 8.2, in the chapter on post-testing activities. The report is the only lasting product of the whole exercise, and it decides whether the test changes anything.

The settled structure begins with an executive summary - one to two pages without jargon, covering the scope, the few most important findings, an overall assessment and recommendations. Then comes a description of the methodology: the guide applied, the scope, the timeframe, the team and the tools. The core is the detailed findings, where each item has an identifier, a title, a severity rating with a CVSS score, a list of systems, a description, evidence, the impact on the organisation's activity and a remediation recommendation with references to CVE, CWE or OWASP.

The findings are usually followed by a summary ordered by severity and a proposed remediation sequence. The deadlines assigned to individual levels - seven days for critical and thirty for high, for instance - do not come from the guide; they are an industry convention worth agreeing with the client rather than inserting automatically. Appendices with raw results and further evidence close the document.

Report length depends on scope and in our practice ranges from a few dozen pages for a single application to several hundred for a test covering a whole organisation. Page count is not a measure of quality, though - a good report on one application is sometimes shorter than a dump of scanner output.

How it is delivered matters too, because the report is a document whose leak does more harm than most of the weaknesses described in it. The standard is an encrypted file or a secured channel, together with a checksum. To that is usually added a short walkthrough for management and a longer, technical one for the teams responsible for remediation.

How it relates to OWASP, OSSTMM, PTES and MITRE ATT&CK

SP 800-115 is rarely applied on its own. In practice it serves as a process framework, supplemented by more detailed methods chosen to match the object of the test.

The OWASP Web Security Testing Guide ^[2] in version 4.2, released in December 2020, contains detailed scenarios for testing web applications. Where NIST says "test authentication", the WSTG gives specific test cases. It is the most common supplement for application testing. A separate OWASP document is the Top 10 ^[3], which organises categories of weakness but is not a testing methodology and does not replace the WSTG.

OSSTMM ^[4] in its third version takes a different road: it proposes its own model for measuring operational security. It is more formal and less widespread, but useful where a repeatable measure is needed rather than a list of findings.

PTES ^[5] divides a test into seven stages, from pre-engagement, through information gathering, threat modelling, vulnerability analysis, exploitation and post-exploitation, to reporting. Separate technical guidelines descend to the level of specific tools and commands, which SP 800-115 deliberately avoids.

MITRE ATT&CK ^[11] is not a testing methodology but an organised description of tactics and techniques observed in real attackers. In testing it serves to describe exactly what was simulated, which lets the defending team check which of those behaviours it detected at all.

TIBER-EU ^[6] is in turn the European Central Bank framework for tests conducted on the basis of threat intelligence in the financial sector. Since DORA entered into application it has become the reference for threat-led penetration testing at the largest financial entities.

A typical stack therefore looks like this: SP 800-115 as the process, the WSTG or PTES as the technical layer, ATT&CK as the language for describing simulated behaviour, and, for regulated testing, TIBER-EU as the overarching organisational framework. On the defensive side the equivalent practical layer is the CIS Controls ^[13], to which report recommendations are often mapped.

Legal aspects in the Polish context

A penetration test without authorisation is technically indistinguishable from an attack, and the criminal provisions contain no exemption for good intentions. Written consent is therefore not a formality but a condition of the whole exercise being lawful.

What matters above all are the provisions of chapter XXXIII of the Polish criminal code. Article 267 covers unauthorised access to information, including breaking or circumventing a safeguard. Articles 268 and 268a cover destroying, damaging or altering a record of significant information. Articles 269 and 269a concern disruption of an ICT system or network. Article 269b criminalises producing, obtaining and supplying tools adapted to committing those acts.

In practice three situations call for particular care. The first is a test covering systems maintained by an external provider - the client's consent does not then extend to infrastructure that is not theirs. The second is shared environments, where the effects of a test may reach third parties. The third is encountering personal data: the way to proceed should be settled in the rules of engagement beforehand, because there is no time for it during the test, and incidentally recording such data creates its own obligations under the GDPR.

One obvious point is easy to forget in external testing: the consent of an application owner does not extend to the hosting provider or to the network operator through which the test is conducted.

Typical mistakes in testing

The problems below recur regardless of who runs the test and how large the organisation is.

1. Scope set too narrowly. A test limited to one application misses the route an attacker actually takes - most often through an internet-facing service or stolen credentials.
2. No exclusions in the rules of engagement. Until what must not be done is written down, the argument about it will erupt at the worst possible moment: after a production service has stopped.
3. Authorisation signed by somebody without authority. A department manager's consent does not protect the tester if the scope covers other units' systems.
4. A report with no evidence. A finding described without a screenshot, a captured request or a log entry is an assertion rather than a fact to the remediation team, and it is the first thing to be challenged.
5. Severity divorced from context. A CVSS score alone does not account for whether the vulnerable system processes critical data or sits in an isolated test segment.
6. No cleanup after the attack phase. Accounts, tools and persistence mechanisms left behind become a real vulnerability introduced by the test itself.
7. A one-off test treated as a permanent state. The result describes the environment of a particular week. After changes are deployed it has to be verified again, at least for the findings that were fixed.
8. No retest. Without checking that a fix worked, the organisation has only the maintenance team's word for it.