CGRC cheat sheet
CGRC · Keep the key ideas within reach.
Security and Privacy Governance
Governance establishes direction through policies, assigned roles, oversight bodies, and documented risk decisions.
The three lines model separates operational risk ownership, risk/compliance oversight, and independent internal audit assurance.
The policy hierarchy flows from laws and regulations to policies, then standards, procedures, and guidelines.
Accountability for security and privacy outcomes remains with organizational leadership when controls are delegated.
Privacy governance commonly addresses notice, choice, data minimization, purpose limitation, retention, security, and accountability.
FISMA assigns agency-level responsibility to agency heads and designates roles such as CIO, CISO, and authorizing official.
Governance reporting uses measurable metrics, thresholds, and trends rather than anecdotal status statements.
Segregation of duties prevents one person from holding conflicting responsibilities such as requesting and approving access.
Risk Management, and Compliance Program
Risk is commonly expressed as likelihood multiplied by impact, with inherent risk measured before controls and residual risk after controls.
Risk response options are mitigate, transfer, avoid, and accept; each requires an accountable owner and documented rationale.
Risk appetite is the amount and type of risk an organization will pursue; risk tolerance is acceptable variation around that appetite.
A risk register records asset, threat, vulnerability, likelihood, impact, owner, response, status, and review date.
A compliance program typically includes scoping, control mapping, evidence collection, testing, remediation, and reporting.
Control mapping links one control to multiple framework requirements and must include rationale for partial or non-equivalent mappings.
Continuous monitoring uses metrics, thresholds, and automated data feeds to detect control drift and emerging risk.
A POA&M tracks weaknesses, remediation milestones, resources, responsible owners, and scheduled completion dates.
Scope of the System
The system boundary defines the people, processes, data, technology, and facilities included in assessment and authorization.
The authorization boundary includes components that process, store, transmit, or protect information within the assessed system.
FIPS 199 categorizes confidentiality, integrity, and availability as low, moderate, or high, with the overall value set by the high-water mark.
Information types and their impact values determine the system's security category and influence baseline selection.
Interconnections, external services, and shared controls must be documented with responsibilities and evidence of operation.
Data flow diagrams show ingress, egress, processing locations, and trust boundaries between components with different security assumptions.
Exclusions from scope require justification, documented risk, and approval by the appropriate authority.
Cloud scope splits responsibilities between provider and customer, and inherited controls must be validated rather than assumed.
Selection and Approval of Framework, Security, and Privacy Controls
The NIST Risk Management Framework steps are prepare, categorize, select, implement, assess, authorize, and monitor.
NIST control baselines are low, moderate, and high; overlays and tailoring adjust them for mission, technology, or community needs.
FIPS 199 categorization drives baseline selection and the rigor of assessment and authorization activities.
Tailoring includes scoping controls out, parameterizing values, adding supplemental controls, and applying compensating controls.
Privacy controls may come from the NIST Privacy Framework or the PT family in NIST SP 800-53.
Framework selection considers legal and regulatory obligations, mission needs, industry practice, and existing control investments.
Common controls are inherited from providers or parent systems; system-specific controls remain the responsibility of the system owner.
The authorizing official approves the selected control set and accepts the residual risk associated with authorization.
Implementation of Security and Privacy Controls
Implementation status and evidence belong in the system security plan, including responsible roles and inherited controls.
Configuration baselines, benchmarks, and STIGs provide documented hardening settings that are verified after deployment.
Least privilege and separation of duties limit access and reduce the impact of accidental or malicious actions.
Change control assesses security and privacy impact before deployment and determines whether reassessment is required.
Privacy implementation includes consent management, data minimization, retention enforcement, and incident notification procedures.
Inherited controls require documented provider evidence and explicit customer responsibilities that remain in scope.
Deviations from planned implementation must be documented with risk rationale and approval.
Training and awareness support control operation but do not substitute for technical or administrative controls.
Assessment/Audit of Security and Privacy Controls
NIST assessment methods are examine, interview, and test, applied to determine whether controls meet stated objectives.
Design effectiveness asks whether a control is capable of meeting its objective; operating effectiveness asks whether it worked over the period.
Evidence must be sufficient, appropriate, relevant, reliable, and collected within the period being assessed.
Sampling risk increases when populations are large or variable; sample size and selection method should be documented.
Findings map to assessment criteria and are classified by severity, likelihood, and impact to support prioritization.
Assessor independence is preserved when assessors do not evaluate controls they designed or implemented.
Penetration testing supplements control assessment but does not replace examination of policy, process, and evidence.
Assessment reports include scope, methods, results, findings, evidence references, and conclusions.
System Compliance
Authorization decisions include authorization to operate, interim authorization to operate, and denial of authorization.
An authorization to operate requires an acceptable level of residual risk and completion of required assessment activities.
An interim authorization to operate is time-limited and depends on an approved remediation plan with milestones.
Significant changes, such as new interconnections or major releases, can trigger reassessment and reauthorization.
Continuous monitoring maintains the authorization decision by tracking control effectiveness, vulnerabilities, and threats.
The authorizing official documents risk acceptance; the system owner remains accountable for day-to-day operation.
Compliance status and unresolved weaknesses are reported to the authorizing official and governance bodies.
Decommissioning requires data sanitization, record retention, and formal closeout of the authorization.
Compliance Maintenance
Continuous monitoring covers configuration status, vulnerability management, patching, logging, and control effectiveness.
Metrics and trends reveal control drift; defined thresholds trigger escalation and corrective action.
Reassessment is triggered by significant change, incidents, new threats, or updated laws and regulations.
Evidence lifecycle management includes collection, validation, retention according to schedule, and secure disposal.
Corrective actions are tracked to closure with root cause analysis and verification evidence.
Third-party monitoring uses attestations, certifications, questionnaires, and right-to-audit clauses.
A compliance calendar schedules recurring assessments, policy reviews, training, reporting deadlines, and vendor reviews.
Lessons learned feed updates to policies, controls, risk registers, and monitoring thresholds.