Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  / ,

  / CMMC vs NIST 800-171: Key Differences, Comparisons, and What Defense Contractors Need to Know

CMMC vs NIST 800-171: Key Differences, Comparisons, and What Defense Contractors Need to Know

Around the year 2019, The DoD found a problem. Contractors were self-attesting to NIST SP 800-171 compliance, signing off on security postures that, in many cases, existed only on paper. Sensitive defense information was leaving the supply chain through vulnerabilities that everyone had technically promised to close. That failure gave rise to CMMC, and understanding how these two frameworks relate, where they overlap, and where they diverge is now a contractual necessity for every organization in the Defense Industrial Base.

This guide cuts through the confusion and provides a precise, current account of how CMMC 2.0 and NIST SP 800-171 compare and coexist.

What Is NIST SP 800-171?

NIST Special Publication 800-171 is a set of cybersecurity requirements developed by the National Institute of Standards and Technology for the protection of Controlled Unclassified Information (CUI) in non-federal information systems and organizations. It was first published in 2015 and most recently updated with Revision 3 in May 2024.

The framework covers 14 families of security requirements in its current Revision 2 form, spanning access control, audit and accountability, incident response, configuration management, identification and authentication, and more. Revision 3 restructures this into 17 families, reducing the number of top-level requirements from 110 to 97 while introducing three new domains: Planning, System and Services Acquisition, and Supply Chain Risk Management. Do not let the lower requirement count mislead you. According to NIST, Revision 3 increases the number of determination statements, the specific verification actions required during an assessment, by 32 percent.

NIST 800-171 is not a certification. It is a compliance standard built on a self-assessment model. Organizations determine their own score, document it in their System Security Plan (SSP), and report it to the DoD’s Supplier Performance Risk System (SPRS). That self-reporting architecture is precisely what CMMC was designed to fix.

Worth Knowing: NIST SP 800-171 applies broadly across federal contracting, not just the DoD. Any non-federal organization handling CUI in support of a federal agency, including NASA, GSA, and others, may be required to comply. CMMC, by contrast, is exclusively a DoD program.

What Is CMMC 2.0?

The Cybersecurity Maturity Model Certification is the Department of Defense’s formal certification program for cybersecurity compliance across the Defense Industrial Base. CMMC 2.0 was finalized in October 2024 and became effective December 16, 2024, with enforcement rolling out in phases through 2028.

Where NIST 800-171 describes what security controls an organization should implement, CMMC adds a verification layer: it requires that compliance be independently confirmed before a contract is awarded. CMMC uses a three-level maturity model, with each level corresponding to the sensitivity of the data handled and the rigor of the required assessment.

CMMC is enforced through DFARS clause 252.204-7021. Phase 1 of the rollout began November 10, 2025, and the DoD estimates that approximately 65 percent of the Defense Industrial Base will be affected. Major primes including Lockheed Martin and Boeing have already issued directives requiring CMMC documentation from their supply chains, in some cases ahead of official DoD deadlines.

How CMMC and NIST 800-171 Connect

CMMC 2.0 does not replace NIST 800-171. It is built on top of it. CMMC Level 2, the level most defense contractors will encounter, directly mirrors the 110 requirements in NIST SP 800-171 Revision 2. CMMC Level 3 extends that baseline by adding 24 enhanced requirements drawn from NIST SP 800-172.

Think of it this way: NIST 800-171 is the technical standard, and CMMC is the auditing and enforcement mechanism. Implementing 800-171 is a prerequisite for CMMC Level 2 certification. The critical difference is that 800-171 compliance is self-declared, while CMMC compliance is independently verified.

Both frameworks require a System Security Plan and a Plan of Action and Milestones (POA&M) for identified gaps. Assessment results from third-party or government-led CMMC assessments are recorded in eMASS, the DoD’s Enterprise Mission Assurance Support Service, while self-assessment results continue to be recorded in SPRS.

