The provided text is the official definition of a "Major Application" as established by the U.S. Office of Management and Budget (OMB) and used within the NIST Risk Management Framework (RMF) context. This classification is used for systems that are mission-critical, handle sensitive data, or are of significant financial value. The key elements in the definition—"special attention to security," "risk and magnitude of harm," and the note's reference to "special management oversight"—directly correspond to the criteria for designating an application as major, which necessitates more rigorous security controls and continuous monitoring than a non-major or general support system.

B. Humble Application: This is not a recognized term in information security or federal risk management frameworks; it serves as a distractor.

C. Slight Application: This is not a standard classification. It implies low impact, which is the direct opposite of the definition provided.

D. Worthless Application: This is incorrect as the definition clearly describes an application of high value and risk, warranting special security attention.

1. Office of Management and Budget (OMB). (2000). OMB Circular A-130, Appendix III, Security of Federal Automated Information Resources. The question's text is a verbatim quote from Section 2.a.(3) of this historical but foundational document. It states: "Major application. An application that requires special attention to security due to the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application."

2. National Institute of Standards and Technology (NIST). (2006). NIST Special Publication 800-18, Guide for Developing Security Plans for Federal Information Systems. In Appendix A, this guide provides a glossary that defines "Major Application" by directly referencing and quoting the definition from OMB Circular A-130, Appendix III.

3. National Institute of Standards and Technology (NIST). (2018). NIST Special Publication 800-37, Revision 2, Risk Management Framework for Information Systems and Organizations. While the term "major application" has been largely superseded by impact-level categorization (Low, Moderate, High), the concept is identical. Section 2.3, "System and Information Integrity," discusses categorizing systems based on the potential impact of a loss of integrity, which directly relates to the "magnitude of harm" described in the question. A "Major Application" would be categorized as a moderate- or high-impact system under the current RMF.

The question provides the official definition of security Certification. This process is a comprehensive technical evaluation of a system's management, operational, and technical controls. The findings from the certification process provide the necessary information for an Authorizing Official (AO) to make a risk-based decision on whether to grant an Accreditation (now more commonly called an Authorization to Operate or ATO). Certification directly assesses if controls are implemented correctly, operating as intended, and achieving the desired security outcomes, forming the foundation for the formal accreditation decision.

B. Examination: An examination is a part of the overall assessment but is not the comprehensive, formal process of certification that supports an accreditation decision.

C. Operation: This refers to a phase in the system development life cycle where the system is in use, not the assessment process itself.

D. Information: This is the asset being protected by the security controls, not the process of evaluating those controls.

1. Committee on National Security Systems (CNSS). (2015). Instruction No. 4009, National Information Assurance (IA) Glossary.

This document provides the verbatim definition used in the question. On page 10, "Certification" is defined as: "A comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security accreditation, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system."

2. National Institute of Standards and Technology (NIST). (2010). Special Publication 800-37, Revision 1, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach.

In Appendix G, Glossary, page G-2, this foundational document provides the same official definition for "Certification," linking it directly to the accreditation process.

3. National Institute of Standards and Technology (NIST). (2018). Special Publication 800-37, Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy.

While modern RMF terminology has replaced "Certification" with the "Assess" step, the function is identical. Section 2.3, "The RMF Steps," describes the Assess step as the process to "determine if the controls selected for the system...are implemented correctly, operating as intended, and producing the desired outcome." This aligns perfectly with the classic definition of certification.

Applying the first three steps of the Risk Management Framework (RMF) to a legacy system is fundamentally a gap analysis. The process involves categorizing the system (Step 1) and selecting the required baseline security controls (Step 2). Then, this required baseline is compared against the controls already implemented in the legacy system (Step 3). The objective of this comparison is to identify the "gaps"—any necessary controls that are missing, incorrectly implemented, or insufficient. This analysis determines the specific actions needed to bring the legacy system into compliance with the newly established security requirements.

A. Sequential: This describes the procedural order of the RMF steps, not the analytical method used to evaluate a legacy system's control posture against a required baseline.

B. Level of effort: This term refers to the amount of resources and work required for a task, not the specific type of analysis being performed.

D. Common control: This refers to a security control that can be inherited by multiple systems. It is a type of control, not a method of analysis.

1. NIST Special Publication 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. While not using the exact term "gap analysis" in this specific context, the described process is functionally identical. Section 2.3, "Relationship to Existing Processes," explains that for existing systems, organizations apply the RMF steps to ensure compliance, which necessitates comparing the current state to the required state.

2. NIST Interagency Report (NISTIR) 8170, The Cybersecurity Framework: Implementation Guidance for Federal Agencies. This document, which provides guidance on implementing a risk framework closely related to the RMF, explicitly defines this process. Section 3.2, "Step 3: Create a Target Profile," states, "The results of this activity can be used to perform a gap analysis between the Current Profile and the Target Profile to determine what is necessary to meet the cybersecurity risk management requirements." This directly maps to evaluating a legacy system (Current Profile) against an RMF baseline (Target Profile).

3. Carnegie Mellon University, Software Engineering Institute (SEI), CERT Resilience Management Model (CERT-RMM) v1.2. As a reputable academic and research institution, the SEI's work on resilience management aligns with RMF principles. The model emphasizes assessing existing capabilities against required practices, stating, "A gap analysis can reveal weaknesses in practices that an organization can then resolve." (CERT-RMM v1.2, Section 2.4, "Appraisal and Improvement"). This validates the use of gap analysis for evaluating existing systems against a framework.

