Document: NRC Regulatory Guide
Document ID: 3eb179d3-5491-407d-8b0e-eed083d58a17
Document Type: regulatory_guide
Title: Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants + HISTORY - HISTORY 08/2012 – DG-1206 , Proposed Revision 1 08/1996 – DG-1055 , Proposed Revision 0 (Rev. 1)
Source: NRC Regulatory Guide Division 1
Source URL: https://www.nrc.gov/docs/ML1032/ML103200044.pdf
Revision Date: 2023-06
Chapter: 
Section ID: RG-1.169
CFR Part: 
CFR Title: 

Content:
r satisfying the agency’s regulatory requirements with respect to configuration management plans for safety system software with the exceptions and additions listed in these regulatory positions. In this section of the guide, the cited criterion refers to Appendix B to 10 CFR Part 50 unless otherwise noted. 1. Definitions IEEE Std. 828-2005 refers to IEEE/ Electronic Industries Association (EIA) 12207.0-1996, “Industry Implementation of International Standard ISO/IEC 12207:1995 (ISO/IEC 12207) Standard for Information Technology-Software Life Cycle Processes,” issued March 1998 (Ref. 10), for definitions of the technical terms that are enumerated in Clause 2 of IEEE Std. 828-2005. These definitions are acceptable with the clarifications and additions noted below. a. Baseline Meaning (1) of the term “baseline” from IEEE Std. 828-2005 is to be used. “Formal review and agreement” is considered to mean that responsible management has reviewed and approved a baseline. Baselines are subject to change control. Regulatory Position 2 of this regulatory guide describes the acceptable baseline change approval authority. b. Interface All four variations of the meaning of the term “interface” in IEEE Std. 828-2005 are to be used, depending on the context. Meaning (1), “a shared boundary across which information is passed,” is interpreted broadly according to Criterion III to include design interfaces between participating design organizations. c. Configuration Audit In the context of an audit for delivery of a product, a configuration audit includes both a functional configuration audit and a physical configuration audit. 2. Authority Levels DG-1206, Page 7 Hierarchies of change approval authority levels are permitted, provided that the required authority level is commensurate with the life-cycle stage (nearness to release) and the product’s importance to safety. The promotion of a software product from one level of safety significance to another level of