Now that NEI 08-09 Revision 7 is out, what does that mean for your nuclear cybersecurity program? This is a question every licensee should be asking. NEI 08-09 has long served as the industry template for developing and maintaining Cybersecurity Plans for nuclear power reactors, and Revision 7 is more than a housekeeping update. It reflects years of implementation experience, incorporates guidance that accumulated after Revision 6, and responds to the realities of modern nuclear digital environments. This article explores the most important changes, suggests practical actions to capitalize on the new revision, and discusses realistic paths for bringing a nuclear cybersecurity program up to date.
The Value of Adopting Revision 7
Revision 6 was issued in 2010, at a time when many nuclear cybersecurity programs were still moving from design into implementation. Since then, the operating fleet has built inventories of critical digital assets, completed security control assessments, developed defensive architectures, matured monitoring programs, and generated years of inspection and self-assessment experience. During that same period, the threat environment changed substantially. Remote connectivity, wireless technologies, vendor support models, software supply chains, cloud-adjacent business services, and more complex data flows have all increased the number of interfaces that cybersecurity programs must understand and manage.
Revision 7 matters because it consolidates that experience into the plan template rather than leaving licensees to reconcile a web of addenda, related NEI guidance, NRC correspondence, white papers, SFAQ’s, and site-specific interpretations. NRC correspondence describes NEI’s Revision 7 package as a request for NRC review and endorsement of changes to NEI 08-09, and later NRC acceptance materials note that the updated package incorporates NRC feedback and clarifies guidance in areas such as wireless technologies and defense-in-depth. For a licensee, the practical message is clear: the Cybersecurity Plan should no longer be treated as a static compliance artifact. It should be treated as a living program document that reflects current guidance, current plant configurations, and current cyber risk.
What Changed from Revision 6 to Revision 7
The first major change is consolidation. Revision 6 did not remain frozen after 2010. Addenda and supplemental guidance addressed topics such as alternative controls, vulnerability management, ongoing monitoring and assessment, wireless technology, critical digital asset determination, control assessment, and event notification. Many sites adopted some of that material through approved program changes, while others incorporated portions into procedures, assessment templates, or engineering workflows. Revision 7 brings much of that accumulated guidance into one updated baseline, reducing ambiguity about where expectations reside.
The second change is alignment. Revision 7 is intended to better align NEI 08-09 with related guidance such as NEI 10-04 for critical digital asset identification, NEI 13-10 for security control assessments, NEI 15-09 for cyber event notifications, and NRC Regulatory Guide 5.71. This matters because the Cybersecurity Plan is not implemented in isolation. The plan depends on a consistent chain of decisions: which systems are in scope, which assets are critical digital assets, which security controls apply, how alternative controls are justified, how vulnerabilities are managed, and how events are reported. A Revision 7 transition should therefore evaluate not only the plan text but also the implementing procedures that translate the plan into daily work.
The third change is a stronger emphasis on adaptable defense-in-depth. Nuclear cybersecurity has always relied on layered protection, but modern implementation requires more than fixed architecture diagrams and control checklists. Licensees need monitoring, assessment, and response capabilities that can adjust as threats, technologies, vendors, and plant configurations change. Revision 7’s clarifications around monitoring, defense-in-depth, and modern communications should push programs to examine whether their controls are merely documented or are actively verified through evidence, testing, and operational feedback.
What It Means for Your Cybersecurity Plan
The biggest implication is that a licensee should avoid treating Revision 7 as a simple word-processing update. The right question is not, “Can we swap the plan template?” The right question is, “What does the new baseline change in our licensing basis, program commitments, control implementation, assessment evidence, and change-management process?” Some Revision 7 content may already exist in a site’s program because it was adopted through earlier addenda or approved changes. Other content may require new analysis, revised procedures, updated security control implementation statements, or additional evidence. A disciplined transition separates these categories before making regulatory or programmatic commitments.
Critical digital asset scoping is a good place to start. If Revision 7 aligns the Cybersecurity Plan more closely with CDA determination and control assessment guidance, then legacy asset lists should be reviewed for consistency. Plants should confirm that safety, security, emergency preparedness, and support-system functions are still being evaluated with the correct consequence-based logic. They should also confirm that boundary decisions, indirect support relationships, data pathways, and shared infrastructure assumptions remain valid. The most common risk in a transition is not that a program lacks controls; it is that the basis for applying or excluding controls has become stale.
Security control assessments also deserve close attention. If controls were assessed years ago, the implementation evidence may no longer reflect current network architecture, user access practices, logging capabilities, vendor support arrangements, or removable media workflows. Revision 7 provides an opportunity to refresh the security control assessment process so that it is not only complete but defensible. Each control should connect to an implementing procedure, a technical or administrative implementation, an owner, evidence, compensating or alternative control rationale where applicable, and a periodic review mechanism.
Actions to Take Now
The first action is to build a formal Revision 6-to-Revision 7 delta matrix. The baseline should not be Revision 6 alone; it should be Revision 6 plus all addenda, approved white papers, site commitments, and NRC-approved changes already incorporated into the program. The matrix should identify the Revision 7 source, the prior source basis, the type of change, the impacted procedure or control family, whether the change affects the Cybersecurity Plan text, and whether it may trigger a 10 CFR 50.54(p) evaluation. This prevents the team from misclassifying an already-adopted expectation as new or overlooking a subtle change in the control basis.
The second action is to prioritize the changes by implementation impact. High-priority items are those that could affect CDA scope, defensive architecture, monitoring and detection, incident response, wireless connectivity, vendor access, vulnerability management, alternate controls, or regulatory commitments. Medium-priority items may require procedure updates, training changes, or evidence improvements. Lower-priority items may be editorial or terminology updates, but they should still be tracked to closure. A prioritized approach keeps the project focused on risk and compliance significance rather than page count.
The third action is to engage the right stakeholders early. Cybersecurity, engineering, licensing, operations, security, emergency preparedness, procurement, information technology, and quality assurance may all own pieces of the implementation. Revision 7 touches program governance as much as technical control language. A successful transition requires clear ownership for asset inventory updates, procedure changes, control assessment evidence, vendor and supply-chain considerations, training updates, corrective action program entries, and any required regulatory evaluations.
Two Practical Paths to Update the Program
One path is a targeted update. This approach is appropriate when a licensee has already adopted most Revision 6 addenda, has mature implementing procedures, and can show that Revision 7 introduces limited substantive change to the site program. The targeted path focuses on documented deltas, licensing review, selective procedure revisions, and focused evidence updates. It is efficient, but it depends on strong configuration control and well-maintained program records.
The second path is a comprehensive program refresh. This is appropriate when the current plan has accumulated years of local interpretations, when CDA inventories or control assessments have not been recently validated, or when the site has introduced new technologies, vendor models, or communications pathways. A refresh is more resource-intensive, but it can reduce long-term inspection risk by reconnecting the Cybersecurity Plan, CDA basis, procedures, assessments, evidence, and corrective action program into a coherent whole.
Both paths should include a regulatory decision point. Under 10 CFR 50.54(p), changes to security plans must be evaluated to determine whether they decrease safeguards effectiveness or require NRC approval. The transition team should therefore document not only what changed, but why the change is equivalent, more conservative, administrative, or potentially substantive. Licensing should be involved before implementation packages are finalized, not after procedure changes have already been issued.
The Bottom Line
NEI 08-09 Revision 7 should be viewed as an opportunity to modernize and strengthen the nuclear cybersecurity program, not merely as a compliance burden. It gives licensees a chance to consolidate years of guidance, clarify the relationship between plan commitments and implementing procedures, update assumptions about modern technologies, and improve the evidence that supports high assurance. The programs that benefit most will be those that approach the transition deliberately: establish the correct baseline, map the deltas, prioritize by risk and regulatory impact, involve the right stakeholders, and choose an update path that matches the maturity of the existing program.
The immediate next step is simple: assemble the current NRC-approved Cybersecurity Plan, the site’s adopted Revision 6 addenda, implementing procedures, CDA inventory basis, security control assessment records, and the Revision 7 package. From there, build a defensible transition matrix and let that matrix drive the project plan. Done well, the Revision 7 transition can become more than an administrative update. It can become a focused program health check that improves compliance confidence, operational resilience, and readiness for the next generation of nuclear digital systems.
-Stacy Baskin
President, Cyber Realm Solutions