Module 29 · Capstone · ⏱ 120 min · 🏆 +600 XP

Capstone: Build a Full GRC Program

You are the new GRC Director at MeridianHealth Cloud — a multi-cloud telehealth platform serving 4 million patients across 11 states with 34 third-party vendors. Every concept from Modules 1–28 converges here. Deliver a complete program. Defend it to the board. This is the job.

Program Integration Governance Charter Risk Register Policy Pack Audit Plan Board Defense

Learning Objectives

  • Synthesize governance, risk, compliance, privacy, audit, and continuity into one integrated GRC program.
  • Produce and justify all seven core GRC program artifacts for a complex organization.
  • Apply the GRC program design framework to balance regulatory obligations, business enablement, and risk management.
  • Explain how each program component connects and reinforces the others in a systems-thinking approach.
  • Defend the program to a skeptical board using quantified ROI and risk language.
  • Demonstrate mastery of all 28 prior modules in a real-world integrated scenario.

Company Brief — MeridianHealth Cloud

🏥
Your Assignment

You are stepping in as GRC Director. The previous GRC function was audit-only and compliance-reactive. Your mandate: build a modern, integrated, risk-based GRC program from the ground up within 12 months.

Organization Profile

DimensionDetail
Business ModelTelehealth SaaS platform — video consultations, e-prescriptions, remote patient monitoring devices, AI-powered clinical documentation
Scale4 million patients, 11 states, 1,200 employees, $340M ARR
Data HandledPHI (Protected Health Information), PII, payment card data (PCI scope), clinical imaging, continuous biometric device telemetry
InfrastructureAWS (primary), Azure (DR/secondary), 12 SaaS applications, on-premises clinical device management
Third Parties34 vendors — EHR vendors (3), payment processors (2), SMS/notification (2), AI transcription (1), cloud hosting (2), clinical device manufacturers (8), revenue cycle management (2), other (14)
Compliance ObligationsHIPAA Security Rule, HIPAA Privacy Rule, HITECH, PCI-DSS v4.0, CCPA (California), state-level health privacy laws (11 states), SOC 2 Type II (customer commitments), contractual breach-notification SLAs (<48 hours)
Recent IncidentsRansomware near-miss (6 months ago — contained, no patient data affected), vendor data exposure (12 months ago — EHR vendor misconfigured API exposing 8,200 records)
Board Mandate"Modernize GRC. Justify every dollar. No compliance theater. Show us real risk management."

Theory — Integrated GRC Program Design

🏗️ The Integrated GRC Program Architecture

A full GRC program is not a collection of independent functions — it is an ecosystem where every component feeds the others. Understanding the integration points is what separates a program director from a function manager:

1
Governance Charter → Risk Appetite → Policy Pack

The charter establishes authority and committee structure. The committees define risk appetite. Risk appetite drives policy requirements — if the appetite is "low risk on PHI exposure," the data classification policy must define Restricted handling for all PHI and mandate encryption and access controls. Policy requirements flow directly from governance decisions. Without governance, policies are arbitrary.

2
Risk Register → Audit Plan → Compliance Map

The risk register identifies top risks. The audit plan prioritizes testing of controls over those top risks. The compliance map shows which frameworks require those controls — enabling a single control to satisfy HIPAA, SOC 2, and PCI-DSS simultaneously. Risks drive audit focus; audit findings update the risk register; the loop is continuous.

3
Vendor Risk Framework → Risk Register → Compliance Map

Vendor risk assessments feed risk register entries (each Tier 1 vendor with gaps generates a risk item). Vendor contractual requirements reflect compliance framework obligations (HIPAA BAAs, PCI-DSS contractual clauses). The vendor framework is not separate from the compliance program — it IS a required control under every major framework.

4
Dashboard → Governance → Risk Register

The dashboard feeds governance committees with current risk posture. Governance decisions (accept, mitigate, escalate) generate actions that update the risk register and treatment plans. The dashboard does not just report — it is the input to governance decision-making. Without the loop, reporting is theater.

📐 The Seven Core GRC Artifacts — What Each Must Contain

1. Governance Charter

Must include: Program purpose and authority. Committee structure (Board Risk Committee, Executive Steering, Security Operations Review). Reporting lines (CISO → CEO → Board). Risk appetite statement. Decision authority matrix. Annual review requirement. Common mistake: Governance charters that describe what governance does but do not assign authority or decision rights are unenforceable.

2. Risk Register

Must include: Unique risk ID and risk statement. Category, likelihood, impact, inherent and residual scores. Risk owner (named individual). Current controls. Treatment decision with justification. Target completion date. Review date. Common mistake: Risk registers with no named owners or past-due treatment dates — the register becomes a graveyard of acknowledged-but-ignored risks.

3. Policy Pack

Must include: Information Security Policy (high-level intent). Acceptable Use Policy. Data Classification Policy. Access Control Policy. Incident Response Policy. Vendor Risk Policy. Business Continuity Policy. Each with version, owner, approval, and review date. Common mistake: Policies written in abstract language that cannot be audited against.

4. Audit Plan

Must include: 12-month schedule of internal audits based on risk register priority. External audit schedule (HIPAA, PCI-DSS, SOC 2). Scope definition for each audit. Evidence collection approach. Reporting format and governance distribution. Follow-up tracking process. Common mistake: Audit plans based on rotation rather than risk — high-risk areas audited every 3 years while low-risk areas get annual attention.

5. Vendor Risk Framework

Must include: Vendor tiering criteria (1–4). Due diligence requirements per tier. Questionnaire templates. Onboarding approval gate. Ongoing monitoring approach. SOC report review schedule. Offboarding procedure. Contractual security clause requirements. Fourth-party (sub-processor) management approach. Common mistake: Frameworks that only cover onboarding and never revisit active vendors.