Key Differences Between CMMC and NIST 800-171

 

Attribute

NIST SP 800-171

CMMC 2.0

 

Purpose

Technical standard for CUI protection

Certification program verifying CUI protection

Who It Applies To

Any non-federal entity handling CUI

DoD contractors and subcontractors handling FCI or CUI

Maturity Levels

None, flat set of 110 requirements

Three levels (Foundational, Advanced, Expert)

Assessment Model

Self-assessment and self-attestation

Self-assessment (L1), C3PAO (L2), DIBCAC (L3)

Where Results Are Recorded

SPRS

SPRS (self-assessments), eMASS (C3PAO/DIBCAC)

POA&M Restrictions

No closure deadline or item limit

Limited open items; must close within 180 days

Contract Consequence

Contractually required; limited enforcement mechanism

Required for contract award; False Claims Act exposure

Current Revision in Use

Rev. 2 (CMMC use); Rev. 3 published May 2024

Aligned to Rev. 2 for Level 2 assessments

Cloud Requirements

FedRAMP Moderate equivalent minimum

FedRAMP Moderate (L2); FedRAMP High (L3)

Applies to Non-DoD Agencies?

Yes

No, DoD only

Is Compliance Mandatory?

Both frameworks are contractually required for DoD contractors handling CUI through the DFARS 252.204-7012 clause. The critical difference is consequence. NIST 800-171 compliance has been contractually required for years, but the self-attestation model created minimal accountability. CMMC adds teeth: without the required certification level, organizations cannot be awarded or retain DoD contracts. Under the False Claims Act, falsely certifying CMMC compliance can expose both the organization and signing individuals to treble damages.

Does It Use a Maturity Model?

NIST SP 800-171 does not use a maturity model. It presents a flat set of requirements that either are or are not implemented. CMMC structures compliance into three ascending levels, with each level carrying specific assessment requirements and targeting a different category of sensitive information.

Does It Require a Third-Party Assessor?

NIST 800-171 is self-assessed. CMMC Level 1 is also self-assessed annually. For CMMC Level 2, the picture is more complex: some contracts allow self-assessment, but most high-priority contracts require assessment by a Certified Third-Party Assessment Organization (C3PAO). CMMC Level 3 requires a direct audit by the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC), a government body.

Scope: What Data Does Each Framework Protect?

Both frameworks center on CUI protection, but there is an important distinction. NIST SP 800-171 also includes requirements for Non-Federal Organization (NFO) controls, giving it a broader scope. CMMC focuses primarily on CUI and Federal Contract Information (FCI) within the DoD supply chain. Passing a CMMC certification assessment does not automatically confirm full NIST 800-171 compliance because of this scope difference.

Assessment and Verification Requirements

Under NIST 800-171, organizations self-score against the 110 controls and submit results to SPRS. There is no ceiling on open POA&M items and no mandated closure timeline. CMMC restricts the number of open POA&M items permitted at contract award and requires that all open items be closed within 180 days. This is a material operational constraint that many organizations overlook during gap assessment.

Important: A common mistake is treating an SPRS score as CMMC readiness. Your self-assessed NIST 800-171 score documents your posture, but it does not constitute CMMC certification. A C3PAO will independently verify each control, and the assessment criteria are rigorous. Organizations that discover this distinction late often face significant remediation

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

How CMMC Levels Map to NIST 800-171

CMMC Level 1 vs. NIST 800-171

Level 1 is foundational. It covers 17 basic cybersecurity practices drawn from FAR clause 52.204-21 and focuses on protecting Federal Contract Information rather than CUI. Level 1 requires annual self-assessment and does not align with NIST 800-171 in any comprehensive way. It is the entry point for contractors whose work involves only non-sensitive federal contract data.

CMMC Level 2 vs. NIST 800-171

