Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  / ,

  / CMMC Encryption Requirements: A Complete Guide for Defense Contractors

CMMC Encryption Requirements: A Complete Guide for Defense Contractors

The CMMC is vast in coverage and can easily become overwhelming. It includes 110 security controls for each level, excluding level 1, which has only 15, with many encryption controls required throughout.

This guide breaks down exactly what the four core encryption controls demand, how they apply across certification levels, and where assessors consistently find gaps that could have been caught months earlier.

Whilst most of these controls are straightforward, one stands out on the Defense Industrial Base Cybersecurity Assessment Center’s list of most commonly failed controls: SC.L2-3.13.11, which mandates FIPS-validated cryptography for protecting Controlled Unclassified Information (CUI).

This is not because it is technically complex. It is because most contractors misunderstand what it truly requires.

The mistake is almost always the same: assuming that using AES-256 is enough. It is not. CMMC encryption requirements are about validated modules, not algorithms, and that distinction is what fails organisations that believed they were ready.

 

What Are the CMMC Encryption Requirements?

CMMC 2.0 is the Department of Defense’s framework for verifying that contractors protect sensitive defense information. It operates on three certification levels:

  • Level 1, Basic protection of Federal Contract Information (FCI)
  • Level 2, Protection of CUI in alignment with NIST SP 800-171
  • Level 3, Protection of the most sensitive CUI against advanced persistent threats

Encryption requirements live primarily at Level 2 and above. With CMMC, the requirement for FIPS 140 validation now applies to every member of the Defense Industrial Base (DIB), an estimated 215,000 companies, that handles CUI. Every system that performs encryption and touches CUI must use FIPS-validated cryptography. That is a significant shift: previously, FIPS validation was largely reserved for vendors selling directly to federal agencies.

The timeline is active. The CMMC Acquisition Rule became effective November 10, 2025, with Phase 2, mandatory C3PAO assessments for Level 2 contracts, beginning November 10, 2026.

The 4 Core CMMC Encryption Controls Explained

Three controls form the backbone of CMMC’s encryption requirements. Understanding each one separately matters, because failing any of them has direct consequences on your assessment score.

ControlNameWhat It RequiresApplies To
SC.L2-3.13.11FIPS-Validated CryptographyCryptographic modules must hold a valid NIST CMVP certificateAny system that handles CUI
SC.L2-3.13.8CUI in TransitCryptographic mechanisms must protect CUI across all transmission channelsNetworks, email, file transfers, APIs
SC.L2-3.13.16CUI at RestCUI stored on any system must be encryptedServers, workstations, databases, backups
SC.L2-3.13.10Cryptographic Key ManagementKeys must be generated, stored, and revoked in a controlled, documented processAll systems using encryption to protect CUI
MP.L2-3.8.7.CUI on MediaEncryption must extend to physical and removable mediaUSB drives, external disks, backup tapes, laptops

 

SC.L2-3.13.11: Employ FIPS-Validated Cryptography to Protect CUI

This is the headline control and the most misunderstood. A common mistake is confusing cryptographic algorithms with cryptographic modules. The CMMC requirement is about the module, not just the algorithm.

You can run AES-256 across your entire environment. If the module implementing it has not been validated through NIST’s Cryptographic Module Validation Program (CMVP), you are not compliant. The algorithm is not the certificate.

Pro Tip

During an assessment, you will be asked to provide the FIPS certificate number for each product that handles CUI, not a vendor’s claim that they “support AES-256.” Have those certificate numbers documented before the assessment starts.

SC.L2-3.13.8 and SC.L2-3.13.16: CUI in Transit and at Rest

SC.L2-3.13.8 requires cryptographic mechanisms to protect CUI during transmission, covering all communication channels: network connections, email, file transfers, and API communications. SC.L2-3.13.16 requires protection of CUI at rest. Neither control names a specific algorithm, but the FIPS validation requirement from 3.13.11 applies across both.

SC.L2-3.13.10: Establish and Manage Cryptographic Keys

Encryption without key management is security theatre. This control requires that keys be generated, stored, and revoked in a controlled, documented way. A compromised key renders all your encryption irrelevant regardless of algorithm strength.

MP.L2-3.8.7: Control Access to CUI on Media

