In many current requests for proposals (RFPs) and tenders for penetration tests, explicit reference is made to “the BSI standard” or “the NIST standard.” At first glance, this suggests methodical maturity and clear quality requirements. In my view, however, this trend is not without its problems: both references are highly generic and cannot substitute a concrete Statement of Work for a modern penetration test.<\/p>\n\n\n\n
At this point, I would estimate that a good third of all inquiries and RFPs we see are primarily AI-generated.<\/strong> The trend toward broadly referencing these standards is heavily accelerated by the unreflective use of Large Language Models. At the push of a button, an AI will churn out plausible, industry-standard buzzwords and frameworks. As a result, tenders look highly professional and technically robust on the surface, while remaining completely vague in terms of actual substance.<\/p>\n\n\n\n Simply naming BSI or NIST does not answer which systems are to be tested, what depth of testing is expected, whether exploitation is permitted, which roles will be provided, what evidence is required, or how the report should be structured.<\/p>\n\n\n\n That is exactly why it is worth taking a closer look at both references. Not because NIST SP 800-115 or the BSI concept are inadequate\u2014on the contrary, both documents provide valuable guidance. However, one must understand what they were designed for, where their limits lie, and why simply copying and pasting them into an RFP does not yet yield a resilient pentest requirement.<\/p>\n\n\n\n Penetration testing is often misunderstood as a purely technical discipline: scan, find vulnerabilities, exploit, report. However, anyone who looks into established standards quickly realizes that professional penetration testing is much more than just running a few tools. It is a managed process with clear objectives, a defined scope, legal frameworks, methodical execution, and traceable risk assessment.<\/p>\n\n\n\n Two key references in this context are NIST Special Publication 800-115<\/strong> “Technical Guide to Information Security Testing and Assessment”<\/em> and the BSI study<\/strong> “Durchf\u00fchrungskonzept f\u00fcr Penetrationstests”<\/em> (Implementation Concept for Penetration Tests). Both documents aim to make security assessments more structured, comparable, and reliable. Nevertheless, they focus on different areas.<\/p>\n\n\n\n The core difference can be summarized briefly:<\/p>\n\n\n\n NIST SP 800-115 is frequently cited in the pentesting world, but it is not a pure penetration testing framework. The guide takes a broader view of technical security evaluations, distinguishing between three fundamental assessment methods:<\/p>\n\n\n\n By doing so, NIST positions penetration testing as an important, but not the sole component of a technical security assessment. This is a crucial point: not every security check is a pentest, and a simple list of vulnerabilities does not automatically constitute a resilient proof of security.<\/p>\n\n\n\n For penetration testing itself, NIST outlines a four-phase methodology<\/strong>:<\/p>\n\n\n\n In the planning phase, objectives, scope, legal boundaries, and organizational frameworks are defined. The discovery phase involves information gathering, scanning, and vulnerability analysis. In the attack phase, vulnerabilities are exploited in a controlled manner to validate actual risks. The reporting phase documents results, attack paths, risks, and prioritized remediation measures.<\/p>\n\n\n\n Particularly valuable in the NIST guide is the clear distinction between vulnerability scanning<\/em> and penetration testing<\/em>. A vulnerability scan primarily delivers raw data and potential findings. A penetration test validates these findings, puts them into context, and demonstrates the actual impact a vulnerability could have. It is precisely this manual, expert-driven effort that makes the difference between an automated scan report and a real pentest.<\/p>\n\n\n\n The BSI study “Implementation Concept for Penetration Tests” focuses more narrowly on penetration testing as a specific project. It outlines a structured approach to planning, executing, and evaluating pentests while accounting for not only technical, but also organizational, legal, and economic frameworks.<\/p>\n\n\n\n The historical context is important here: the study is strongly shaped by the German public sector and administrative environment. It is primarily aimed at clients, IT security service providers, and security decision-makers. As a result, it is highly compatible with public entities, regulated organizations, and enterprises that place a high premium on traceability, contractual clarity, and legal certainty.<\/p>\n\n\n\n The BSI model describes a five-phase process<\/strong>:<\/p>\n\n\n\n Preparation is given exceptionally high priority. Objectives, scope, legal boundaries, communication channels, responsibilities, and emergency contacts must be clarified before testing begins. This is not just operationally sound, but legally vital\u2014especially in Germany, where unauthorized testing quickly touches upon criminal liability (such as the “Hacker Paragraph” \u00a7 202c StGB).<\/p>\n\n\n\n Following preparation, information is gathered regarding the target systems and attack surfaces. The collected data is then evaluated, and potential vulnerabilities are prioritized. Only after this stage do active penetration attempts follow, simulating real-world attack scenarios in a controlled manner. The final analysis covers the evaluation of the results, documentation, and restoring the systems to their original state.<\/p>\n\n\n\n A major advantage of the BSI approach is its project orientation. The study ensures that a pentest is not treated as a loose series of technical tasks, but as a properly commissioned, managed, and tightly bounded security project.<\/p>\n\n\n\n Despite their different perspectives, both approaches share a foundational premise: professional penetration tests require structure.<\/p>\n\n\n\n Both NIST and BSI emphasize that goals, scope, boundaries, responsibilities, and documentation must be defined in advance. Both frameworks prevent a common misconception: a pentest is not uncontrolled “on-demand hacking,” but a highly coordinated security assessment governed by strict rules.<\/p>\n\n\n\n Furthermore, both models emphasize risk assessment. Findings should not just be described technically, but put into context regarding their significance to the organization. The decisive factor is not merely whether a vulnerability exists, but whether it is exploitable, what impact it has, and which remediation measures should be prioritized.<\/p>\n\n\n\n There is also significant overlap in reporting. A good report must be traceable, reproducible, and actionable. It should contain more than just technical details, supporting management, IT operations, and security officers alike.<\/p>\n\n\n\n The core difference lies in the perspective.<\/p>\n\n\n\n NIST SP 800-115 views technical security evaluations from the standpoint of a comprehensive security assessment. Within this framework, penetration testing is just one method among several. This makes NIST particularly suitable for organizations looking to build an overarching security testing program. The guide helps answer which testing methods make sense when, and how technical assessments can be methodically classified.<\/p>\n\n\n\n The BSI study focuses more heavily on the individual penetration test itself. It describes how such a test should be prepared, commissioned, executed, and completed. This makes it highly effective for concrete pentest projects, RFPs, statements of work, and coordination between the client and the service provider.<\/p>\n\n\n\n The two documents also differ culturally and from a regulatory standpoint. NIST was developed within the US federal context but has been widely adopted internationally. The BSI study is tailored specifically to German frameworks, public sector entities, and local legal requirements. While this provides a practical advantage for organizations in the DACH region, it can limit its direct applicability in international contexts.<\/p>\n\n\n\n Referencing NIST SP 800-115 or the BSI concept is useful when treated as a methodological framework. It becomes problematic when it is used to replace the actual technical requirements.<\/p>\n\n\n\n Phrases like “Execution according to BSI” or “Testing in accordance with NIST SP 800-115” leave the most critical project questions completely unanswered:<\/p>\n\n\n\n Without this level of detail, incoming proposals become difficult to compare. One vendor might quote a highly limited vulnerability scan with manual validation, while another proposes a deep-dive pentest involving exploitation, attack path analysis, and a comprehensive retest. Both could technically claim adherence to the same standard, yet they would deliver completely different services.<\/p>\n\n\n\n For this reason, a tender must do more than just drop standard names\u2014it must operationalize them. NIST or BSI can provide the baseline framework, but the concrete depth of testing, the scope, the permitted methods, and the expected results must be described specifically for each project.<\/p>\n\n\n\n While both documents remain valuable foundations, they are no longer entirely sufficient for today’s pentesting scenarios. This is not just because they are written generically; it is quite simply due to the age of the underlying references.<\/p>\n\n\n\n NIST SP 800-115 was published back in 2008. In practice, the BSI concept is heavily tied to its “Practical Guide for Penetration Tests”<\/em> (Version 2.0). This guide also belongs to an era when classic network, server, and on-premises application landscapes were far more dominant than today\u2019s cloud-native, highly automated, and identity-centric environments.<\/p>\n\n\n\n This reality highlights the boundaries of these standards. Modern architectures and risks are not covered with the depth required for modern security posture assessments:<\/p>\n\n\n\n Particularly within a DevSecOps environment, a traditional phased model falls short. It is no longer just about testing a target system at a single point in time. It requires evaluating build and deployment pipelines, secret management, artifact repositories, CI\/CD access controls, container images, IaC templates, cloud role models, and automated guardrails across the entire supply chain.<\/p>\n\n\n\n This does not render the frameworks obsolete. Their strength still lies in their process quality: clear goal alignment, clean scoping, legal safeguards, methodical execution, controlled testing, traceable reporting, and concrete remediation steps. These principles remain valid regardless of the technology stack.<\/p>\n\n\n\n However, these documents should be read as historical and methodological baselines rather than up-to-date technical checklists. The technical depth required for modern environments must be supplemented by modern specialized standards, project-specific threat modeling, and tailored testing requirements.<\/p>\n\n\n\n For legacy infrastructure, network, and broad organizational assessments, NIST SP 800-115 remains a robust foundation. It is particularly useful when embedding penetration testing into a larger corporate security assessment or risk management program.<\/p>\n\n\n\n The BSI study, on the other hand, excels when planning or procuring a specific penetration test. It aids in aligning the client and the service provider, defining legal and organizational boundaries, and executing the project structurally.<\/p>\n\n\n\n In practice, the question shouldn’t be whether NIST or BSI is “better.” The most effective approach is to combine both perspectives, enriched by modern, specialized technical standards:<\/p>\n\n\n\n NIST SP 800-115 and the BSI concept are not competing standards, but rather two different lenses through which to view professional security testing.<\/p>\n\n\n\n NIST views penetration testing as part of a comprehensive technical security assessment program. This makes it highly suited for governance, methodology, and integration into a repeatable corporate testing framework.<\/p>\n\n\n\n The BSI study views penetration testing strictly as a defined, commissioned, and legally insulated project. This makes it incredibly valuable for clients, vendors, and regulated entities looking for project structure in the German-speaking market.<\/p>\n\n\n\n At the same time, we must not over-rely on these references. They are generic frameworks from an era before cloud-native architectures, DevSecOps, identity-centric attack paths, and modern supply chain risks became the norm.<\/p>\n\n\n\n In procurement and RFPs, simply demanding a test “according to BSI” or “in line with NIST” is no longer enough. If you want to receive robust, comparable, and high-quality proposals, you must explicitly define the scope and parameters of the expected test.<\/p>\n\n\n\n The ideal formula remains: NIST for the overarching assessment program, BSI for the pentest project structure, modern specialized standards for technical depth\u2014and a well-crafted Statement of Work for everything these standards intentionally leave open.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" In many current requests for proposals (RFPs) and tenders for penetration tests, explicit reference is made to “the BSI standard” or “the NIST standard.” At first glance, this suggests methodical maturity and clear quality requirements. In my view, however, this trend is not without its problems: both references are highly generic and cannot substitute a … [Read more…]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[220],"tags":[],"class_list":["entry","post","publish","author-psauer","post-4307","format-standard","category-pentesting"],"_links":{"self":[{"href":"https:\/\/security.sauer.ninja\/en\/wp-json\/wp\/v2\/posts\/4307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/security.sauer.ninja\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/security.sauer.ninja\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/security.sauer.ninja\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/security.sauer.ninja\/en\/wp-json\/wp\/v2\/comments?post=4307"}],"version-history":[{"count":3,"href":"https:\/\/security.sauer.ninja\/en\/wp-json\/wp\/v2\/posts\/4307\/revisions"}],"predecessor-version":[{"id":4312,"href":"https:\/\/security.sauer.ninja\/en\/wp-json\/wp\/v2\/posts\/4307\/revisions\/4312"}],"wp:attachment":[{"href":"https:\/\/security.sauer.ninja\/en\/wp-json\/wp\/v2\/media?parent=4307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/security.sauer.ninja\/en\/wp-json\/wp\/v2\/categories?post=4307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/security.sauer.ninja\/en\/wp-json\/wp\/v2\/tags?post=4307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Two References with Distinct Objectives<\/h2>\n\n\n\n
\n
NIST SP 800-115: Security Assessment Over Mere Penetration Testing<\/h2>\n\n\n\n
\n
\n
The BSI Concept: The Pentest as a Controlled Project<\/h2>\n\n\n\n
\n
Similarities: Structure, Scope, and Traceability<\/h2>\n\n\n\n
Differences: Broad Assessment Model vs. Targeted Project Process<\/h2>\n\n\n\n
Why a Standard Reference Alone Is Insufficient for Tenders<\/h2>\n\n\n\n
\n
Technical Limitations: The Age Factor Is Real<\/h2>\n\n\n\n
\n
Practical Application: When to Use Which Model<\/h2>\n\n\n\n
\n
\n
Conclusion<\/h2>\n\n\n\n