Free CGRC Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

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.

Leveraged authorization is a process where an organization accepts an existing authorization of a system, service, or application from another organization to avoid redundant assessment and authorization efforts. In the scenario described, a single complex information system is used by two agencies. This system is defined by a single, unique accreditation boundary. One agency (the provider or owner) performs the initial authorization. The second agency then "leverages" this existing authorization package to grant its own Authority to Operate (ATO). Although two agencies issue separate ATOs, they are both for the same system contained within that single boundary. Therefore, the minimum number of system boundaries is one.

B. Only two, because there are two agencies.

This is incorrect. The number of agencies using a system does not dictate the number of system boundaries. Leveraged authorization is designed for a single system to be used by multiple entities.

C. At least two.

This is incorrect. The principle of leveraged authorization for a shared or common system is most efficient when applied to a single system with one boundary, making one the minimum.

D. A leveraged authorization cannot be conducted with more that one agency involved.

This is incorrect. The concept of "leveraged" authorization inherently requires at least two parties: the entity providing the authorization package and the entity leveraging it.

---

1. NIST Special Publication 800-37, Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy.

Section 2.5, "Relationship Among Authorizations," describes leveraged authorizations: "An authorization based on a leveraged authorization is an authorization decision that is based, in part, on another authorization decision." This confirms that one system's authorization can be the basis for another agency's decision, implying a single system boundary is the subject.

Appendix F, "Authorization Boundary," defines the authorization boundary as encompassing all components of a single information system to be authorized. This supports the concept of one system having one boundary, regardless of the number of consuming agencies.

2. Federal Risk and Authorization Management Program (FedRAMP), Guide to Understanding FedRAMP.

"What is an Agency ATO?" section: This guide explains how federal agencies leverage the FedRAMP authorization of a Cloud Service Provider (CSP). The CSP's service has a single authorization boundary, and multiple agencies can grant their own ATOs by leveraging the single FedRAMP package. This is a direct, real-world application of the principle.

3. ISC2, (ISC)² CGRC Certified in Governance, Risk and Compliance Official Study Guide (1st ed.).

Chapter 4, "Select, Implement, and Assess Security and Privacy Controls": This chapter discusses the RMF process, including the concept of reciprocity and leveraging existing authorizations for common controls and shared systems, reinforcing that a single authorized system can serve multiple entities.

The Organization Level (Tier 1) is responsible for establishing the overall risk management strategy and governance for the entire organization. This involves defining the complete, logical lifecycle for managing risk. The correct answer presents the standard, sequential phases of a risk management process. The process logically begins with risk assessment and evaluation to understand potential risks. This is followed by a risk response, such as mitigation or acceptance. Finally, the process includes continuous monitoring of risks and is governed by strategic oversight. This sequence represents the comprehensive strategy established at Tier 1 and executed throughout the organization.

B: Incorrect because it places risk response activities (Mitigation, Acceptance) before the essential first step of assessing and evaluating the risk.

C: Incorrect because it begins with risk acceptance, a decision that can only be made after a risk has been properly assessed and evaluated.

D: Incorrect because it illogically separates risk evaluation from risk assessment and places it before the assessment has been conducted.

1. NIST Special Publication 800-39, Managing Information Security Risk: Organization, Mission, and Information System View. Section 2.3, "The Risk Management Process," outlines the core components as Frame, Assess, Respond, and Monitor. The sequence in the correct answer (A) directly maps to this process: Assess (Assessment, Evaluation), Respond (Mitigation, Acceptance), and Monitor (Monitoring), all under the governance of Frame (Oversight).

2. NIST Special Publication 800-37, Revision 2, Risk Management Framework for Information Systems and Organizations. Appendix D, "Risk Management Roles," describes Tier 1 responsibilities, which include establishing the risk management strategy and providing oversight for the entire process, confirming that Tier 1 is concerned with this complete lifecycle.

3. Carnegie Mellon University, Software Engineering Institute, OCTAVE Allegro: Information Security Risk Assessment Method. The OCTAVE method follows a similar logical progression. Phase 2 involves identifying and evaluating risks to information assets, and Phase 3 focuses on identifying risks and developing mitigation strategies, reinforcing the Assess-then-Respond sequence. (See "OCTAVE Allegro Guidebook v1.0," CMU/SEI-2007-TR-012, Steps 5-7).

The question provides the verbatim definition of an information system as established by U.S. law and adopted by the National Institute of Standards and Technology (NIST). An information system is a comprehensive term that includes not just technology but also the people and processes organized for the specific purpose of managing the information lifecycle (collection, processing, maintenance, disposition). This definition is fundamental to the Risk Management Framework (RMF) and the CGRC domain. The other options represent either subsets or foundational components of an information system, but not the complete, defined entity itself.

B. A General Support System (GSS) is a specific type of information system that provides a shared infrastructure, making it a narrower term than the definition provided.

C. An IT infrastructure is the underlying technological foundation (hardware, networks) but lacks the specific, organized purpose of information processing and management described in the question.

D. A Major Application is a software component that runs within an information system, not the entire discrete set of organized resources itself.

1. NIST Special Publication 800-53, Revision 5, Security and Privacy Controls for Information Systems and Organizations, Appendix A, Page A-10. The document defines an Information System as: "A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information."

2. NIST Special Publication 800-37, Revision 2, Risk Management Framework for Information Systems and Organizations, Page 11, Section 2.1. This publication states, "The RMF applies to all federal information systems..." and uses the standard definition throughout, reinforcing that the question describes an information system.

3. 44 U.S. Code § 3502 (Definitions). The E-Government Act of 2002, which is a primary legal source for federal information security, defines "information system" in this section, providing the legal basis for the NIST definition. The text is nearly identical to the question.

The System Owner (or Information System Owner) is a managerial role with ultimate responsibility for an information system throughout its lifecycle. Their responsibilities encompass procurement, development, operation, and disposal.

Option A is correct as it addresses the crucial lifecycle responsibility of integrating security from the very beginning. Option B correctly identifies the owner's duty to ensure ongoing security posture management, including vulnerability assessments and reporting. Option D provides a concise, high-level summary of the System Owner's core accountability for ensuring the system complies with security requirements, as explicitly defined in NIST frameworks.

C. This option is incorrect because it conflates the managerial oversight of the System Owner with the specific, hands-on technical tasks of a System Administrator or Custodian. While the owner ensures security policies are met, they do not typically oversee the granular details of "operating system configurations."

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

Appendix F, Section F.2.6 (Information System Owner): States the System Owner is "Responsible and accountable for ensuring that the security and privacy of the information system are adequately addressed throughout the life cycle... [and] for ensuring that all security and privacy controls are implemented and operating as intended." This directly supports option D. It also supports the lifecycle concept in option A.

2. NIST Special Publication 800-18, Revision 1, Guide for Developing Security Plans for Federal Information Systems. (February 2006).

Section 2.2 (Roles and Responsibilities), System Owner: Defines the role as the "official responsible for the overall procurement, development, integration, modification, operation, maintenance, and disposal of an information system." This supports option A (procurement, development) and the operational oversight implied in option B.

3. Carnegie Mellon University, Information Security Office, Information Security Roles and Responsibilities. (2023).

System Owners Section: Lists responsibilities including: "Ensuring that appropriate security controls are in place and functioning as intended" (supports D), "Ensuring that the system is regularly scanned for vulnerabilities" (supports B), and "Ensuring that security is a part of the system's entire life cycle" (supports A). This source clearly delineates these high-level responsibilities for the owner.