This control extends encryption requirements to physical and removable media. CUI stored on a USB drive, an external hard disk, or a backup tape must be protected. Contractors who focus on network-level encryption and forget about the laptop bag sitting in a car park consistently fail this one.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

CMMC Encryption Requirements by Certification Level

Level 1 covers organisations handling only FCI. The controls are foundational and do not explicitly mandate encryption, though it remains a recommended practice. This changes sharply at Level 2.

Under the CMMC scoring methodology:

  • 5 points deducted if no cryptography is employed
  • 3 points deducted if cryptography is present but not FIPS-validated
  • Maximum score: 110 | Minimum passing threshold: 88

Getting SC.L2-3.13.11 wrong costs points you cannot afford to lose.

Level 3 introduces additional requirements aligned with NIST SP 800-172, including enhanced key management controls, stricter access controls on cryptographic infrastructure, and greater scrutiny of the supply chain around cryptographic tools.

 

Pro Tip

According to research by Merrill Research and CyberSheath, only 4% of defense contractors are fully prepared for CMMC certification based on third-party assessment criteria, while 75% believe they are compliant based on self-assessment. The gap is widest in technical controls, with encryption and key management among the most common failure points.

What Is FIPS-Validated Cryptography and Why Does It Matter?

FIPS stands for Federal Information Processing Standards. FIPS 140, developed by NIST, sets the benchmark for cryptographic modules intended to protect sensitive information. It requires that cryptographic modules be tested by accredited third-party laboratories and certified by NIST, a process managed through the Cryptographic Module Validation Program (CMVP).

FIPS 140-2 vs. FIPS 140-3

FIPS 140-3 is the newer standard, published March 22, 2019, and aligns with the international ISO/IEC 19790:2012(E) standard. Both remain acceptable under current CMMC requirements. FIPS 140-3 introduces stricter requirements around physical security, key management, and testing methodologies, and will likely become the primary standard as the framework evolves.

If your vendor holds a current FIPS 140-2 certificate and that module remains on NIST’s active modules list, you are covered for now, but plan your migration path.

Acceptable Encryption Standards Under CMMC

AES-256 is the most widely deployed algorithm in CMMC-compliant environments, and it satisfies cryptographic strength requirements when implemented through a FIPS-validated module. For data in transit, TLS 1.2 and TLS 1.3 support AES-256 cipher suites that meet the requirement. TLS 1.3 is the current best practice and should be your target configuration.

Pro Tip

Before your assessment, pull the FIPS certificate numbers for every product in your environment that touches CUI, your email platform, endpoint encryption, VPN, and cloud storage. Your assessor will ask for them. Having a documented inventory with certificate numbers and their active or historical status saves hours during evidence review.

Encrypting CUI at Rest for CMMC Compliance

Endpoints, Laptops, and Local Storage

Every device that stores CUI must have full-disk or file-level encryption enabled through a FIPS-validated module. In Windows environments, BitLocker is commonly used, but BitLocker in default mode is not FIPS-compliant. You must enable FIPS mode explicitly through Group Policy, and you must verify it is active, not just configured. Assessors will check both.

Removable Media and Hardware-Encrypted Devices

Removable media is one of the most consistent failure points across the DIB. A contractor can have bulletproof endpoint encryption and still fail this control because an employee transferred a CUI document to a personal USB drive. Hardware-encrypted USB devices with FIPS 140-2 Level 3 validation exist for this purpose. Controlling their use through both policy and technical enforcement is as important as choosing the right device.

Cloud Storage and FedRAMP-Authorised Infrastructure

FedRAMP Moderate and High authorisations include FIPS-validated cryptography by design. Microsoft 365 GCC High, AWS GovCloud, and Azure Government are the most commonly used platforms that meet this bar. Standard commercial tiers of the same platforms do not.

Note: Many contractors use a FedRAMP-authorised cloud platform and assume the encryption requirement is fully satisfied. It covers the provider’s infrastructure, not how users access it, what they download from it, or how they share files outside of it. The environment is FedRAMP-covered; the behaviour around it often isn’t.

Encrypting CUI in Transit for CMMC Compliance

Email Transmission of CUI

Standard email is not encrypted end-to-end. Your email might travel over a TLS-encrypted connection between mail servers, but that protects the transport pipe, not the message content. Secure email solutions that apply encryption to message content provide the protection CMMC requires for email containing CUI. Microsoft 365 GCC High with S/MIME or Office Message Encryption configured for CUI use cases addresses this. Standard Office 365 does not.

