1.5 Establishing and Operating the Compliance Program

Establishing and Operating the Compliance Program

CGRC task 1.2 asks for one thing: the establishment of a compliance program for the applicable framework. This is deliberately organizational rather than technical. The exam wants to know whether you can stand up the machinery that makes system-level compliance repeatable — before any individual system enters the RMF.

---

1. Step One: Select the Framework and Define Applicability

Everything downstream inherits from this decision, so it is made first and approved at the executive level.

Applicability scoping is the second half of the decision and the half candidates skip. A framework does not automatically apply to every system the organization owns. PCI DSS applies to the cardholder data environment and systems connected to it — not the whole enterprise. CMMC applies where CUI is processed. Defining and documenting this scope boundary at program level prevents both under-coverage (a regulated system left outside the program) and waste (applying High-baseline rigor to systems that never touch regulated data).

[!IMPORTANT] Legal obligation versus contractual obligation. FISMA and HIPAA are statutes; PCI DSS and CMMC bind through contract. Both are enforceable, but the consequence differs: statutory violation brings regulatory action, while contractual violation brings breach-of-contract remedies and loss of the ability to do that business. The exam expects you to know that "not a law" does not mean "optional."

---

2. The Policy Hierarchy

A compliance program is only as enforceable as its documentation hierarchy. Four levels, each with a distinct author, audience, and mutability:

Three exam-relevant rules follow. Only guidelines are optional — the other three are mandatory once approved. Policy must exist before controls, because a control with no policy behind it has no authority and no enforcement path. And SP 800-53 requires the -1 control in every family (AC-1, AU-1, CM-1 …) to be the policy-and-procedures control, which is why an organization with excellent technical controls and no written policy fails assessment on twenty separate findings simultaneously.

---

3. Program Foundations

Beyond framework and policy, a defensible program needs five structural elements in place before the first system is categorized:

1. Named accountable roles. Authorizing Official, Risk Executive (Function), Senior Agency Official for Privacy, System Owners, Common Control Providers, ISSOs, and Security Control Assessors — identified by position, with documented separation between those who implement and those who assess.
2. A complete system inventory. You cannot claim compliance for systems you have not enumerated. Shadow IT discovered during an audit is simultaneously an inventory finding and an authorization finding.
3. An enterprise common control catalog. Cataloguing which controls the organization provides centrally — physical security, enterprise identity, network boundary protection, security awareness training — is the single highest-leverage program activity, because every system afterwards inherits rather than rebuilds. This is what turns compliance from per-system heroics into an economy of scale.
4. A defined evidence and reporting cadence. What evidence is collected, by whom, how often, where it is retained, and to whom results are reported. Evidence gathered only when an auditor asks is evidence that will be incomplete.
5. A risk register and escalation path. A standing mechanism for recording risks that exceed a system owner's authority and routing them to the Risk Executive or Authorizing Official.

Program Management Controls Live at Tier 1

NIST SP 800-53 Rev. 5 contains the PM (Program Management) family specifically to implement these organization-wide capabilities — PM-1 (information security program plan), PM-4 (POA&M process), PM-5 (system inventory), PM-9 (risk management strategy), PM-30 (supply chain risk management strategy), and others.

Critically, SP 800-53B does not allocate PM controls to the Low, Moderate, or High system baselines. They are implemented once at the organizational level (Tier 1) and apply enterprise-wide, independent of any individual system's categorization. Candidates who expect to find PM-9 in a Moderate baseline and conclude the baseline is defective have misread the architecture — this distinction is directly examinable.

---

4. Harmonizing Multiple Frameworks

Most real organizations are subject to several regimes simultaneously. Running a separate program per framework produces duplicated effort, contradictory requirements, and audit fatigue. The correct approach is one control set, many mappings:

• Adopt the most comprehensive applicable framework as the primary control set (typically SP 800-53 or ISO/IEC 27002).
• Build a crosswalk mapping each control to the corresponding requirement in every secondary framework. The NIST Cybersecurity Framework is widely used as the neutral pivot for these mappings because its outcome-based subcategories translate cleanly across regimes.
• Collect evidence once and reuse it against every mapped requirement. A single access-review artifact can satisfy SP 800-53 AC-2, ISO/IEC 27001 A.5.18, and PCI DSS requirement 7 simultaneously.
• Where two frameworks conflict, implement the stricter requirement and document the rationale. Meeting the stricter obligation satisfies the weaker one by definition.

[!NOTE] Maturity is repeatability, not paperwork. A program that produces flawless documentation only because one expert manually assembles it before each audit is ad hoc, not mature. Maturity models — CMMC levels, the CIGIE/FISMA IG maturity scale, and CMMI-derived scales — all measure whether a process is defined, consistently executed, measured, and improved. The exam consistently favours answers describing institutionalized, evidence-producing processes over answers describing larger document sets.