NIST Rewrites Its Executive Security Handbook After Twenty Years: What Leaders Should Check Before December 4

When NIST published the original Information Security Handbook in 2006, the Cybersecurity Framework did not exist, and the Risk Management Framework, the Privacy Framework and the AI Risk Management Framework all came later. On October 21, 2026, NIST released an initial public draft of a rewrite, SP 800-100 Rev. 1, titled Information Security Handbook: A Guide for Executive Leadership, and opened it for public comment through December 4, 2026.

The document will not change anyone’s legal obligations. It is a plain-language map of how NIST’s own guidance fits together, written for people who oversee security without doing the technical work. That makes it more useful than its modest framing suggests, particularly for privacy and compliance teams that need to explain to executives how security, privacy and risk programs relate. It also makes it worth reading critically, because comments sent in now can still change what the final version says.

What NIST actually published

The NIST publication page lists four authors: Isabel Van Wyk, Jeff Brewer, Jeremy Licata and Jeffrey Marron. NIST says the cybersecurity landscape, the regulatory environment and its own body of guidance have changed substantially since 2006, so the revision restructures the handbook around the NIST Cybersecurity Framework (CSF) 2.0. It gives high-level summaries of governance, risk management, information exchange, security awareness and training, contingency planning, configuration management and incident response, and points readers to other NIST publications for technical detail.

The draft itself says its audience is people who manage, support and oversee information security and risk management but do not necessarily hold technical responsibilities: senior leaders such as CIOs and CISOs, program managers, information system owners and other managers with security duties. It describes itself as a high-level guide, and it says nongovernmental organizations may use it on a voluntary basis. The document is built from federal authority, specifically FISMA, but nothing in the draft makes it a requirement for private companies.

Two practical limits follow from that framing. First, it is a draft, and sections may change after comments. Second, it deliberately avoids implementation detail. A security team looking for configuration baselines or control tests will be sent elsewhere in the NIST library.

How the draft is organized

The structure follows the CSF’s logic, with a few additions for executives. The sections, in order:

• An introduction that lists leadership roles and what each is expected to own, from the head of the organization and the CIO and CISO to the chief enterprise architect and the senior privacy official.
• An overview of seven NIST frameworks and how they relate: the Risk Management Framework, CSF 2.0, the NICE workforce framework, the Privacy Framework, the Secure Software Development Framework, the AI Risk Management Framework and cybersecurity supply chain risk management, which the draft notes is not technically a NIST framework.
• Governance, including risk appetite and tolerance, enterprise risk management, governance roles and policy.
• The CSF’s Identify and Protect functions, covering asset management, risk assessment, information exchange, measurement and metrics, zero trust, awareness and training, contingency planning and configuration management.
• Continuous monitoring, and detection, response and recovery.

The more valuable part of the overview is the connective tissue. NIST says the Risk Management Framework is the operational foundation, that the CSF’s outcomes layer on top of it, that the Privacy Framework supplements it for privacy risk, and that the AI RMF is a domain-specific extension for AI. In other words, NIST is telling executives that these are not competing programs. They are one risk process viewed from different angles.

Where privacy appears in the draft

Privacy is present but not dominant, which is itself something privacy teams may want to comment on. The roles section assigns the senior agency official for privacy, or chief privacy officer, responsibility for developing and supporting the privacy program, leading privacy risk management, ensuring privacy compliance for information security assets and activities, and reviewing and implementing privacy regulations. The Privacy Framework gets its own subsection, describing it as a voluntary tool that is agnostic to technology, sector, law and jurisdiction.

One passage in that subsection makes a point worth repeating: even an organization that fully complies with applicable laws can suffer unintended consequences to its brand, finances and growth prospects, and privacy risk assessments help find those gaps. That is a useful argument to take to a leadership team that treats privacy as a legal checkbox. It frames privacy risk as a business risk that continues after the legal analysis ends.

Ideas from the draft that privacy teams can borrow

Risk appetite is not risk tolerance

The governance section separates the two. Risk appetite is set at the highest level and guides the type and amount of risk senior leaders will accept in pursuit of the mission. Risk tolerance is the more specific level considered acceptable within that appetite, and the draft says tolerance statements are always more specific than the appetite statements above them. Many privacy programs have neither written down. If a company cannot say how much unexplained tracker activity or how many overdue deletion requests it will accept, it has not made the decision; it has only deferred it.

Three levels of risk management

The draft describes organization-level, mission and business process-level, and system-level risk management, with each level informed by the one above it. For a privacy team, that translates into a simple test: does the privacy policy set at the top reach the system owner who actually configures the tag manager or the data warehouse? A policy that stops at the second level is not yet a control.

Asset inventories include data flows and outside services

The asset management text says an inventory covers hardware, software, data and facilities, may include services provided by external parties and may document organizational data flows, and that it is not a one-time task. Most privacy programs already keep records of processing activities, but the draft’s wording is a reminder that an inventory is only as good as its maintenance process.

Information exchange needs formal agreements