File Transfers and Collaboration Tools

SFTP and FTPS both support encrypted transmission, but implementations must use FIPS-validated cryptographic modules. Consumer file-sharing tools, even those marketed with encryption enabled, are almost never FIPS-validated. Dropbox, standard-tier Google Drive, and similar services are not acceptable for CUI transmission regardless of their encryption claims.

Remote Access and VPN Encryption

All remote access sessions that could expose CUI must use FIPS-validated encryption. Configure your VPN to enforce TLS 1.2 at minimum, disable older protocol versions, and document the configuration explicitly. When CUI leaves your physically controlled environment, cryptography is the primary protection mechanism, and that is precisely when FIPS validation becomes non-negotiable.

Encryption Key Management Under CMMC

Key Generation and Storage Requirements

Keys must be generated using approved random number generators within FIPS-validated modules and stored in a way that prevents unauthorised access. Hardware Security Modules (HSMs) are the gold standard. Software-based key stores within FIPS-validated environments are acceptable at Level 2, but your documentation must demonstrate the approach clearly.

Key Rotation and Revocation Best Practices

Define rotation intervals in your key management policy, and actually follow them. Rotate encryption keys when staff with key access leave the organisation. Have a tested revocation process. A policy that says “we rotate annually” but has never been executed will not survive an assessor interview.

Pro Tip

Document your key management lifecycle in your System Security Plan (SSP). Assessors are not just looking for functioning encryption, they are looking for documented, repeatable processes. A gap between what your SSP says and what you actually do is a finding, even if the technical controls are otherwise correct.

Common CMMC Encryption Deficiencies Found During Assessments

The Subcontractor Flow-Down Gap

Prime contractors invest heavily in their own encrypted environments, then allow subcontractors to access CUI through portals that lack proper encryption controls. Per 32 CFR Part 170, CMMC requirements flow down to subcontractors based on the type of data they process, store, or transmit. If your subcontractor downloads CUI to an unencrypted device, that exposure is your problem as much as theirs.

The Affirmation Window Vulnerability

Certified organisations must complete annual affirmations confirming ongoing compliance. Encryption configurations drift between assessments. A patch can disable FIPS mode. A new device can be deployed without the correct policy applied. Without continuous monitoring, the gap between your affirmed posture and your actual posture grows quietly, until the next assessor walks in.

Sensitive Bid Preparation Risks

CUI often flows early in a contract cycle, during proposal preparation and technical review, before formal compliance processes kick in. Contractors receive technical documents marked CUI, open them on standard workstations, email sections to colleagues, and store drafts on unencrypted shared drives. This is one of the most common real-world exposure scenarios, and it almost never appears in System Security Plans.

What a CMMC Assessor Will Look for on Assessment Day

Assessors examine documentation, configuration evidence, and staff interviews. For encryption specifically, expect requests for:

  • FIPS certificate numbers for each product handling CUI
  • Live demonstration that FIPS mode is active
  • Data flow diagrams showing how CUI moves through your environment and what encrypts it at each step
  • Key management logs showing actual rotation history, not just policy documents

Important: If minor gaps are identified during an assessment, organisations may address deficiencies within 180 days through a Plan of Action and Milestones (POA&M). Major issues require full reassessment. Encryption deficiencies attract close scrutiny and will affect your SPRS score for the duration of any POA&M period.

How to Remediate CMMC Encryption Gaps

Conducting an Encryption Gap Analysis

Map every location where CUI is stored, processed, or transmitted. For each data flow, identify the encryption method in use and verify whether the underlying module appears on the NIST CMVP active modules list. Document what is compliant, what requires remediation, and what requires a structural decision, some legacy systems need compensating controls or architectural changes rather than a direct fix.

A structured Encryption Gap Analysis is the most reliable way to surface these issues before an assessor does.

Implementing Per-File Encryption to Close Compliance Gaps

When full-disk encryption is not feasible, legacy embedded systems, manufacturing equipment, isolated lab environments, per-file encryption applied at the point of CUI creation or receipt can serve as a compensating control. The file travels encrypted regardless of where it is stored or how it is transmitted. This approach requires clear staff training and disciplined execution to be effective.

What CMMC Encryption Does Not Require

