Certified in Governance, Risk and Compliance (CGRC)

2.1 – Describe the system

• System name and scope documented
• System purpose and functionality

2.2 – Determine security compliance required

• Information types processed, stored, or transmitted
• Security objectives outlined for each information type based on national and international security and privacy compliance requirements (e.g., Federal Information Processing Standards (FIPS), International Organization for Standardization/International Electrotechnical Commission (ISO/IEC), data protection impact assessment)
• Risk impact level determined for system based on the selected framework

3.1 – Identify and document baseline and inherited controls

3.2 – Select and tailor controls

• Determination of applicable baseline and/or inherited controls
• Determination of appropriate control enhancements (e.g., security practices, overlays, mitigating controls)
• Specific data handling/marking requirements identified
• Control selection documentation
• Continued compliance strategy (e.g., continuous monitoring, vulnerability management)
• Control allocation and stakeholder agreement

4.1 – Develop implementation strategy (e.g., resourcing, funding, timeline, effectiveness)

• Control implementation aligned with organizational expectations, national or international requirements, and compliance for security and privacy controls
• Identification of control types (e.g., management, technical, common, operational control)
• Frequency established for compliance documentation reviews and training

4.2 – Implement selected controls

• Control implementation consistent with compliance requirements
• Compensating or alternate security controls implemented

4.3 – Document control implementation

• Residual security risk or planned implementations documented (e.g., Plan of Action and Milestones (POA&M), risk register)
• Implemented controls documented consistent with the organization’s purpose, scope, and risk profile (e.g., policies, procedures, plans)

5.1 – Prepare for assessment/audit

• Stakeholder roles and responsibilities established
• Objectives, scope, resources, schedule, deliverables, and logistics outlined
• Assets, methods, and level of effort scoped
• Evidence for demonstration of compliance audited (e.g., previous assessments/audits, system documentation, policies)
• Assessment/audit plan finalized

5.2 – Conduct assessment/audit

• Compliance capabilities verified using appropriate assessment methods: interview, examine, test (e.g., penetration, control, vulnerability scanning)
• Evidence verified and validated

5.3 – Prepare the initial assessment/audit report

• Risks identified during the assessment/audit provided
• Risk mitigation summaries outlined
• Preliminary findings recorded

5.4 – Review initial assessment/audit report and plan risk response actions

• Risk response assigned (e.g., avoid, accept, share, mitigate, transfer) based on identified vulnerabilities or deficiencies
• Risk response collaborated with stakeholders
• Non-compliant findings with newly applied corrective actions reassessed and validated

5.5 – Develop final assessment/audit report

• Final compliance documented (e.g., compliant, non-compliant, not applicable)
• Recommendations documented when appropriate
• Assessment report finalized

5.6 – Develop risk response plan

• Residual risks and deficiencies identified
• Risk prioritized
• Required resources identified (e.g., financial, personnel, and technical) to determine time required to mitigate risk

6.1 – Review and submit security/privacy documents

• Security and privacy documentation required to support a compliance decision by the appropriate party (e.g., authorizing official, third-party assessment organizations, agency) compiled, reviewed, and submitted

6.2 – Determine system risk posture

• System risk acceptance criteria
• Residual risk determination
• Stakeholder concurrence for risk treatment options
• Residual risks defined in formal documentation

6.3 – Document system compliance

• Formal notification of compliance decision
• Formal notification shared with stakeholders

7.1 – Perform system change management

• Changes weigh the impact to organizational risk, operations, and/or compliance requirements (e.g., revisions to baselines)
• Proposed changes documented and approved by authorized personnel (e.g., Change Control Board (CCB), technical review board)
• Deploy to the environment (e.g., test, development, production) with rollback plan
• Changes to the system tracked and compliance enforced

7.2 – Perform ongoing compliance activities based on requirements

• Frequency established for ongoing compliance activities review with stakeholders
• System and assets monitored (e.g., physical and logical assets, personnel, change control)
• Incident response and contingency activities performed
• Security updates performed and risks remediated/tracked
• Evidence collected, testing performed, documentation updated (e.g., service level agreements, third party contracts, policies, procedures), and submission/communication to stakeholders when applicable
• Awareness and training performed, documented, and retained (e.g., contingency, incident response, annual security and privacy)
• Revising monitoring strategies based on updates to legal, regulatory, supplier, security and privacy requirements

7.3 – Engage in audits activities based on compliance requirements

• Required testing and vulnerability scanning performed
• Personnel interviews conducted
• Documentation reviewed and updated

7.4 – Decommission system when applicable

• Requirements for system decommissioning reviewed with stakeholders
• System removed from operations and decommissioned
• Documentation of the decommissioned system retained and shared with stakeholders