Level 2 is the most consequential for the majority of the defense supply chain. It directly maps to all 110 requirements in NIST SP 800-171 Revision 2. For most contracts, Level 2 requires C3PAO assessment. The DoD has explicitly stated that Level 2 assessments continue to be conducted against Revision 2, and that the transition to Revision 3 will occur through future rulemaking, not through the current CMMC program.

Level 2 certification preparation typically takes between 6 and 12 months for organizations that have begun gap remediation. Those starting from a low SPRS baseline should plan for 12 to 24 months from initial assessment to certification.

CMMC Level 3 vs. NIST 800-171

Level 3 is reserved for contractors involved in the DoD’s most critical programs. It incorporates the 110 requirements from NIST SP 800-171 Revision 2 plus 24 selected enhanced requirements from NIST SP 800-172. Assessment at this level is conducted directly by DIBCAC and is not available through a C3PAO. Phase 3 of the CMMC rollout, targeting mandatory Level 3 certifications, is scheduled for March 2027.

CMMC vs NIST 800-171 Controls and Practices

NIST SP 800-171 Revision 2 contains 110 requirements organized across 14 control families. Revision 3, published in May 2024, restructures this into 17 families with 97 top-level requirements. The apparent reduction is misleading: the number of determination statements, the specific verification actions an assessor must confirm, increases from 320 to 422, a 32 percent jump.

CMMC Level 2 controls map one-for-one with NIST SP 800-171 Rev. 2 requirements. CMMC Level 3 adds 24 controls from SP 800-172, bringing the total to 134. At all levels, CMMC requires implementation, not merely documentation. A policy that exists but is not enforced, tested, and evidenced will not satisfy a C3PAO assessment. This is one of the most common pitfalls organizations encounter in compliance programs across frameworks.

Pro Tip: Scope reduction is one of the most effective ways to reduce compliance cost and complexity. By isolating CUI into a defined enclave, separating those systems from the rest of your environment, you can reduce the number of assets subject to C3PAO assessment significantly. This strategy is increasingly common among small manufacturers and subcontractors managing constrained compliance budgets.

CMMC vs NIST 800-171 Assessments

Under NIST 800-171, assessment is internal. An organization reviews its implementation against the 110 controls, calculates a score using the DoD Assessment Methodology, and submits results to SPRS. The score ranges from 110 (full compliance) to -203 (no controls implemented). Agencies can review SPRS scores, but there is no formal audit unless the agency initiates one.

CMMC assessments are more structured. For Level 2, a C3PAO evaluates implementation against all 110 Rev. 2 controls using evidence including configuration documentation, logs, policies, procedures, and interviews. Organizations with existing frameworks such as ISO 27001 or SOC 2 can reduce their preparation time by 4 to 6 months by leveraging overlapping control evidence.

One practical constraint: C3PAO capacity is limited. The pool of approved assessors is not large relative to the 300,000+ organizations in the Defense Industrial Base that will eventually require certification. Contractors who wait for CMMC requirements to appear in their contract before engaging an assessor risk extended delays and potential contract ineligibility.

Does CMMC Replace NIST 800-171?

No. CMMC 2.0 does not replace NIST SP 800-171. The DFARS 252.204-7012 clause, which mandates NIST 800-171 compliance, remains in effect independently of CMMC. CMMC 2.0 adds a certification requirement on top of the existing NIST 800-171 obligation. For DoD contracts involving CUI, contractors must satisfy both: implement the NIST 800-171 controls and obtain the required CMMC certification level.

The distinction matters operationally. Achieving CMMC Level 2 certification verifies your implementation of the 800-171 controls for CUI protection, but it does not certify compliance with NIST 800-171’s NFO control requirements. Organizations that need to demonstrate full 800-171 compliance, for example, for contracts with non-DoD federal agencies, still need to address those requirements separately.

Why Did the DoD Create CMMC If NIST 800-171 Already Existed?

The self-attestation model failed. The DoD found consistent evidence that contractors were claiming NIST 800-171 compliance without implementing the required controls. Sensitive defense information was being exfiltrated through contractor networks, and the honor system that governed compliance verification had no enforcement mechanism.