FIPS-validated modules are required when cryptography serves as your primary method of protecting CUI confidentiality, mainly when CUI leaves your physical control. When CUI stays within a physically secured boundary and physical controls provide the confidentiality protection, FIPS validation for internal network infrastructure is not mandated.

You do not need FIPS-validated switches, routers, or internal firewalls just because they carry traffic on a network that also carries CUI. This is a common and expensive misconception that sends contractors chasing requirements that do not apply to them.

 

Final Thoughts

Ready to find out where your encryption posture stands before an assessor does? Axipro works with defense contractors across the DIB to conduct pre-assessment gap analyses, identify FIPS compliance deficiencies, and build a remediation plan that holds up on assessment day. Get in touch to start the conversation.

What encryption algorithm is required for CMMC compliance?

CMMC does not mandate a specific algorithm by name. It requires FIPS-validated cryptography, and AES-256 is the most widely implemented algorithm that satisfies this requirement. The critical point: the cryptographic module implementing the algorithm must hold a current FIPS certificate.

Yes. Controls SC.L2-3.13.16 and SC.L2-3.13.8 address at-rest and in-transit CUI respectively, and both apply at Level 2.

AES-256 through a FIPS-validated module is sufficient. AES-256 through a non-validated implementation is not. The distinction matters enormously on assessment day.

FIPS 140-3, published in 2019, introduces updated testing methodologies aligned with ISO/IEC 19790. Both are currently acceptable under CMMC. FIPS 140-3 will likely become the primary standard as the framework evolves.

Yes. CMMC requirements flow down through the supply chain. If a subcontractor processes, stores, or transmits CUI, they must meet the same encryption requirements as the prime contractor for that data.

It satisfies encryption requirements for data within that provider’s authorised boundary. It does not address how users access, download, or share that data outside the boundary.

Unmet encryption controls result in score deductions and a finding in your assessment report. Minor gaps can be addressed through a POA&M within 180 days. Significant gaps may prevent certification until remediated, blocking contract eligibility during that period.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