Federal Information Processing Standard (FIPS) 199, "Standards for Security Categorization of Federal Information and Information Systems," is used to determine a system's security category (e.g., Low, Moderate, or High) based on the potential impact of a loss of confidentiality, integrity, and availability. This security categorization is a foundational component and a direct input to the System Security Plan (SSP). The SSP must document this categorization, as it dictates the selection of the initial baseline of security controls from NIST SP 800-53 that are required for the system. The SSP then describes how these selected controls are implemented.

A. The Security Assessment Report (SAR) documents the results of testing security controls. The FIPS 199 category influences the assessment scope but is not a direct input to the report itself.

C. The Plan of Actions and Milestones (POA&M) is created from the findings in the SAR to track the remediation of identified weaknesses. It is a downstream artifact.

D. The Authorization Decision Document is the final output from the Authorizing Official after reviewing the entire authorization package (SSP, SAR, POA&M), not a direct recipient of FIPS 199 data.

1. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-18 Rev. 1, Guide for Developing Security Plans for Federal Information Systems, December 2006.

Section 2.2, "System Security Plan Content," Page 4: "The FIPS 199 security categorization of the information system is a key element of the system security plan."

2. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, December 2018.

Chapter 2, Section 2.3, Task P-1 "System Security and Privacy Plans," Page 30: This task, part of the "Prepare" step, involves developing, reviewing, and approving plans to manage security and privacy risk. The SSP is the primary output, and its development relies on the outputs of the "Categorize" step, which uses FIPS 199.

3. Federal Information Processing Standards (FIPS) Publication 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004.

Section 4, "SPECIFICATION OF SECURITY CATEGORIES," Page 5: "The security categories are to be used in conjunction with vulnerability and threat information in assessing the risk to an organization... The security category of an information system will be used to guide the selection of the appropriate set of minimum security controls..." This selection and documentation process occurs within the SSP.

The question refers to the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF), a foundational process for the CGRC certification detailed in NIST SP 800-37. The RMF consists of a six-step cycle preceded by a "Prepare" step. Step 6 is "Monitor Security Controls." This final step in the cycle involves continuously monitoring the effectiveness of security controls, assessing changes to the system and its environment, and reporting on the system's security posture. The objective is to maintain ongoing situational awareness and ensure that the system operates within an acceptable level of risk, thereby supporting the continuation of its authorization.

B. Select Controls: This is Step 2 of the RMF, where controls are chosen based on the system's security categorization and tailored to the environment.

C. System Boundary: Defining the system boundary is a critical task performed during Step 1, Categorize System, not a distinct, numbered step itself.

D. Authorize: This is Step 5 of the RMF, where a senior official formally accepts the risk and grants an Authorization to Operate (ATO).

1. National Institute of Standards and Technology (NIST). (2018). Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy (NIST Special Publication 800-37, Revision 2). U.S. Department of Commerce.

Reference: Figure 2, "The Risk Management Framework," on page 10, explicitly lists the six steps, with Step 6 being "MONITOR."

Reference: Section 2.8, "Step 6: Monitor," on page 51, details the purpose and tasks of this step.

2. Purdue University. (n.d.). Cybersecurity Courseware: Introduction to the Risk Management Framework (RMF). Purdue University Global.

Reference: The course module on the RMF lifecycle explicitly identifies the six steps in order, stating, "Step 6: Monitor Security Controls. All implemented security controls are monitored for effectiveness."

3. University of Washington. (n.d.). CISO Certificate Program: Frameworks and Standards. UW Professional & Continuing Education.

Reference: The program curriculum outlines the NIST RMF, listing Step 6 as "Monitor security controls: Continuously monitor the system and controls for ongoing effectiveness."

The statement is definitively false. The core objectives of Configuration Management (CM) and its associated controls are precisely to document all proposed and actual changes to an information system and to assess the security impact of those changes. This process is fundamental to maintaining the security posture, integrity, and operational stability of a system. The statement claims the opposite, which misrepresents the entire purpose of the Configuration Management domain.

This is a True/False question. The option "True" is incorrect because it would imply that the function of Configuration Management is to avoid documenting changes and assessing their impact. This contradicts the foundational principles of information system security and governance as established in all major frameworks. Effective CM is impossible without rigorous documentation and impact analysis.

1. NIST Special Publication (SP) 800-53, Revision 5, Security and Privacy Controls for Information Systems and Organizations.

Control CM-3, Configuration Change Control: This control explicitly requires organizations to "a. Determine the types of configuration changes that are to be controlled...; b. Approve or disapprove configuration change requests with explicit consideration for security and privacy impacts; [and] c. Document configuration change decisions associated with the system..." (Page 133).

Control CM-4, Security and Privacy Impact Analysis: This control is entirely dedicated to the concept negated in the question. It mandates that "The organization: a. Analyzes changes to the system to determine potential security and privacy impacts prior to change implementation; and b. Documents the security and privacy impact analysis." (Page 134).

2. NIST Special Publication (SP) 800-128, Guide for Security-Focused Configuration Management of Information Systems.

Section 2.2.3, Configuration Change Control: This section states, "Configuration change control is the systematic proposal, justification, implementation, testing, review, and disposition of changes to the system... The process includes managing and controlling all changes to the system configuration... The configuration change control process also ensures that the security impact of any change is analyzed and documented." (Page 8). This directly refutes the premise of the question.