CMMC was the DoD’s response: a structured certification process where compliance is verified by an independent third party before a contract is awarded. CMMC 2.0 was designed to balance security with compliance burden, which is why it consolidated the original five-level CMMC 1.0 framework into three levels and aligned more directly with existing NIST standards.

Insider Note: The False Claims Act exposure created by CMMC is not theoretical. If a senior official signs an annual affirmation confirming CMMC compliance status that turns out to be false, the organization and the individual can be held personally liable for treble damages, three times the government’s loss, plus significant civil penalties. This is a qualitative shift from the previous regime, where non-compliance had limited direct consequences.

Do You Need CMMC, NIST 800-171, or Both?

The answer depends on the type of data you handle and the agencies you contract with. If you work with the DoD and handle CUI, you need both. NIST 800-171 compliance is the technical baseline; CMMC certification is the verification requirement for DoD contracts. If you handle CUI for non-DoD federal agencies only, NIST 800-171 applies, but CMMC does not.

Subcontractors are not exempt. Prime contractors are required to flow down CMMC requirements to all suppliers handling FCI or CUI. The CMMC level required of a subcontractor is determined by the sensitivity of the data they process, not by their position in the supply chain. A small machine shop producing specialized components under a classified program may face the same Level 2 requirements as the prime.

If your organization is navigating multiple certification paths simultaneously, CMMC alongside SOC 2, for instance, it’s worth understanding how frameworks overlap before you invest in separate workstreams. Tools that automate evidence collection and control mapping across frameworks can significantly reduce duplication. Platforms like Drata are increasingly used by contractors managing simultaneous compliance programs, and a detailed Drata vs Vanta comparison can help you determine the right fit. If you want a broader view, you can also compare compliance tools across the major platforms before committing.

CMMC vs NIST 800-171 for Cloud Compliance

Both frameworks require that cloud services used to process, store, or transmit CUI meet Federal Risk and Authorization Management Program (FedRAMP) standards or provide equivalent protections. For NIST 800-171, that means FedRAMP Moderate at minimum. CMMC Level 2 carries the same standard. For Level 3, FedRAMP High authorization is typically required.

In practice, this means that contractors storing CUI in the cloud must use compliant platforms such as Microsoft 365 GCC High or an equivalent FedRAMP-authorized environment. Commercial Microsoft 365 and standard cloud storage solutions do not satisfy this requirement, regardless of how they are configured. This is one of the most commonly missed control areas during CMMC gap assessments, and remediating it frequently requires platform migration with significant lead time.

Time and Cost to Achieve CMMC vs NIST 800-171 Compliance

NIST 800-171 compliance, through self-assessment, can theoretically be completed in weeks for organizations with mature security programs. The practical challenge is that the self-assessment score only reflects what you document and certify to, not what an independent auditor would verify.

CMMC Level 2 certification is a different undertaking. Preparation typically takes 6 to 12 months from the start of remediation. Organizations beginning the process in 2025 should plan for late 2026 certification at the earliest. Those with existing ISO 27001 or SOC 2 frameworks can reduce that timeline by 4 to 6 months by leveraging overlapping evidence. Level 1 is faster, requiring 3 to 6 months for the 17 basic controls and the self-assessment process.

Cost varies significantly by organizational size and maturity. Small businesses with limited existing security infrastructure face the steepest climb. However, the cost of ineligibility for DoD contracts consistently exceeds the cost of compliance. The pool of compliant contractors in the DIB is expected to shrink as deadlines approach, which means certified organizations will see increased prime contractor interest.

How to Implement CMMC and NIST 800-171 Efficiently

The most efficient path is combined implementation. Because CMMC Level 2 is built on NIST 800-171 Rev. 2, organizations can treat NIST compliance and CMMC preparation as a single project rather than sequential initiatives. Start with a gap assessment against NIST SP 800-171 Rev. 2, produce an SSP and POA&M, begin remediation, and engage a C3PAO for a pre-assessment once major gaps are resolved.

