Why this post
Most of my posts are about a finding or an incident. This one is the post I wish someone had handed me when GRC work first landed on my desk: what these frameworks are, where they came from, how they are leveled, and where the real documents live.
The single most useful habit in GRC is reading the primary source. Vendor blogs (and, yes, this one) are summaries. Auditors, assessors and regulators work from the regulation text and the standard itself, so that is where your answers should come from too.
The vocabulary first
The same words get used loosely, so pin these down before anything else.
| Term | What it means |
|---|---|
| GRC | Governance (who decides and how), Risk (what could go wrong and how much it matters), Compliance (proving you meet an external requirement). |
| Law / regulation | Binding government rules. A law (statute) is passed by Congress; a regulation is the agency rule that implements it and lives in the Code of Federal Regulations (CFR). HIPAA is both. |
| Standard | A published set of requirements. Binding only if a law or contract makes it binding. PCI DSS is a standard made binding by contract. |
| Framework | A structured way to organize controls (NIST CSF, CIS Controls). Often voluntary. |
| Control | A specific safeguard: MFA on remote access, encrypted backups, a written incident response plan. |
| Scope | The systems, people and locations the requirements apply to. Most compliance pain is scoping pain. |
| Assessment / audit | Someone checks your controls against the requirements. Self-assessment means you do it; third-party means an accredited outsider does. |
| Evidence | What proves a control exists: configs, screenshots, logs, signed policies, tickets. |
| POA&M | Plan of Action and Milestones: a documented list of gaps with owners and dates. |
| Compensating control | An alternative control that meets the intent of a requirement you can’t meet as written. |
Keep two questions in mind for every framework: who makes you do this, and who checks. The answers explain most of the differences below.
HIPAA (1996): the law with no levels
Where it came from
The Health Insurance Portability and Accountability Act was signed in August 1996. Its main goal was health insurance portability; the privacy and security pieces came from its “Administrative Simplification” provisions, which pushed the industry toward electronic transactions and directed HHS to write rules protecting the data those transactions carried.
| Year | Milestone |
|---|---|
| 1996 | HIPAA enacted (Public Law 104-191). |
| 2000 / 2003 | Privacy Rule published; most covered entities had to comply by April 2003. |
| 2003 / 2005 | Security Rule published; compliance required by April 2005. |
| 2009 | HITECH Act: extends direct liability to business associates, creates the Breach Notification Rule, raises penalties. |
| 2013 | Omnibus Rule: implements HITECH, updates all of the above. |
| 2025 | Security Rule proposed overhaul (NPRM) published January 6, 2025. Still a proposal; see Caveats. |
Base definitions
- Covered entity: health plans, health care clearinghouses, and health care providers that conduct certain transactions electronically.
- Business associate (BA): anyone who creates, receives, maintains or transmits PHI on behalf of a covered entity. MSPs, cloud hosts and billing companies are usually BAs, and they sign a Business Associate Agreement (BAA).
- PHI / ePHI: individually identifiable health information; ePHI is the electronic subset. The Security Rule only covers ePHI. The Privacy Rule covers PHI in any form.
- OCR: the HHS Office for Civil Rights, which enforces HIPAA. State attorneys general can also bring actions under HITECH.
How it is structured
HIPAA does not have levels or certifications. Instead it has rules, and the Security Rule is built from safeguards, standards and implementation specifications.
| Rule | Where it lives | What it covers |
|---|---|---|
| Privacy Rule | 45 CFR Part 164, Subpart E | Who can use and disclose PHI, patient rights (access, amendment), minimum necessary. |
| Security Rule | 45 CFR Part 164, Subpart C | Protecting ePHI: confidentiality, integrity, availability. |
| Breach Notification Rule | 45 CFR Part 164, Subpart D | Who to notify, and when, after a breach of unsecured PHI. |
| Enforcement Rule | 45 CFR Part 160, Subparts C–E | Investigations, penalties, hearings. |
The Security Rule’s safeguards:
| Safeguard | Section | Examples |
|---|---|---|
| Administrative | § 164.308 | Risk analysis, risk management, workforce training, incident procedures, contingency plan. |
| Physical | § 164.310 | Facility access, workstation security, device and media controls. |
| Technical | § 164.312 | Access control, audit controls, integrity, authentication, transmission security. |
Each standard has implementation specifications marked required or addressable. Addressable does not mean optional. It means you assess whether the specification is reasonable and appropriate for you, then implement it, implement an equivalent, or document why neither fits. Encryption at rest is the classic addressable item that people skip without the paperwork.
The Security Rule is deliberately scalable: a two-provider clinic and a hospital system apply the same rule, sized by their risk analysis. That makes the risk analysis (§ 164.308(a)(1)(ii)(A)) the foundation of everything else, and it is the deficiency OCR cites most often.
On breaches: affected individuals are notified without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more residents of a state or jurisdiction also require media notice, and 500 or more overall must be reported to HHS within the same 60 days; smaller breaches go to HHS in an annual log.
There is no such thing as being “HIPAA certified.” Vendors who say so mean they had a third party assess them against the rule. Useful, but not a government certification.
Primary documents
- HIPAA, Public Law 104-191 (Congress.gov)
- 45 CFR Part 164 (eCFR) and Part 160
- HHS: Summary of the HIPAA Security Rule
- HHS: Summary of the HIPAA Privacy Rule
- HHS: Breach Notification Rule
- NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule (the best plain-language companion to the rule)
PCI DSS (2004): the contract you signed with your bank
Where it came from
Before 2004, each card brand ran its own security program (Visa’s Cardholder Information Security Program, Mastercard’s Site Data Protection, and others). Merchants serving several brands faced overlapping requirements. The brands merged their programs into PCI DSS 1.0 in December 2004, and in 2006 American Express, Discover, JCB, Mastercard and Visa formed the PCI Security Standards Council (PCI SSC) to own it.
| Version | Year | Note |
|---|---|---|
| 1.0 | 2004 | First unified standard. |
| 2.0 | 2010 | Moves to a three-year lifecycle. |
| 3.0 / 3.2.1 | 2013 / 2018 | 3.2.1 was the long-lived version, retired March 31, 2024. |
| 4.0 | March 2022 | Major rewrite: customized approach, targeted risk analyses, broader MFA. |
| 4.0.1 | June 2024 | Limited revision (clarifications, no new or removed requirements). The only active version since v4.0 retired on December 31, 2024. |
The v4.0 requirements that were “future-dated” (best practice until then) became mandatory on March 31, 2025, so they are fully in play now.
Base definitions
- Account data: cardholder data (the PAN, plus name, expiration and service code when stored with it) and sensitive authentication data (full track data, CVV2, PINs). Sensitive authentication data must never be stored after authorization.
- CDE (cardholder data environment): the people, processes and systems that store, process or transmit account data, plus anything that can connect to them. Shrinking the CDE (tokenization, P2PE, segmentation) is the biggest lever you have.
- Merchant / service provider: a merchant accepts cards; a service provider stores, processes or transmits account data on someone else’s behalf, or can affect its security. An MSP managing a merchant’s firewall can be a service provider.
- Acquirer: the merchant’s bank. It enforces PCI compliance on the merchant.
- QSA / ISA / ASV: Qualified Security Assessor (external), Internal Security Assessor (trained staff), Approved Scanning Vendor (quarterly external scans).
How it is structured
The PCI SSC writes the standard but does not enforce it. The card brands and acquirers do, through merchant agreements. That is why PCI is a contractual obligation, not a law (a handful of states reference it in statute, but the core mechanism is contract).
The standard is 12 requirements grouped under six goals:
| Goal | Requirements |
|---|---|
| Build and maintain a secure network and systems | 1. Network security controls · 2. Secure configurations |
| Protect account data | 3. Protect stored account data · 4. Strong cryptography in transit over open, public networks |
| Maintain a vulnerability management program | 5. Anti-malware · 6. Secure systems and software |
| Implement strong access control measures | 7. Need-to-know access · 8. Identify and authenticate users · 9. Physical access |
| Regularly monitor and test networks | 10. Log and monitor access · 11. Test security regularly |
| Maintain an information security policy | 12. Policies and programs |
Version 4 added two ways to meet each requirement: the defined approach (do what the requirement says) and the customized approach (meet the stated objective your own way, with a documented targeted risk analysis and an assessor willing to test it). New programs should start with the defined approach.
Levels
Every in-scope entity must meet the whole standard. The level only changes how you validate, and the card brands define the levels, not the PCI SSC. Visa’s merchant levels are the common reference (other brands are similar):
| Merchant level | Annual Visa transactions | Typical validation |
|---|---|---|
| 1 | Over 6 million (any channel), or any merchant Visa designates, including after a compromise | Annual Report on Compliance (ROC) by a QSA (or ISA), quarterly ASV scans |
| 2 | 1 to 6 million (any channel) | Annual Self-Assessment Questionnaire (SAQ); some acquirers require more |
| 3 | 20,000 to 1 million e-commerce | Annual SAQ |
| 4 | Fewer than 20,000 e-commerce, and other merchants up to 1 million | Annual SAQ, as the acquirer requires |
Service providers have two levels (Visa: Level 1 above 300,000 transactions a year, which requires a ROC). Your acquirer has the final say, so confirm your level with them.
The SAQ type (A, A-EP, B, B-IP, C, C-VT, D, P2PE, SPoC) depends on how you take payments, not your volume. An e-commerce site that fully outsources the payment page to a compliant provider might fill out SAQ A; one that hosts its own card form is in SAQ D territory. Either way, you finish with an Attestation of Compliance (AOC) signed by an officer of the company.
Primary documents
- PCI SSC Document Library (PCI DSS v4.0.1, Summary of Changes, SAQs, ROC template, AOCs; free but requires accepting the license)
- PCI SSC: Just Published, PCI DSS v4.0.1 (version and retirement dates)
- Your card brands’ compliance pages and your acquirer’s requirements (levels and deadlines live there, not in the standard)
CMMC (2020): proving it to the Pentagon
Where it came from
CMMC is the newest of the three, but its requirements are not new. The history matters because it explains why CMMC exists at all.
| Year | Milestone |
|---|---|
| 2010 | Executive Order 13556 creates the Controlled Unclassified Information (CUI) program. |
| 2015 / 2016 | FAR 52.204-21 sets 15 basic safeguards for Federal Contract Information; DFARS 252.204-7012 requires defense contractors to implement NIST SP 800-171 for CUI and report incidents within 72 hours. Deadline: December 31, 2017. |
| 2020 | CMMC 1.0 published with five levels. Interim DFARS rule adds the NIST SP 800-171 DoD Assessment Methodology and scores in SPRS (effective November 30, 2020). |
| 2021 | DoD pauses and reviews CMMC 1.0; announces CMMC 2.0 with three levels. |
| 2024 | CMMC Program rule (32 CFR Part 170) final, effective December 16, 2024. |
| 2025 | DFARS acquisition rule (48 CFR) final, effective November 10, 2025. Phase 1 begins. |
| 2026 | July 13: Phase 2 and all later milestones suspended pending a CMMC Reform Task Force review. Phase 1 stays in force. |
The short version: from 2017, contractors self-attested to SP 800-171 and many did not actually implement it. CMMC is a verification program: the controls were already required, and CMMC adds proof.
Base definitions
- DIB: the Defense Industrial Base, the companies (primes and subcontractors) that do work for DoD.
- FCI (Federal Contract Information): information provided by or generated for the government under a contract, not intended for public release.
- CUI (Controlled Unclassified Information): government information that requires safeguarding under law or policy, such as controlled technical drawings. It has a registry of categories.
- OSA / OSC: Organization Seeking Assessment / Certification. That’s the contractor.
- C3PAO: Certified Third-Party Assessment Organization, accredited to perform Level 2 certification assessments.
- DIBCAC: the DCMA Defense Industrial Base Cybersecurity Assessment Center, which performs Level 3 assessments.
- SPRS: the Supplier Performance Risk System, where self-assessment results and annual affirmations are recorded.
Levels
The level is set by the contract, based on the data involved.
| Level 1 | Level 2 | Level 3 | |
|---|---|---|---|
| Data | FCI | CUI | CUI on high-priority programs |
| Requirements | 15 from FAR 52.204-21 | 110 from NIST SP 800-171 Rev. 2 | Level 2 plus 24 selected from NIST SP 800-172 |
| Assessment | Self-assessment | Self-assessment or C3PAO, as the contract specifies | DIBCAC, after a final Level 2 C3PAO certification |
| Frequency | Annual | Every 3 years | Every 3 years |
| Affirmation | Annual, by a senior official in SPRS | Annual | Annual |
| POA&Ms | Not allowed | Limited; at least 80% of the score to get conditional status, gaps closed within 180 days | Limited; same 180-day closeout |
Two points trip people up. First, NIST published SP 800-171 Rev. 3 in May 2024, but DoD has kept contractors on Rev. 2 for now; CMMC Level 2 assesses Rev. 2’s 110 requirements. Second, CMMC levels apply to an assessment scope (an enclave, a whole company), and scoping rules in 32 CFR 170.19 decide which assets are in.
Where it stands today
As of mid-October 2026, Phase 1 is the operative phase: contracts can require Level 1 or Level 2 self-assessments. The July 2026 suspension stopped the November 10, 2026 move to mandatory C3PAO certification and every later milestone while the task force reviews the program. The underlying rules and DFARS 252.204-7012 are unchanged, so the obligation to protect CUI with SP 800-171 has not paused, and a signed SPRS affirmation is a representation to the government with False Claims Act exposure behind it. Primes can still require certification from their subcontractors.
Primary documents
- 32 CFR Part 170, CMMC Program (eCFR) and the final rule with preamble (89 FR 83092)
- DFARS acquisition rule (90 FR 43560)
- DoD CIO: CMMC (assessment guides, scoping guides, current status)
- NIST SP 800-171 Rev. 2 and SP 800-171A (the assessment procedures)
- NIST SP 800-172
- FAR 52.204-21 and DFARS 252.204-7012
The three side by side
| HIPAA | PCI DSS | CMMC | |
|---|---|---|---|
| Type | Federal law and regulation | Industry standard, enforced by contract | Federal contract requirement |
| Who sets it | Congress / HHS | PCI SSC (standard), card brands (levels) | DoD |
| Who enforces | HHS OCR, state AGs | Card brands via acquirers | Contracting officers, primes, DOJ (False Claims Act) |
| Protects | PHI / ePHI | Account data | FCI / CUI |
| Levels | None (scaled by risk analysis) | 4 merchant, 2 service provider levels (validation only) | 3 levels (requirements and assessment) |
| Proof | No certification; OCR investigates after complaints or breaches | ROC or SAQ plus AOC, annually | SPRS affirmation, self or third-party assessment |
| Control source | The Security Rule itself | The standard itself | NIST SP 800-171 / 800-172 |
The overlap is large. MFA, logging, patching, access reviews, encryption, incident response and risk assessment show up in all three. Build one control set and map it to each framework, rather than running three separate programs.
Caveats
- Levels are not maturity. A PCI Level 4 merchant has the same requirements as Level 1; only the paperwork differs. A CMMC Level 1 company is not “less mature,” it holds a different kind of data.
- Compliance is not security. A clean SAQ or a perfect SPRS score describes a point in time against a fixed list. Attackers do not read the list.
- Your scope is your risk. In all three, getting scope wrong (forgetting a backup server, a SaaS tool, a jump box) is how organizations fail assessments and get breached.
- I’m not a lawyer. Legal applicability questions (am I a covered entity, is this CUI, does this contract flow down) belong with counsel, the contracting officer or your acquirer.
Key takeaways
- Ask “who makes us do this, and who checks?” first. Law (HIPAA), contract (PCI DSS) and acquisition rule (CMMC) produce very different enforcement.
- HIPAA has no levels; the risk analysis is what sizes the program. PCI levels change how you validate, not what you implement. CMMC levels change both.
- Read the primary source. Every requirement in this post traces back to a CFR section, the PCI DSS standard or a NIST publication linked above.
- CMMC and the HIPAA Security Rule are both in motion. Track the official pages, not headlines.
- Map once, comply many. The controls overlap far more than the frameworks’ vocabularies suggest.
References
- HHS. Summary of the HIPAA Security Rule; HIPAA Security Rule NPRM; NPRM in the Federal Register (90 FR 898)
- eCFR. 45 CFR Part 164; 32 CFR Part 170
- NIST. SP 800-66 Rev. 2; SP 800-171 Rev. 2; SP 800-171A; SP 800-172
- PCI SSC. Document Library; PCI DSS v4.0.1 announcement and FAQ
- DoD CIO. Cybersecurity Maturity Model Certification
- Federal Register. CMMC Program final rule (89 FR 83092); DFARS CMMC acquisition rule (90 FR 43560)
- Acquisition.gov. FAR 52.204-21; DFARS 252.204-7012
- National Archives. CUI Registry