A business continuity plan that has never been tested is, to a SOC 2 auditor, a document and nothing more. The Availability criteria do not award credit for a polished plan sitting in a shared drive. They ask for evidence that you ran the plan, watched it work or fail, recorded what happened, and fixed what broke. That gap — between having a plan and proving it works — is where most availability findings originate. Business continuity plan testing for SOC 2 is the exercise that turns your plan into auditable evidence. It maps directly to Availability criterion A1.3, one of the few SOC 2 controls that explicitly requires you to test something rather than merely document it. This guide covers what counts as a valid test, the test types auditors accept, a step-by-step process, the exact evidence you need, and the mistakes that turn a routine review into a finding. What Is Business Continuity Plan Testing in the Context of SOC 2? Business continuity plan (BCP) testing is the structured validation of whether your organization can keep critical operations running — and restore them within defined targets — during a disruption. In a SOC 2 context, the testing is not freeform. It must produce dated, traceable evidence that the recovery procedures in your plan actually work, that the people involved know their roles, and that systems and data come back within your stated recovery objectives.   Why SOC 2 Requires Business Continuity Plan Testing SOC 2 is an attestation against the AICPA’s Trust Services Criteria, and the Availability category exists specifically for organizations that make uptime or resilience commitments to customers. A plan you never exercise cannot demonstrate operating effectiveness over the audit period — which is the entire point of a Type 2 examination. Testing is the control that converts a static plan into a recurring, observable activity an auditor can sample. SOC 2 Trust Services Criteria and BCP Testing Requirements Availability is one of the five Trust Services Criteria, and it is optional, included only when your service commitments warrant it. When in scope, it is built around three sub-criteria: A1.1 addresses capacity management. A1.2 addresses recovery infrastructure and backup processes. A1.3 addresses the testing of recovery procedures. BCP testing lives squarely in A1.3, with A1.2 supplying the backups and infrastructure that the test validates. Availability Criteria A1.2 and A1.3 Explained Per the AICPA’s Trust Services Criteria, A1.2 requires the entity to design, implement, operate, and monitor environmental protections, recovery infrastructure, and data backup processes that meet its availability objectives. In plain terms: you need real backups, stored away from production, with recovery infrastructure ready to use. A1.3 then requires the entity to test recovery plan procedures supporting system recovery to meet its objectives. The two work as a pair: A1.2 builds the capability, A1.3 proves it functions. Important: The most common A1.3 gap is not a missing test. It is a test that never validated the recovery objectives. Teams run a tabletop, write “no issues found,” and move on — but the plan claims a 4-hour RTO that no one ever measured against an actual restore. If your plan states recovery targets, your test evidence must show whether you met them. A test that does not measure against your RTO and RPO leaves the most important question unanswered.   What Auditors Look for During a BCP Test Review Auditors want proof that the test happened, proof that it was meaningful, and proof that it led somewhere. Concretely, that means a test plan with a defined scenario, a dated record of execution with participants, results measured against your recovery objectives, a list of gaps or issues found, and evidence that those issues were remediated. A test that finds nothing and changes nothing is treated with suspicion — because real tests almost always surface something.   Types of Business Continuity Plan Tests Accepted for SOC 2 SOC 2 does not mandate a specific test type. It expects the rigor of the test to match the criticality of what you are protecting. The four common approaches sit on a spectrum from low-effort, low-disruption to high-effort, high-assurance. Tabletop Exercises A tabletop exercise is a facilitated discussion where key personnel talk through a disruption scenario and their responses. It is cheap, fast, and excellent for confirming that people understand their roles and that the plan reads coherently. Its limit is obvious: nobody actually recovers anything. For many organizations a tabletop is a legitimate annual test, especially in the first audit cycle, but auditors expect more rigor as a program matures. Walkthrough and Simulation Tests A simulation applies a specific scenario and asks the team to perform recovery actions, not just describe them. It is more involved than a tabletop and far better at exposing the gaps that only appear when people touch the tools. Simulations are where teams discover that a runbook references a system that was decommissioned, or that the on-call engineer lacks the access the plan assumes. Full Interruption Tests A full interruption test shuts down primary systems and shifts operations entirely to the recovery environment. It is the most comprehensive validation available and the only one that proves your failover genuinely works end to end. It also carries real operational risk, so it demands thorough planning and is usually reserved for mature programs and the most critical systems. Parallel Testing Parallel testing activates recovery systems alongside production without taking the primary offline, then compares the two to confirm the recovery environment performs as expected. It delivers much of the assurance of a full interruption test while sparing the business the disruption. For most SaaS and cloud-hosted services, parallel testing of failover and restore is the sweet spot between confidence and risk. How to Test Your Business Continuity Plan for SOC 2 Compliance The sequence below aligns with the contingency planning process in NIST’s Contingency Planning Guide, SP 800-34, which auditors widely treat as authoritative for resilience practices. Each step produces an artifact, and the artifacts together form