Scope reduction is worth prioritizing early. Define the boundary of systems that touch FCI and CUI, and isolate those systems from the rest of your environment. Every asset removed from scope reduces the cost and complexity of the C3PAO assessment. For manufacturing environments with legacy equipment on the shop floor, this scoping exercise can be complex: CNC machines processing files that contain CUI are in scope, regardless of their age or operating system.

Build for continuous compliance rather than point-in-time certification. CMMC requires an annual affirmation of compliance status and will not remain valid if controls degrade. Organizations that implement monitoring, regular internal audits, and change management processes before their first assessment will find maintenance significantly less burdensome than those that treat certification as a one-time event.

Recent Updates to NIST 800-171 and CMMC You Should Know

NIST SP 800-171 Revision 3 was published in May 2024. It reduces top-level requirements from 110 to 97, adds three new control families (Planning, System and Services Acquisition, and Supply Chain Risk Management), introduces organizationally defined parameters for greater flexibility, and increases determination statements by 32 percent. CMMC Level 2 assessments currently continue to use Revision 2. The DoD has indicated it will transition through a separate rulemaking process.

The CMMC 2.0 final rule was published October 15, 2024, and took effect December 16, 2024. The 48 CFR acquisition rule, which allows CMMC requirements to be written into contracts, was finalized in November 2025. Phase 1 enforcement began November 10, 2025. Phase 2, requiring Level 2 third-party certifications on applicable contracts, is scheduled for March 2026. Phase 3 for Level 3 follows in March 2027, with full implementation across all relevant DoD contracts by March 2028.

Worth Knowing: Contractors aiming for DoD contracts in fiscal year 2027 need their remediation roadmaps active now. The average time from initial gap assessment to C3PAO certification is 12 to 24 months. Factor in C3PAO scheduling lead times, which are increasing as demand rises, and the window for comfortable preparation is already narrowing.

Ready to Start Your CMMC Compliance Journey?

Whether you’re mapping your first gap assessment or preparing for a C3PAO audit, the window for comfortable preparation is narrowing. If you want expert guidance on where to start, or how to accelerate a compliance program already in progress, contact us to discuss your specific situation. And if you’re managing parallel compliance obligations, our SOC 2 guide and broader SOC 2 resources can help you understand how those workstreams can share evidence and reduce duplication with your CMMC effort.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

What is the main difference between CMMC and NIST 800-171?

NIST 800-171 is a technical compliance standard verified through self-assessment. CMMC is an independent certification program that verifies compliance with those same controls before a DoD contract is awarded. CMMC adds mandatory third-party audits, a maturity model, and contract eligibility consequences that NIST 800-171 alone does not.

Yes. CMMC Level 2 directly maps to all 110 requirements in NIST SP 800-171 Revision 2. They are the same controls. The difference is that Level 2 requires independent verification of those controls by a C3PAO for most DoD contracts, whereas NIST 800-171 permits self-assessment.

If you are a DoD contractor handling CUI, yes. DFARS 252.204-7012 requires NIST 800-171 compliance independently of CMMC. CMMC adds the certification requirement for DoD contract award. Implementing NIST 800-171 is a prerequisite for CMMC Level 2 certification, so in practice, both requirements are addressed through a single implementation effort.

No. CMMC builds on NIST 800-171, it does not replace it. Both requirements coexist for DoD contractors. CMMC Level 2 uses NIST SP 800-171 Rev. 2 as its technical baseline and adds a formal verification layer on top.

As of April 2026- Not yet. CMMC Level 2 assessments continue to be conducted against Revision 2. The DoD has stated that the transition to Revision 3 will occur through a separate rulemaking process. Organizations should prepare against Rev. 2 for current CMMC purposes while monitoring DoD communications on the transition timeline.

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