CGRC common mistakes
CGRC · Understand the traps and how to avoid them.
Assigning RMF responsibilities to the wrong role - e.g., saying the Authorizing Official (AO) 'performs the security assessment,' the System Owner 'grants the ATO,' or the SCA 'accepts residual risk.'
In real organizations these duties blur, and candidates memorize the RMF step names (Categorize, Select, Implement, Assess, Authorize, Monitor) without attaching the accountable role to each output.
What to do instead
Build a role-to-artifact table from NIST SP 800-37: System Owner produces the SSP and owns the system; SCA/assessment team produces the Security Assessment Report; AO reviews the SAR/POA&M and signs the authorization decision; ISSO supports day-to-day monitoring. Drill 'who signs what' until each artifact has exactly one accountable role.
Treating privacy as a separate afterthought - omitting the Privacy Impact Assessment (PIA) or SORN analysis from the control selection/implementation work and answering privacy questions only in terms of the Privacy Act generally.
Candidates study privacy law as background reading rather than as triggers inside the RMF, so they miss that privacy controls sit in the same 800-53 catalog (PT family) and are assessed with the same methods.
What to do instead
Memorize the PIA and SORN trigger conditions (PII collection, new matching of records, new routine use, system of records changes) and practice placing PT controls in the SSP alongside AC/AU controls, with the Senior Agency Official for Privacy as the accountable privacy role.
Drawing the authorization boundary around only the hardware the IT team owns, excluding interconnected systems, external service providers, supporting infrastructure (HVAC, physical access, power), and the people/processes that operate the system.
Candidates equate 'boundary' with 'asset inventory' or with the network diagram, so anything not on the equipment list gets dropped - which then makes inherited controls inexplicable.
What to do instead
Define the boundary as the people, processes, and technology that support the system plus every interface, and document it with a data-flow/interface description in the SSP. Explicitly list which controls are inherited from outside the boundary (e.g., facility, enterprise identity, cloud provider) and who provides the evidence.
Opening the NIST SP 800-53 control catalog and marking controls in or out before the system has been categorized under FIPS 199, or assigning impact by averaging rather than by high-water mark.
The control catalog is the most familiar document, so candidates start there; the FIPS 199 three-step process (information types → provisional impact → system high-water mark) is easy to skim and hard to apply.
What to do instead
Enforce the order: identify information types and provisional C/I/A impacts, take the high-water mark as the system categorization, select the matching 800-53B baseline, then tailor. When a question asks 'what comes next,' answer from the sequence, not from the control you recognize.
Treating tailoring as deletion - marking a baseline control 'not applicable' or 'N/A' with no documented rationale, compensating control description, or approval.
Tailoring feels like an editing task, and candidates confuse scoping (removing controls that genuinely do not apply) with supplementation (adding controls) and with risk-based decisions that require justification.
What to do instead
For every deviation, write three things: the rationale, the compensating or alternative control if any, and who approved it. Practice distinguishing scoping decisions (not applicable to the environment), compensating controls (different mechanism, same intent), and supplementation (adding controls such as a FedRAMP or agency overlay).
Writing implementation statements that restate the control text ('the organization implements least privilege') instead of describing who does what, how, how often, with what tooling, and whether the control is system-specific, common, or hybrid.
Candidates treat the SSP as a compliance narrative rather than an operational description, and they under-use the responsibility designation that determines who has to produce evidence.
What to do instead
Use a fixed sentence pattern for every statement: responsibility (system/common/hybrid) + mechanism + frequency + role + evidence source. If a statement would be true of any organization on earth, it is not an implementation statement.
Claiming inherited controls without obtaining the common control provider's documentation or confirming that the inherited control's parameters match this system's requirements.
Inheritance is taught as a checkbox in the SSP, so candidates assume the provider's authorization covers them automatically.
What to do instead
For each inherited control, record the provider, the specific control/parameter provided, and the evidence source (provider SSP, assessment results, FedRAMP package). Flag gaps where the provider's implementation does not meet the system's required parameter as a hybrid or system-specific obligation.
Reporting a control as 'satisfied' because documentation exists, without applying the examine/interview/test methods or explaining sampling and coverage.
Candidates collapse assessment into document review; 800-53A's method/object/attribute structure and coverage concepts (e.g., sampled vs. all instances) are the least-practiced part of the exam.
What to do instead
For each control, state which methods apply (examine, interview, test) and what object is examined. Distinguish 'documented' from 'implemented' from 'effective,' and be ready to justify a sample size or a full-population test.
Leaving findings floating - no POA&M entry, no milestone dates, no assigned resources, or accepting risk verbally rather than through a documented authorization decision.
Candidates memorize that POA&Ms exist but not what makes one valid, and they blur the AO's risk acceptance with the assessor's job of reporting.
What to do instead
Every finding maps to a POA&M line with weakness description, milestone with scheduled completion date, responsible party, resources, and status. The AO - not the assessor or the system owner - accepts residual risk and issues the authorization decision, which then feeds monitoring.
Treating an ATO as permanent and self-renewing, or failing to distinguish ATO, ATO with conditions, IATT, and denial, and who is empowered to grant each.
The authorization step is studied as a single event rather than as a decision with types, conditions, and an expiration tied to continuous monitoring.
What to do instead
Memorize the four decision types and their constraints (conditions require POA&M tracking with dates; IATT is time-boxed and for limited scope; denial requires remediation and reauthorization). Tie every authorization to ongoing authorization under the ConMon strategy, including what happens when conditions are not met.
Missing significant-change triggers - e.g., a new cloud service, a change in data sensitivity, a new interconnection, or a moved enclave - and continuing under the existing authorization without impact analysis or reauthorization.
Configuration management is treated as an operations topic, so candidates do not connect change types to authorization impact, and they assume any change is fine if it is in the CM process.
What to do instead
Practice classifying changes: routine changes handled through CM, and changes requiring security impact analysis, updated assessment, and a new or amended authorization decision. Know that changes to categorization (FIPS 199) or boundary are always significant.