Technology buyers routinely accept static security documentation during procurement and diligence, including Service Organization Control (SOC) 2 reports, penetration test summaries and security questionnaires that may be months or years old by the time a deal closes. A relatively recent publication by the National Institute of Standards and Technology (NIST) offers a framework for asking better questions.
On June 30, 2026, NIST released Special Publication 800-18 Revision 2 (SP 800-18), which addresses how organizations can maintain current, integrated documentation across security, privacy and supply chain risk. This guidance can be adopted by technology buyers as a practical reference for evaluating whether a vendor's or acquisition target's policies truly reflect their operational posture.
The SP 800-18 Approach to Security, Privacy and Supply Chain Risks
SP 800-18 has long served as NIST's guide for developing system security plans. The original Revision 1, published in 2006, focused on documenting security requirements and controls for federal information systems. The guidance was primarily designed for federal agencies and their contractors, but over time, it became a recognized reference for organizations seeking a structured approach to security documentation.
The core value of SP 800-18 lies in its emphasis on system-level planning. Rather than treating security as a standalone compliance exercise, the publication frames system plans as operational documents that describe the assets being protected, controls in place, individuals responsible for those controls and relationships between interconnected systems. A well-maintained system plan provides visibility into how an organization actually implements its security program, not just what policies exist on paper.
For technology buyers evaluating vendors or acquisition targets, SP 800-18's framework offers an approach for soliciting more useful information about an active security program. Instead of accepting a general representation that a vendor "maintains reasonable security," buyers can ask whether the vendor maintains a current system inventory, data flows are documented, control ownership is assigned and changes to system architecture are tracked over time.
Revision 2's Integrated Risk Management
Revision 2 expands the scope of system planning in two significant ways.
First, the publication now addresses three interconnected plan types: the system security plan, system privacy plan and cybersecurity supply chain risk management (C-SCRM) plan. NIST refers to these collectively as "system plans." The consolidation reflects the reality that security, privacy and supply chain risks are interrelated. An organization cannot meaningfully evaluate its risk posture by looking at security controls in isolation from its data processing activities or reliance on third-party providers. By bringing these three areas into a single framework, Revision 2 encourages organizations to maintain a holistic view of system-level risk.
Second, Revision 2 emphasizes the use of information management tools to maintain system plan information over time. The NIST announcement releasing Revision 2 explains that the update "emphasizes the use of machine-readable data formats to support automated data collection using widely developed platforms, including Governance, Risk, and Compliance (GRC) tools; Security Orchestration, Automation, and Response (SOAR) platforms; and Security Information and Event Management (SIEM) systems." The publication notes that reporting dashboards enabled by these platforms "support near real-time risk management decision-making and reduce the reliance on static, point-in-time documentation."
This shift is significant. Traditional system security plans were often static documents, drafted at a point in time and updated infrequently. Revision 2 recognizes that modern technology environments change continuously. System components are added and removed. External service providers are onboarded and offboarded. Controls are implemented, modified and sometimes degraded. Security documentation that was accurate six or 12 months ago may no longer reflect the current environment.
NIST also published supplemental materials alongside Revision 2, including example outlines for system security plans, system privacy plans and C-SCRM plans, as well as updated guidance on roles and responsibilities for system plan development and maintenance. These templates provide a useful starting point for organizations building or updating their documentation.
Finally, Revision 2 retires legacy system classification terminology such as "general support system" and "major application" in favor of terms that align with current requirements and modern technology ecosystems. This change reflects the evolution from on-premises infrastructure to hybrid and cloud environments where traditional classifications no longer map cleanly to operational reality.
Leveraging SP 800-18 to Guide Diligence and Ongoing Monitoring in Tech Services
Technology customers routinely receive security documentation during the procurement process. A typical package might include a SOC 2 report, penetration test summary, completed security questionnaire, list of sub-processors and various program policies. These materials provide evidence that the vendor implemented a security program and had it vetted by some form of external validation.
The challenge is that most of this documentation reflects a point in time. For example, a SOC 2 Report typically covers a specific audit period and may precede the transaction by six months or more. A penetration test reflects the state of one or more company environment(s) on the date the test was conducted. A security questionnaire captures the vendor's answers as of the date of completion and may present an overly positive picture. If the vendor's program experienced subsequent gaps (e.g., new unpatched vulnerabilities) or experienced subsequent changes in architecture, sub-processors, cloud providers or a modified control environment, the documentation delivered during procurement may be inaccurate or incomplete.
Revision 2's emphasis on maintaining current system information suggests a different approach. Rather than treating security documentation as a static procurement deliverable that can easily be stale, technology agreements could address the ongoing maintenance and periodic provision of security, privacy and supply chain information. For example, existing vendor "trust centers" could be expanded to include customer subscriptions and more regular notices regarding relevant security posture.
Drawing on the elements described in SP 800-18, contract provisions might address the following areas:
- System and Data Flow Documentation. Contracts could require vendors to maintain current system architecture diagrams and data flow documentation reflecting the components, boundaries and external connections relevant to the services provided. The focus is not on requiring vendors to adopt any particular format but ensuring that documentation exists and is kept reasonably current.
- Component and Supplier Information. SP 800-18 Revision 2 addresses system component inventories, including software bill of materials (SBOM) information and external service provider relationships. Technology agreements could require vendors to maintain current information about significant system components and improve notice when material changes occur, such as tracking the use of open source code, addition of new sub-processors or changes in hosting infrastructure.
- Control Status and Remediation. Beyond point-in-time audit reports, buyers may benefit from periodic information about the current status of key controls and any known remediation activities. Customer-facing trust portals or dashboards can provide updated information on control status, incident history and compliance findings. Contracts could contemplate access to such resources where available or periodic reporting where they are not.
- Change Notification. Contracts could improve expectations for collaborative efforts to keep customers informed of material changes to system architecture, control environment or external service providers. The goal is not to require approval for every operational change but ensure that customers have better visibility into changes that could affect the risk profile of services.
- Documentation Through Termination. Contracts could address the preservation and availability of relevant documentation through the termination or transition period. Buyers conducting post-termination audits or transitions to a new provider may need access to system documentation, data flow information and incident records that were maintained during the contract term.
None of these provisions require a vendor to adopt SP 800-18 as a compliance standard. Rather, the framework provides a reference point for businesses to identify the types of capabilities and information that could better support ongoing visibility into vendor security, privacy and supply chain practices.
Leveraging SP 800-18 for Mergers and Acquisitions Diligence
Acquisition targets often present well-drafted information security policies, privacy notices and vendor management procedures during diligence. These documents demonstrate that the target has a formal program and has thought through the relevant issues at a policy level. What they don't always demonstrate is whether the policies are implemented, the implementation is current and the target has visibility into its own risk posture.
SP 800-18's system plan elements provide a useful framework for probing beneath policy-level documentation. A target may have a written information security policy, but does it maintain a current system inventory? The target may have a vendor management policy, but does it have an accurate and up-to-date list of third-party service providers and their access to its sensitive data? The target may have an incident response plan, but does it have records of past incidents and remediation activities?
For buyers conducting information technology and cybersecurity diligence, the following questions informed by SP 800-18's framework may be useful:
- System Inventory. Does the target maintain a current inventory of information systems, potentially including system boundaries, hosting environments and interconnections with other systems? How often is the inventory updated?
- Data Flows. Does the target maintain a record of core data flows, including data collected, processed, stored and transmitted by key systems? Do the records include external data exchanges and third-party access?
- Control Ownership. For key security and privacy controls, has the target documented who is responsible for implementation and ongoing maintenance? Are those assignments current?
- External Providers. Does the target maintain a current list of third-party service providers with access to systems or data? How does the target manage risk associated with those providers?
- Assessment and Remediation History. Beyond current audit reports, does the target have records of past assessments, identified gaps and remediation activities? How have controls evolved over time?
- Change Documentation. Has the target documented significant changes to its system architecture, control environment or external provider relationships over the relevant period? Can it demonstrate that system documentation was updated to reflect those changes?
Rather than overshoot for "compliance" with SP 800-18 or another NIST standard, a company can use the publication's framework to evaluate whether a target's security and privacy program is supported by current operational evidence.
For business acquirers, the gap between supplied security policies and operational evidence can be a significant source of closing risk. Unremediated program gaps, undocumented data flows and unknown third-party dependencies are integration problems at best and liability issues at worst. SP 800-18's approach to risk management can potentially help organizations identify and assess those issues.
Conclusion
NIST SP 800-18 (Revision 2) may not be an optimal security standard for many organizations, but given that it provides a unique lens to assessing risk across security, privacy and supply chain programs through operational practices, it offers a practical reference for probing security programs, including through better questions, more effective contract provisions and more rigorous diligence. In a landscape where point-in-time certifications and static policy documents are still the norm, SP 800-18 can help distinguish between organizations that truly understand and manage their risk posture and those that have simply checked the box.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
[View Source]