A SOC 2 auditor will not ask whether you have an incident reporting policy. They will ask you to pull a specific incident from the last twelve months and walk them through it: when it was detected, who classified it, when it was escalated, who was notified, and how it was closed. The policy is the easy part. The part that fails audits is the gap between what the document says and what the timestamps actually show. Incident reporting sits at the center of the SOC 2 System Operations criteria, and it is one of the most frequently exception-flagged areas in Type 2 reports. The reason is consistent: teams treat reporting as paperwork generated after the fire is out, rather than as a controlled process that produces evidence at every step. This guide breaks down how to build a reporting process that an auditor can test, sample, and sign off on without a finding. What Is the Incident Reporting Process in SOC 2? The incident reporting process is the documented, repeatable sequence your organization follows from the moment a security event is detected to the moment the incident is formally closed and archived. It governs how events are logged, classified, escalated, communicated, and recorded. Reporting is not a single notification email. It is the connective tissue that links detection, response, and post-incident review into an auditable chain. How SOC 2 Defines a Security Incident SOC 2 does not hand you a rigid statutory definition. It works through the AICPA’s Trust Services Criteria, which frame an incident around a failure, or potential failure, of the system to meet the organization’s service commitments and security objectives. In practice, a security incident is any event that compromises, or could compromise, the confidentiality, integrity, or availability of systems or data. The criteria expect you to define this threshold yourself and apply it consistently, which is precisely what auditors test against. What Qualifies as a Reportable Security Incident Under SOC 2? An event becomes reportable when it crosses the threshold your own policy sets. The distinction matters. A blocked phishing email is a security event. A user who clicked the link and entered credentials is a reportable incident. SOC 2 rewards organizations that draw this line explicitly, because a clear definition is what makes consistent triage possible. Vague language like “significant events will be reported” invites the auditor to ask who decides what counts as significant, and on what basis. Examples of Security Incidents Relevant to SOC 2 Common reportable incidents include unauthorized access to production systems, credential compromise, malware or ransomware infection, data exfiltration or accidental disclosure, denial-of-service events affecting availability, lost or stolen devices holding company data, and misconfigurations that expose data to the public. Vendor and subprocessor breaches that touch your data belong on this list, too, since the criteria extend your responsibility into the supply chain. How Incident Severity Levels Are Established and Classified Severity classification drives everything downstream: how fast you respond, who gets pulled in, and which notification clocks start ticking. Most mature programs use a tiered scheme tied to business impact rather than technical noise. The point is not the labels you choose but the fact that the labels map to defined response times and escalation paths, and that the mapping is documented before an incident occurs, not invented during one. Auditors quietly judge your maturity by how few P1s you declare and how consistently you apply the tiers. A program that labels everything critical looks panicked; one that never escalates looks asleep. The strongest signal is a severity matrix with response-time SLAs next to each tier, and ticket history showing the tiers were actually applied as written. SOC 2 Incident Reporting Requirements There is no single “incident reporting requirement” in SOC 2. The obligation is distributed across several Common Criteria, and the auditor assembles a picture from all of them. Understanding which criteria govern reporting tells you exactly what evidence to keep. Which SOC 2 Trust Services Criteria Govern Incident Reporting? Incident reporting lives mainly in the CC7 (System Operations) series. CC7.2 covers monitoring system components to detect anomalies that may signal an incident. CC7.3 requires you to evaluate detected events to determine whether they are incidents and to take action. CC7.4 governs the response itself, including containment, eradication, and communication. CC7.5 addresses recovery and remediation. Communication obligations also reach into CC2.2 and CC2.3, which deal with internal and external information flow, and third-party incidents implicate CC9.2 on vendor risk. These are points of focus, not a checklist, but auditors use them to frame their testing. For a deeper look at how these criteria map to your broader compliance program, see our SOC 2 compliance guide. What Evidence Do Auditors Expect From Your Incident Reporting Process? Auditors want artifacts with time references, not assertions. That means incident tickets showing detection and closure timestamps, severity classifications with the name of who assigned them, escalation records, communication logs, and post-incident review notes. In a Type 2 examination they will trace one real incident end to end. Evidence pulled from a staging environment, or any artifact with no clear date, gets challenged immediately. Who Is Responsible for Reporting Security Incidents? Everyone reports; a defined role decides. SOC 2 expects that all staff know how to raise a suspected incident, and that a named function, often a security lead or incident commander, owns the determination of severity and the decision to escalate. The auditor will look for evidence that this ownership is real: a RACI chart is fine, but ticket history showing the right person actually classified and closed incidents is better. Step-by-Step SOC 2 Incident Reporting Process The following sequence maps cleanly to the lifecycle in NIST’s Computer Security Incident Handling Guide (SP 800-61), which auditors widely recognize as authoritative. NIST withdrew Revision 2 in April 2025 and released Revision 3, which reorganizes the lifecycle around the six functions of the Cybersecurity Framework 2.0. The underlying steps below remain the same; the framing simply shifts toward continuous risk management.