6. Compliance Map (Control Crosswalk)

Must include: Control inventory with unique IDs. Mapping of each control to every applicable framework requirement (HIPAA, PCI-DSS, SOC 2, CCPA, ISO 27001). Implementation status per control. Evidence type for each control. Control owner. Test frequency. Common mistake: Separate compliance silos — separate HIPAA controls and separate PCI controls, despite significant overlap.

7. GRC Dashboard

Must include (board tier): Top 3 risks with ALE and trend. Residual risk vs appetite ratio. Regulatory compliance status by framework. Incident trend (3-month rolling). Vendor risk concentration. Must include (operational tier): Open critical vulnerabilities by age. Access review completion rate. Patch SLA compliance. Open audit findings. Common mistake: Technical metrics at board level; strategic metrics buried in operational reports.

⚖️ Regulatory Obligations Integration for MeridianHealth

MeridianHealth operates under five overlapping regulatory regimes. A unified control crosswalk prevents duplicate effort:

ControlHIPAAPCI-DSSSOC 2CCPA
Encryption at rest (AES-256)§164.312(a)(2)(iv)Req 3.5CC6.1Implicit
Multi-Factor Authentication§164.312(d)Req 8.4CC6.1, CC6.3
Quarterly Access Reviews§164.308(a)(4)Req 7.2CC6.2, CC6.3
Vendor BAA / Security Contract§164.308(b)Req 12.8CC9.2Data Processing Agreement
Incident Response Plan & Testing§164.308(a)(6)Req 12.10CC7.5Breach Notification
Annual Risk Assessment§164.308(a)(1)Req 12.3CC3.1, CC3.2Implicit
Security Awareness Training§164.308(a)(5)Req 12.6CC1.4
Audit Logging / SIEM§164.312(b)Req 10CC7.2

Every cell in this table where a control satisfies multiple frameworks is a saved audit, saved evidence collection, and saved documentation effort. For MeridianHealth, a unified crosswalk covering 40 controls can satisfy approximately 200 individual framework requirements — without writing 200 separate controls.

📊 MeridianHealth Top-5 Risk Register — Model Entries

Use these professionally structured risk entries as your model for the deliverable section:

RiskInherentKey ControlsResidualTreatmentOwner
Ransomware encrypting PHI systems (given near-miss 6 months ago)5×5=25EDR, offline immutable backups, IR plan3×3=9Mitigate: deploy MFA on all remote access, test DR quarterlyCISO
Vendor API misconfiguration exposes PHI (given prior incident)4×5=20TPRM program, contractual controls, API security testing2×4=8Mitigate: Tier 1 vendor reassessment + penetration test of EHR APIVP Engineering
HIPAA breach notification failure (34 vendors, contractual 48h SLA)3×5=15IR plan, vendor notification clauses, legal retainer2×4=8Mitigate: Update all vendor contracts; test notification process quarterlyGeneral Counsel
Insider PHI exfiltration by clinical staff3×4=12RBAC, DLP, access reviews, background checks2×3=6Mitigate: Deploy clinical DLP; implement behavior analyticsCISO
Cloud misconfiguration exposing patient records (multi-cloud)4×5=20CSPM, IaC scanning, SCPs2×4=8Mitigate: Deploy Wiz CSPM across AWS + Azure; implement guardrailsVP Cloud Ops

🎯 The 12-Month GRC Program Build Roadmap

A realistic build sequence for a program like MeridianHealth's — balancing quick wins with sustainable foundations:

Month 1–2
Assess and Charter

Read all existing policies, audit reports, incident records, vendor contracts. Interview CISO, General Counsel, CFO, VP Engineering. Produce a current-state gap assessment. Draft and get approved: Governance Charter, Risk Appetite Statement, and GRC team structure. Quick win: present the gap assessment to the board — immediate visibility without requiring remediation.

Month 3–4
Risk Register and Policy Pack

Build the risk register with top 15 risks (starting with lessons from the two prior incidents). Draft the core policy pack (7 policies). Establish the Executive Security Steering Committee with monthly cadence. Begin the vendor inventory and tier classification for all 34 vendors.

Month 5–6
Compliance Map and Vendor Risk

Build the control crosswalk (HIPAA × PCI × SOC 2 × CCPA). Complete Tier 1 and Tier 2 vendor assessments (approximately 12 of 34 vendors). Launch SOC 2 readiness gap assessment — customer commitments are at risk. Deploy CSPM to address the cloud misconfiguration risk.

Month 7–9
Audit Plan and Monitoring

Launch the internal audit program with risk-based scheduling. Begin automated control testing (configuration checks, access review automation). Deploy the GRC platform with integrated risk register, compliance tracking, and vendor risk module. Start generating the board dashboard with real data.

Month 10–12
SOC 2 Audit and Program Maturity

Begin SOC 2 Type II audit period (minimum 6 months — started Month 7). Complete first-year board GRC report with maturity score, risk posture trend, and next-year investment request. Present program to customers as differentiator. Target: GRC Maturity Level 3 by Year 1 end, Level 4 by Year 2.

Your Capstone Deliverables

Instructions: For each of the 7 deliverables, write substantive content. Use the theory section above as your guide. Write as a GRC Director presenting to the board — specific, justified, measurable. Each response should be at least 3–5 substantive sentences.

Board Scenario — Defending the Program

The board meeting is in 10 minutes. You have built the program. Now defend it.

Final Integration Quiz

This quiz tests your ability to integrate concepts across all 28 prior modules. Questions are at Director-level judgment — not just recall.

🎓 Capstone Complete

Outstanding achievement. You have designed and defended a complete enterprise GRC program. One module remains: Module 30 — GRC Leadership and Strategic Communication.
← Module 28 Final Module: GRC Leadership →