The draft defines information exchange as accessing or transferring data outside authorization boundaries, and says organizations establish formal agreements for system interconnections that set technical and security requirements, define responsibilities and identify inherited risks. That is vendor management in security vocabulary. A data processing agreement without the technical interconnection terms behind it covers only half of the arrangement.

Monitoring is a cycle, not a report

The continuous monitoring section lays out six stages: define, establish, implement, analyze, respond and review or update. It emphasizes automating collection and analysis where possible and reporting on the effectiveness of controls, not only their existence. A completed assessment is not proof that a technical control works; the draft’s own approach is to keep measuring after the assessment is signed.

Incident response includes the people outside security

The incident response discussion names legal, public affairs, human resources and facilities staff alongside technical responders. It says non-federal organizations are not required to follow federal incident guidance but may benefit from it, and it points to OMB Memorandum M-17-12 for procedures on breaches of personally identifiable information. A response plan that lists only the security team has left out the people who will write the notices.

1. Six questions to bring to your leadership team

These questions are our own suggestions for turning the draft into an internal discussion. They are not requirements from NIST.

1. Who owns privacy risk, in writing? The draft assigns a privacy official specific duties. Check whether your organization’s equivalent has authority over security-related decisions that touch personal data.
2. Have we stated an appetite and a tolerance? Write one sentence for each, for example for third-party data sharing, and see whether leaders agree.
3. Does our asset inventory show where personal data goes? Look for external services and data flows, and check the date of the last update.
4. Which agreements govern our connections to other organizations? Match contracts to the technical interconnections they are supposed to cover.
5. What do we measure after launch? Pick two controls, such as consent signal enforcement and deletion completion, and ask what evidence shows they still work.
6. Who beyond security is in our incident plan? Confirm that legal, communications and HR have named contacts and have taken part in an exercise.

Commenting before December 4

NIST asks for comments by email to sp800-100-comments@nist.gov and encourages commenters to use its comment template. The draft’s cover material also states that all comments are subject to release under the Freedom of Information Act, so companies should assume that what they submit may become public.

Several features of the draft invite specific feedback. The scope question is the obvious one: should a handbook for executive leadership say more about privacy governance than a privacy official’s role description and a subsection on the Privacy Framework? Another is how the document treats AI. It describes the AI RMF and its functions, but AI appears only in the framework overview and the section on how the frameworks relate. It is not carried into governance, monitoring or incident response. The draft is also visibly unfinished in places. Several cross-references still read “Error! Reference source not found,” and a few entries in the federal governance list have run into the references. Careful readers can help NIST by pointing those out, though substantive comments will count for more.

Where Captain Compliance fits

The handbook is about governance and risk, and those are areas where Captain Compliance offers advisory support. Its privacy and cyber governance service describes helping organizations define leadership roles for privacy and cybersecurity, build frameworks aligned to relevant standards, run privacy audits against those frameworks and prepare regular privacy and cybersecurity discussions for executives and boards. Its privacy records and inventory service covers identifying and mapping personal data, classifying it, maintaining records of processing activities and keeping those records current. Those map loosely to the draft’s governance and asset inventory sections.

That is a map, not an equivalence. Nothing Captain Compliance provides makes an organization conform to SP 800-100, which is not a conformance standard, and the technical control testing the handbook points to sits with security teams and the cited NIST publications. For more on how to align privacy and security frameworks, see our guide to choosing between NIST, ISO 27701 or neither, our piece on integrating privacy into enterprise risk management and our write-up of NIST’s human-centered cybersecurity concept paper.

Frequently asked questions

Is SP 800-100 Rev. 1 mandatory?

No. The draft states that nongovernmental organizations may use it voluntarily. It draws on federal authorities such as FISMA, which apply to federal agencies, but the handbook itself is guidance. Contracts, regulators or customers may still ask organizations to show alignment with NIST guidance, which is a different matter.

How is the revision different from the 2006 handbook?

NIST says it restructures the handbook to follow the organization of CSF 2.0 and adds summaries of newer NIST frameworks, including the Privacy Framework, the AI RMF and cybersecurity supply chain risk management. The original was released in 2006, before most of these existed.

Who should comment?

Anyone affected by the guidance: executives who rely on it, privacy and security practitioners, auditors and vendors. NIST encourages organizations to review draft publications during comment periods. Because comments may be released under FOIA, avoid including confidential business details.

Does the draft cover AI governance?

It summarizes the AI Risk Management Framework, with its Govern, Map, Measure and Manage functions, and describes how it relates to the Risk Management Framework. It does not set out AI-specific governance requirements, and it directs readers to NIST AI 100-1 for details.

What is the deadline, and how do I submit?

Comments are due December 4, 2026, by email to sp800-100-comments@nist.gov, and NIST encourages use of its comment template.

Does following the handbook protect a company in an enforcement action?

There is no such assurance in the draft. Regulators and courts look at what a company did and could show, not at which guide it cited. Documentation that ties decisions to a recognized framework can help explain them, but it does not replace working controls.

The handbook asks executives to put their risk decisions in writing and own them. The comment process asks the same of any company that wants the final version softened or sharpened: say it on the record, knowing that the record may be released to anyone who files a request.