HIPAA and GDPR are the two most consequential data protection frameworks any healthcare or technology organisation is likely to encounter. They share a common purpose, protecting sensitive personal data, but they differ significantly in scope, enforcement mechanisms, and compliance obligations. For organisations operating across the Atlantic, understanding where they align, where they clash, and how to satisfy both simultaneously is not optional. It is a legal necessity. What Is HIPAA? The Health Insurance Portability and Accountability Act was enacted by the U.S. Congress in 1996. Its original purpose was to modernise the flow of healthcare information and ensure the portability of health insurance coverage. Over time, it became primarily known for its data protection requirements, administered by the U.S. Department of Health and Human Services (HHS) and enforced by the Office for Civil Rights (OCR). HIPAA is built around three core rules. The Privacy Rule governs how Protected Health Information (PHI) may be used and disclosed. The Security Rule sets standards for safeguarding electronic PHI (ePHI). The Breach Notification Rule establishes mandatory reporting timelines when PHI is compromised. Who Needs to Be HIPAA Compliant? HIPAA applies to covered entities, healthcare providers, health plans, and healthcare clearinghouses, and to their business associates: any third-party organisation that handles PHI on their behalf. If you build software that processes patient data for a U.S. hospital, you are a business associate. If you store medical records in the cloud for an insurance company, you are a business associate. A Business Associate Agreement (BAA) is the formal contract that governs this relationship. What Types of Data Does HIPAA Protect? HIPAA protects Protected Health Information (PHI): any individually identifiable information relating to a person’s past, present, or future physical or mental health condition, the provision of healthcare, or the payment for healthcare. This includes names, dates of birth, Social Security numbers, medical record numbers, and any data that could be used to identify a patient in connection with their health. Electronic PHI, the subset stored or transmitted digitally, is subject to the Security Rule’s additional technical requirements. What Is GDPR? The General Data Protection Regulation came into force across the European Union on 25 May 2018, replacing the 1995 Data Protection Directive. It is the world’s most comprehensive data privacy law, and its extraterritorial reach means it extends well beyond Europe’s borders. The GDPR is enforced by national Data Protection Authorities (DPAs) and coordinated at the European level by the European Data Protection Board (EDPB). Unlike HIPAA, GDPR is not sector-specific. It applies to any organisation processing the personal data of EU residents, regardless of industry. Who Needs to Be GDPR Compliant? Any organisation that processes the personal data of individuals located in the European Union, regardless of where the organisation is based. A U.S. hospital treating European patients, a SaaS company offering services to German users, or a health app collecting data from French residents all fall within GDPR’s scope. The regulation applies to both data controllers (organisations that determine how and why data is processed) and data processors (third parties that process data on a controller’s behalf). What Types of Data Does GDPR Protect? GDPR protects all personal data: any information relating to an identified or identifiable natural person. Health data is explicitly designated a special category under GDPR Article 9, commanding heightened protection alongside biometric data, genetic data, racial or ethnic origin, religious beliefs, and sexual orientation. HIPAA vs GDPR: Key Differences at a Glance Feature HIPAA GDPR Jurisdiction United States only EU + extraterritorial reach Sector Healthcare only All sectors Regulatory body HHS / OCR National DPAs / EDPB Data covered PHI only All personal data Consent model Treatment-based exceptions Explicit consent required Breach notification 60 days (proposed: 72 hours) 72 hours Max fine $1.9M per violation category/year €20M or 4% of global turnover DPO required No Sometimes Right to erasure Limited Yes Scope and Geographic Reach HIPAA’s reach is defined by entity type: it applies to covered entities and business associates operating within the United States. Whether a patient holds EU citizenship is irrelevant to HIPAA jurisdiction. What matters is whether the organisation providing care or processing health data operates within the U.S. healthcare system. GDPR’s reach is defined by the location of the data subject, not the organisation. Article 3 of the GDPR gives it explicit extraterritorial effect. If your organisation targets or monitors EU residents, GDPR applies, regardless of where you are headquartered, where your servers are located, or what industry you operate in. Types of Data Protected: Personal Data vs Protected Health Information (PHI) This is the sharpest structural difference between the two frameworks. HIPAA is focused exclusively on health data in the context of healthcare delivery or payment. GDPR covers all personal data, from email addresses and IP addresses to medical records and genetic profiles. Health data under GDPR is a subset of the broader personal data category, not the totality of it. An organisation that is fully HIPAA-compliant may still be in violation of GDPR if it mishandles employee data, marketing data, or website analytics. Legal Basis for Data Processing GDPR requires organisations to identify a valid legal basis before processing any personal data. For health data, that typically means explicit consent or one of the specific derogations in Article 9(2), such as processing necessary for medical diagnosis or the provision of healthcare. This is a meaningful threshold; pre-ticked boxes, bundled consent, or vague terms of service do not meet GDPR’s standard. HIPAA takes a different approach. It permits covered entities to use and disclose PHI for treatment, payment, and healthcare operations without obtaining patient consent. Authorisation is required only in specific circumstances, such as disclosures for marketing purposes or release of psychotherapy notes. Important: GDPR’s explicit consent requirement creates real friction for U.S. healthcare organisations treating EU patients. A hospital cannot rely on its standard HIPAA-compliant intake forms to satisfy GDPR. The legal bases must be documented separately, and consent forms must meet the GDPR’s granularity requirements. Regulatory Authority and Enforcement HHS OCR is