Domain 1: Security and Privacy Governance, Risk Management, and Compliance Program
- The RMF has seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor; CGRC domains map to these steps end to end.
- Key roles: the Authorizing Official (AO) accepts risk and grants authorization; the ISSO manages day-to-day security for a system; the ISSM oversees security at the org level; the Security Control Assessor (SCA) independently tests controls; the System Owner is accountable for the system.
- Prepare (organization-level) establishes risk management roles, a risk management strategy, organizational risk tolerance, and a common control provider before any single system enters the RMF.
- FISMA requires federal agencies to develop, document, and implement an agency-wide information security program; NIST publishes the implementing standards and guidance (FIPS, SP 800-series).
- The Privacy Act of 1974 governs collection, use, and disclosure of records about individuals held by federal agencies; a Privacy Impact Assessment (PIA) is required when a system processes PII.
- FedRAMP standardizes security assessment and authorization for cloud service offerings used by federal agencies, layering on top of the RMF and NIST SP 800-53 controls.
- Risk appetite is the amount of risk an organization is willing to pursue; risk tolerance is the acceptable variation around that appetite; both are set by senior leadership, not by the ISSO.
- Supply chain risk management (C-SCRM, per NIST SP 800-161) addresses risk introduced by vendors, suppliers, and third-party components throughout the acquisition and system lifecycle.
- A risk management strategy defines how the organization identifies, assesses, responds to, and monitors risk consistently across all systems, tying individual system risk to enterprise risk.
- Governance documents follow a hierarchy: policy (mandatory intent from leadership), standards (mandatory specifics), procedures (step-by-step instructions), and guidelines (recommended, optional).
- Senior leadership commitment and a documented risk executive function are prerequisites for a functioning governance, risk, and compliance program.
- Legal and regulatory drivers (FISMA, Privacy Act, FedRAMP, agency-specific mandates) determine which controls and processes are mandatory versus discretionary for a given system.
Domain 2: Scope of the System
- Categorize is the RMF step where the system boundary, information types, and impact levels are established; it happens before controls are selected.
- The authorization boundary (system boundary) defines everything included in the system for risk management purposes; components outside the boundary belong to a different system or provider.
- FIPS 199 requires categorizing a system's confidentiality, integrity, and availability as Low, Moderate, or High based on potential impact if that security objective were compromised.
- The high-water mark rule sets the overall system categorization to the highest impact level assigned across confidentiality, integrity, and availability.
- NIST SP 800-60 provides guidance for mapping information types (e.g., financial, PII, mission-critical data) to impact levels to support FIPS 199 categorization.
- Information types must be identified and documented first, because each type may carry a different confidentiality, integrity, and availability impact rating.
- A Privacy Impact Assessment (PIA) is triggered when a system collects, maintains, or disseminates PII, and it documents what PII is collected, why, and how it is protected.
- System type matters for scoping: general support system, major application, or a cloud/shared-services offering each have different boundary and inheritance considerations.
- Interconnections with other systems (via an Interconnection Security Agreement or similar) must be identified and documented as part of defining the boundary.
- Registering the system in the organization's system inventory and assigning ownership are administrative steps that formalize scope before categorization is finalized.
- Incorrectly scoping the boundary too broadly or too narrowly leads to under- or over-applying controls and misstating risk to the authorizing official.
Domain 3: Selection and Approval of Framework, Security, and Privacy Controls
- Select is the RMF step where a control baseline is chosen based on the system's FIPS 199 categorization (Low, Moderate, or High).
- NIST SP 800-53 Rev 5 organizes controls into families (e.g., AC, AU, CA, CM, IA, IR, RA, SC, SI); SP 800-53B defines the Low, Moderate, and High baselines drawn from those families.
- Tailoring adjusts a baseline to the system's actual risk and operating environment: scoping guidance, compensating controls, and organization-defined parameters are all tailoring actions.
- A compensating control satisfies the intent of a baseline control using an alternative safeguard when the original control cannot be implemented as specified.
- Overlays are specialized sets of controls, control enhancements, and supplemental guidance for specific communities of interest (e.g., cloud, privacy, industrial control systems) applied on top of a baseline.
- Controls are classified by implementation responsibility: common (inherited from a provider, e.g., data center physical security), system-specific (unique to one system), or hybrid (part common, part system-specific).
- Control inheritance lets a system leverage another system's already-authorized common controls, reducing duplicate assessment effort while still requiring documentation of what is inherited.
- Privacy controls are selected alongside security controls; NIST SP 800-53 integrates privacy control families (e.g., PT - Privacy Authorization) rather than treating privacy as a separate framework.
- The control selection and tailoring decisions must be documented and approved, typically through a security plan review, before controls move into the Implement step.
- Risk assessment results (from Prepare and Categorize) inform which tailoring actions and overlays are appropriate for the system's actual threat environment.
- The AO or a designated representative reviews and approves the tailored control set, ensuring it is commensurate with the categorized risk level.
Domain 4: Implementation of Security and Privacy Controls
- Implement is the RMF step where selected controls are put into place within the system and documented in the System Security Plan (SSP).
- The SSP describes the system, its boundary, categorization, and how each selected control is implemented (or planned), and is the central artifact carried through the rest of the RMF.
- Implementation must reflect how a control actually operates in the system (people, process, and technology), not just restate the control text from SP 800-53.
- Common controls inherited from a provider must be referenced in the SSP along with evidence of the provider's own authorization, not re-implemented from scratch.
- Allocation decisions determine whether a control is applied at the system level, a component level, or inherited, and this allocation is recorded in the SSP.
- Configuration management and secure baseline configurations are part of implementation, ensuring controls remain consistently applied as the system changes.
- Privacy control implementation documents how PII is collected, used, retained, and disposed of, aligned with the PIA and any System of Records Notice requirements.
- Implementation evidence (configurations, screenshots, policies, procedures) should be collected as controls are implemented to support the later Assess step.
- Gaps between required and actual implementation should be tracked early, since unimplemented controls typically become POA&M items later in the process.
- Technical, operational, and management controls each require different implementation approaches (technology configuration vs. process/procedure vs. oversight activity).
- The SSP must stay synchronized with the actual system; undocumented changes during implementation create discrepancies that assessors will flag.
Domain 5: Assessment/Audit of Security and Privacy Controls
- Assess is the RMF step where an independent Security Control Assessor (SCA) determines whether implemented controls are effective and correctly implemented.
- Assessor independence is required: the SCA must not have been responsible for developing or operating the controls being assessed, to avoid self-review bias.
- The Security Assessment Plan (SAP) documents the scope, methods, and schedule of the assessment and must be approved before testing begins.
- NIST SP 800-53A defines three assessment methods: examine (review documents/artifacts), interview (talk to personnel), and test (exercise the control to observe behavior), often combined for higher assurance.
- Assessment procedures should be tailored to the system's control baseline and risk, focusing depth and coverage where risk is highest.
- Findings are rated (e.g., satisfied or other than satisfied) based on evidence gathered; unsupported or weak evidence should not be rated as satisfied.
- The Security Assessment Report (SAR) documents assessment results, findings, and the assessor's risk-related recommendations for each control.
- Evidence must be sufficient, relevant, and traceable to the specific control being tested; anecdotal or undocumented claims are not adequate evidence.
- Weaknesses and deficiencies identified during assessment feed into risk determination and, if not remediated immediately, become candidate POA&M items.
- The SCA's role is to report risk objectively to the AO, not to make the authorization decision; that decision remains with the AO.
- Continuous monitoring assessment activities reuse the same SP 800-53A methods on an ongoing basis, not just during the initial authorization assessment.
Domain 6: System Compliance
- Authorize is the RMF step where the AO reviews the authorization package and makes a risk-based decision to allow (or deny) the system to operate.
- The authorization package consists of the SSP, the Security Assessment Report (SAR), and the Plan of Action and Milestones (POA&M).
- Authorization decision types include an Authorization to Operate (ATO), an Interim Authorization to Test (IATT) for testing in an operational environment, an ATO with conditions, or a denial of authorization to operate.
- The AO's decision is a risk-based judgment weighing the SAR findings, mission need, and organizational risk tolerance, not a simple pass/fail on control counts.
- A POA&M documents each identified weakness, planned remediation actions, resources required, and milestone dates, and is used to track remediation over time.
- The AO may accept residual risk, require additional mitigations before authorizing, or transfer/share risk, but cannot eliminate all risk before deciding.
- Authorization is time-bound and tied to the specific system configuration and risk posture assessed; significant changes can invalidate the authorization.
- The authorizing official's acceptance of risk must be formally documented and communicated to system stakeholders and the risk executive function.
- An authorization decision considers the aggregate risk from all outstanding POA&M items, not each weakness in isolation.
- Denial of authorization to operate means the system cannot process, store, or transmit information until identified risks are addressed and resubmitted.
- System owners are responsible for ensuring the authorization package is complete, accurate, and current before it is submitted to the AO for decision.
Domain 7: Compliance Maintenance
- Monitor is the ongoing RMF step that maintains situational awareness of system security and privacy posture after authorization.
- A continuous monitoring strategy defines what controls are monitored, how frequently, and what metrics indicate a change in risk, tailored to the system's categorization.
- Ongoing authorization relies on continuous monitoring data to let the AO reassess risk without requiring a full point-in-time reauthorization for every change.
- Configuration and change management processes ensure that changes to the system are reviewed for security/privacy impact before implementation.
- A significant change (e.g., major architecture change, new interconnection, or change in categorization) can trigger reauthorization or a new security impact analysis.
- POA&M items must be tracked to closure with evidence that remediation was completed and verified, not just marked done administratively.
- Periodic control assessments (a subset of controls each cycle) and annual self-assessments support ongoing risk determination between full reauthorizations.
- Security status reporting keeps the AO, ISSM, and risk executive function informed so authorization decisions reflect the system's current, not historical, risk.
- Decommissioning and disposal require secure sanitization or destruction of media, updates to the system inventory, and closure of the authorization record.
- Reauthorization can be time-driven (per policy, e.g., every three years) or event-driven (triggered by a significant change or a major security incident).
- Ongoing monitoring results should feed back into organizational risk management so lessons learned improve future Categorize and Select decisions for other systems.
(ISC)² CGRC (Governance, Risk and Compliance) exam tips
- Answer from the AO's or risk manager's perspective: when two answers seem correct, choose the one that best manages organizational risk and follows the documented RMF process, not the most technically thorough action.
- Memorize the RMF step order (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor) and what artifact each step produces (SSP, SAP, SAR, POA&M, authorization decision); many questions test sequencing.
- Know who owns each decision: the AO accepts risk and authorizes, the SCA independently assesses, the ISSO manages day-to-day security, and the system owner is accountable for the system - do not swap these roles.
- Distinguish similar artifacts precisely: SSP describes implementation, SAP plans the assessment, SAR reports assessment results, and POA&M tracks remediation - questions often hinge on picking the right document.
- Treat continuous monitoring and ongoing authorization as a process, not a one-time event: expect scenario questions about what happens after authorization when a system changes.
Study guide FAQ
What is the CGRC exam format?
The CGRC exam has 125 multiple-choice questions with a 180-minute time limit. You need a scaled score of 700 out of 1000 to pass. It is a linear, non-adaptive exam covering the seven domains aligned to the NIST RMF lifecycle.
Does CGRC require hands-on technical or coding skills?
No. CGRC is a management and process-focused certification. It tests your ability to manage the RMF lifecycle, roles, documentation, and risk-based decision making rather than configuring specific technologies or writing code.
What experience is required to sit for CGRC?
Candidates need at least two years of cumulative paid work experience in one or more of the seven CGRC domains. If you pass the exam without the required experience, you become an Associate of ISC2 and have up to three years to gain the experience needed for full certification.
How does CGRC relate to the NIST Risk Management Framework?
CGRC's seven domains are built directly on the NIST RMF's seven steps (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor) as defined in NIST SP 800-37 Rev 2. The exam validates that you can execute each RMF step correctly, using supporting standards like FIPS 199, SP 800-60, SP 800-53/800-53B, and SP 800-53A.
Why did the exam name change from CAP to CGRC?
ISC2 renamed the Certified Authorization Professional (CAP) to Certified in Governance, Risk and Compliance (CGRC) to better reflect the certification's scope, which extends beyond system authorization to the full governance, risk management, and compliance lifecycle. The underlying RMF-based domains and exam remain the same credential continuing under a new name.