The CIS Controls (Center for Internet Security Critical Security Controls) are a prioritized set of 18 defensive actions, organized into 153 safeguards, that any organization can use to harden its environment against common cyberattacks. They are maintained by the Center for Internet Security and cross-walked into nearly every major government framework, including the NIST Cybersecurity Framework and NIST SP 800-53.

This guide is written for security engineers, IT leads, virtual CISOs, and founders who need a defensible security program without a full GRC team. It covers what the CIS Controls require in 2026, the three Implementation Groups (IG1, IG2, IG3), the difference between the Controls and the Benchmarks, realistic cost ranges, and how the program maps to NIST, ISO 27001, and PCI DSS.

Most teams start with the CIS Controls because they are free, version-controlled, and prescriptive in a way NIST is not. NIST tells you what outcomes to achieve. The CIS Controls tell you what to configure, which logs to keep, and which assets to inventory first. Many programs use NIST CSF for governance and the CIS Controls for execution.

For broader framework context, see the NIST Cybersecurity Framework guide and the cybersecurity compliance guide.

What are the CIS Controls?

The CIS Critical Security Controls are a community-developed cybersecurity framework first published in 2008 (then called the SANS Top 20) and now in version 8.1 as of 2024. The Center for Internet Security took stewardship in 2015 and runs the consensus process that updates them every three to four years. The current count is 18 controls and 153 safeguards.

Each control covers one defensive domain: asset inventory, secure configuration, account management, vulnerability management, malware defense, audit logging, incident response, and so on. Each control contains a list of safeguards, the specific testable actions that implement it. A safeguard reads like a control statement from NIST SP 800-53, but shorter and more prescriptive.

The 18 controls in v8.1 are:

1. Inventory and Control of Enterprise Assets
2. Inventory and Control of Software Assets
3. Data Protection
4. Secure Configuration of Enterprise Assets and Software
5. Account Management
6. Access Control Management
7. Continuous Vulnerability Management
8. Audit Log Management
9. Email and Web Browser Protections
10. Malware Defenses
11. Data Recovery
12. Network Infrastructure Management
13. Network Monitoring and Defense
14. Security Awareness and Skills Training
15. Service Provider Management
16. Application Software Security
17. Incident Response Management
18. Penetration Testing

Controls 1 through 6 are the basic cyber hygiene controls. They cover roughly 80% of common attack paths according to the CIS community analysis published alongside v8. If you do nothing else, the first six controls move the needle the most.

The Controls are free to download. The Center for Internet Security distributes them as PDFs, Excel workbooks, and a navigator tool. There is no certification, no auditor, no badge. What exists instead is an extensive set of cross-walks: every safeguard maps to controls in NIST SP 800-53, NIST SP 800-171, the NIST Cybersecurity Framework, ISO/IEC 27001, and PCI DSS v4.0. That cross-walk is why the framework has stuck around for nearly two decades: it translates between the abstract frameworks auditors care about and the concrete work engineers actually do.

Why CIS Controls matter in 2026

The CIS Controls answer a question no other framework answers cleanly: given finite money and people, what should we do first?

NIST CSF tells you to "Identify, Protect, Detect, Respond, Recover" and leaves the prioritization to you. ISO 27001 gives you 93 Annex A controls and asks you to justify exclusions. The CIS Controls explicitly sequence the work into three Implementation Groups by company size and risk profile.

Three forces have pushed the CIS Controls deeper into mainstream compliance since 2022:

State data-protection laws referencing them. Multiple state laws now provide affirmative defense or safe harbor for breach litigation if a company implemented a recognized cybersecurity framework. The CIS Controls are explicitly named in laws including Ohio's Data Protection Act and Connecticut's Public Act 21-119.

Federal cross-walks. Defense contractors implementing NIST SP 800-171 for Controlled Unclassified Information commonly use the CIS Controls as the implementation layer. The 110 NIST 800-171 controls map directly onto roughly 130 CIS safeguards.

Insurance underwriter adoption. Cyber insurance carriers now require evidence of specific CIS safeguards (multi-factor authentication, endpoint detection and response, immutable backups) before binding coverage. Several major carriers publish CIS-aligned questionnaires pulled directly from the v8 safeguard list.

CISA also references the CIS Controls in its Cyber Performance Goals, particularly for small and mid-sized organizations that lack resources to build a custom control set from NIST 800-53.

CIS Controls v8 and v8.1 (what changed)

CIS Controls v8 was released in May 2021 and introduced the most significant restructuring in the framework's history. The control count dropped from 20 to 18, controls were reorganized around activities rather than asset types, and the Implementation Group system was formalized.

The major v7-to-v8 changes: v7 was implicitly on-premises, v8 treats cloud, mobile, and remote work as primary use cases. v7 had separate controls for "wireless access" and "boundary defense"; v8 consolidated these into broader categories such as Network Infrastructure Management. v7 had a basic/foundational/organizational tier system; v8 replaced it with IG1, IG2, IG3. The safeguard count went from 171 to 153 with significantly tighter wording.

v8.1, published in 2024, is a refinement release. It aligned terminology with the NIST Cybersecurity Framework 2.0 release, clarified ambiguous safeguard descriptions, and refreshed the mapping documents. Organizations on v8 do not need to re-implement anything to move to v8.1.

CIS Implementation Groups: IG1, IG2, IG3

The Implementation Groups are the single most useful organizing principle in the framework. They prevent the trap that every other prescriptive framework falls into: a one-size-fits-all list that exhausts small teams and underwhelms enterprise security programs.

IG1 is the floor. The CIS community calls it "essential cyber hygiene" and treats it as the minimum any organization should achieve, regardless of size. The 56 IG1 safeguards include maintaining an asset inventory, deploying MFA for administrative accounts, restoring from documented backups, and configuring browsers and email clients with security headers.

IG2 adds risk-management practices for companies processing regulated data or sensitive IP: centralized identity management, application allow-listing, audit log centralization, network segmentation. IG3 adds controls against sophisticated threat actors: red-team testing, application sandboxing, advanced authentication for privileged accounts, continuous adversary emulation.

The right answer for most organizations is to target IG1 fully in year one, IG2 in years two to three, and IG3 only if the threat model demands it. Companies that jump straight to IG3 typically half-implement IG1 and IG2 simultaneously, which is worse than fully implementing IG1 alone.

CIS Benchmarks vs CIS Controls

This is the most common point of confusion. They are different things designed to work together.

CIS Controls are the high-level program: 18 controls, 153 safeguards. They tell you what to do.

CIS Benchmarks are the low-level system configurations. 100+ benchmarks cover specific platforms: Windows Server 2022, Ubuntu 22.04, AWS Foundations, Microsoft 365, Kubernetes, Cisco IOS, and dozens more. Each is a hardening guide with hundreds of specific settings.

CIS Control 4 says "Secure Configuration of Enterprise Assets and Software." The corresponding Windows Server 2022 Benchmark spells out the exact registry keys, group policy objects, and audit settings that satisfy Control 4 on a Windows host. The Control names the goal; the Benchmark names the bits.

Most teams use both. The Controls drive the program-level conversation with leadership and auditors. The Benchmarks drive configuration management code in Terraform, Ansible, or Group Policy. CIS publishes Hardened Images on AWS, Azure, and Google Cloud Marketplaces that ship with the Benchmarks pre-applied.

The Benchmarks are free. Paid CIS SecureSuite membership ($2,500 to $52,500 annually) adds the CIS-CAT Pro automated assessment tool, customizable profiles, and the CIS WorkBench platform.

Mapping CIS Controls to NIST CSF, NIST 800-53, and ISO 27001

The CIS Controls explicitly map to every major framework. The mapping documents are free downloads.

To NIST Cybersecurity Framework. The 18 controls map to the six NIST CSF functions (Govern, Identify, Protect, Detect, Respond, Recover). Controls 1, 2, 3, 15 land in Identify. Controls 4 through 12 cover Protect. Controls 8, 13 cover Detect. Controls 17, 18 cover Respond and Recover.

To NIST SP 800-53. Every CIS safeguard maps to one or more controls in NIST SP 800-53 Rev 5. One CIS safeguard often satisfies parts of multiple 800-53 controls. Federal contractors and FedRAMP candidates use the cross-walk to demonstrate that a CIS-aligned program satisfies the relevant 800-53 baseline. See the NIST 800-53 controls guide.

To NIST SP 800-171. The 110 controls in NIST SP 800-171 Rev 3 governing Controlled Unclassified Information map to roughly 130 CIS safeguards. Many defense contractors implement against the CIS Controls operationally and use the mapping for CMMC assessments. See the NIST 800-171 compliance guide.

To ISO 27001 Annex A and PCI DSS. The 93 controls in ISO 27001:2022 Annex A map to the CIS safeguards with gaps in the governance areas where ISO 27001 requires formal ISMS documentation. See the ISO 27001 certification guide. For PCI DSS v4.0, mapping documents show roughly 95% safeguard coverage of the 12 PCI requirements.

CIS Controls cost and timeline

The CIS Controls cost nothing. The Controls, Benchmarks, navigator tool, and all mapping documents are free downloads. What costs money is implementation.

A realistic budget for a 100-person SaaS implementing IG1 in year one:

• Internal effort: 0.5 to 1.5 FTE over six months. Loaded cost roughly $80,000 to $250,000 depending on geography.
• Tooling gaps: $40,000 to $120,000 annually. Typical purchases: an asset inventory or attack surface management tool, an EDR platform, a SIEM, a vulnerability scanner, a backup verification tool.
• External help (optional): $20,000 to $80,000 for a vCISO or compliance consultancy to run the readiness assessment and policy set.
• CIS SecureSuite membership (optional): $2,500 to $52,500 annually for CIS-CAT Pro and customizable Benchmark profiles.

Total year-one cost for a 100-person SaaS targeting IG1: $140,000 to $500,000, with year-two operating cost typically 40-60% lower.

For an enterprise targeting IG3 across thousands of endpoints, costs scale into the millions and the timeline extends to 24-36 months. The dominant variable is environment heterogeneity.

Timeline for IG1:

• Months 1-2: Asset inventory baseline (Controls 1, 2). Cloud sprawl, shadow IT, and contractor devices typically account for 15-30% of the asset base nobody on the team knew about.
• Months 2-4: Identity and access (Controls 5, 6). MFA rollout, account lifecycle, privileged access.
• Months 3-5: Configuration and vulnerability management (Controls 4, 7). CIS Benchmarks applied here.
• Months 4-6: Logging, malware defense, backup (Controls 8, 10, 11).
• Month 6: Internal readiness assessment. Most teams reach 70-85% IG1 implementation by month six.

CIS Controls process: the 9-step rollout

There is no official CIS Controls implementation methodology, but the community has converged on a consistent rollout pattern:

Step 1. Pick the Implementation Group. IG1 for sub-100-employee organizations. IG2 for mid-market. IG3 only if the threat model demands it. Document the choice and the reasoning.

Step 2. Baseline inventory. Build an authoritative inventory of enterprise assets (Control 1) and software assets (Control 2) before anything else. Every later safeguard depends on knowing what exists. Manual spreadsheets become stale within weeks.

Step 3. Gap assessment. Score the current environment against the chosen Implementation Group's safeguards. CIS-CAT Pro automates much of this for the Benchmark side. The Control side typically requires interviews and document review.

Step 4. Prioritize. Sequence remaining gaps by risk reduction per dollar. Asset inventory and MFA come first; penetration testing and red-teaming come last. The CIS Community Defense Model v2.0 publishes data on which safeguards block the most ATT&CK techniques per safeguard implemented.

Step 5. Apply CIS Benchmarks. For each system class (Windows, Linux, AWS, M365), apply the corresponding CIS Benchmark configuration. Use CIS Hardened Images where available. Track exceptions in a documented control matrix.

Step 6. Build the evidence trail. Each safeguard needs documented evidence that it is operating: configuration state, vulnerability scan reports, access review records, training completion logs. Treat the evidence trail as a first-class deliverable.

Step 7. Internal validation. Run a self-assessment against the full Implementation Group. CIS-CAT Pro for technical safeguards; manual review for policy and process safeguards. Identify gaps and remediate before any external assessment.

Step 8. External validation (optional). Engage a vCISO firm, MSSP, or CMMC assessor to validate. The CIS Controls themselves do not certify, but implementation can be validated as part of a NIST CSF assessment, ISO 27001 internal audit, or CMMC assessment.

Step 9. Continuous improvement. Re-baseline annually. Re-apply Benchmarks after major OS or platform upgrades. The CIS Controls operate continuously, not as a one-time project.

CIS Controls for different organization types

Small SaaS (IG1). The 56 IG1 safeguards are tractable for a 10-50 employee SaaS company over six months. The dominant work is asset inventory, identity hygiene (SSO, MFA, joiner-mover-leaver process), and backup verification. Many founders fold the CIS Controls into their SOC 2 program because the IG1 safeguards substantially cover the SOC 2 Security Trust Services Criterion. See the build a compliance program guide for the integrated approach.

Mid-market (IG2). Companies in the 100-500 employee range typically need IG2 because enterprise buyers require it or regulatory pressure (HIPAA, GLBA) demands it. New work over IG1: centralized log management, network segmentation, application allow-listing, and formal vendor management. Budget 12-18 months on top of IG1.

Defense contractors and CUI handlers. Companies in the Defense Industrial Base typically use the CIS Controls as the day-to-day operational framework and the NIST SP 800-171 control set as the assessment framework. The two map well, and CMMC assessors are familiar with this pattern. See the NIST 800-171 compliance guide for the CMMC mechanics.

Public companies and critical infrastructure. SOX-regulated public companies wrap the CIS Controls around their IT general controls; the safeguards covering access management, change control, and audit logging map into SOX ITGC families. Energy, water, and transportation operators align CIS alongside sector-specific requirements such as NERC CIP. CISA references the CIS Controls as a recommended baseline for state, local, tribal, and territorial governments and small critical infrastructure operators.

Common pitfalls (and how to avoid them)

Starting with the Benchmarks instead of the Controls. Engineering teams love the Benchmarks because they are concrete. But applying Windows hardening before you have an asset inventory leaves you hardening the wrong systems. Always start with Controls 1 and 2.

Skipping IG1 to chase IG2 or IG3. Half-implementing IG1 while picking favorite safeguards from IG2 produces a Swiss-cheese program that looks comprehensive on paper but fails under audit. Complete IG1 first.

Treating the framework as a checklist. The CIS Controls are continuous operating practices, not project deliverables. A safeguard that says "establish and maintain" requires ongoing operation. Auditors and breach litigants look for evidence of continuous operation.

Ignoring the cross-walk. Many programs implement the CIS Controls and then re-implement NIST CSF separately, doing the same work twice. The cross-walk documents are free. Use them to demonstrate one implementation against multiple frameworks.

Manual evidence collection. Programs that ship screenshots quarterly spend 3-5x more effort than programs that pipe configuration state and access reviews automatically into a GRC platform.

Tools and platforms for CIS Controls implementation

The tooling landscape is fragmented because the safeguards span identity, endpoint, network, cloud, and application domains. No single tool covers everything. A typical IG2 program touches 8-15 distinct tools.

Smaller organizations sometimes consolidate by selecting an MSSP that bundles asset discovery, EDR, SIEM, and vulnerability management under one contract. The trade-off is reduced visibility for lower headcount.

Frequently Asked Questions

What is a CIS control?

A CIS control is one of the 18 prioritized defensive activities published by the Center for Internet Security. Each control covers a defensive domain (asset inventory, access control, logging, incident response) and contains specific safeguards. v8.1 has 18 controls and 153 safeguards covering the major attack paths identified in the NIST Cybersecurity Framework.

What are the CIS top 20 controls?

The "top 20" name refers to v7 and earlier. v8 consolidated related controls into broader categories, dropping the count to 18. Articles referencing "CIS top 20" are using v7 terminology. The current list is the 18 controls in v8.1, organized into Implementation Groups IG1, IG2, and IG3.

What is the difference between CIS and NIST controls?

The CIS Controls are a prioritized list of 18 prescriptive defensive activities aimed at organizations of any size. The NIST Cybersecurity Framework and NIST SP 800-53 are broader frameworks aimed primarily at federal agencies and contractors. They are designed to coexist: NIST CSF for governance, the CIS Controls for prioritized execution, NIST 800-53 as the detailed control catalog.

What are the CIS 18 controls?

The 18 controls in v8.1 are: Inventory and Control of Enterprise Assets, Inventory and Control of Software Assets, Data Protection, Secure Configuration, Account Management, Access Control Management, Continuous Vulnerability Management, Audit Log Management, Email and Web Browser Protections, Malware Defenses, Data Recovery, Network Infrastructure Management, Network Monitoring and Defense, Security Awareness Training, Service Provider Management, Application Software Security, Incident Response Management, and Penetration Testing.

Are the CIS Controls free, and is there a certification?

The Controls, Benchmarks, navigator, and all mapping documents are free downloads. CIS SecureSuite membership ($2,500 to $52,500 annually) adds CIS-CAT Pro automated assessment and customizable Benchmark profiles. There is no formal CIS certification: no auditor, no badge. Organizations validate through internal assessment, third-party consulting, or by mapping CIS to a framework that does certify (ISO 27001 or CMMC).

How long does CIS Controls implementation take?

For a sub-100-employee organization targeting IG1, six months is realistic with a half-FTE to full-FTE of effort. For mid-market targeting IG2, plan 12-18 months on top of IG1. For enterprise IG3, expect 24-36 months. The dominant variable is environment heterogeneity, not headcount.

Bottom line

The CIS Controls are the most practical cybersecurity framework available in 2026. They prioritize the work, scope it by organization size, map cleanly to every other major framework, and cost nothing to adopt. For most organizations under 500 employees, they are the right starting point, with NIST CSF for governance reporting and ISO 27001 or SOC 2 for external attestation when buyers demand it.

The companies that get the most out of the framework treat it as a continuous operating practice. They start with asset inventory and identity, apply the Benchmarks through configuration management code, and automate evidence collection from day one. The companies that struggle treat it as a checklist, skip IG1, and end up with partial implementations across multiple groups.

For broader context, see the cybersecurity compliance guide, build a compliance program guide, and the cybersecurity compliance checklist.

Primary Sources

This article references the following authoritative sources:

• NIST Cybersecurity Framework. NIST CSF 2.0 (cross-walks to CIS Controls)
• NIST SP 800-53 Rev 5. Security and Privacy Controls (CIS safeguard mapping target)
• NIST SP 800-171 Rev 3. Controlled Unclassified Information (CIS cross-walk for defense contractors)
• NIST Computer Security Resource Center. Publications and glossary referenced throughout
• CISA. Cybersecurity and Infrastructure Security Agency (references CIS Controls in Cyber Performance Goals)
• ISO/IEC 27001. Information security management system standard (CIS Annex A mapping)
• NIST SP 800-207 Zero Trust Architecture. Architecture model referenced by CIS Controls cloud safeguards

FedRAMP compliance is the body of security, assessment, and continuous monitoring obligations imposed by the Federal Risk and Authorization Management Program on any cloud service offering used by a U.S. federal agency. It is the single largest cloud security regime in the United States, and after the FedRAMP Authorization Act of 2022 it is codified into federal law.

This guide is written for cloud product leaders, SaaS founders selling into government, security engineers, and compliance directors building a FedRAMP program. It covers what FedRAMP requires in 2026, the three impact baselines, the two authorization pathways, how a Third Party Assessment Organization (3PAO) actually tests you, the real cost and timeline, what continuous monitoring looks like after authorization, and how the FedRAMP Marketplace works for buyers.

This is the pillar guide. For tighter answers on cost, timeline, and the four-step process, see our companion FedRAMP authorization FAQ. Most companies underestimate the lift. FedRAMP is a continuous control environment with monthly scans, annual reassessments, and a public marketplace listing your status to every agency in the country.

For deeper companion pieces, see NIST 800-53, NIST 800-171, CMMC, and SOC 2.

What is FedRAMP compliance?

FedRAMP is the U.S. government program that standardizes how cloud products and services are security-assessed, authorized, and continuously monitored for federal use. It was established by Office of Management and Budget memorandum M-11-08 in December 2011 and is operated jointly by the General Services Administration, the Department of Defense, the Department of Homeland Security, and the FedRAMP Program Management Office (PMO).

The core promise is "do once, use many times." Instead of every federal agency separately assessing the same cloud service, a single FedRAMP authorization can be reused by every agency that wants to consume that service. This is what makes a single authorization commercially valuable: it unlocks the entire federal market rather than one contract.

FedRAMP applies to any cloud service offering (CSO) that processes, stores, or transmits federal information. Software as a Service, Platform as a Service, and Infrastructure as a Service all fall in scope. On-premises software delivered as a perpetual license to a single agency typically does not. The cloud delivery model is the trigger.

The legal foundation changed in 2022. Congress passed the FedRAMP Authorization Act as Title LIX of the FY2023 National Defense Authorization Act, signed into law in December 2022. The Act codified the program into statute, established a Federal Secure Cloud Advisory Committee, required automation where feasible, and directed GSA to publish a presumption of adequacy for authorizations across agencies.

Who FedRAMP covers

FedRAMP covers three categories of organization:

• Cloud service providers (CSPs). Any company offering a cloud product or service that a federal agency wants to consume. The CSP pursues authorization, builds the system security plan, and pays for the 3PAO assessment.
• Federal agencies. Civilian, defense, and independent agencies acquiring cloud services. The agency either sponsors a new authorization or reuses an existing one.
• Third Party Assessment Organizations (3PAOs). Independent assessors accredited by A2LA under the FedRAMP 3PAO Requirements. The 3PAO performs the security assessment and issues the Security Assessment Report (SAR).

Resellers and integrators that handle federal data inside a CSP's environment are covered by the CSP's authorization. Subcontractors that operate their own systems may need their own FedRAMP coverage.

What FedRAMP compliance covers

FedRAMP compliance is built on three pillars: a security control baseline, an independent assessment, and ongoing continuous monitoring.

The control baseline is derived from NIST SP 800-53 Rev 5, the federal catalog of security and privacy controls. FedRAMP selects a subset of those controls for each impact level and tightens many of the parameters. A control like AC-2 (Account Management) exists in NIST 800-53 in generic form; the FedRAMP baseline specifies the audit frequency, the maximum account inactivity period, and the documentation requirements that agencies expect.

The assessment is performed by a 3PAO against the NIST Risk Management Framework, defined in NIST SP 800-37 Rev 2. The RMF has seven steps (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor). FedRAMP is the RMF applied to commercial cloud.

Continuous monitoring is the operational discipline after authorization: monthly vulnerability scans, monthly Plan of Action and Milestones (POA&M) updates, annual penetration tests, and significant change requests for major architectural changes.

FedRAMP impact baselines: Low, Moderate, High

FedRAMP uses three baselines that map to the FIPS 199 categorization of federal information. The baseline depends on the worst-case impact (confidentiality, integrity, or availability) of a security breach on the system.

The "Low Impact SaaS" or LI-SaaS baseline is a streamlined Low variant for simple SaaS products that do not store agency data beyond user credentials and basic configuration. It is the lightest entry point into FedRAMP.

The mapping to FIPS 199 is the gating decision. If any of the three security objectives (confidentiality, integrity, availability) is High, the system is High. If the worst is Moderate, the system is Moderate. Agencies sometimes ask a CSP to authorize at a higher baseline than the data alone would require, to keep the option to expand usage later. Roughly 80% of FedRAMP authorizations sit at Moderate, which is why most budgets and timelines in this guide use Moderate as the default reference.

The 3PAO: what an assessment actually looks like

A Third Party Assessment Organization is an independent firm accredited by A2LA to perform FedRAMP security assessments. The CSP selects and pays the 3PAO directly. The 3PAO is not chosen by the agency.

What the 3PAO does:

1. Readiness Assessment. Optional but recommended. The 3PAO walks the environment, reviews documentation, and issues a Readiness Assessment Report (RAR). A passing RAR earns the CSP a FedRAMP Ready designation, listed publicly on the Marketplace.
2. Security Assessment Plan (SAP). Before testing begins, the 3PAO publishes the scope, schedule, and test procedures, approved by the CSP and authorizing official.
3. Full Security Assessment. The 3PAO tests every control in the baseline through documentation review, staff interviews, configuration inspection, automated scanning, and authenticated penetration testing of the boundary.
4. Security Assessment Report (SAR). Findings are categorized as Critical, High, Moderate, or Low. Critical and High findings typically must be remediated before authorization. Moderate and Low findings can be carried as POA&M items.
5. Annual reassessment. Each year the 3PAO re-tests a subset of controls and validates significant changes.

The 3PAO market is small. As of 2026 the FedRAMP Marketplace lists fewer than 50 accredited 3PAOs. Pricing for a Moderate baseline full assessment typically falls between $150,000 and $400,000 depending on system complexity and whether the firm also performs the readiness assessment. Ask for references from CSPs with comparable infrastructure before signing.

The two authorization pathways: JAB P-ATO vs Agency ATO

FedRAMP offers two ways to reach authorization. The security work is identical. The difference is who reviews the package and how broadly it is trusted.

JAB Provisional Authorization (P-ATO)

The Joint Authorization Board is composed of the CIOs of the General Services Administration, the Department of Defense, and the Department of Homeland Security. A JAB P-ATO is the closest thing FedRAMP has to a gold standard.

Strengths:

• Highest cross-agency credibility. A JAB P-ATO carries a strong presumption of adequacy.
• Most efficient for CSPs targeting broad federal demand. A single P-ATO can be reused by every agency.
• The most rigorous review process, which is itself a marketing asset.

Constraints:

• The JAB is selective. It runs a connect process called FedRAMP Connect and prioritizes CSOs with broad demand signals from multiple agencies.
• Timelines are longer. Twelve to eighteen months for Moderate is typical, with some High systems running longer.
• Requires FedRAMP Ready designation as a prerequisite.

The JAB selects a limited number of CSPs each cycle. If selected, the CSP works against a shared schedule, with reviews by the JAB technical representatives in parallel.

Agency Authorization (Agency ATO)

In the Agency path, a specific federal agency sponsors the authorization. The agency's Authorizing Official (AO) reviews the package and issues the Authority to Operate. The FedRAMP PMO then performs a separate review before the CSO is listed on the Marketplace as Authorized.

Strengths:

• Faster than JAB. Six to twelve months for Moderate is realistic when the CSP and agency are aligned.
• Works for any CSP that already has a federal customer or pending contract.
• More flexibility on control interpretation, because a single AO is making the risk decision.

Constraints:

• Requires an agency sponsor. Without a federal customer willing to be the AO, the Agency path is not available.
• Cross-agency reuse depends on the FedRAMP Marketplace listing and any agency-to-agency briefings.
• Historically perceived (sometimes unfairly) as less rigorous than JAB. The 2024 program modernization changes reduced this perception by tightening PMO review of agency packages.

For most CSPs in 2026, the Agency path is the realistic default. The JAB path is appropriate when broad federal demand is already established and the CSP wants the JAB stamp as a competitive moat.

After the FedRAMP Authorization Act of 2022, Congress directed the program to publish a presumption of adequacy. The practical effect is that a Marketplace-listed authorization from either path now carries similar legal weight when an agency consumes the service.

FedRAMP Ready: the entry milestone

FedRAMP Ready is a milestone, not a final authorization. A CSP earns Ready by engaging an accredited 3PAO, completing a Readiness Assessment, receiving a passing RAR, and submitting it to the FedRAMP PMO for review.

Once accepted, the CSP is listed on the FedRAMP Marketplace with a Ready designation. Ready signals to agencies that the CSP is assessment-ready, is a prerequisite for JAB FedRAMP Connect selection, and is a marketing milestone federal sales teams can quote to procurement.

Ready is not the same as Authorized. A CSP can be Ready but still need 6 to 18 months of additional work to reach In Process and then Authorized. Agencies cannot consume a Ready-only service for production federal data, although they can engage commercially and run pilots in non-production environments.

Timeline and cost

A first-time FedRAMP Moderate authorization for a mid-sized SaaS company runs 12 to 24 months end to end:

• Months 1 to 4: Preparation. Gap assessment, boundary definition, SSP development, control implementation, evidence gathering.
• Months 4 to 8: Readiness. 3PAO Readiness Assessment, RAR submission, PMO review for the Ready designation.
• Months 8 to 14: Full Assessment. 3PAO full assessment, remediation of Critical and High findings, POA&M development, SAR finalization.
• Months 14 to 18: Authorization. Submit the package to JAB or sponsoring agency, address review questions, receive authorization.
• Months 18 onward: Continuous monitoring. Monthly scans, monthly POA&M updates, annual reassessment.

Costs for a Moderate baseline in 2026 typically fall in the ranges below. LI-SaaS programs land at the low end; complex multi-cloud or High baselines run two to three times higher.

Two factors swing the budget more than anything else. The first is boundary scope: a tightly scoped boundary with a single data plane is fundamentally cheaper than one that pulls in marketing systems, support tooling, and corporate IT. The second is the underlying infrastructure. A SaaS built on AWS GovCloud or Azure Government inherits hundreds of authorized controls; a SaaS on a custom data center or commercial-cloud-only stack inherits none. For most CSPs, a single agency contract typically covers the initial investment within the first year.

Continuous monitoring

Authorization is the start of the operational program, not the end. Continuous monitoring (ConMon) is the discipline that keeps the authorization valid year over year.

The core ConMon obligations:

• Monthly vulnerability scans. Authenticated scans of operating systems, web applications, and databases inside the boundary. Findings must be reported to the authorizing official within the timelines specified by FedRAMP guidance (typically 30 days for High severity findings, 90 days for Moderate, 180 days for Low).
• Monthly Plan of Action and Milestones updates. The POA&M is the living register of all open findings, with target remediation dates, status, and risk acceptance documentation where applicable.
• Annual penetration testing. Performed by the 3PAO using attack vectors specified in FedRAMP Penetration Test Guidance.
• Annual security assessment. The 3PAO re-tests a subset of controls each year, with the full set re-tested over a three-year rolling window.
• Significant change requests. Any architectural change above the threshold (new data flow, sub-service, region, or major component upgrade) requires approval before deployment.
• Incident reporting. Reportable incidents go to US-CERT and the authorizing agency within timelines defined by CISA Cyber Incident Reporting guidance.

ConMon is where many programs lose momentum. The first six months after authorization often go well. By month twelve, the scan cadence and POA&M discipline can erode if the program is treated as a project rather than an operating function. CSPs that maintain authorization cleanly staff ConMon as a continuous capability.

The FedRAMP Marketplace

The FedRAMP Marketplace is the public directory of every cloud service offering at every status: In Process, Ready, Authorized, and (when applicable) decommissioned. It is the central source of truth for agencies, integrators, and procurement officials.

Each listing shows the CSP and CSO name, impact level, authorization path (JAB or Agency, with sponsoring agency named), current status, agency reuses, the assessing 3PAO, and authorization date.

Agencies use the Marketplace as a procurement filter. When a federal acquisition includes a cloud component, contracting officers are directed to start with Marketplace-Authorized services. The 2022 Act's presumption of adequacy reinforced this default. For CSPs, the listing is the highest-value federal sales artifact: status badge, agency reuse counter, and authorization date signal credibility no slide deck can match.

The FedRAMP Authorization Act of 2022 and the 2024 modernization

The FedRAMP Authorization Act of 2022 was the most significant statutory change to the program since its 2011 launch. The headline changes:

• Codification. FedRAMP is now a creature of statute, not just OMB policy. This makes the program harder to roll back and gives agencies firmer legal grounding to rely on authorizations.
• Presumption of adequacy. Agencies must accept a FedRAMP authorization unless they document a specific reason it is insufficient for their use case.
• Federal Secure Cloud Advisory Committee. A statutory advisory body with industry, agency, and assessor representation to advise the GSA Administrator.
• Automation mandate. GSA was directed to automate the security assessment, authorization, and continuous monitoring process where feasible. The OSCAL (Open Security Controls Assessment Language) effort accelerated under this mandate.

The 2024 modernization that followed brought several operational changes. Rev 5 of NIST SP 800-53 became the baseline for all new authorizations, with existing CSPs working through Rev 4 to Rev 5 transition plans. PMO review of Agency packages was tightened, narrowing the historical perception gap between JAB and Agency authorizations. The Marketplace UI was updated to surface reuse data and authorization age more prominently.

For new CSPs in 2026, the practical implication is that the JAB versus Agency choice matters less than it did in 2020. Agency ATO trustworthiness has converged toward JAB levels, and the FedRAMP brand sits on the Marketplace listing more than on the specific path that produced it.

How FedRAMP connects to other frameworks

FedRAMP does not exist in isolation. Programs operating under adjacent frameworks share substantial control overlap.

• NIST 800-53. The direct source of every FedRAMP control. A mature 800-53 program has done the heaviest lifting.
• NIST 800-171. A subset of 800-53 covering Controlled Unclassified Information. The 110 controls map cleanly into FedRAMP Moderate.
• CMMC. DoD's contractor model, built on 800-171. CMMC Level 2 shares most controls with FedRAMP Moderate.
• NIST Cybersecurity Framework. A higher-level governance frame. Identify, Protect, Detect, Respond, Recover maps cleanly to FedRAMP control families.
• SOC 2. A commercial AICPA assurance report. A Type 2 demonstrates many of the operational controls FedRAMP requires, but evidence sets are not interchangeable.
• Cybersecurity compliance more broadly. For a survey alongside HIPAA, PCI DSS, and ISO 27001.

For tighter answers on the four-step process and per-baseline costs, see the companion FedRAMP authorization guide.

Frequently Asked Questions

What is FedRAMP compliance?

FedRAMP compliance is the body of security, assessment, and continuous monitoring requirements imposed by the Federal Risk and Authorization Management Program on any cloud service used by a U.S. federal agency. The baseline is drawn from NIST SP 800-53 Rev 5. Authorization is granted by either the Joint Authorization Board or a sponsoring agency.

What are the FedRAMP impact baselines?

FedRAMP has three baselines aligned to FIPS 199: Low (about 156 controls, including the LI-SaaS variant), Moderate (about 325 controls, covering most CUI and PII), and High (about 421 controls, covering law enforcement and systems where breach impact is severe or catastrophic). Roughly 80% of authorizations are at Moderate.

What is a 3PAO?

A 3PAO is a Third Party Assessment Organization, an independent firm accredited by A2LA. The 3PAO performs the Readiness Assessment, the full Security Assessment, the annual reassessment, and the annual penetration test. It is selected and paid by the cloud service provider, not the government.

What is the difference between JAB P-ATO and Agency ATO?

A JAB Provisional Authorization is issued by the Joint Authorization Board (CIOs of GSA, DoD, and DHS). An Agency Authorization is issued by a single sponsoring agency's Authorizing Official with PMO review. The security work is identical. JAB carries the strongest cross-agency presumption but is selective and slower; Agency is the default for most CSPs in 2026.

How long does FedRAMP authorization take?

Twelve to twenty-four months end to end for a first-time Moderate. The JAB path typically runs 12 to 18 months from selection. The Agency path can run 6 to 12 months once a sponsor is in place.

How much does FedRAMP authorization cost?

Year-one budgets for a Moderate authorization typically range from about $925,000 to $2.9 million. Year-two and ongoing budgets settle to $625,000 to $2 million per year. LI-SaaS lands at the low end; High and complex multi-cloud architectures at the high end.

What changed with the FedRAMP Authorization Act of 2022?

The Act codified FedRAMP into statute as Title LIX of the FY2023 NDAA, established a presumption of adequacy across agencies, created the Federal Secure Cloud Advisory Committee, and directed GSA to automate authorization workflows. The 2024 modernization brought Rev 5 baselines, tighter PMO review of Agency packages, and an updated Marketplace.

Bottom line

FedRAMP is the cost of entry to the U.S. federal cloud market, and after the 2022 Authorization Act it is statutory. Companies that succeed treat it as an operating program, not a one-time audit: tight boundary, a 3PAO experienced in their architecture, Agency path by default, and continuous monitoring staffed as a steady-state function.

For most cloud companies, a single federal contract pays back the initial investment inside the first year. The moat compounds from there: every agency reuse, every renewed authorization, and every Marketplace update makes the next federal sale faster.

Primary Sources

This article references the following authoritative sources:

• FedRAMP official site. The Federal Risk and Authorization Management Program
• FedRAMP program basics. Pathways, baselines, and process overview
• FedRAMP Marketplace. Authorized, In Process, and Ready cloud service offerings
• GSA FedRAMP page. Program governance and policy
• FedRAMP Authorization Act of 2022. Statutory codification (Title LIX of the FY2023 NDAA)
• NIST SP 800-53 Rev 5. Security and privacy controls catalog
• NIST Risk Management Framework (SP 800-37 Rev 2). The RMF that underpins FedRAMP
• NIST SP 800-171 Rev 3. Controlled Unclassified Information in non-federal systems
• FIPS Publication 199. Standards for Security Categorization of Federal Information and Information Systems
• CISA Cyber Incident Reporting. Federal incident reporting guidance
• NIST Cybersecurity Framework. Cross-cutting governance framework

GLBA compliance is the set of privacy, safeguards, and customer notice obligations imposed by the Gramm-Leach-Bliley Act of 1999 on any company that is a "financial institution" under federal law. It governs how your business collects, protects, and shares nonpublic personal information about consumers, and the Federal Trade Commission enforces it for most non-bank financial institutions.

This guide is written for fintech founders, mortgage and lending operators, tax preparers, investment advisers, and the IT and compliance leads who report to them. It covers what GLBA requires in 2026 after the FTC's 2023 Safeguards Rule amendments, who counts as a "financial institution", the two operative rules (Safeguards and Privacy), how GLBA maps to other privacy laws, and what enforcement looks like.

Most teams underestimate the scope. GLBA predates every state privacy law on the books and is one of the few federal privacy regimes with a concrete security mandate in the statute. If you handle financial information about U.S. consumers, GLBA almost certainly applies, even if you do not think of yourself as a "bank".

For the security deep dive, see the cybersecurity compliance guide and the NIST Cybersecurity Framework guide. For a wider fintech regulatory map, see fintech compliance requirements. For breach funding, see cyber insurance requirements. For program design that holds GLBA, SOX, and SOC 2 together, see how to build a compliance program.

What is GLBA compliance?

GLBA is short for the Gramm-Leach-Bliley Act, also known as the Financial Services Modernization Act of 1999. Congress passed it primarily to repeal the 1933 Glass-Steagall separation of commercial banking from investment banking and insurance. Title V was added to address the privacy concerns of letting banks, brokers, and insurers merge.

Title V of GLBA produced three operative obligations for financial institutions:

• The Financial Privacy Rule (15 U.S.C. 6801-6803). Customers receive a clear notice of what information you collect, who you share it with, and an opportunity to opt out of certain sharing with nonaffiliated third parties.
• The Safeguards Rule (15 U.S.C. 6801(b), implemented at 16 CFR Part 314). Every covered financial institution must develop, implement, and maintain a written information security program containing administrative, technical, and physical safeguards appropriate to its size, complexity, and the sensitivity of customer information.
• The Pretexting Provisions (15 U.S.C. 6821-6827). Prohibits the use of false or fraudulent statements to obtain customer financial information from a financial institution.

Enforcement is split by institution type. The FTC covers non-bank financial institutions (most fintechs, mortgage brokers, payday lenders, tax preparers, debt collectors). The Consumer Financial Protection Bureau enforces certain GLBA-related rules within its jurisdiction. The federal banking regulators (the Federal Reserve, OCC, FDIC, and NCUA) cover the depository institutions they supervise. The SEC enforces it for registered broker-dealers, investment companies, and investment advisers under Regulation S-P.

GLBA is not a certification. There is no "GLBA certified" stamp. What exists is your written information security program, privacy notice, opt-out records, and the audit trail your regulator examines if it comes calling.

Who this matters for in 2026

GLBA matters because the federal definition of "financial institution" is broader than common usage suggests. The statute covers any institution "the business of which is engaging in financial activities" as defined in section 4(k) of the Bank Holding Company Act of 1956. The FTC's Safeguards Rule, at 16 CFR 314.2(h), explicitly names:

• Mortgage brokers, lenders, and servicers
• Payday lenders, check cashers, and currency exchanges
• Finance companies and account servicers
• Personal property and real estate appraisers
• Tax preparation firms
• Non-federally insured credit unions
• Investment advisers not required to register with the SEC
• Real estate settlement services companies
• Wire transfer providers
• Some debt collection businesses (collecting on debts they extend)
• Higher-education institutions in Title IV federal student aid (via Department of Education rules)

Three forces have changed the GLBA landscape since 2020:

The 2023 FTC Safeguards Rule amendments. The FTC adopted significant amendments in October 2021, and most provisions took effect on June 9, 2023. The amendments added nine specific elements to the previously high-level security program requirement: a designated Qualified Individual, written risk assessments, access controls, encryption in transit and at rest, MFA, secure disposal, change management, monitoring, and an incident response plan. See the FTC's press release on the final rule and the updated compliance resource.

The 2023 breach notification amendment. A further FTC amendment now requires non-bank financial institutions to notify the FTC of any "notification event" involving the unencrypted customer information of 500 or more consumers, no later than 30 days after discovery. The rule took effect May 13, 2024.

State privacy law overlap. California, Virginia, Colorado, Texas, and a growing list of other states now have comprehensive privacy laws. Most exempt data subject to GLBA, but the exemptions are entity-level in some states and information-level in others. Which data sits under GLBA versus CCPA is now part of every fintech privacy program. See our CCPA compliance guide and GDPR compliance for US companies.

The two rules: Privacy Rule vs Safeguards Rule

People conflate these constantly. They are different rules, with different mechanics, different deadlines, and (for non-banks) different parts of the FTC's regulatory book.

The Privacy Rule is the older, lower-volume workstream. You write a notice, give customers an opt-out for sharing with nonaffiliated third parties (with some exceptions), keep records, and reissue the notice when sharing practices change. The CFPB version, Regulation P at 12 CFR Part 1016, is the operative rule for most CFPB-supervised institutions and tracks the FTC's Part 313.

The Safeguards Rule is where the volume of work lives in 2026.

The 2023 FTC Safeguards Rule: nine required elements

The current Safeguards Rule, in 16 CFR 314.4, requires every covered financial institution (except those with information on fewer than 5,000 consumers, which receive a partial exemption) to develop, implement, and maintain a written information security program with the following elements. These are the nine elements every GLBA program now has to deliver.

1. Designate a Qualified Individual. One accountable person responsible for overseeing the program. The role can be staffed in-house or by an affiliate or service provider, but accountability stays with the institution.

2. Conduct a written risk assessment. Periodic written identification of reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of customer information, with criteria for evaluating those risks and the sufficiency of safeguards.

3. Design safeguards to control identified risks. Implement the controls the risk assessment indicates are appropriate. The rule names the safeguard families:

• Access controls, including periodic review of user privileges
• Identification and inventory of data, personnel, devices, systems, and facilities
• Encryption of customer information in transit over external networks and at rest (substitute controls allowed where encryption is infeasible)
• Secure development practices for in-house applications
• Multi-factor authentication for any individual accessing any information system
• Secure disposal of customer information no later than two years after last use, with documented exceptions
• Change management procedures
• Monitoring and logging of authorized user activity and detection of unauthorized access

4. Regularly test or monitor the effectiveness of safeguards. Either continuous monitoring, or annual penetration testing plus vulnerability assessments at least every six months. The FTC accepts continuous monitoring in lieu of the pen test plus scans, but if you do not run continuous monitoring you must run both.

5. Train staff and contractors. Security awareness training, plus verification that staff with significant security responsibilities are maintaining current knowledge of changing threats and countermeasures.

6. Oversee service providers. Select providers capable of maintaining appropriate safeguards, require those safeguards by contract, and periodically reassess them based on the risk they present.

7. Evaluate and adjust the program. In light of testing and monitoring results, material changes to operations or business arrangements, and any other circumstances with a material impact on the program.

8. Establish a written incident response plan. Covering goals, internal response processes, roles and decision-making authority, internal and external communications, remediation of weaknesses, documentation, and post-incident evaluation and revision.

9. Annual written report to the board. The Qualified Individual reports at least annually on the overall status of the program and the institution's compliance with the rule, including risk assessment results, service provider arrangements, testing outcomes, security events, and recommended changes.

The 5,000-consumer threshold matters. Institutions below that line are exempt from the written risk assessment, the monitoring/pen-test requirement, the written IR plan, and the annual board report. Everything else still applies.

For mapping these controls into a broader program, see the NIST Cybersecurity Framework guide. NIST CSF's Identify, Protect, Detect, Respond, and Recover functions map cleanly to the nine Safeguards Rule elements, and most mid-market institutions design against NIST CSF with the GLBA-specific elements riding on top.

What counts as "customer information" and "nonpublic personal information"

GLBA protects "nonpublic personal information" (NPI) about a "consumer" or "customer". The definitions decide what falls inside the WISP and the notice obligations.

Nonpublic personal information is personally identifiable financial information provided by a consumer, resulting from a transaction, or otherwise obtained by the institution. It also includes any list or grouping of consumers derived using NPI that is not publicly available.

Consumer is an individual who obtains a financial product or service for personal, family, or household purposes. Customer is a consumer with a continuing relationship. Privacy notices are triggered by customer relationships, not every consumer interaction.

The practical result: data about a small-business borrower is generally not GLBA-protected, but data about an individual who applies for a personal loan, files a tax return, or opens a brokerage account is.

GLBA penalties and enforcement

GLBA does not contain a single statutory civil penalty amount. Enforcement happens through the existing authorities of the supervising agency. For non-bank institutions enforced by the FTC, violations are typically charged as unfair or deceptive acts or practices under Section 5 of the FTC Act. Civil penalties can reach $51,744 per violation under inflation-adjusted amounts, with each affected consumer or each day of violation often counted separately.

Recent FTC actions show what real penalties look like. The FTC's data security enforcement page catalogues cases where mortgage analytics firms, tax preparers, and online lenders faced multi-million dollar settlements and 20-year compliance monitoring requirements after Safeguards Rule failures. The pattern is consistent: monetary penalty, injunction, and mandatory third-party security assessments every two years for 20 years.

For SEC-registered institutions, GLBA violations are charged under Regulation S-P. The 2024 Reg S-P amendments (30-day breach notification, expanded coverage to transfer agents) signal a more aggressive posture.

Criminal penalties exist but are rare. The pretexting provisions at 15 U.S.C. 6823 make it a federal crime to obtain customer financial information through false pretenses, with penalties up to five years' imprisonment, or ten years if part of a pattern involving more than $100,000 in any 12-month period.

State AGs have concurrent enforcement authority in some states and tend to be more active than the FTC on small to mid-sized institutions. New York's DFS has its own cybersecurity regulation (23 NYCRR 500) that overlaps heavily with the Safeguards Rule.

GLBA vs other privacy laws

The overlap with other U.S. privacy laws is one of the most underappreciated dimensions of running a financial institution in 2026.

The CCPA interaction is the most operationally important. California treats the GLBA exemption as information-level, not entity-level. A fintech holding NPI under GLBA still has to honor CCPA rights for the marketing and behavioral data it collects on the same consumer outside GLBA scope. The cleanest fix is two parallel data inventories with field-level classification at ingestion.

GLBA compliance for different organization types

Fintech startups. Year one of a fintech almost always misses GLBA. The team focuses on the product, regulatory advisors focus on lending licensing or money transmission, and Title V gets noticed when an enterprise partner asks for a Safeguards Rule attestation. Write the WISP early, designate the Qualified Individual at hiring time, and treat GLBA as the security floor that SOC 2, ISO 27001, and partner attestations sit on. See fintech compliance requirements for the full picture.

Mortgage and lending operators. The FTC has been most active here. Brokers, servicers, and online lenders have been the subject of repeated Safeguards Rule enforcement, often after a third-party breach exposes loan applications. The 2024 breach notification amendment specifically targets this segment.

Tax preparation firms. Explicitly named in the rule. Even a 5-person CPA practice with under 5,000 clients still has to comply with access controls, encryption, MFA, training, service-provider oversight, and program adjustment. The IRS publishes its own WISP guidance for tax professionals (Publication 5708) aligned to the FTC rule.

Higher education institutions. Universities in Title IV federal student aid programs are treated as financial institutions for Safeguards Rule purposes under the Department of Education's Federal Student Aid cybersecurity compliance program. The annual single audit now tests Safeguards Rule controls.

SEC-registered advisers and broker-dealers. Regulation S-P (17 CFR 248.30) is the SEC's GLBA implementation. The 2024 amendments added a 30-day customer notification requirement, phasing in through 2025-2026.

Common pitfalls (and how to avoid them)

Treating the Privacy Rule as the whole job. Plenty of fintechs write a clean privacy notice and never get to the Safeguards Rule. The Safeguards Rule is where regulators look after a breach.

Skipping the Qualified Individual designation. One named, accountable person. Splitting the role across a CTO, COO, and external counsel does not satisfy the rule.

Substitute controls without written sign-off. The rule allows substitutes where encryption or MFA is infeasible, but only if the Qualified Individual approves them in writing. Skipping encryption on legacy databases without that approval is exposure.

Relying on a SOC 2 report in lieu of a GLBA risk assessment. A SOC 2 covers a service organization's controls. It does not stand in for the institution's own written risk assessment of how customer information moves through its environment.

Service provider oversight on paper only. Vendors handling high volumes of NPI need actual due diligence, not just a signed DPA. The FTC has cited this in recent enforcement. An untested incident response plan is the same trap.

Frequently Asked Questions

What is GLBA compliance?

The set of obligations the Gramm-Leach-Bliley Act of 1999 imposes on financial institutions to protect customer information, provide privacy notices, and offer opt-out rights for certain information sharing. The two operative rules are the Privacy Rule and the Safeguards Rule, the latter substantially expanded by FTC amendments effective June 9, 2023.

What are the three key rules of GLBA?

The Financial Privacy Rule (notice and opt-out for information sharing), the Safeguards Rule (the written information security program), and the Pretexting Provisions (prohibiting acquisition of customer information through false pretenses). The Safeguards Rule consumes most of the program effort in practice.

What is the difference between GDPR and GLBA?

GDPR is the EU's comprehensive horizontal privacy regulation covering all personal data of EU residents. GLBA is a U.S. sector-specific statute covering only financial information held by financial institutions. GDPR grants affirmative rights (access, deletion, portability) and requires a lawful basis for processing. GLBA primarily requires notice, opt-out for nonaffiliated sharing, and security.

Who has to comply with the GLBA Safeguards Rule?

Any "financial institution" engaged in financial activities under the Bank Holding Company Act, plus the categories named in 16 CFR 314.2(h): mortgage brokers, payday lenders, tax preparers, finance companies, investment advisers, real estate settlement firms, wire transfer services, and others. Bank-supervised institutions follow the parallel federal banking agency safeguards guidelines instead.

What is the 5,000 consumer threshold?

Institutions with customer information on fewer than 5,000 consumers are exempt from four of the nine Safeguards Rule elements: the written risk assessment, the continuous monitoring or pen test plus vulnerability scan requirement, the written IR plan, and the annual board report. The other five elements still apply.

How long do I have to notify the FTC of a breach?

For non-bank institutions covered by the Safeguards Rule, no later than 30 days after discovery of a "notification event" involving the unencrypted customer information of 500 or more consumers. Notification is made through the FTC's online notification form. The rule took effect May 13, 2024.

Does GLBA apply to business customers?

Generally no. GLBA protects individuals who obtain a financial product or service primarily for personal, family, or household purposes. Information about a business borrower or corporate brokerage account is not GLBA-protected, though it may still be covered by other obligations.

Bottom line

GLBA is the federal floor for any company handling consumer financial information in the United States, and the floor got higher in 2023. The companies that struggle treat the Privacy Rule notice as the deliverable and meet the Safeguards Rule after an enforcement action. The companies that operate well treat the nine elements of the 2023 rule as the spine of their security program and let SOC 2, NIST CSF, and partner attestations layer on top.

For a newly-funded fintech, the year-one move is to designate the Qualified Individual when you hire your first compliance lead, write the WISP before the first partnership goes live, and run the first risk assessment within six months of launch. For institutions already at scale, the 2026 action is to confirm the 2023 amendments are fully reflected: encryption at rest, MFA across the board, a tested incident response plan, and a Qualified Individual whose annual board report is actually written.

The cost of doing GLBA well is a fraction of the cost of a Safeguards Rule enforcement action with 20 years of mandatory third-party assessments attached.

Primary Sources

This article references the following authoritative sources:

• Gramm-Leach-Bliley Act, Public Law 106-102 (full text). Library of Congress
• FTC: Gramm-Leach-Bliley Act business guidance. Federal Trade Commission
• FTC Safeguards Rule, 16 CFR Part 314. Federal Trade Commission
• FTC press release on 2021 Safeguards Rule amendments. Federal Trade Commission
• FTC Safeguards Rule: What Your Business Needs to Know. Federal Trade Commission compliance guide
• FTC data security guidance and enforcement. Federal Trade Commission
• Consumer Financial Protection Bureau. CFPB jurisdictional reference
• Department of Education: Updates to the Gramm-Leach-Bliley Act Cybersecurity Requirements. Federal Student Aid
• IRS Publication 5708: Creating a Written Information Security Plan for Your Tax & Accounting Practice. Internal Revenue Service
• NIST Cybersecurity Framework. National Institute of Standards and Technology

GRC software is the category of platforms that centralizes governance, risk, and compliance work in one place. It replaces spreadsheets, shared drives, and email threads with a system of record for controls, policies, evidence, risks, vendors, and audit findings.

This guide is written for security leads, compliance directors, founders preparing for their first SOC 2, and risk officers at companies past 500 employees. It assumes you already know you need a tool. The job here is helping you pick the right kind.

The category is messy. A startup buying "GRC software" to pass SOC 2 ends up looking at very different products than a Fortune 500 bank buying "GRC software" for operational risk. They are not the same market, and treating them as one is the most common reason buyers regret their pick by year two. This article splits the category into the three groups that actually exist in 2026, maps each group to the frameworks and company stages it serves, lists the costs, and walks through a decision tree you can apply in an afternoon.

For head-to-head comparisons, see Vanta vs Drata vs Secureframe, Sprinto vs Vanta, and the Vanta review. For a ranked list of compliance-focused tools, see best GRC software platforms. For the operational workflow these tools accelerate, see the compliance automation guide.

What GRC software is, and what it isn't

GRC stands for governance, risk, and compliance. Each word maps to a discipline that existed long before the software did. Governance is the structure of policies, accountability, and board oversight. Risk is the identification, scoring, and mitigation of things that could hurt the business. Compliance is the demonstration that you meet specific frameworks, regulations, or contractual obligations.

A GRC platform is a system of record that holds the artifacts of all three disciplines and connects them. The control that mitigates a risk is the same control that satisfies a compliance requirement. The policy that documents the control is the same policy the auditor asks for. The evidence that proves the control ran is the same evidence the board wants to see. GRC software exists to keep these artifacts in one place and stop them from drifting.

A GRC platform is not a security tool. It does not block attacks, monitor traffic, or scan code. It tells you whether your organization is operating the controls it claims to operate, and produces the paperwork needed to prove it. It is also not a substitute for a security program. A clean SOC 2 report from a well-run Vanta instance means very little if the underlying controls are weak. The software automates the bookkeeping. The controls still have to work.

Who GRC software is for

Three buyer profiles dominate the market in 2026:

The startup or growth-stage SaaS company buying its first compliance tool because enterprise prospects keep asking for a SOC 2 report. Headcount 20 to 500. Frameworks: SOC 2 Type 2, eventually ISO/IEC 27001, often HIPAA. Buyer: head of security, engineering, or founder. Budget: $10K to $50K per year.

The mid-market or post-IPO company that needs a real internal audit function and a control inventory that survives external scrutiny. Headcount 500 to 5,000. Frameworks: SOC 1, SOC 2, ISO 27001, SOX ITGCs, PCI DSS, and customer-specific mappings. Buyer: Director or VP of Internal Audit, GRC, or Compliance. Budget: $75K to $400K per year.

The enterprise needing integrated risk management across operations, IT, vendors, business continuity, and dozens of regulators in multiple jurisdictions. Headcount 5,000+. Frameworks: all of the above plus NIST SP 800-53, FedRAMP, GLBA, NYDFS 23 NYCRR 500, DORA, and industry-specific regulations. Buyer: CISO, Chief Risk Officer, or Chief Compliance Officer. Budget: $300K to $2M+ per year.

These three profiles map to three different software categories, and that mapping is the most important decision in this purchase.

The three categories of GRC software

The marketing materials of every GRC vendor blur category lines. The product capabilities do not. Here is the breakdown that holds in 2026.

Compliance automation platforms

Vanta, Drata, and Secureframe are the category leaders, with Sprinto, Strike Graph, and Hyperproof rounding out the field. They share a common architecture: deep integrations into cloud and SaaS tools, automated evidence collection, pre-built control libraries mapped to common frameworks, and a guided audit workflow that ends with a clean SOC 2 or ISO 27001 report.

The frameworks these tools cover well are the ones a cloud-native company actually needs in years one through three. The AICPA Trust Services Criteria underpin SOC 2, and every platform in this category supports them. ISO/IEC 27001:2022 and its Annex A controls are universally covered. HIPAA Security Rule mappings, PCI DSS v4.0, GDPR, and CCPA are standard. NIST 800-53 and CMMC are supported by most. FedRAMP Tailored or Low-Impact SaaS is supported by some, with Vanta the most invested. The FedRAMP marketplace lists authorized service providers and the underlying NIST 800-53 baseline the program enforces.

What these platforms do poorly is anything outside the cloud-native SaaS pattern. Heavy on-prem environments, multi-entity consolidated risk reporting, integrated business continuity, and operational risk at financial-services scale are not their strengths. For head-to-head economics within this group, see Vanta vs Drata vs Secureframe and Sprinto vs Vanta.

GRC platforms

The middle tier. AuditBoard, Workiva, LogicGate, and Hyperproof dominate. Buyers are internal audit, SOX, or GRC teams at companies between 500 and 10,000 employees, often public, often regulated, usually running more than one framework.

The capabilities that matter here are the ones compliance automation platforms do not prioritize: multi-entity control rollups for subsidiaries, SOX ITGC testing tied to financial statement audits, internal audit workflow with planning and fieldwork, policy lifecycle management with review cycles and attestations, risk registers that quantify and aggregate exposure across business units, and vendor risk assessment beyond simple SOC 2 report requests.

These platforms typically map controls to dozens of frameworks, including NIST SP 800-53, ISO 27001 Annex A, COSO, COBIT, NIST Cybersecurity Framework, and industry-specific frameworks like HITRUST for healthcare or NERC CIP for utilities. They also handle SSAE 18 SOC 1 attestations, which the compliance automation platforms generally do not. Tugboat Logic used to sit on the seam between this tier and the compliance automation tier; OneTrust acquired it in 2021 and folded it into OneTrust Certification Automation, pulling the product decisively into the IRM tier described next.

Integrated risk management (IRM) platforms

The enterprise tier. ServiceNow GRC, OneTrust, MetricStream, RSA Archer (now a standalone company), and Riskonnect operate at the top of the market. The buying motion is a multi-year, six-or-seven-figure platform decision, often tied to a broader enterprise architecture initiative.

These platforms treat risk as a horizontal function. Operational, IT, cyber, vendor, business continuity, and regulatory compliance share underlying data: controls, policies, processes, business units, and risks. ServiceNow GRC, for example, sits on the broader ServiceNow platform and pulls operational data directly from IT service management, asset management, and HR.

The framework universe at this tier is effectively unlimited: NIST 800-53, ISO 27001, ISO 27002, ISO 31000, the ISO management system standards family, SOX, COSO ERM, BCBS 239, DORA, NYDFS 23 NYCRR 500, and dozens more. Custom framework authoring is standard.

The cost reflects the scope. Six-figure annual contracts are entry points; seven figures is normal for global enterprises. Implementation timelines run 6 to 18 months and typically involve external systems integrators. For the cloud security posture layer that often feeds into IRM platforms, see best CSPM tools.

Framework coverage in practice

The frameworks GRC software targets fall into a handful of families. Every serious platform covers some subset. The question is which.

SOC 2 (and SOC 1, SOC 3). Built on the AICPA Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy. SSAE 18 is the underlying attestation standard the AICPA publishes. Universally supported by compliance automation platforms. SOC 1 (financial reporting controls) is more often handled in GRC and IRM tier platforms.

ISO/IEC 27001. The ISO/IEC 27001:2022 information security management system standard, with its 93 Annex A controls drawn from ISO/IEC 27002:2022. The 2022 update reduced control count from 114 to 93 and reorganized them into four themes (organizational, people, physical, technological). Confirm any platform you evaluate is current with the 2022 control set, not the 2013 set.

HIPAA. The HHS Office for Civil Rights enforces the Security Rule and Privacy Rule for covered entities and business associates. The HHS HIPAA portal lists the rule text and enforcement actions. GRC platforms map controls to the Security Rule's administrative, physical, and technical safeguards.

PCI DSS. Maintained by the PCI Security Standards Council. PCI DSS v4.0 is the current version, with v4.0.1 the active errata. Compliance automation platforms support self-assessment questionnaires; GRC platforms add fuller scoping and Report on Compliance workflows.

NIST SP 800-53. The NIST SP 800-53 Revision 5 control catalog is the foundation for U.S. federal information systems and the baseline behind FedRAMP. Depth varies: a compliance automation platform may map the 200-plus baseline controls; an IRM platform handles the full 1,000+ control catalog with parameter customization.

FedRAMP. The FedRAMP program authorizes cloud service providers for federal use, based on NIST 800-53. Pursuing FedRAMP authorization narrows the platform field substantially. Vanta is the most invested compliance automation vendor in FedRAMP Tailored and Low-Impact SaaS. Full Moderate and High authorizations almost always pull buyers into the GRC or IRM tiers.

SOX ITGCs. Section 404 of Sarbanes-Oxley drives a controls regime for public companies that almost universally runs on a GRC tier platform. AuditBoard, Workiva, and LogicGate dominate the post-IPO mid-cap segment. The compliance automation tier can support SOX ITGC mapping but is rarely a complete fit at scale.

Privacy frameworks. GDPR, CCPA, the EU AI Act, India's DPDP Act, and a growing list of state and national privacy laws. OneTrust is the category leader for privacy-specific workflows; most other GRC platforms support privacy control mappings but defer the operational privacy workflow (consent, DSRs, ROPA) to dedicated tools.

For the workflow these frameworks share, see the compliance automation guide, and for ISO 27001 program planning, the ISO 27001 certification guide.

Pricing tiers and what drives them

GRC software pricing is quote-based across the entire category. Published "starting at" numbers are entry points, not typical contract values. Here is the realistic spend by tier in 2026.

Compliance automation tier. Entry pricing for a single framework at a sub-50-employee company starts around $8,000 to $12,000 per year across the four major vendors. A growth-stage SaaS at 100 to 300 employees with two frameworks typically spends $20,000 to $50,000. Enterprise SaaS at 1,000 employees with three or more frameworks reaches $75,000 to $150,000. Add-ons that change the number meaningfully: vendor risk management modules, trust centers, AI questionnaire automation, additional workspaces for multi-product companies, and premium support tiers.

GRC tier. Workiva, AuditBoard, and LogicGate typically land between $75,000 and $250,000 for a mid-market deployment, with $400,000 to $600,000 normal for larger public companies running SOX, internal audit, and ERM modules on one platform. Hyperproof tends to anchor the lower end of this tier and overlaps with the upper end of the compliance automation tier.

IRM tier. ServiceNow GRC, OneTrust, and MetricStream rarely come in below $300,000 per year and routinely run $750,000 to $1.5M+ for global deployments. Implementation costs are separate and typically equal or exceed the first-year license fee. Expect a 6 to 12-month implementation with a systems integrator.

Cost drivers within each tier are roughly identical: headcount, number of frameworks, number of integrations, number of business units or legal entities, premium modules (vendor risk, AI questionnaires, trust center), and the level of professional services purchased at the start. The variable that surprises buyers most often is "workspaces" or "instances" for multi-product or multi-subsidiary companies. Confirm the model up front.

The buying decision tree by company stage

Different stages have different right answers. The table below is the same logic an experienced GRC consultant would walk you through.

Two practical notes on running this decision tree.

First, do not over-buy. The single most common GRC software mistake is a Series B SaaS company being talked into a six-figure GRC tier contract when a compliance automation platform would have served them better for years. The reverse mistake also happens: a post-IPO company tries to extend a compliance automation tool into SOX testing and discovers at year-end that the auditor cannot work with the evidence package format.

Second, validate auditor fit before signing. Compliance automation platforms have partner auditor networks (Vanta, Drata, and Secureframe each list dozens of firms), and using an in-network auditor materially smooths the first audit cycle. GRC tier platforms are typically auditor-agnostic but still benefit from your audit firm having seen the platform before. Confirm during the sales cycle.

Common selection mistakes

Five patterns repeat in regretted GRC purchases.

Buying for today's framework, not the one you will have in 18 months. A company that buys a SOC 2-only tool and then adds HIPAA, ISO 27001, and PCI DSS within a year rebuilds evidence flows multiple times. Pick a platform that covers your two-year framework roadmap.

Treating "375 integrations" as a feature. Three integrations pulling rich evidence beat 50 that pull a status flag. Ask vendors to demo evidence collection from the three or four systems that dominate your stack.

Underestimating implementation. Compliance automation: 20 to 40 hours to stand up the first framework. GRC tier: 8 to 16 weeks. IRM tier: 6 to 12 months plus a systems integrator. Build this into the procurement timeline.

Ignoring policy workflows. Most platforms generate or import policies; far fewer handle review cycles, attestations, and version history well. If a board, auditor, or regulator asks for evidence that employees acknowledged the current policy version, this matters.

Confusing trust centers with security programs. Vanta's, Drata's, and OneTrust's trust centers are valuable buyer-facing artifacts. They are not a security program. The work behind the trust center produces the clean report; the trust center just publishes the receipts.

Frequently asked questions

What is the difference between GRC software and a compliance automation platform?

A compliance automation platform is one slice of GRC software, focused on automating evidence collection and audit preparation for common frameworks (SOC 2, ISO 27001, HIPAA, PCI DSS) at cloud-native companies. Broader GRC platforms add internal audit workflow, policy lifecycle, risk registers, multi-entity rollups, and SOX testing. IRM platforms extend further into operational, vendor, business continuity, and regulatory risk. All three are "GRC software"; they serve different buyers.

Do I need GRC software for my first SOC 2 audit?

You can do a first SOC 2 Type 1 without dedicated software. You should not do a SOC 2 Type 2 without it. Type 2 requires evidence across a 6 to 12-month observation window, and assembling that evidence from spreadsheets, screenshots, and email at audit time is where most first-time programs fail. A compliance automation platform pays for itself by the time you start the Type 2 readiness assessment. See the Vanta review for a deeper look at the math.

Is open-source GRC software a real option?

There are open-source projects (Eramba, SimpleRisk, Comp AI) that handle pieces of the GRC workflow, primarily risk registers and policy management. None come close to the integration depth or audit workflow of the commercial tools. They are credible for very small companies with strong internal engineering capacity and tolerance for self-hosting. For most companies, the staff time required to operate open-source GRC software exceeds the license cost of a commercial alternative.

How long does GRC software implementation take?

Compliance automation tier: 4 to 8 weeks to first-audit readiness, plus the audit window itself (6 to 12 months for Type 2). GRC tier: 8 to 16 weeks for a single module, longer for multi-module rollouts. IRM tier: 6 to 12 months minimum, often longer for global enterprises. Implementation time is shorter when the buying team has done it before and has clear control framework decisions made up front.

Can one platform handle SOC 2, ISO 27001, HIPAA, and PCI DSS together?

Yes, and this is one of the strongest arguments for compliance automation platforms. The major vendors map a single control to multiple framework requirements, so adding a second or third framework usually adds 10 to 20% more work, not 100%. Confirm the platform supports your full framework set before signing, and validate the auditor relationship for each framework.

What is the difference between GRC and IRM?

GRC (governance, risk, and compliance) is the older term and tends to refer to platforms organized around compliance frameworks and internal controls. IRM (integrated risk management) is the term Gartner pushed starting around 2017 and emphasizes risk as the organizing concept across operations, IT, vendors, and regulation. In practice, the categories overlap heavily at the high end. The label matters less than whether the platform can serve the breadth of risk disciplines your organization needs.

Should we use the GRC software our auditor recommends?

It is a useful data point, not a deciding factor. Auditors recommend platforms they have worked with successfully. That is a signal of operational fit, especially in the compliance automation tier where partner auditor networks exist. It is not a signal that the platform is the right product for your roadmap. Run the decision tree on your own needs, then check auditor fit at the end of the shortlist.

Bottom line

GRC software is a three-category market: compliance automation for cloud-native SaaS, GRC platforms for mid-market and public companies needing internal audit and SOX, and IRM platforms for global enterprises with horizontal risk management. Pick the category that matches your buyer profile and two-year roadmap before you pick the vendor. Inside each category, integration depth, auditor fit, and price decide. Across categories the products are not interchangeable, and the most expensive mistakes happen when buyers pick the wrong tier.

For the next layer, see best GRC software platforms, Vanta vs Drata vs Secureframe, Sprinto vs Vanta, the Vanta review, the compliance automation guide, and best CSPM tools.

Primary sources

• AICPA SOC 2 reporting framework
• AICPA SSAE 18 attestation standards
• ISO/IEC 27001:2022 information security management
• ISO/IEC 27002:2022 information security controls
• ISO management system standards overview
• NIST SP 800-53 Rev 5 control catalog
• NIST Cybersecurity Framework
• FedRAMP program and marketplace
• PCI Security Standards Council
• HHS HIPAA portal

Last reviewed: 2026-05-12.

HITRUST certification is a third-party-validated attestation that an organization's security and privacy controls meet the HITRUST Common Security Framework (CSF). It is the certification most enterprise health buyers ask for when they want to trust a vendor with protected health information.

This guide is for security leads, compliance managers, and founders at healthcare SaaS, business associates, MSPs handling PHI, and any vendor that just received a procurement request mentioning HITRUST. It covers what HITRUST is, the three tiers (e1, i1, r2), realistic cost and timeline ranges, the assessment process, and how the framework lines up against HIPAA, SOC 2, NIST, and ISO 27001.

If you are still mapping the territory between HIPAA the law and HITRUST the certification, start with the HIPAA vs HITRUST comparison and the HIPAA compliance guide. For the security control side, the SOC 2 compliance guide and the NIST Cybersecurity Framework guide give you the surrounding context.

What HITRUST certification actually is

HITRUST is a private organization, the HITRUST Alliance, founded in 2007. It publishes the HITRUST CSF, an integrated control framework that consolidates requirements from HIPAA, the NIST Cybersecurity Framework, NIST SP 800-53, ISO/IEC 27001, PCI DSS, GDPR, and roughly 40 other authoritative sources into one rationalized set of controls.

The framework is the substance. The certification is the proof. When an organization is "HITRUST certified," a HITRUST-authorized External Assessor has reviewed its controls against the relevant CSF requirements and HITRUST has validated the report. Three things separate HITRUST from most other compliance schemes:

1. Prescriptive controls, not principles. Where SOC 2 leaves much of the control language up to the auditor and the service organization, HITRUST defines specific implementation requirements. You either meet the requirement or you do not.
2. Maturity scoring. Each in-scope control is scored on a 5-point model: Policy, Procedure, Implemented, Measured, Managed. A policy on the shelf does not pass. Documented evidence that the control is operating and being reviewed does.
3. One audit, many frameworks. A single HITRUST r2 engagement can satisfy customer requests for HIPAA evidence, NIST mapping, ISO 27001 readiness, and several state privacy laws at once. That is the value proposition.

Who HITRUST is for

HITRUST is built for organizations that handle PHI and sell into large regulated buyers. The most common candidates: healthcare SaaS vendors selling to hospital systems and payers, business associates handling PHI at scale, pharma and life sciences technology vendors, MSPs supporting healthcare clients, payer-side analytics and claims vendors, and AI companies processing PHI.

It is generally not the right first move for pre-revenue startups, vendors selling only to small clinics and dental practices, companies whose buyers have never mentioned HITRUST, or organizations without a working HIPAA program. Get a HIPAA program in place first, layer SOC 2 if your buyers ask for it, and only escalate to HITRUST when a specific deal demands the certificate.

The HITRUST CSF: what is actually in the framework

The HITRUST CSF is organized into 14 control categories and 49 control objectives, with control specifications that vary by certification tier and risk profile. Categories cover the full security and privacy stack: information security management, access control, human resources, risk management, security policy, asset management, physical security, operations, system development, incident management, business continuity, and privacy practices.

Each control specification maps to authoritative source citations. A single HITRUST control on access reviews may map to HIPAA Security Rule administrative safeguards, NIST 800-53 AC-2, ISO 27001 Annex A 5.18, and PCI DSS requirement 7. Cross-walks are documented inside the MyCSF platform, the tool HITRUST sells for managing assessments. HITRUST CSF v11 was released in early 2023, with subsequent point releases adding controls for AI risk and refreshed mappings against NIST Cybersecurity Framework 2.0.

Risk factors and tailoring

HITRUST controls are tailored through organizational, regulatory, and system-level risk factors. The risk factors expand or contract the control set. A 30-person SaaS storing 10,000 patient records faces a smaller control set than a 5,000-person clearinghouse processing 100 million claims a year, at the same certification tier. This is why cost estimates vary so widely: the same r2 certification can produce a 250-control audit for one company and a 2,000-control audit for another.

HITRUST e1 vs i1 vs r2: choosing the right tier

HITRUST offers three certification levels as of the current CSF version. They are different products, not different difficulty levels of the same product. Each is appropriate for a different organizational risk profile and buyer expectation.

When e1 is the right call

The e1 (Essentials) certification covers 44 foundational controls as a 1-year, lower-cost entry point. It is appropriate for vendors handling a limited amount of PHI, selling into smaller buyers, or needing a baseline third-party attestation while building toward i1 or r2. E1 is roughly comparable in effort to a SOC 2 Type 1, with heavier emphasis on prescriptive controls. The trade-off is buyer recognition: many large hospital systems will not accept an e1 in lieu of an i1 or r2 for high-risk vendor categories. Ask the specific buyer before investing.

When i1 is the right call

The i1 (Implemented) certification covers a fixed 182 controls with no risk-factor expansion. Every i1 audit assesses the same control set. Validity is 1 year. I1 has become the workhorse certification for growth-stage healthcare SaaS because scope is predictable, cost is predictable, and buyer recognition is meaningful.

For most companies with a working HIPAA program and a SOC 2 Type 2 already in place, i1 is the natural next step. Roughly 70 percent of i1 controls overlap with a properly scoped SOC 2 Type 2 audit, which materially shortens preparation time.

When r2 is the right call

The r2 (Risk-based, 2-year) certification is the flagship. It is what enterprise health buyers usually mean when they say "HITRUST" without further qualification. The control set is risk-tailored, validity is 2 years with an interim review, and the audit produces a full 5-level maturity score on every applicable control.

Pursue r2 when a specific enterprise contract requires it in writing, the contract value justifies the $100,000 to $250,000+ first-year cost, you already have SOC 2 Type 2 or equivalent control documentation, and you can dedicate 1 to 2 FTEs for 12 to 18 months. Do not pursue r2 as your first compliance certification. Companies that try this typically pay 2 to 3 times what they should because they have not built the underlying documentation the audit consumes.

HITRUST certification cost and timeline

Cost is the question almost every buyer-facing security lead asks first. The honest answer is that cost varies more than for any other major certification, because HITRUST scope is risk-tailored. The ranges below are realistic 2026 estimates for a 25-to-100-person healthcare SaaS, sourced from public assessor quotes and industry reporting. Verify against actual quotes from a HITRUST-authorized External Assessor before budgeting.

A few honest notes: audit-only totals exclude internal labor and platform spend, often already budgeted for other reasons. R2 quotes for organizations above 500 employees frequently exceed $300,000 in year 1. The MyCSF platform is required (no self-certification path), and an External Assessor is required for i1 and r2.

Realistic timeline by tier

For an organization with an existing HIPAA program and a SOC 2 Type 2 report:

• e1: 3 to 6 months from kickoff to certificate.
• i1: 6 to 12 months from kickoff to certificate.
• r2: 12 to 18 months from kickoff to certificate.

For an organization starting without a SOC 2 or working HIPAA documentation, add 6 to 12 months to each estimate. The bulk of that added time is policy authoring, evidence collection, and remediation of control gaps that the assessor surfaces during the readiness phase.

The HITRUST assessment process, step by step

Every HITRUST engagement runs through roughly the same eight steps. Depth and duration scale with certification tier.

1. Scope definition. Decide what systems, products, and locations are in scope. Scope determines risk factors, which determine the control set. For r2 this alone can take 4 to 6 weeks of discussion with the assessor.
2. Risk factor entry in MyCSF. Enter organizational, regulatory, and system-level risk factors. MyCSF generates the tailored control set.
3. Readiness assessment. A self-conducted gap analysis or a paid readiness performed by the External Assessor. Most organizations find 15 to 40 percent of controls have gaps at this stage.
4. Remediation. Close every gap: author missing policies, deploy missing controls, fix monitoring. This is the phase that takes 6 to 12 months for a first-time r2 candidate.
5. Validated assessment fieldwork. The External Assessor reviews every in-scope control, samples evidence, interviews control owners, scores maturity. Typical window: 6 to 12 weeks.
6. HITRUST QA. HITRUST itself reviews the assessor's work before certifying. Most teams underestimate this step. Plan for 4 to 12 weeks.
7. Certification issuance. HITRUST issues the report and certificate. Shareable with buyers under NDA.
8. Continuous compliance. Quarterly reviews of high-frequency controls, annual evidence refresh, and (for r2) the interim assessment in year 2.

Scoring: the part that surprises people

Every in-scope control on r2 (and many controls on i1) is scored across five maturity levels:

• Policy: A formal, approved, distributed policy exists for this control.
• Procedure: A documented procedure operationalizes the policy.
• Implemented: The control is actually in place and operating.
• Measured: Metrics or logs are produced and reviewed.
• Managed: The control is continuously improved based on those measurements.

A control passes only if it scores adequately across all relevant levels. A policy on the shelf with no implementation evidence will fail. An implemented control with no measurement or review will fail at higher tiers. This is the single biggest difference between HITRUST and a SOC 2 Type 2 audit, where the auditor primarily asks whether the control exists and operated during the audit window.

HITRUST vs HIPAA: the relationship

The most common HITRUST confusion is the relationship to HIPAA. The two are not alternatives. HIPAA is the federal law. HITRUST is one of several ways to demonstrate that you comply with HIPAA's Security Rule and (in part) its Privacy Rule.

HHS publishes NIST SP 800-66 Rev 2 as the official implementation guide for the HIPAA Security Rule. HITRUST CSF controls map back to the same Security Rule requirements that NIST SP 800-66 addresses, plus a great deal more. A HITRUST r2 audit produces evidence that satisfies most HIPAA Security Rule requirements as a side effect.

Three things HITRUST does not replace:

• The legal obligation. You remain subject to HIPAA enforcement by the HHS Office for Civil Rights. HITRUST certification is supporting evidence in an OCR investigation, not legal immunity.
• Business Associate Agreements. HITRUST does not negotiate or sign your BAAs. You still need executed BAAs with every subcontractor that touches PHI.
• Breach Notification. The HIPAA Breach Notification Rule still applies. HITRUST controls help reduce breach risk and improve detection, but the notification timelines and obligations live in federal regulation.

For a deeper comparison of the two from a buyer perspective, see HIPAA vs HITRUST. For the BAA mechanics specifically, see HIPAA documentation templates.

HITRUST vs SOC 2

The HITRUST vs SOC 2 comparison comes up because both are voluntary third-party attestations and both are sold by similar assessor firms. They are not interchangeable.

The AICPA Trust Services Criteria that govern SOC 2 are principles-based: the auditor and the service organization agree on the controls that satisfy each criterion. HITRUST is prescriptive: control language and testing requirements are defined by the framework, not negotiated.

For most B2B SaaS the path is SOC 2 Type 2 first (every B2B buyer asks for it), HITRUST i1 or r2 second (when healthcare and enterprise buyers escalate). See the SOC 2 compliance guide and the broader cybersecurity compliance guide for the stacking pattern.

HITRUST vs ISO 27001 and NIST CSF

HITRUST overlaps heavily with both ISO/IEC 27001 and the NIST Cybersecurity Framework. The CSF cross-walks to both. A working ISO 27001 ISMS gives you a head start on roughly 60 percent of HITRUST CSF controls. A mature NIST CSF program gives a similar head start at the framework level, though NIST CSF is functions and categories rather than prescriptive controls, so the mapping is looser.

Decision rules that hold for most companies: if your buyers are primarily United States healthcare, HITRUST is the highest-impact certificate. If buyers are primarily international, ISO 27001 is more universally recognized. If you sell into United States federal government, NIST 800-53 and FedRAMP are the relevant standards. If you sell into both healthcare and international markets, the stack is usually SOC 2 + ISO 27001 + HITRUST r2. For the standalone paths, see the ISO 27001 certification guide and the NIST Cybersecurity Framework guide.

Who needs HITRUST in 2026

HITRUST has moved past its "healthcare only" framing. The CSF is increasingly cited in vendor risk assessments in financial services, life sciences, and government contracting. The buyer pull is still strongest in healthcare. Clear indicators you actually need HITRUST: a hospital system or large payer has requested it in writing, your contract template includes a HITRUST clause as a precondition for renewal, you are processing PHI for multiple large health plans, a pharma buyer is asking for it on a master services agreement, or you are answering RFPs that score HITRUST in their rubric.

You probably do not need HITRUST yet if no buyer has asked, you are under $1M ARR, your healthcare buyers are small clinics that accept a BAA plus self-attestation, or you have no SOC 2 and no working HIPAA documentation. Build those first.

Common pitfalls on the first HITRUST audit

Patterns that repeat on first-time engagements:

• Underscoping then overshooting. Teams scope narrowly to control costs, then the assessor expands scope during fieldwork because the boundary diagram does not match the systems actually handling PHI. Fix: spend real time on the scope diagram in readiness.
• Maturity-level surprise. Teams pass on Implemented but fail on Measured because no one is reviewing the logs the control produces. Fix: build review cadence into control design from the start.
• Policy without procedure. Policies exist but procedures are missing or stale. Fix: treat procedure docs as a first-class artifact.
• Training records that cannot be proven. Workforce training exists but cannot be tied to specific employees and dates. Fix: export completion reports monthly to a controlled location.
• BAAs missing for subcontractors. Fix: a single source-of-truth vendor inventory tied to BAA status.
• Risk assessment over a year old. Fix: run it on a fixed calendar date each year.
• Vulnerability findings without remediation tracking. Fix: treat the tracker as a control artifact, not a tooling output.

A working SOC 2 Type 2 program closes most of these in advance. Going for HITRUST without that foundation is the most expensive sequencing mistake teams make.

Frequently Asked Questions

What is HITRUST certification?

HITRUST certification is a third-party-validated attestation that an organization's controls meet the HITRUST Common Security Framework (CSF). The CSF consolidates requirements from HIPAA, NIST, ISO 27001, PCI DSS, GDPR, and 40 other authoritative sources. Certification is performed by a HITRUST-authorized External Assessor and validated by the HITRUST Alliance. Three tiers exist: e1, i1, and r2.

What is the difference between HIPAA and HITRUST certification?

HIPAA is United States federal law. Every covered entity and business associate handling PHI must comply regardless of size. HITRUST is a voluntary certification. There is no official HIPAA certificate, so organizations use HITRUST (or SOC 2 with a HIPAA mapping) to prove their HIPAA Security Rule implementation to buyers. HITRUST is built on top of HIPAA, not instead of it.

How long does it take to get HITRUST certification?

For an organization with a HIPAA program and a SOC 2 Type 2 report, e1 takes 3 to 6 months, i1 takes 6 to 12 months, and r2 takes 12 to 18 months. Starting from zero adds another 6 to 12 months. The bulk of the time is policy work, evidence collection, and remediation, not audit fieldwork.

How much does HITRUST certification cost?

Realistic 2026 first-year ranges for a 25-to-100-person healthcare SaaS: e1 around $25,000 to $40,000, i1 around $60,000 to $90,000, r2 around $100,000 to $250,000 or more. These cover External Assessor fees, MyCSF subscription, and HITRUST certification fees. Internal labor and compliance automation platforms are additional. Larger organizations can push r2 above $300,000.

What is the difference between HITRUST e1, i1, and r2?

E1 (Essentials) covers 44 controls, valid for 1 year, for lower-risk vendors. I1 (Implemented) covers a fixed 182 controls, valid for 1 year, the standard mid-tier choice. R2 (Risk-based) is the flagship: 200 to 2,000+ controls scoped by risk factors, valid 2 years with an interim review, scored on the full 5-level maturity model. R2 is what enterprise health buyers typically mean by "HITRUST."

Do I need HITRUST if I already have SOC 2?

Only if a specific buyer asks for it. SOC 2 Type 2 satisfies most B2B SaaS buyers. HITRUST is the escalation when a hospital system, payer, or pharma company requires more than SOC 2 in vendor risk. A scoped SOC 2 Type 2 makes HITRUST i1 roughly 30 percent cheaper and faster than starting cold.

Is HITRUST recognized outside healthcare?

Increasingly, yes. The CSF is being adopted in financial services, life sciences, and federal contracting. The strongest buyer pull remains healthcare. Outside healthcare, ISO 27001 and SOC 2 remain the more common certifications buyers ask for.

Bottom line

HITRUST is the most rigorous voluntary certification path for organizations handling PHI in the United States, and the most credible single attestation in front of enterprise health buyers. The CSF consolidates requirements from HIPAA, NIST, ISO 27001, PCI DSS, and 40-plus other sources into one prescriptive, maturity-scored framework with three tiers (e1, i1, r2). Pursue it when a specific buyer or contract requires it, sequence it after a working HIPAA program and a SOC 2 Type 2 to control cost, and budget honestly: $25,000 to $250,000+ in audit fees and 3 to 18 months of preparation depending on tier.

Primary Sources

• HHS HIPAA Security Rule. United States Department of Health and Human Services.
• HHS HIPAA Privacy Rule. United States Department of Health and Human Services.
• HHS Office for Civil Rights. HIPAA enforcement authority.
• HHS Sample Business Associate Agreement Provisions.
• NIST SP 800-66 Rev 2: Implementing the HIPAA Security Rule. National Institute of Standards and Technology.
• NIST SP 800-53 Rev 5: Security and Privacy Controls. National Institute of Standards and Technology.
• NIST Cybersecurity Framework. National Institute of Standards and Technology.
• AICPA SOC Suite of Services and Trust Services Criteria. American Institute of Certified Public Accountants.
• ISO/IEC 27001 Information Security Management Systems. International Organization for Standardization.

First, the correction the search results owe you: there is no official HIPAA certification. The U.S. Department of Health and Human Services does not certify, accredit, or approve organizations for HIPAA compliance. HHS enforces HIPAA through its Office for Civil Rights (OCR), which investigates complaints, self-reported breaches, and conducts audits, but it issues no certificates. Any document marketed as a "HIPAA certification" from a private vendor carries zero legal weight in an OCR enforcement action.

What healthcare buyers are actually asking when they say "are you HIPAA certified" is whether you have done the documented work: risk assessment, policies, technical safeguards, training, and Business Associate Agreements. That work takes two months to a year, depending on your organization size and starting point. This guide breaks it down.

TL;DR

• HHS does not issue HIPAA certifications. "HIPAA compliance" is a documented state you maintain; it is not a credential you earn once.
• A healthcare SaaS startup with strong security hygiene can reach compliance readiness in 2 to 4 months (editorial estimate based on practitioner-reported ranges; no HHS benchmark exists). The minimum credible timeline is around 60 days.
• A mid-size service organization typically takes 4 to 6 months; an enterprise healthcare org with legacy systems can take 6 to 12 months (both editorial estimates).
• HITRUST CSF certification (a private framework that maps to HIPAA plus other standards) is a separate process: 9 to 18 months for an r2 validated assessment (per HITRUST Alliance published guidance).
• Compliance is not a milestone you hit once. Annual risk assessment review, policy updates, and workforce retraining are required on an ongoing basis under 45 CFR § 164.308(a)(8).

Who this is for

This guide is for SaaS founders, security leads, and compliance managers at organizations that handle protected health information (PHI) and need to understand what HIPAA compliance readiness requires before they can sign a Business Associate Agreement with a healthcare customer. It covers Business Associates more than Covered Entities, though the phase structure applies to both.

The "certification" question, corrected

When people search for how long HIPAA certification takes, they are usually asking one of two things:

1. How long until we can tell a healthcare buyer we are HIPAA compliant and sign their BAA?
2. How long does HITRUST CSF certification take?

These are different questions with different answers.

For question one, the word "certification" is a misnomer. HIPAA is a federal statute, the Health Insurance Portability and Accountability Act of 1996, implemented through regulations at 45 CFR Parts 160 and 164. Compliance means your organization meets the Privacy Rule, the Security Rule, and the Breach Notification Rule. HHS OCR enforces those rules reactively: investigations are opened after a complaint or a reported breach, not as a proactive licensing gate. There is no examination, no government-issued certificate, and no expiration date on a certificate because no certificate exists.

For question two, HITRUST CSF is a private certification program run by the HITRUST Alliance. It consolidates HIPAA, NIST, ISO 27001, PCI DSS, and other frameworks into a single set of testable controls. Healthcare enterprises frequently require HITRUST CSF certification from their vendors as a proxy for HIPAA compliance. HITRUST r2 validated assessments are conducted by HITRUST Authorized External Assessors, involve the highest tier of control requirements, and are valid for two years. Getting there takes substantially longer than baseline HIPAA compliance.

Timeline by organization type

The table below reflects editorial estimates of the typical range for each org type to reach a state where they can credibly tell a healthcare customer they are HIPAA compliant and produce evidence if asked. These ranges are based on practitioner-reported timelines; no official HHS benchmark exists.

The minimum credible timeline for a small SaaS is around 60 days (editorial estimate). Anything faster than that typically means policies were adopted without a genuine risk assessment, which matters the moment an OCR audit opens or a buyer's security team does due diligence.

Phase 1: Discovery and gap assessment (Weeks 1 to 4)

The first step is scoping. HIPAA requirements differ depending on whether your organization is a Covered Entity (a healthcare provider, health plan, or healthcare clearinghouse) or a Business Associate (a vendor that creates, receives, maintains, or transmits PHI on a Covered Entity's behalf). Most SaaS companies fall into the Business Associate category.

Deliverables:

• Document your CE or BA determination.
• Map all systems, people, and third-party services that touch PHI.
• Conduct a Security Rule risk analysis per 45 CFR § 164.308(a)(1): "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information."
• Score findings against the 18 standards in the Security Rule (Subpart C of Part 164).
• Produce a remediation plan ranked by risk level.

HHS publishes a Security Risk Assessment Tool specifically for this purpose.

Effort typically ranges from 40 hours for a small cloud-only startup to over 100 hours for a multi-site organization with on-premise systems (editorial estimates; actual effort varies significantly by existing security maturity).

For a full walkthrough, see our HIPAA risk assessment guide.

Phase 2: Policy and procedure development (Weeks 3 to 8)

The Security Rule requires written policies for administrative, physical, and technical safeguards. The Privacy Rule adds policies covering patient rights, minimum necessary use, and disclosure tracking. Most Business Associates need 15 to 25 distinct policies (editorial estimate based on the enumerated standards in 45 CFR Parts 164.308, 164.310, 164.312, and Subpart E).

Administrative safeguard policies required under 45 CFR § 164.308:

• Security management process (risk analysis, risk management, sanction policy, activity review)
• Assigned security responsibility
• Workforce security (authorization, clearance, termination procedures)
• Information access management
• Security awareness and training
• Security incident procedures
• Contingency plan (data backup, disaster recovery, emergency mode operations)
• Evaluation cadence

Technical safeguard policies required under 45 CFR § 164.312:

• Access control (unique user IDs, emergency access procedure)
• Audit controls
• Integrity controls
• Person or entity authentication
• Transmission security

Privacy Rule policies under 45 CFR Subpart E:

• Breach notification policy
• Minimum necessary use policy
• Patient rights policy
• Disclosure tracking

Drafting from scratch takes 6 to 10 weeks of compliance lead time. Using a vetted template library from a compliance automation platform cuts that to 2 to 4 weeks of customization and review. Free policy templates exist but typically require substantial editing before they are production-ready.

For template options, see our HIPAA documentation templates guide.

Phase 3: Technical and physical safeguard implementation (Weeks 5 to 16)

This is the engineering phase. The five technical safeguard categories under 45 CFR § 164.312, access control, audit controls, integrity, person/entity authentication, and transmission security, each have a mix of required and addressable specifications.

Notable distinctions: encryption at rest is an addressable specification under 164.312(a)(2)(iv), meaning organizations must implement it or document why an equivalent alternative was chosen. Encryption in transit is also addressable under 164.312(e)(2)(ii). In practice, any organization storing ePHI in cloud infrastructure should treat both as required; the "addressable" designation was written before modern cloud environments made encryption trivially available.

Physical safeguard requirements under 45 CFR § 164.310 include:

• Facility access controls
• Workstation use policies
• Workstation security
• Device and media controls

For cloud-only SaaS, the physical safeguard phase is lighter: data center physical security is typically handled by the cloud provider under the shared responsibility model, covered by the provider's BAA. For healthcare providers operating clinics or labs with on-premise equipment, this phase involves physical walkthroughs and can extend 8 to 16 weeks.

See our HIPAA Security Rule safeguards guide for specific control implementation details.

Phase 4: Workforce training (Weeks 8 to 12)

45 CFR § 164.530(b) requires Covered Entities to train "all members of its workforce on the policies and procedures with respect to protected health information." The regulation specifies that training must be given:

• By the compliance date for the entity
• "Within a reasonable period of time" after a new workforce member joins
• "Within a reasonable period of time" after a material policy change

Documentation must be retained for a minimum of six years from creation or the last effective date, per 45 CFR § 164.530(j).

Business Associates have parallel obligations under their BAAs, even though the training requirement sits in the Privacy Rule, which formally applies to Covered Entities.

Typical training content splits by role: general HIPAA awareness for all staff, technical safeguard training for engineers, and Privacy Rule content for support staff who handle patient inquiries. Training delivery via an LMS generates the attendance records needed for evidence.

See our HIPAA training requirements breakdown.

Phase 5: Business Associate Agreements (Weeks 6 to 12)

Every vendor that creates, receives, maintains, or transmits PHI on your behalf must sign a BAA before they receive PHI. The BAA is a contract requirement under 45 CFR § 164.308(b), which requires "written contracts or other arrangements" with business associates documenting satisfactory HIPAA safeguard assurances.

Steps:

1. Inventory every vendor that may contact PHI: cloud infrastructure, email, monitoring, logging, support tooling, payment processors.
2. Apply the test: do they "create, receive, maintain, or transmit" PHI? If yes, they need a BAA.
3. Request BAAs from each vendor. Major cloud providers (AWS, Azure, GCP, Google Workspace, Microsoft 365) offer standard BAAs. Many smaller vendors do not, which can require finding an alternative or obtaining a custom agreement.
4. Store executed BAAs with your compliance documentation.

BAA collection typically takes 6 to 12 weeks because vendor legal teams move slowly. Starting this phase early, before other phases complete, is one of the most reliable ways to shorten your overall timeline.

See our HIPAA Business Associate Agreement guide.

Phase 6: Internal audit and remediation (Weeks 12 to 20)

Before representing to customers that you are HIPAA compliant, run an internal audit to confirm your evidence package holds up. Audit scope:

• Are all required policies in place, approved, and dated?
• Are technical safeguards implemented and verified (not just planned)?
• Are workforce training records complete and retained?
• Are BAAs executed for all vendors that need them?
• Does the risk assessment reflect your current environment (not the environment from six months ago)?
• Is the breach response plan documented and tested?
• Are audit log reviews happening on schedule?

Budget 1 to 2 weeks of audit, 2 to 4 weeks of remediation, and 1 to 2 weeks of verification for a clean cycle. If findings are significant, add another remediation round.

HITRUST CSF: the third-party attestation that gets confused with HIPAA

HITRUST CSF is frequently described as "HIPAA certification" by healthcare enterprise procurement teams. It is not, but it functions as a more rigorous proxy.

HITRUST publishes a Common Security Framework that harmonizes HIPAA, NIST, ISO 27001, PCI DSS, GDPR, and others into a single set of controls. The organization offers three certification tiers:

The r2 validated assessment is what most large healthcare enterprises require. It involves:

1. Scoping and readiness gap analysis with a HITRUST Authorized External Assessor
2. Implementing or remediating controls to meet the r2 requirement set
3. Formal validated assessment by the authorized assessor
4. HITRUST QA review and certification issuance

The 9 to 18 month timeline for r2 reflects the full cycle: a small organization with mature security and existing SOC 2 may reach r2 in under a year; a large enterprise with legacy systems typically takes 12 to 18 months.

HITRUST publishes annual breach performance reports comparing breach rates among certified versus non-certified organizations; its reports have consistently shown materially lower breach rates among certified entities (per HITRUST Alliance breach performance publications; exact figures are self-reported by HITRUST and should be interpreted in that context). Enterprise healthcare buyers use HITRUST as a compliance proxy precisely because the assessment is auditor-verified rather than self-attested.

For a side-by-side comparison, see our HIPAA vs HITRUST guide.

SOC 2 with HIPAA criteria: a faster third-party path

SOC 2 is a different kind of attestation. It is defined by the AICPA's Trust Services Criteria and covers five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. It does not map directly to HIPAA, but auditors can include a HIPAA criteria section that tests controls relevant to the Security and Privacy Rules.

SOC 2 with HIPAA criteria is not a HIPAA audit, it is an attestation by a licensed CPA firm that specific controls were in place during the observation period. It does not create a legal safe harbor from OCR enforcement. But it is a documented third-party review that healthcare buyers accept as evidence of serious compliance effort.

For organizations that already have SOC 2 Type 2, layering HIPAA-specific controls typically adds 6 to 10 weeks rather than starting a HIPAA program from scratch, because the administrative infrastructure (audit logs, evidence collection, policy management) is already operating.

For the full comparison, see our HIPAA vs SOC 2 guide.

Ongoing compliance cadence

Reaching initial compliance readiness is not the end of the obligation. 45 CFR § 164.308(a)(8) requires that Covered Entities and Business Associates "perform a periodic technical and non-technical evaluation" of their security policies against applicable standards. In practice, this means:

• Annual risk assessment review: Did your environment change? New systems, new vendors, new PHI data flows?
• Annual policy review and re-approval: Are policies still accurate? Did regulations change?
• Annual workforce training (or upon material policy change, per 45 CFR § 164.530(b)(2))
• Ongoing audit log review: Most organizations do this monthly or quarterly
• BAA inventory management: Vendor contracts change; BAAs need to track those changes
• Breach response testing: At minimum annually
• HITRUST r2 re-assessment: Every two years if you hold r2 certification

The most common way organizations that were compliant in one year fall out of compliance by the next is not a major incident, it is accumulated drift: new vendors added without BAAs, staff turnover that breaks training records, system changes that invalidate the risk assessment. A compliance calendar inside your automation platform or a shared document is the practical tool for preventing this.

What the penalty structure actually looks like

Since there is no certificate to protect you, the enforcement exposure is direct. Per 45 CFR § 160.404, as adjusted for inflation under the Federal Civil Monetary Penalties Inflation Adjustment Act and published annually at 45 CFR § 102.3, the 2025 penalty tiers are:

These figures are published at 45 CFR § 102.3 and updated annually.

A recent enforcement example: in 2024, Montefiore Medical Center settled with HHS OCR for $4.75 million following a breach in which a workforce member sold patient records. The settlement documents, available from HHS OCR's resolution agreements page, identify the specific Security Rule standards at issue. Skipping the workforce sanction policy and the information system activity review, both administrative safeguards under § 164.308, are commonly cited in enforcement actions.

For a full breakdown of violation scenarios, see our HIPAA violation penalties guide.

Frequently asked questions

Is there an official HIPAA certificate?

No. HHS does not certify organizations for HIPAA compliance. Any document sold as a "HIPAA certificate" by a private vendor is a self-assessment product with no legal standing in an OCR enforcement action. The legitimate third-party attestations are HITRUST CSF certification (from the HITRUST Alliance) and SOC 2 reports with HIPAA criteria, both of which involve independent assessors but are private frameworks, not government programs.

How long does HIPAA compliance take for a small SaaS startup?

Typically 2 to 4 months from kickoff to a state where you can credibly sign a BAA and produce evidence if asked. The fastest legitimate path combines a compliance automation platform (for policy templates and evidence collection), a small engineering team to implement technical safeguards, and an experienced compliance lead to drive the risk assessment. Moving faster than 60 days usually means the risk assessment or BAA inventory was not done properly.

Can I become HIPAA compliant in 30 days?

For a five-person company with SOC 2 Type 1 already in place, adding HIPAA-specific policies and BAAs could technically be done in 30 days. In practice, healthcare buyers with security review processes will question a 30-day timeline because the risk assessment, workforce training, and BAA inventory cannot be done thoroughly in that window. Due diligence will surface the shortcuts.

Do I need a HIPAA audit every year?

There is no required annual external audit. 45 CFR § 164.308(a)(8) requires periodic evaluation, which most organizations interpret as annual. Many organizations also run voluntary annual third-party gap assessments to maintain readiness. HITRUST CSF r2 re-assessment is required every two years for certified organizations.

What is the difference between HIPAA compliance and HITRUST certification?

HIPAA is a US federal regulation. Compliance with it is a legal obligation if you handle PHI; there is no certificate. HITRUST CSF is a private certification framework that maps HIPAA requirements into a testable control set alongside other standards. HITRUST r2 certification is issued by the HITRUST Alliance after a validated assessment by an authorized external assessor. It is a stronger evidence artifact than a self-attested HIPAA compliance claim, which is why large healthcare enterprises frequently require it from vendors.

Does HIPAA compliance expire?

There is no certificate to expire. But your compliance state can drift between annual reviews if your environment changes and your documentation does not keep pace. The practical equivalent of expiration is an organization whose risk assessment is two years stale, whose BAA inventory is incomplete, and whose workforce training records have gaps, that organization is not compliant in any meaningful sense, even if it once was.

Sources used

1. 45 CFR § 164.308(a)(8), accessed 2026-05-12
2. 45 CFR Parts 160 and 164, accessed 2026-05-12
3. Security Risk Assessment Tool, accessed 2026-05-12
4. 45 CFR § 164.312, accessed 2026-05-12
5. 45 CFR § 164.310, accessed 2026-05-12
6. 45 CFR § 164.530(b), accessed 2026-05-12
7. HITRUST, accessed 2026-05-12
8. 45 CFR § 160.404, accessed 2026-05-12
9. 45 CFR § 102.3, accessed 2026-05-12
10. resolution agreements page, accessed 2026-05-12

Last reviewed: 2026-05-12. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.

An incident response plan is the written document and operational program that defines how a company detects, contains, eradicates, and recovers from a cybersecurity incident, plus the legal and regulatory disclosures it makes during and after. The federal reference standard is NIST SP 800-61 Rev 2, the Computer Security Incident Handling Guide. The regulatory floor in 2026 is set by the SEC cybersecurity disclosure rules adopted in July 2023, the HIPAA Breach Notification Rule, and CISA advisories.

This guide is for CISOs, security engineers, GRC leads, founders, and counsel who need a single reference for what an IRP must contain in 2026 and how it ties into the broader compliance program. It covers the seven incident handling phases, the SEC 4-business-day Form 8-K clock, the HIPAA 60-day breach notification rule, team roles, severity classifications (P1 through P4), tabletop exercises, ransomware playbooks, and how the plan fits inside a broader cybersecurity compliance program. The companies that handle incident response well treat the plan as a living operational document, not a binder.

What is an incident response plan?

An IRP is a documented set of procedures, roles, and decision criteria that an organization follows when it detects a cybersecurity event. The plan covers technical actions (isolate a host, rotate keys, preserve evidence), governance actions (who declares an incident, who briefs the board), and regulatory actions (when to file an 8-K, when to notify under HIPAA, when to coordinate with the FBI through IC3 and CISA).

NIST SP 800-61 Rev 2 is voluntary but widely adopted, and is what most U.S. regulators implicitly point to when asking whether an organization had a "reasonable" capability. NIST distinguishes between an event (any observable occurrence) and an incident (an event with actual or potential adverse effects on confidentiality, integrity, or availability). Every alert is an event. Only some events are incidents.

An IRP is not a runbook. It is the framework runbooks plug into. A mature program maintains the master IRP plus 8 to 15 playbooks (ransomware, business email compromise, insider exfiltration, denial of service, supply chain, account takeover, cloud key compromise). The master plan governs how playbooks are invoked, who has authority, and what disclosures attach.

Why incident response matters in 2026

Three things have raised the regulatory cost of poor incident response since 2023.

The 2023 SEC cybersecurity disclosure rule. In July 2023, the SEC adopted final rules requiring public companies to disclose material cybersecurity incidents on Form 8-K within four business days of determining materiality, and to disclose risk management, strategy, and governance in the annual 10-K. The clock starts when the company concludes the incident is material, not when it is first detected, which makes the materiality determination itself a control. Companies without a written, repeatable materiality workflow are exposed to enforcement actions for late or inadequate disclosure.

HIPAA Breach Notification enforcement. The HIPAA Breach Notification Rule, enforced by the HHS Office for Civil Rights, requires covered entities to notify affected individuals within 60 days of discovering a breach of unsecured protected health information, notify HHS, and (for breaches affecting 500 or more individuals) notify prominent media in the affected state. See our HIPAA compliance guide for the full stack.

CISA reporting expectations. The Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) directs CISA to require covered entities to report cyber incidents within 72 hours and ransom payments within 24 hours. As of 2026 the final rule is proceeding through rulemaking. CISA already publishes cybersecurity advisories that organizations are expected to consume and act on.

Two large public breaches have shifted board-level expectations. The SolarWinds supply chain compromise showed that incident response now has to cover third-party code paths. The Equifax data breach showed that the cost of a delayed, poorly-disclosed response is measured in billions, not millions.

Incident response plan requirements

An IRP that satisfies the major U.S. compliance regimes shares a common spine. The components below are required or strongly expected by NIST CSF 2.0, the NIST 800-53 IR control family, the SEC disclosure rule, the HIPAA Security Rule, and PCI DSS 4.0.

A reasonable IRP in 2026 is not 200 pages. It is a tight 25 to 50 page master document plus the playbooks. Long plans rot. Short, current, exercised plans survive contact with a real incident.

Incident response plan cost and timeline

Costs vary by company size, regulated industry, and whether the team is fully internal, hybrid, or retainer-backed. The figures below are practitioner ranges for U.S. companies in 2026.

Initial plan development (year one). A 30 to 200 person company building its first formal IRP typically spends $25,000 to $80,000 in advisory fees plus 200 to 400 hours of internal time. Larger enterprises can spend $150,000 to $500,000 in year one.

Annual program operating cost. $200,000 to $1.2M annually at the mid-market level, covering a dedicated incident commander, engineer contributions, allocated SIEM and SOAR tooling, retainer fees, and exercise costs.

Incident response retainer. Typical retainers run $15,000 to $50,000 annually for guaranteed response time. Hours convert to fees during an engagement at $400 to $900 per hour. A real ransomware response consumes 800 to 3,000 retainer hours.

Tabletop exercises. $8,000 to $30,000 per facilitated session with a custom scenario. Most regulated organizations run two facilitated and two internal exercises per year.

Timeline. From decision to draft IRP, 8 to 12 weeks. From decision to a tested IRP that can survive an audit, 6 to 9 months. The bottleneck is rarely writing the plan. It is integrating it with the detection stack, training the team, and running the first useful tabletop.

The seven phases of incident response

The four-phase NIST 800-61 model and the seven-phase practitioner model describe the same lifecycle at different granularities. The seven-phase version below maps directly into the NIST CSF 2.0 Respond and Recover functions.

1. Preparation. Build the team, write the plan, deploy tooling, train staff, and exercise before an incident occurs. 80% of the value of an IR program lives here. A team that has not exercised will improvise badly on day one.

2. Identification. Detect the event, triage the alert, decide whether it is an incident, classify severity (P1 through P4), and open a formal incident ticket. The output is a written incident declaration with a unique identifier, initial scope estimate, and assigned incident commander.

3. Containment. Short-term containment isolates the immediate threat (disable the account, segment the host, block the C2 domain). Long-term containment puts a sustainable hold on the adversary while the eradication plan is built. NIST 800-61 explicitly warns against jumping straight to eradication because it destroys evidence and often alerts the attacker.

4. Eradication. Remove the adversary and the artifacts. Rebuild compromised systems, rotate all credentials in scope, remove backdoors, patch the initial access vector. Teams often declare victory before they have actually closed the original access path.

5. Recovery. Bring affected systems back into production. Restore from clean backups, validate restored systems are clean before reconnecting them, monitor closely for adversary return. Recovery is also when most disclosure clocks run in parallel, so communications are at peak load.

6. Lessons Learned. Within two weeks of incident close, run a structured post-mortem. Document root cause, timeline, control failures, and a written improvement list with owners and due dates. Track items to closure. This is what turns an incident into a permanent control improvement.

7. Continuous Testing. Annual tabletop minimum. Full-scope red or purple team exercise every 18 months. Update playbooks after every real incident and every exercise. The plan that is not exercised is fiction.

Incident response team roles

A functioning IR team has named roles, not generic responsibilities. NIST 800-61 Section 2.4 outlines the model. The version below reflects how most U.S. mid-market and enterprise companies structure it in 2026.

Every role needs a primary and at least one named backup. Incidents happen on weekends and during the incident commander's vacation. A plan that depends on one person being reachable is broken by definition.

Severity classification: P1, P2, P3, P4

The P1 to P4 model appears in SANS incident handling guidance, most commercial IR retainer SLAs, and NIST 800-61 Section 3.2.6 as one example of a categorization approach.

P1 (Critical). Material business impact, active data exfiltration, production ransomware, or an incident reasonably likely to require SEC disclosure or HIPAA breach notification. Engages the full IRT, executive sponsor, and outside counsel. Response within 30 minutes, 24x7.

P2 (High). Confirmed incident with significant but bounded impact. Includes business email compromise with financial loss, single-host ransomware, privileged account takeover, sensitive data exposure without confirmed exfiltration. Response within 1 hour business, 2 hours off-hours.

P3 (Medium). Contained incident with limited impact. Malware on a single endpoint stopped by EDR, low-volume phishing with confirmed clicks, minor data leakage to a non-adversary recipient. Response within 4 business hours.

P4 (Low). Suspicious activity not rising to a confirmed incident. Investigated, closed, and tracked for trending. Response within one business day.

The severity tier ties directly to the SEC materiality assessment. P1 triggers immediate materiality review by counsel and the executive sponsor. P2 triggers a documented review on a documented timeline. P3 and P4 incidents are not material on their own, but a cluster of P3s may aggregate to a material event.

The SEC 4-business-day disclosure clock

The biggest 2023 to 2026 shift in U.S. corporate incident response is the SEC cybersecurity disclosure rule. The plain reading: a registrant must file a Form 8-K under Item 1.05 within four business days of determining a cybersecurity incident is material.

Two operational points matter.

The clock starts at materiality determination, not detection. The SEC chose this trigger to avoid forcing premature disclosure, but it places the materiality workflow itself inside the disclosure regime. The determination must be made "without unreasonable delay" once facts are known. A plan with no defined workflow, no executive sponsor named to make the call, and no documented timeline is the plan most likely to face an SEC enforcement question.

Form 8-K Item 1.05 content is prescriptive. The filing must describe the material nature, scope, and timing of the incident plus the material impact or reasonably likely material impact. Pre-stage an 8-K template aligned to those elements, reviewed by counsel, so that on day three the company is not drafting from scratch.

The SolarWinds compliance lessons covers what SEC enforcement looks like against companies that disclosed late or incompletely. The pattern is consistent: enforcement focuses less on whether the breach occurred and more on whether the disclosure process was reasonable, repeatable, and timely.

HIPAA breach notification: the 60-day clock

For covered entities and business associates, the HIPAA Breach Notification Rule sets a separate clock. Within 60 calendar days of discovering a breach of unsecured protected health information, the entity must notify each affected individual, notify HHS via the OCR portal, and (for breaches affecting 500 or more individuals in a state) notify prominent media in that state.

The 60-day clock starts at discovery, not materiality determination. Discovery is the first day the breach is known, or by reasonable diligence would have been known, to any workforce member other than the person committing the breach. Both clocks can run simultaneously at a publicly-traded healthcare company. The IRP must handle parallel disclosure timelines without producing inconsistent statements. Counsel coordination is what makes this work.

Ransomware incident response

Ransomware deserves its own playbook. The Target/PCI DSS analysis covers the broader pattern of large breach failure modes. The ransomware-specific elements:

• Do not pay before a structured analysis. OFAC sanctions exposure, the FBI's standing guidance against payment, and the reality that decryptors often fail all argue for a clear-eyed analysis first.
• Engage external IR and counsel within the first hour. Forensics, negotiation, and disclosure all benefit from privileged communication.
• Snapshot evidence before remediation. Encrypted disks, ransom notes, network captures, EDR telemetry. Pre-decide the preservation-vs-recovery tradeoff for each system class.
• Assume data exfiltration. Modern groups exfiltrate before encryption. Treat the incident as a breach unless forensics affirmatively prove otherwise.
• Coordinate with CISA and the FBI. CISA's Stop Ransomware program provides free technical assistance and may identify a known decryptor.

A typical mid-market ransomware response runs 14 to 45 days from detection to recovery, with $500,000 to $5M in incident-related costs separate from any ransom payment.

How incident response fits the broader compliance program

An incident response plan is one chapter of a cybersecurity compliance program. It sits in the Respond and Recover functions of the NIST Cybersecurity Framework but pulls evidence from every other function. Identify feeds the IRP its asset inventory and data classification. Protect controls determine how quickly an adversary can move once inside. Detect is the on-ramp: every alert is the first input to identification. Respond is the IRP itself. Recover covers restoration plus the lessons-learned loop back into Identify and Protect.

For organizations standing up a compliance program from scratch, see our step-by-step build guide. The IRP is usually one of the first three artifacts produced, after the asset inventory and the policy framework.

Common pitfalls

No written materiality workflow. Most companies have an IRP that names a severity scheme but does not say how a P1 escalates into a materiality determination, who makes the call, or what triggers the 8-K filing. This is the single most enforceable gap under the 2023 SEC rule.

The plan and the playbooks disagree. The master IRP says one thing about evidence preservation; the ransomware playbook says another. Adversaries do not care about your version control. Review the plan and playbooks together at least annually.

No backup for every role. Incidents happen on holidays. A plan with single points of failure in human roles fails on day one.

Tabletop exercises that are not exercises. A 90-minute walkthrough with a slide deck is a walkthrough, not an exercise. Real exercises inject ambiguity, time pressure, and contested information. Use external facilitators at least once a year.

No post-incident control updates. Lessons learned without owners, due dates, and tracked closure is a document, not a process. The next incident will notice.

Treating breach notification as a legal-only activity. Notifications to affected individuals, HHS, state AGs, and media are operational workstreams with templates, mailing infrastructure, call center capacity, and identity-protection vendor contracts. They cannot be improvised inside the 60-day clock.

Ignoring third-party scope. The SolarWinds incident and the Equifax incident both involved third-party failure. The IRP should explicitly address what happens when a vendor reports a compromise affecting your systems, and what contractual rights you have to forensic data.

Tools and platforms

The IR tooling stack typically includes a SIEM (Splunk, Microsoft Sentinel, Elastic) for log aggregation; EDR/XDR (CrowdStrike, SentinelOne, Microsoft Defender) for endpoint response; SOAR (Tines, Torq, Splunk SOAR) for playbook automation; case management (TheHive, ServiceNow SecOps); forensics tools (Velociraptor, KAPE); and dedicated war room channels with an out-of-band fallback like Signal.

The platforms do not produce a working IRP. They produce data and automation that a working IRP consumes. Companies that buy tooling without the program discover during their first real P1 that the tools have been ingesting logs nobody reads.

Frequently Asked Questions

What are P1, P2, P3, and P4 incidents?

P1 is a critical incident with material business impact and potential disclosure obligations (production ransomware, confirmed data exfiltration). P2 is a confirmed incident with significant but bounded impact. P3 is a contained, limited-impact incident. P4 is suspicious activity not rising to a confirmed incident. The model aligns with NIST 800-61 Section 3.2.6 examples and most commercial IR retainer SLAs.

What are the 8 basic elements of an incident response plan?

A mission and scope statement, executive sponsor and approval, defined IR team and roles, a severity classification scheme, detection and analysis procedures, containment-eradication-recovery procedures, communication and disclosure procedures, and a post-incident review and exercise program. Each maps to a section of NIST SP 800-61 Rev 2.

What are the 7 stages of incident response?

Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned, and Continuous Testing. The seven-stage model is a granular restatement of the four-phase NIST 800-61 lifecycle and is compatible with the NIST CSF 2.0 Respond and Recover functions.

How fast must a public company disclose a cyber incident?

Within four business days of determining the incident is material. The trigger is the materiality determination, not initial detection. The disclosure is filed on Form 8-K under Item 1.05 and must describe the nature, scope, timing, and material impact of the incident. See the SEC final rule.

What is the HIPAA breach notification timeline?

Within 60 calendar days of discovering a breach of unsecured protected health information. Covered entities must notify each affected individual, notify HHS via the OCR portal, and (for breaches of 500 or more individuals in a state) notify prominent media in that state. See the HIPAA Breach Notification Rule.

Do small businesses need an incident response plan?

Yes. State breach notification laws apply at any size, FTC data security expectations apply to any business holding personal information, and cyber insurance underwriters now require a written IRP as a condition of coverage. Small businesses can run a 15 page plan; they cannot run no plan.

How often should we run a tabletop exercise?

At least annually as the absolute minimum, twice a year for regulated companies, and quarterly for critical infrastructure. A reasonable cadence is one external-facilitator tabletop and one internal exercise per year, plus a red or purple team simulation every 18 months.

Bottom line

An IRP in 2026 is the operational program, not the binder: a written master plan, 8 to 15 playbooks, a named team with backups, a documented materiality workflow, and a tested capability to file an 8-K in four business days, notify under HIPAA in 60 days, and brief CISA when ransomware is involved. The companies that handle incidents well exercise the plan, update it after every event, and treat lessons learned as a control improvement engine.

For broader context, see our cybersecurity compliance guide and NIST Cybersecurity Framework guide.

Primary Sources

This article references the following authoritative sources:

• NIST SP 800-61 Rev 2: Computer Security Incident Handling Guide. The federal reference standard for incident handling.
• NIST Cybersecurity Framework 2.0. Respond and Recover functions referenced throughout.
• NIST SP 800-53 Rev 5. Incident Response (IR) control family.
• SEC Final Rule: Cybersecurity Disclosure (2023). Form 8-K Item 1.05 4-business-day disclosure requirement.
• HIPAA Breach Notification Rule. HHS OCR enforcement, 60-day individual notification clock.
• CISA Cybersecurity Advisories. U.S. national baseline for active threats and recommended actions.
• CISA Stop Ransomware. Federal ransomware guidance and resources.
• FBI Internet Crime Complaint Center (IC3). Federal reporting channel for cyber incidents.
• FTC Data Security Guidance. FTC enforcement expectations on data security.

TL;DR

• ISO 27001 is certifiable. ISO 27002 is not. Auditors check your ISMS against ISO 27001 clauses and Annex A. No certificate exists for ISO 27002.
• ISO 27001 tells you what to do. Its 93 Annex A controls set the requirements your ISMS must meet or formally exclude.
• ISO 27002 tells you how to do it. The same 93 controls are expanded into approximately 150 pages of implementation guidance, examples, and considerations.
• Buy ISO 27001 first. If you are pursuing certification, ISO 27001 is the only document your auditor will check compliance against.
• Use both together. ISO 27001 sets the bar; ISO 27002 shows you how to clear it. Most practitioners keep both open during implementation.

Who this is for

This article is for compliance leads, security engineers, and IT managers who are starting an ISO 27001 certification program or maintaining an existing one. It is also for auditors and consultants who need a plain-language explanation of the two standards to share with clients.

What is ISO 27001?

ISO/IEC 27001:2022 is the international standard for an Information Security Management System (ISMS). Published by the International Organization for Standardization, it is the document that organizations certify against. The current version is ISO/IEC 27001:2022, published in October 2022.

ISO 27001 has two structural components:

Clauses 4 through 10 define how to build and operate an ISMS. They cover: context of the organization, leadership commitment, planning and risk assessment, support (resources, competence, awareness), operation, performance evaluation, and improvement. Every clause is mandatory. An auditor will check all of them.

Annex A lists 93 reference controls in short form, organized into four themes. These controls are not all mandatory; organizations choose which apply based on their risk assessment. Any control excluded must be justified in the Statement of Applicability.

Passing an ISO 27001 certification audit means demonstrating that the ISMS is operating across clauses 4 through 10, that the Statement of Applicability addresses every Annex A control, and that the controls you claim to have implemented actually work.

For a complete walkthrough of the certification pathway, see our ISO 27001 certification guide.

What is ISO 27002?

ISO/IEC 27002:2022 is the companion standard. It is a code of practice for information security controls. The current version was published on 15 February 2022, ahead of the ISO 27001:2022 update that aligned with it.

While ISO 27001 describes each of its 93 Annex A controls in roughly two or three lines, ISO/IEC 27002:2022 expands those same 93 controls into roughly 150 pages of implementation guidance, attribute tables, examples, and practical considerations. The 2022 edition also broadened the standard's scope beyond information security to include cybersecurity and privacy protection.

ISO 27002 is not certifiable. No accreditation body issues an "ISO 27002 certification." Its role is as a reference manual: when you are implementing a control that ISO 27001 Annex A requires, ISO 27002 shows you what that implementation should actually contain.

The core difference

The relationship between the two standards is the relationship between a contract and an instruction manual. ISO 27001 defines the obligations. ISO 27002 explains how to fulfill them.

If you can only buy one, buy ISO 27001. If you are doing the implementation work yourself rather than relying on a consultant, ISO 27002 will save you significant guesswork on each control.

Why the two documents exist separately

When ISO published the precursor standards, ISO 17799 (later renumbered 27002) and ISO 27001, the split was deliberate.

A certifiable standard has to be lean. Auditors across dozens of accreditation bodies in different countries must be able to check the same document against the same criteria and reach consistent conclusions. A 150-page document filled with "consider the following..." implementation suggestions would have made certification inconsistent: some auditors would have treated the suggestions as mandatory; others would have ignored them entirely.

A guidance document, by contrast, has to be detailed. Practitioners need enough specificity to actually implement controls without hiring a consultant for every clause. Collapsing all that implementation detail into the certifiable standard would have ballooned the audit scope and made certification impractical for smaller organizations.

The 2022 revision aligned the two documents tightly. ISO 27001:2022 Annex A is now a one-to-one mirror of the ISO 27002:2022 control set. Before 2022, the mapping between the two had gaps. That gap is now closed.

What the 2022 revision changed

The 2022 revision made three structural changes worth understanding before you start an implementation:

1. Control consolidation. The control count dropped from 114 (in the 2013 edition) to 93. The reduction came from merging overlapping controls, not from removing requirements. If you are migrating from a 2013-based ISMS, your existing controls likely cover the merged set already.

2. New grouping. The 2013 edition organized controls into 14 domains (A.5 through A.18). The 2022 edition replaces those domains with four themes: Organizational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). The structure is cleaner and maps better to how security teams are actually organized.

3. New controls. Five controls appear in 2022 that had no direct equivalent in 2013. These are the gaps that organizations certified on the 2013 standard needed to close before the transition deadline:

The transition deadline was 31 October 2025. Organizations that had not migrated to ISO 27001:2022 by that date have certifications that are no longer valid under the 2022 standard.

The four themes of ISO 27002:2022

Every one of the 93 controls belongs to exactly one of these four themes.

Organizational controls (37 controls) cover governance, policy, and management-level processes: information security policies, segregation of duties, contact with authorities, threat intelligence, project management security, asset inventory and classification, access control policy, identity and access management, supplier security, ICT readiness for business continuity, intellectual property, and privacy and PII protection.

People controls (8 controls) cover the human side of security: pre-employment screening, employment terms and conditions, security awareness education and training, disciplinary process, responsibilities on termination, confidentiality or non-disclosure agreements, remote working, and information security event reporting.

Physical controls (14 controls) cover facility and hardware security: physical security perimeters, entry controls, securing offices rooms and facilities, physical security monitoring, protecting against physical and environmental threats, working in secure areas, clear desk and clear screen policy, equipment siting and protection, off-site asset security, storage media, supporting utilities, cabling security, equipment maintenance, and secure disposal or re-use.

Technological controls (34 controls) cover technical implementation: user endpoint devices, privileged access rights, information access restriction, source code access, secure authentication, capacity management, malware protection, technical vulnerability management, configuration management, deletion of information, data masking, data leakage prevention, backup, redundancy, logging, monitoring, clock synchronization, use of privileged utility programs, software installation on operational systems, network controls, network segregation, web filtering, cryptography, secure development life cycle, application security requirements, secure system architecture and engineering principles, secure coding, security testing in development, outsourced development, separation of development environments, change management, test information, and information systems audit protection.

How auditors use ISO 27001 and ISO 27002

In a certification audit, the auditor's reference document is ISO 27001. They work through clauses 4 through 10 and then check the Statement of Applicability against Annex A. A standard Stage 2 audit includes questions like:

• Is the ISMS scope documented and approved by leadership?
• Does the organization have a documented risk assessment methodology?
• Does the Statement of Applicability address every Annex A control, with documented justification for any exclusions?
• Are objectives documented and tracked? Have they been reviewed?
• Has the organization completed an internal audit of the ISMS?
• Has management reviewed the ISMS at planned intervals and documented the outcomes?
• Have identified non-conformities been corrected?

None of those questions cite ISO 27002. ISO 27002 does not appear in the audit checklist.

Where ISO 27002 matters is in the evidence. If your Statement of Applicability says you have implemented control 5.15 (access control), the auditor will ask to see how access control actually works in your environment. They are not checking your implementation against ISO 27002, but if your implementation was built without ISO 27002 as a reference, it is likely to be thin. ISO 27002 tells you that an access control policy should cover topics like access provisioning, access review cycles, privileged access separation, and segregation of duties. Implementations that cover those specifics hold up better under scrutiny than implementations that just say "we manage access."

For a closer look at what auditors actually examine, see our ISO 27001 internal audit guide.

Which document do you need first

The right starting point depends on what you are doing:

• Building toward certification: start with ISO 27001. Clauses 4 through 10 define what your ISMS must contain. Annex A defines the control set your Statement of Applicability must address. You cannot pass a certification audit without it.

• Implementing a specific control: start with ISO 27002. Each control entry includes purpose, attribute tags, implementation guidance, and considerations for different organizational contexts. You will apply ISO 27002 during the build phase, not the audit phase.

• Mapping your controls to another framework (SOC 2, NIST CSF, HIPAA): start with ISO 27002. Its full control descriptions map cleanly to other frameworks' control families. ISO 27001 Annex A is too abbreviated for a useful crosswalk.

• Writing policies from scratch: use ISO 27002 to determine what topics your policy needs to cover, then check ISO 27001 Annex A to confirm the policy satisfies the corresponding reference control.

If budget is a constraint and you are working with a consultant or auditor who already has ISO 27002, buying ISO 27001 alone is often sufficient. Your consultant will reference ISO 27002 when relevant.

How certification actually works

The seven-step certification path:

1. Buy ISO 27001:2022. Read clauses 4 through 10 and Annex A end to end before doing anything else.
2. Reference ISO 27002:2022. Use it as your implementation guide for each applicable Annex A control.
3. Run a gap assessment. Compare your current state against ISO 27001 clauses and each Annex A control.
4. Build the ISMS. Document scope, risk methodology, policies, procedures, and staff training.
5. Run an internal audit. Verify the ISMS is operating as described before engaging an external body.
6. Engage an accredited certification body. Stage 1 (documentation review) followed by Stage 2 (operating effectiveness audit, typically on-site).
7. Receive certification. Valid for three years with annual surveillance audits.

ISO 27002 does not appear on your certificate. It will not be cited in the audit report. But every well-implemented control in your ISMS should be traceable to ISO 27002 guidance.

For cost and timeline planning, see our ISO 27001 certification cost breakdown.

The rest of the ISO 27000 family

ISO 27001 and ISO 27002 are the two documents most organizations need. The broader family includes:

ISO 27005 is worth reading when you build your risk methodology. ISO 27017 and ISO 27018 are worth buying for cloud-heavy organizations that need to extend their ISMS to cover cloud service provider relationships.

Common mistakes to avoid

Claiming ISO 27002 certification. No such certificate exists. If a vendor tells you they are "ISO 27002 certified," that is either a miscommunication or a misrepresentation.

Skipping ISO 27001 because ISO 27002 looks more practical. You cannot pass a certification audit by referencing ISO 27002. The auditor checks ISO 27001.

Treating Annex A as a mandatory checklist. Every Annex A control can be excluded if your risk assessment justifies it and your Statement of Applicability documents the reasoning. Some small organizations legitimately exclude physical security controls because they have no on-premises infrastructure.

Running the 2013 version of ISO 27001 past October 2025. The 2013-to-2022 transition deadline set by IAF was 31 October 2025. If your organization's current certificate was issued under ISO/IEC 27001:2013, it should have been re-issued under the 2022 standard before that date. Check with your certification body if there is any ambiguity about the version your current certificate references.

Conflating ISO 27001 with SOC 2. ISO 27001 is a certification issued by an accredited certification body. SOC 2 is an attestation report issued by a licensed CPA firm under AICPA standards. They are structurally different: one produces a certificate, the other produces an audit report. They are not interchangeable even where their control sets overlap.

Frequently asked questions

Is ISO 27002 mandatory for ISO 27001 certification?

No. ISO 27002 is a guidance document, not a requirement. Auditors check compliance against ISO 27001 clauses and Annex A, not ISO 27002 sections. That said, most practitioners who implement controls in-house use ISO 27002 because ISO 27001's Annex A provides too little detail to build a working control from scratch.

Can I buy just one of the two standards?

Yes. ISO 27001 is the necessary purchase if your goal is certification. Buy ISO 27002 separately if you are doing the implementation work in-house. If a consultant or auditor is managing the implementation for you, they will typically reference ISO 27002 on your behalf and you may not need your own copy.

How much do ISO 27001 and ISO 27002 cost?

Both standards are sold through the ISO store at CHF-denominated prices. National standards bodies, ANSI in the US, BSI in the UK, AFNOR in France, DIN in Germany, sell the same documents in local currency at equivalent prices. Corporate licensing and multi-user packages are available directly through ISO.

What changed in the 2022 revision?

Control count dropped from 114 to 93 through merging. Controls were regrouped from 14 domains into four themes (Organizational, People, Physical, Technological). Five net-new controls were added: threat intelligence (5.7), cloud services (5.23), ICT readiness for business continuity (5.30), physical security monitoring (7.4), and secure coding (8.28). The main clauses of ISO 27001 also received tighter language around clause 6.1.3 (information security risk treatment options) and clause 6.2 (information security objectives).

Does NIST CSF align with ISO 27002?

Yes, the overlap is well-documented. NIST publishes informative references mapping CSF 2.0 subcategories to various standards including ISO/IEC 27001:2022 controls. Organizations that hold ISO 27001 certification frequently use the NIST CSF mapping to communicate framework maturity to US-based stakeholders. For a full side-by-side, see our NIST CSF vs ISO 27001 guide.

Should I get ISO 27002 if my consultant already has it?

Usually no. If your consultant is doing the implementation work, they will quote the relevant ISO 27002 guidance when it matters. Buy your own copy if you are building the ISMS without outside help, want to train an internal security team, or plan to run future internal audits without a consultant.

What is the Statement of Applicability?

The Statement of Applicability (SoA) is the document that lists all 93 Annex A controls, states whether each one is implemented or excluded, and provides justification for any exclusion. It is one of the first documents an auditor asks for. ISO 27002 is useful when writing the SoA because it gives you enough context about each control to write a meaningful justification rather than a one-line placeholder.

Where to go next

ISO 27001 is the certifiable standard your auditor checks against. ISO 27002 is the implementation manual your team uses when actually building controls. They are a matched pair, not alternatives. Buy ISO 27001 first, use ISO 27002 alongside it during implementation, and remember that no certificate ever says "ISO 27002 certified" because no such certification exists.

With the 2022 revision now mandatory and the October 2025 transition deadline behind us, every organization pursuing or maintaining certification should be working from the 2022 versions of both documents.

For the full certification roadmap, start with our ISO 27001 certification guide and follow through to the ISO 27001 Statement of Applicability template.

Sources used

1. International Organization for Standardization, accessed 2026-05-12
2. ISO/IEC 27002:2022, accessed 2026-05-12
3. 2022 revision, BSI Group, accessed 2026-05-12
4. NIST Cybersecurity Framework, accessed 2026-07-03
5. ISO store, accessed 2026-05-12

Last reviewed: 2026-05-12. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.

SOX compliance is the set of internal control, financial reporting, and audit obligations imposed by the Sarbanes-Oxley Act of 2002 on every company that files financial statements with the U.S. Securities and Exchange Commission. It is the most consequential corporate governance law passed in the United States in the last 25 years, and it applies the moment your company is publicly traded on a U.S. exchange.

This guide is written for CFOs, controllers, internal audit leads, IT general controls (ITGC) owners, and founders preparing for an IPO. It covers what SOX actually requires in 2026, the difference between the 302, 404, and 906 certifications, the real cost ranges, how the audit works end-to-end, and where SOX intersects with the SOC 2 program you already run.

Most companies underestimate the lift. SOX is not a one-time audit. It is a continuous control environment that runs every fiscal quarter, evidenced through every general ledger close, every privileged access review, and every change-management ticket. Then a Big Four (or Big-Four-adjacent) external auditor tests it and writes an opinion your shareholders read.

For specific audit mechanics, see how compliance audits work. For the ITGC-specific work that lands on engineering teams, see NIST 800-53 controls. If you already run SOC 2 and are wondering what carries over, jump to the SOC 2 compliance guide.

What is SOX compliance?

SOX is short for the Sarbanes-Oxley Act, the federal statute Congress passed in July 2002 after the Enron, WorldCom, and Tyco accounting scandals. The Act has 11 titles and over 60 sections, but for compliance practitioners three sections drive the day-to-day work:

• Section 302: Corporate Responsibility for Financial Reports. Quarterly attestation by the CEO and CFO that the company's financials fairly present its condition and that they are responsible for the internal controls behind those financials.
• Section 404: Management Assessment of Internal Controls. Annual report on the effectiveness of internal control over financial reporting (ICFR). For accelerated and large accelerated filers, the external auditor must also issue a separate opinion on ICFR.
• Section 906: Corporate Responsibility for Financial Reports (criminal). Knowing or willful false certification carries fines up to $5 million and imprisonment up to 20 years.

The SEC enforces SOX. The Public Company Accounting Oversight Board was created by the Act to oversee public-company auditors. The combination is what gives SOX its bite: every dollar of revenue that flows to the financial statements has to be backed by an evidence trail that survives external testing, every year.

SOX is not a certification. There is no "SOX certified" stamp. What exists is your annual 10-K filing, which includes management's Section 404 report and, for larger filers, the auditor's ICFR opinion. Those two documents are the public record of your SOX program.

Why SOX matters in 2026

SOX matters because it is non-discretionary. The moment your company is required to file periodic reports with the SEC (typically the quarter after your IPO closes), the clock starts. For accelerated filers, the auditor ICFR attestation under Section 404(b) kicks in by the end of the second fiscal year as a public company. For non-accelerated filers, only management's Section 404(a) assessment is required, but the underlying control work is the same.

Three things have changed the SOX landscape since 2020:

The 2023 SEC cybersecurity disclosure rules. In July 2023, the SEC adopted final rules requiring registrants to disclose material cybersecurity incidents on Form 8-K within four business days and to disclose their cybersecurity risk management, strategy, and governance in annual Form 10-K filings. This is technically separate from SOX, but in practice the ICFR processes that SOX requires now have a cybersecurity overlay. If a breach materially affects financial reporting, your SOX program has to be able to detect it.

Continuous auditing expectations. The PCAOB's auditor guidance now expects something closer to continuous monitoring than the old annual sample-and-test model. Auditors expect to see automated evidence collection, exception-based reviews, and remediation evidence trails, not screenshots assembled the week before fieldwork.

Vendor concentration. A typical mid-cap SaaS company runs Oracle NetSuite, Workday, Salesforce, Stripe, Snowflake, and 30+ other applications inside ICFR scope. SOX testing now includes vendor SOC 1 Type 2 reports for every in-scope service organization. The SOC 1 report from your revenue recognition platform is now as important as your own access reviews.

SOX requirements and the COSO control framework

SOX itself does not prescribe a control framework. The SEC's implementing rules (specifically Item 308 of Regulation S-K) require management's ICFR assessment to use a "suitable, recognized framework". The framework that essentially 100% of U.S. public companies use is the COSO Internal Control: Integrated Framework, originally published in 1992 and updated in 2013.

COSO defines five components of internal control:

In a typical mid-cap SOX program, the control inventory runs 250 to 600 controls. Roughly 60% sit in finance and operations (the "business-process controls"), and the remaining 40% sit in IT (the IT general controls, or ITGCs).

The IT side is where SOX overlaps most heavily with the security frameworks SCG covers in depth. ITGCs concentrate in four families: logical access, change management, computer operations, and system development. The mapping to NIST SP 800-53 access controls (AC family) and configuration management (CM family) is essentially 1:1. If you already operate a SOC 2 program, 70-80% of your ITGCs are already running. They just need to be tied to financially-relevant systems and tested at SOX cadence.

SOX audit cost and timeline

SOX is expensive, and the cost scales with company size, control count, and auditor tier. The Financial Executives Research Foundation 2024 Audit Fee Survey (linked here via SEC's comment file because the underlying report is paywalled) put median total audit fees for U.S. public companies at $2.4M for accelerated filers and $700K for smaller reporting companies. The SOX-specific component of those fees, separate from the financial statement audit, averages 25-35% of the total.

For a first-time SOX program at a newly-public mid-cap SaaS company, a realistic 2026 budget looks like:

• Internal team: $400K to $1.2M for a director-level SOX lead, two senior managers, and an analyst (compensation only; loaded cost is higher).
• External SOX advisory firm: $200K to $600K to help build the control matrix, walk through the controls in year one, and prepare for the auditor's testing.
• External audit ICFR opinion (Section 404(b)): $300K to $900K in incremental audit fees on top of the financial statement audit.
• Technology: $100K to $400K annually for a governance, risk, and compliance (GRC) platform such as Workiva, AuditBoard, or LogicGate that holds the control library, evidence, and testing workflow.

Total year-one cost for a typical post-IPO SaaS company: $1M to $3M, with year two and beyond settling 30-40% lower as the program matures.

Timeline-wise, a first-year SOX program follows this rough sequence:

• Months 1-3: Scoping (which entities, accounts, processes, and systems are in scope), risk assessment, materiality calculations.
• Months 3-6: Control design (writing the controls), walkthroughs (auditors observe the control in operation once), and remediation of design gaps.
• Months 6-12: Operating effectiveness testing (auditors test multiple instances of each control across the fiscal year), management's assessment, audit committee review.
• Year-end + 60 to 90 days: 10-K filing with management's Section 404 report and (for accelerated filers) the auditor's ICFR opinion.

SOX process: the standard 9-step workflow

Every SOX program, from the first year through year 20, follows the same essential workflow. The terminology varies by firm. The structure does not.

Step 1. Scoping. Identify which entities are in scope (typically every consolidated subsidiary that materially contributes to revenue or specific accounts), which financial accounts cross the materiality threshold, and which processes generate those accounts.

Step 2. Risk Assessment. Map each in-scope process to its inherent risks of material misstatement. Output is a Risk and Control Matrix (RACM), the spine of the entire program.

Step 3. Control Identification. For each risk, identify the controls that mitigate it. Distinguish preventive vs. Detective, manual vs. Automated, key vs. Non-key. Most programs end up with 250-600 key controls.

Step 4. Walkthroughs. Auditor observes each key control in operation once. Confirms the control is designed to mitigate the risk.

Step 5. Operating Effectiveness Testing. For each key control, auditor selects a sample (typically 25-60 instances depending on control frequency) across the fiscal year and tests whether the control operated as designed each time.

Step 6. Deficiency Evaluation. Any failed control test becomes a deficiency. Deficiencies are aggregated and rated: a "control deficiency", "significant deficiency", or "material weakness". Each with different SEC disclosure consequences. A material weakness must be disclosed in the 10-K.

Step 7. Remediation. Fix design or operating effectiveness gaps. Document fixes and re-test where the timing allows.

Step 8. Management's Assessment. CFO and SOX lead conclude on ICFR effectiveness as of fiscal year end. The conclusion goes into the 10-K as the Section 404(a) report.

Step 9. Auditor ICFR Opinion (accelerated filers only). External auditor issues an integrated audit opinion covering both the financial statements and ICFR. This is the Section 404(b) report.

The cycle then repeats. Most teams run a parallel control re-design effort every year to retire low-value controls, consolidate redundant ones, and add new controls for new systems and processes.

SOX vs related frameworks

The overlap with security and privacy frameworks is one of the most underrated dimensions of SOX. If you already run other compliance programs, much of the work is shared.

SOX vs SOC 2. SOC 2 reports are about controls at a service organization that affect its customers. SOX is about controls at a publicly-traded company that affect its own financial statements. They share roughly 70% of their IT general controls. Access reviews, change management, backup and recovery, vendor management. The difference is scope and audience: SOC 2 is for buyers; SOX is for shareholders. See our detailed the SOC 2 compliance guide for a control-by-control mapping.

SOX vs SOC 1. This is the more direct overlap. A SOC 1 report is specifically about a service organization's controls that are relevant to its customers' ICFR. If you are a publicly-traded company that uses Workday for payroll, Workday's SOC 1 Type 2 is what your auditors rely on to test the controls inside Workday. As a service provider, generating a SOC 1 Type 2 is essentially what's needed to be "SOX-friendly" for your enterprise customers.

SOX vs NIST 800-53. NIST SP 800-53 is the federal control catalog used primarily by U.S. Government systems. The IT general control families in SOX map cleanly to NIST 800-53's Access Control (AC), Audit and Accountability (AU), Configuration Management (CM), and Identification and Authentication (IA) families. Companies that operate in both spaces (e.g., federal contractors with public equity) typically design their controls against NIST 800-53 and let SOX inherit.

SOX vs ISO 27001. ISO/IEC 27001 covers information security management broadly. SOX cares about controls that affect financial reporting specifically. The ISO 27001 Annex A controls in A.5 (access control), A.8 (asset management), and A.12 (operations security) overlap meaningfully with SOX ITGCs, but the framing is different: ISO 27001 is about protecting information assets; SOX is about ensuring financial statements are accurate.

SOX for different organization types

Newly public SaaS companies. Year one is the hardest. The control library doesn't exist yet, the GRC tooling isn't deployed, and the auditor is asking for walkthroughs of processes that have been informal until last quarter. Expect to add headcount equivalent to one to two FTEs in finance and a dedicated SOX program lead. The advantage is that SaaS revenue models are simpler than physical-goods businesses (no inventory, no complex revenue cutoffs), so the business-process control count is lower.

Late-stage privates considering an IPO. SOX readiness should start 18-24 months before the planned filing. Companies that wait until S-1 work begins end up paying 2-3x more to retrofit controls under deadline pressure. The "SOX readiness assessment" sub-niche (covered in our build-compliance-program guide) is built around this work.

Foreign private issuers. FPIs (foreign companies listed on U.S. exchanges) are subject to SOX with some modifications, including a longer timeline before the auditor ICFR attestation kicks in. The PCAOB inspects auditors of FPIs the same way it inspects U.S. auditors.

Subsidiaries of public companies. If your private company is owned by a public parent, you may be a "key location" in the parent's SOX program. Expect the parent's internal audit team to run walkthroughs and testing at your operations, even if your entity itself never files with the SEC.

Common pitfalls (and how to avoid them)

Over-scoping in year one. New SOX programs often include every account and process "to be safe". This produces 800+ controls, all of which need to be designed, walked through, and tested. By year three the inventory is unsustainable. The fix is rigorous quantitative scoping. Accounts below 5% of materiality are excluded; processes with strong compensating controls upstream are de-scoped.

Manual evidence collection. SOX auditors don't reject screenshots, but they prefer system-generated reports. Programs that ship a screenshot of an access review every quarter are working harder than they need to. Programs that automate evidence collection from the source system (Okta, AWS, Workday) and produce auditor-ready reports on demand spend half the testing-window time.

Mixing SOX testing into SOC 2 testing. It's tempting to test the same control once for both frameworks. Auditors are okay with shared testing for SOC 2 Trust Services Criteria, but SOX requires control population sampling specific to financial-relevance. A SOC 2 sample of 25 user-access reviews is not automatically a SOX sample. The two evidence sets need separation.

Treating SOX as an audit project. Year-one teams often staff SOX like a year-end project, with all hands during testing season and quiet between. Mature programs run continuously: month-end controls happen monthly, quarterly controls happen quarterly, the evidence is in the GRC platform within five days. There is no "SOX project end".

Ignoring entity-level controls. Entity-level controls (board oversight, code of ethics, anti-fraud program, whistleblower hotline) are often treated as paperwork. They are the first thing the auditor tests and the most common source of significant deficiencies in year one.

Tools and platforms for SOX

The SOX tooling market has consolidated around four major platforms that compete on different dimensions:

A typical implementation runs $100K to $400K annually depending on user count and modules. Smaller companies in year one often start with a structured spreadsheet (a "SOX binder") and migrate to a platform in year two once the control library is stable.

For broader compliance automation tooling. Including platforms that handle SOX alongside SOC 2, HIPAA, and ISO 27001. See our GRC software comparison. Vendors like Vanta, Drata, and Secureframe have started offering SOX-adjacent modules, but as of 2026 the dedicated SOX platforms (Workiva, AuditBoard) still own the public-company segment.

Frequently Asked Questions

Do private companies need to be SOX compliant?

No. SOX applies to companies that file periodic reports with the SEC, which means publicly-traded companies on U.S. exchanges and some foreign private issuers. Private companies have no SOX obligation unless they are subsidiaries of public companies, in which case the parent's SOX program may scope them in.

When does SOX Section 404(b) auditor attestation start?

For accelerated filers (public float between $75M and $700M) and large accelerated filers (above $700M), the auditor ICFR attestation under Section 404(b) is required starting with the second annual 10-K filing after becoming a reporting company. Non-accelerated filers (under $75M float) are permanently exempt from 404(b), though they still file management's 404(a) report.

What is the difference between a significant deficiency and a material weakness?

Both are control deficiencies. A significant deficiency is "less severe than a material weakness, yet important enough to merit attention by those responsible for oversight". Typically reported to the audit committee but not in the 10-K. A material weakness is "a deficiency, or combination of deficiencies, in ICFR, such that there is a reasonable possibility that a material misstatement... Will not be prevented or detected on a timely basis". Required disclosure in the 10-K and a serious signal to investors.

How is SOX compliance enforced?

By the SEC for civil enforcement and by the Department of Justice for criminal enforcement under Section 906. Failures range from required filing of restated financials, to civil penalties, to bars from serving as a public-company officer or director. Section 906 willful violations carry up to 20 years' imprisonment and $5M in fines.

Can a public company outsource its SOX program?

Parts of it, yes. The control design, testing execution, and remediation work can be done by external advisors (Big Four, RSM, BDO, mid-market firms). What cannot be outsourced is management's Section 302 and 404 certifications. Those must be signed by the CEO and CFO personally, who remain personally responsible for the conclusions.

Does SOX require specific cybersecurity controls?

SOX doesn't name cybersecurity controls explicitly. But the 2023 SEC cybersecurity disclosure rules and the COSO framework's information-and-communication component effectively require that the IT environment supporting financial reporting be protected against unauthorized access, change, and disclosure. In practice, this means ITGCs covering access management, change control, and data integrity for systems within SOX scope.

How long does a first-year SOX program take?

12 to 18 months from program kickoff to the first 10-K with a clean Section 404 report. The minimum is 9 months for a small reporting company with simple operations. Companies that try to do it in less typically end up with a material weakness disclosure or qualified auditor opinion in year one.

Bottom line

SOX is not optional, but it is manageable. The companies that struggle with it treat it as an annual audit project and add controls reactively. The companies that thrive with it treat it as a continuous control environment, build the evidence pipeline once, and let the auditors test what is already running.

For most newly-public SaaS companies, the right year-one move is to lean on the SOC 2 program already in place (which carries most of the ITGCs), invest in a GRC platform early (year two is too late), and put a director-level SOX lead in place before the first 10-K cycle begins. Year two costs settle 30-40% below year one, and by year three the program runs itself.

The companies that wait, retroactively staff up, and ship screenshots are the same companies that announce material weaknesses in year one. Stock prices drop on material weakness disclosures. The cost of doing SOX well is less than the cost of doing it badly.

For the operational specifics. The audit cost ranges, the readiness assessment work, the ITGC playbook, and the comparison to SOC 2. See the sub-pages of this guide.

Primary Sources

This article references the following authoritative sources:

• Sarbanes-Oxley Act of 2002 (full text). SEC-hosted statute
• Sarbanes-Oxley Act, Public Law 107-204. Library of Congress
• SEC Final Rule: Cybersecurity Disclosure (2023). Form 8-K cybersecurity disclosure requirement
• SEC Disclosure Guidance: Item 308 of Regulation S-K. ICFR framework requirement
• AICPA SOC 1 reporting framework. Service organization controls relevant to user-entity ICFR
• AICPA SOC 2 reporting framework. Context for the SOX/SOC overlap
• NIST SP 800-53 Rev 5. Referenced for IT general controls family mapping
• ISO/IEC 27001. Referenced for ITGC framework comparison

Zero Trust Architecture (ZTA) is a security model that treats every user, device, and network request as untrusted by default and forces explicit verification before any resource access is granted. The authoritative definition lives in NIST SP 800-207, the federal publication that turned a marketing phrase into an engineering blueprint.

This guide is written for CISOs, security architects, IT directors, and the engineering leads who actually have to make Zero Trust work on a Tuesday. It covers what NIST actually says, the seven tenets, the policy components, real cost and timeline ranges, how ZTA compares to a traditional perimeter model, and where most rollouts go wrong.

The reader is assumed to have read at least one vendor explainer already. We will not repeat the castle-and-moat metaphor. We will tell you what NIST 800-207 requires, how the CISA Zero Trust Maturity Model phases the work, and what a credible 18-month rollout looks like at a 2,000-employee company.

For the deeper dive into the federal standard, see our NIST 800-207 implementation guide. For the controls catalog that operationalizes most ZTA components, see NIST 800-53. For a broader compliance map, see the cybersecurity compliance guide.

What is Zero Trust Architecture?

Zero Trust Architecture is the federal term for a security design where trust is never granted implicitly based on network location. NIST SP 800-207 defines it as "an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources". In plain language: it does not matter whether a request comes from inside the corporate LAN, a coffee shop, or a partner network. Every request is evaluated on its own merits, every time.

The model rests on seven tenets from NIST SP 800-207:

1. All data sources and computing services are treated as resources.
2. All communication is secured regardless of network location.
3. Access is granted on a per-session basis.
4. Access is determined by dynamic policy that includes the observable state of the requester.
5. The enterprise monitors the integrity and security posture of all assets.
6. Authentication and authorization are dynamic and strictly enforced before access.
7. The enterprise collects telemetry on assets, infrastructure, and communications and uses it to improve posture.

The tenets are design principles, not a checklist. A real ZTA is the set of identity systems, device posture engines, segmentation, access proxies, and data controls that together satisfy them for every resource.

The model also names three logical components:

• Policy Engine (PE): the brain. Takes signals (identity, device health, behavior, threat intelligence) and outputs an access decision.
• Policy Administrator (PA): the executor. Establishes or tears down the session based on the PE's decision.
• Policy Enforcement Point (PEP): the gatekeeper. Sits inline with the resource and either passes or blocks the request.

Whether the resource is an SSH server, a SaaS app, a database, a Kubernetes pod, or a network segment is irrelevant to the model.

Why Zero Trust matters in 2026

The perimeter model has been dead for a decade and the breach data finally caught up with the architects.

Three forces moved Zero Trust from buzzword to mandate:

Federal direction. Executive Order 14028, signed May 2021, directed federal civilian agencies to adopt Zero Trust. The follow-on OMB Memorandum M-22-09 set deadlines across identity, device, network, application, and data pillars. The DoD Zero Trust Reference Architecture extended this to defense systems with a 2027 target. When the federal government writes a deadline, the contractor ecosystem follows.

Breach economics. Stolen credentials have been a top attack vector for over a decade. A perimeter model assumes attackers stay outside; the breach data says they walk in with valid credentials and pivot laterally. Zero Trust removes lateral movement because every internal hop requires its own authorization.

The hybrid workforce. Most security teams no longer manage a network. They manage identity, devices, and access across hundreds of SaaS applications, a few cloud providers, and a residual data center. The NIST Cybersecurity Framework 2.0 now references Zero Trust directly in its Protect function. CISA's Zero Trust Maturity Model v2.0 provides a phased path across five pillars.

The cost of a credential-based intrusion that pivots inside a flat network for 30 days is routinely 8 figures. The cost of a phased Zero Trust rollout is materially less.

Zero Trust requirements and the five pillars

NIST defines the architecture. CISA's Zero Trust Maturity Model operationalizes it into five pillars, each scored across four maturity stages (Traditional, Initial, Advanced, Optimal). The five pillars are the practical scope of any rollout.

Most enterprises start at Traditional or Initial across all five pillars. Reaching Advanced across the board is a 24 to 36 month journey at a typical 2,000-employee company. Optimal is a multi-year program that few organizations actually complete; the public sector targets it because executive orders require it.

Two cross-cutting capabilities support the pillars: visibility and analytics, and automation and orchestration. Without those, the pillars produce a more expensive version of the legacy architecture with a fresh coat of vendor paint.

Most ZTA controls map directly to control families in NIST SP 800-53: Access Control (AC), Identification and Authentication (IA), Audit and Accountability (AU), and System and Communications Protection (SC). If you already run a NIST 800-53 or NIST 800-171 program, 60 to 70% of your ZTA controls are already specified. They need to be re-architected around per-request decisioning, not perimeter trust.

Zero Trust Architecture cost and timeline

Zero Trust costs scale with company size, application portfolio, and how much legacy network has to be retired. For a representative 2,000-employee company with mixed on-prem and cloud, a credible 2026 budget looks like:

• Identity stack upgrade: $200K to $800K for phishing-resistant MFA, modern IdP (Okta, Entra ID, Ping), and a privileged access management platform.
• Endpoint and device posture: $150K to $500K annually for EDR, MDM, and posture-as-a-signal integration.
• ZTNA (Zero Trust Network Access): $100K to $400K annually for a ZTNA platform (Cloudflare Access, Zscaler ZPA, Netskope, Palo Alto Prisma Access, Tailscale).
• Microsegmentation: $200K to $1M for east-west segmentation tooling (Illumio, Akamai Guardicore, native cloud constructs).
• Internal program: $500K to $1.5M for a director-level lead, two architects, and a PM for the 18-month rollout.
• External advisory: $200K to $700K for a systems integrator in year one.

Total year-one cost for a mid-market enterprise: $1.5M to $4M, settling at $1M to $2.5M annually in steady state.

A representative 18-month rollout:

• Months 1-3: Discovery and scoping. Identify protect surfaces, map access flows, baseline against the CISA model.
• Months 3-6: Identity foundation. Phishing-resistant MFA everywhere, PAM deployed, IdP modernized.
• Months 6-9: Device posture and ZTNA. EDR-to-Policy-Engine integration live, ZTNA fronts the top 20 apps, VPN scope reduced.
• Months 9-15: Microsegmentation and workload identity. East-west segmentation, workload identity for production, secrets management consolidated.
• Months 15-18: Data layer. Classification, DLP integration with access decisions, analytics pipeline tuned.

Companies that try to compress this into 6 months end up with a vendor product, not an architecture.

Zero Trust process: the standard 8-step workflow

Every Zero Trust rollout, whether at a 200-person startup or a 200,000-person bank, follows a similar workflow. The terminology varies. The order does not.

Step 1. Identify the protect surface. List the resources whose compromise would actually hurt the business: customer data stores, source code, financial systems, admin consoles, production secrets. The protect surface is always smaller than the attack surface. Design starts there.

Step 2. Map the transaction flows. For each protect-surface resource, document who accesses it, from where, with what device, and what they do with it. The map will be incomplete in year one. Instrument the rest, revisit quarterly.

Step 3. Architect the environment. Place a PEP in front of each protect-surface resource. Decide which PEP technology fits: identity-aware proxy, ZTNA broker, service mesh, microsegmentation gateway, API gateway. Most enterprises end up with three to five PEP technologies.

Step 4. Write the policy. For each resource, define what the Policy Engine evaluates: who, what, when, where, why. Start coarse (role-based) and refine toward attribute-based decisions over time.

Step 5. Implement the Policy Engine. Consolidate signals: identity from the IdP, device posture from EDR, threat intelligence, behavior analytics. Most enterprises use their IdP as the foundational PE.

Step 6. Pilot and migrate. Pick three to five high-value applications and front them with the new PEPs. Migrate users in phases. Keep VPN running in parallel until pilots stabilize.

Step 7. Monitor and adapt. Instrument every access decision. Build dashboards for denied access by resource, user, and reason. Tune policy to reduce false positives.

Step 8. Expand the protect surface. Add the next tranche of resources. Retire legacy perimeter controls. Re-baseline against the CISA model annually.

Zero Trust is an operating model, not a project. Treat it as a project and the work piles up in years two and three.

Zero Trust vs related frameworks

Zero Trust overlaps with, but does not replace, several adjacent frameworks. Understanding the relationships avoids duplicate work.

Zero Trust vs SASE. Secure Access Service Edge (SASE) is a converged network and security edge, usually from a single vendor. Zero Trust is the architectural philosophy. ZTNA is one component of a SASE offering, alongside SWG, CASB, FWaaS, and SD-WAN. Most enterprises end up with SASE as the delivery vehicle for the network-layer pieces of their ZTA.

Zero Trust vs the NIST Cybersecurity Framework. The NIST Cybersecurity Framework 2.0 has six functions: Govern, Identify, Protect, Detect, Respond, Recover. Zero Trust lives primarily inside Protect, with overlap into Identify and Detect. CSF tells you what outcomes matter; ZTA tells you how to design the access layer to deliver them.

Zero Trust vs NIST 800-53. NIST SP 800-53 is the control catalog. ZTA is the architecture. The AC, IA, and SC control families specify what a ZTA must implement. Agencies and contractors who already document against 800-53 have most of the control text written.

Zero Trust vs ISO 27001. ISO/IEC 27001 covers information security management broadly. ZTA is one design choice within Annex A, particularly A.5 (organizational controls), A.8 (technological controls), and A.5.15 (access control). ISO 27001 does not require Zero Trust.

Zero Trust vs ZTNA. ZTNA is a product category. Zero Trust is the architecture. ZTNA replaces or augments VPN by giving identity-aware, application-level access without exposing the network. Deploying ZTNA without addressing identity, device, application, and data pillars produces a more granular VPN, not Zero Trust.

Zero Trust for different organization types

SaaS companies. Greenfield environments have the easiest path. Identity is cloud-native, the application portfolio is mostly SaaS with SSO and SCIM, and production supports service mesh and workload identity. The hardest part is usually privileged access to production. SaaS programs hit Advanced maturity on identity and applications within 12 months; data classification and device posture lag.

Enterprises with legacy data centers. The cost is in the network and application pillars. Microsegmenting a 20-year-old data center is expensive, slow, and politically painful. Scope Zero Trust to the cloud and modern apps first, then expand backward as legacy systems retire. The DoD reference architecture accepts a multi-year transition.

Healthcare. HIPAA does not require Zero Trust, but the Security Rule's access, audit, and integrity requirements map cleanly to ZTA capabilities. Most healthcare programs start with privileged access to electronic health records.

Federal agencies and contractors. Zero Trust is no longer optional. The federal executive order and OMB M-22-09 set deadlines that have largely passed. Contractors handling CUI must align with NIST SP 800-171, and CMMC Level 2 assessments include Zero Trust-aligned expectations.

SMBs and startups. Below 250 employees, full Zero Trust is overkill. The pragmatic version: phishing-resistant MFA, an IdP with SSO to every SaaS app, EDR on every endpoint, ZTNA in place of VPN, and a written policy that says no implicit trust based on network location. That is 80% of the benefit at 10% of the cost. Build a compliance program on top once the foundation is in place.

Common pitfalls (and how to avoid them)

Treating Zero Trust as a product purchase. Vendors sell Zero Trust like it is a SKU. Buying a ZTNA platform and declaring victory leaves the device, application, and data pillars unaddressed. Start with an architecture document, not an RFP.

Skipping the protect surface exercise. Teams that try to do Zero Trust to "everything" never finish. Start with the small set of resources where access matters most. Expand later.

Failing to consolidate signals. Zero Trust depends on the Policy Engine seeing identity, device, behavior, and threat signals together. Most enterprises run those in silos. Signal integration is often 30% of the program cost and the part most consistently underestimated.

Killing VPN too fast. ZTNA replaces VPN for application access, not for legacy network access (broadcast, multicast, specialized protocols). Plan for a 24-month parallel run. Retire VPN at 12 months and you reinstall it for the long tail.

Ignoring the operations cost. A Policy Engine that denies the wrong request silently is worse than no Policy Engine. Budget a deny-decision review queue, a fast escalation path, and dashboards. At least 1 FTE per 5,000 employees in steady state.

Forgetting the data pillar. Most rollouts get identity, devices, and networks right. Data classification, DLP, and rights management consistently lag. The optimal end state requires access decisions to include data sensitivity, which requires tagging at scale.

Tools and platforms for Zero Trust

The Zero Trust tooling market is fragmented because the architecture spans five pillars. No single vendor credibly covers all five. The pragmatic approach is a stack of best-of-breed tools, integrated through a Policy Engine that consumes their signals.

Credible Zero Trust outcomes typically run 6 to 12 distinct tools across these pillars, glued together through an IdP that acts as the central Policy Engine and a SIEM or analytics platform that collects telemetry. The integration work, not the tool purchase, is the real program cost.

For the GRC platforms that wrap around Zero Trust programs, see our cybersecurity compliance guide. For the deeper federal-standard view, see the NIST 800-207 implementation guide.

Frequently Asked Questions

What are the five pillars of Zero Trust architecture?

The five pillars come from the CISA Zero Trust Maturity Model: Identity, Devices, Networks, Applications and Workloads, and Data. Two cross-cutting capabilities, Visibility and Analytics and Automation and Orchestration, support all five. Each pillar is scored across four maturity stages (Traditional, Initial, Advanced, Optimal), and a credible Zero Trust program advances across all five pillars in parallel rather than perfecting one before starting the next.

What is the NIST standard for Zero Trust architecture?

NIST SP 800-207, published in August 2020, is the authoritative federal standard. It defines Zero Trust Architecture, lists seven tenets, describes the logical components (Policy Engine, Policy Administrator, Policy Enforcement Point), and outlines deployment variants. NIST SP 1800-35 provides practical implementation guidance with vendor-validated build examples.

What are the three components of Zero Trust architecture?

The Policy Engine decides whether to grant access based on policy and signals. The Policy Administrator establishes or shuts down the communication path between the requester and the resource. The Policy Enforcement Point sits in front of the resource and either passes or blocks traffic. All three are logical roles; in practice they are often combined into one product but the architectural separation matters for clarity and for understanding what the vendor is actually selling you.

Is ZTNA replacing VPN?

For most application access use cases, yes. ZTNA gives users access to specific applications rather than to a network segment, which limits lateral movement and aligns with the per-resource access principle in NIST 800-207. For legacy use cases that genuinely need network-level access, broadcast protocols, specialized industrial systems, certain telephony, VPN persists. The typical enterprise pattern in 2026 is ZTNA for 90% of access, retained VPN for the 10% edge cases.

How long does a Zero Trust rollout take?

Realistically, 18 to 36 months to reach Advanced maturity across the five CISA pillars at a 2,000-employee company. Smaller cloud-native companies can hit Advanced in 12 months because they have less legacy to retire. Large enterprises with extensive on-premises footprint plan for 3 to 5 years. Optimal maturity is a long-term aspiration; very few commercial organizations actually reach it.

Does Zero Trust require microsegmentation?

Not strictly. NIST 800-207 does not mandate any specific technology. Microsegmentation is one way to implement the network pillar; identity-based ZTNA is another. Most mature deployments combine both: ZTNA for user-to-application access, microsegmentation for east-west workload-to-workload traffic. Skipping segmentation entirely leaves lateral movement on the table inside the network, which violates the per-resource access tenet.

How much does Zero Trust cost?

For a mid-market enterprise (around 2,000 employees), expect $1.5M to $4M in year one and $1M to $2.5M annually in steady state. The cost varies by how much identity, EDR, and network tooling is already in place and how much legacy network architecture has to be segmented. The largest hidden cost is integration: getting signals from the device, identity, and network tools into a single Policy Engine that can make real-time decisions.

Bottom line

Zero Trust is not a product, a vendor, or a project with an end date. It is an operating model that assumes every request is untrusted until proven otherwise, every session is reauthorized, and every resource has a policy in front of it. The federal standard is NIST SP 800-207, the operational path is the CISA Maturity Model, and the controls map cleanly to NIST 800-53.

For most enterprises, the right move is phased: start with identity and device posture in months 1 to 9, deploy ZTNA against the top applications in months 6 to 12, then expand into microsegmentation and the data pillar over months 12 to 24. Budget $1.5M to $4M for year one and accept that signal integration, not tool selection, is the real work.

Treat Zero Trust as a vendor purchase and you get a more expensive perimeter. Treat it as an architecture, scoped to a protect surface and operated as a real function, and you get a security posture that matches how you actually work in 2026.

Primary Sources

This article references the following authoritative sources:

• NIST SP 800-207: Zero Trust Architecture. The federal definition, seven tenets, and logical components.
• CISA Zero Trust Maturity Model v2.0. Five-pillar phased model with maturity-stage indicators.
• NIST SP 800-53 Rev 5. Control catalog that operationalizes most ZTA capabilities.
• NIST Cybersecurity Framework 2.0. Risk management framework that Zero Trust supports within the Protect function.
• NIST SP 800-171 Rev 3. Controlled Unclassified Information controls relevant to federal contractors.
• OMB Memorandum M-22-09: Federal Zero Trust Strategy. Federal agency mandate and pillar definitions.
• Executive Order 14028: Improving the Nation's Cybersecurity. The 2021 order that put Zero Trust on the federal agenda.
• NIST SP 1800-35: Implementing a Zero Trust Architecture. Practical, vendor-validated implementation guidance.

Most small business owners hear "NIST" and assume it is paperwork built for federal agencies. It is not. The NIST Cybersecurity Framework was rewritten in 2024 specifically so a 12-person company could implement it without a CISO, and the federal contracting world (CMMC, NIST 800-171) is increasingly pulling small subcontractors into scope whether they planned for it or not. The cost of ignoring it is no longer "we are too small to matter."

This guide is a practical NIST compliance checklist for small businesses: which framework applies (CSF, 800-171, 800-53), the controls that actually move the needle, and the order to implement them in. By the end you will have a working list you can run with a one-person IT lead and a small budget.

Which NIST framework applies to a small business?

Small businesses run into one of three NIST publications, and the right starting point depends on whether you sell to the federal government:

• NIST Cybersecurity Framework (CSF) 2.0, voluntary, the right starting point for almost every commercial small business. Six functions, 22 categories, no certification required.
• NIST 800-171, mandatory if you handle Controlled Unclassified Information (CUI) for a federal contract. 110 controls, third-party assessment via CMMC 2.0.
• NIST 800-53, federal agencies and their direct contractors. 1,000+ controls. Almost certainly out of scope for a small business unless you are pursuing FedRAMP.

If you do not have federal contracts, you want NIST CSF 2.0. If you do have federal contracts and they touch CUI, you want NIST 800-171. For background on each, see NIST cybersecurity framework guide and NIST 800-171 compliance guide.

According to the SBA, 43% of cyberattacks now target small businesses, and 60% of small businesses that suffer a major breach close within six months. NIST compliance is no longer a "big company" exercise.

NIST Cybersecurity Framework 2.0: the small business checklist

NIST CSF 2.0 organizes controls into six functions. Each is broken into categories and subcategories. For a small business, you can land 80% of the value with about 30 specific actions across these functions.

Function 1: Govern (GV), set the foundation

The Govern function is new in CSF 2.0 and is where small businesses fall down most often. It is also the cheapest to fix.

• [ ] Document a one-page cybersecurity policy. Owner, scope, how often it is reviewed.
• [ ] Identify a single accountable person for cybersecurity (often the founder or COO at small companies).
• [ ] Define what counts as an incident and who decides to escalate.
• [ ] Maintain a list of legal and regulatory requirements (state breach laws, HIPAA, PCI, contract clauses).
• [ ] Run a cyber risk discussion at least annually with leadership.

For most small businesses, the entire Govern function is 4 to 8 hours of work.

Function 2: Identify (ID), know what you have

You cannot protect what you have not inventoried.

• [ ] Maintain an asset inventory: every laptop, server, cloud service, and SaaS subscription.
• [ ] Maintain a data inventory: customer data, employee data, financial data, and where each lives.
• [ ] Document who has access to what.
• [ ] Identify your top 5 cyber risks (e.g., business email compromise, ransomware, insider, vendor breach, lost device).
• [ ] Track vendor relationships that handle your data, with their security posture noted.

Function 3: Protect (PR), preventive controls

This is where most of the technical work happens. The list looks long but most controls are configuration changes, not capital projects.

• [ ] Enforce multi-factor authentication on email, identity provider, finance, and admin accounts.
• [ ] Use unique passwords stored in a password manager (1Password, Bitwarden), banned email/password reuse.
• [ ] Apply the principle of least privilege: no employee has more access than their role requires.
• [ ] Enable full-disk encryption on every laptop (FileVault on macOS, BitLocker on Windows).
• [ ] Patch operating systems and key applications within 30 days of release for critical vulnerabilities.
• [ ] Maintain endpoint protection (built-in Defender, or a small-business EDR like ThreatDown / SentinelOne).
• [ ] Configure email security: SPF, DKIM, DMARC published; phishing protection on.
• [ ] Train every employee at hire and annually on phishing, password hygiene, and incident reporting.
• [ ] Maintain backups of critical data: ideally 3-2-1 (three copies, two media, one offsite).
• [ ] Test backup restoration at least once a year.

Function 4: Detect (DE), see attacks early

Small businesses cannot afford a SOC, but you can afford basic detection.

• [ ] Centralize logs from key systems (identity provider, email, endpoint).
• [ ] Configure alerts on impossible logins, mass file deletion, and admin role changes.
• [ ] Subscribe to threat intelligence relevant to your industry (US-CERT, MS-ISAC for healthcare/education, FS-ISAC for finance).
• [ ] Run an external attack surface scan at least quarterly (free tier of Bitsight or Detectify is enough for a small footprint).

Function 5: Respond (RS), when something breaks

A 5-page incident response plan is enough for most small businesses.

• [ ] Document your incident response plan: roles, contact list, decision tree.
• [ ] Define notification thresholds: who calls the lawyer, who calls the customer, who calls law enforcement.
• [ ] Pre-arrange a relationship with an incident response firm (Mandiant, CrowdStrike, or a regional IR retainer). Many will sign a $0 retainer that just gets you priority phone access.
• [ ] Keep your cyber insurance contact information accessible offline.
• [ ] Run a tabletop exercise once a year, even if it is 60 minutes over coffee.

Function 6: Recover (RC), get back to business

• [ ] Document recovery time objectives (RTO) and recovery point objectives (RPO) for top 3 systems.
• [ ] Validate backup integrity at least quarterly.
• [ ] Maintain communications templates for customers, employees, and the press in case of a public incident.
• [ ] Review lessons learned after every minor incident, not just breaches.

For broader context, see our NIST CSF 2.0 changes guide.

Comparing NIST framework options for small businesses

For a comparison with other frameworks, see our NIST CSF vs ISO 27001 guide.

NIST 800-171 for small businesses with federal contracts

If a federal contract requires you to handle Controlled Unclassified Information (CUI), NIST 800-171 is mandatory. Under CMMC 2.0 (effective for many DoD contracts in 2025-2026), small businesses now need a third-party assessment for Level 2.

The 110 NIST 800-171 controls span 14 families. The implementation order most small businesses follow:

1. Access Control + Identification and Authentication. MFA on every CUI-touching system. Unique accounts for every user. No shared admin accounts.
2. Configuration Management. Hardened baselines for every device that touches CUI. Approved software list.
3. Audit and Accountability. Centralized logging with at least 90 days of retention.
4. Media Protection + Physical Protection. Encrypted storage, shredded paper, locked rooms.
5. System and Information Integrity. Endpoint protection, vulnerability scanning, patch management.
6. Awareness and Training. All staff trained on CUI handling. Documented annually.
7. Incident Response. Documented plan, tested at least annually.
8. Maintenance, Risk Assessment, Security Assessment. Annual cycles documented.

Budgeting: a small business pursuing CMMC Level 2 should plan $30,000 to $80,000 for the first year of preparation plus $20,000 to $50,000 for the assessment itself, depending on scope. According to a 2024 Department of Defense small business survey, the median cost for a 25-person contractor to reach CMMC Level 2 was $77,000.

A 90-day NIST CSF rollout plan

Small business owners reading this almost always want a sequence, not just a checklist. Here is the rollout most successful programs follow:

Days 1 to 14: Govern + Identify. Write the one-page policy, build the asset and data inventories, identify the top 5 risks. Cost: 12 to 20 hours of leadership time.

Days 15 to 45: Protect (technical baseline). Enforce MFA, deploy a password manager, enable full-disk encryption, configure email authentication (SPF, DKIM, DMARC), train all staff. Cost: $1,500 to $5,000 in tooling for a 25-person company.

Days 45 to 60: Protect (process). Document access reviews, hardening standards, and the patch cadence. Run a backup test.

Days 60 to 75: Detect. Centralize logs from your identity provider, email, and endpoint. Configure 5 to 10 alert rules.

Days 75 to 90: Respond + Recover. Write the 5-page incident response plan. Run a 60-minute tabletop. Validate backup restoration.

After 90 days a 25-person small business can credibly tell a customer or insurer "we follow NIST CSF", not as marketing, but as fact. According to a 2024 Coalition Insurance underwriting report, businesses with documented NIST CSF alignment received 18% to 30% lower premiums than those without.

Common NIST compliance mistakes small businesses make

A few traps that show up in nearly every small business engagement:

Treating NIST CSF as a binary status. It is not pass/fail. Each subcategory has implementation tiers (Partial, Risk Informed, Repeatable, Adaptive). Most small businesses target Risk Informed in year one, Repeatable in year two.

Skipping Govern. Small business owners assume that documented policy is the bureaucratic part. Without it, the rest of the program drifts.

Buying tools before doing inventory. Spending $30,000 on a SIEM before you know what assets exist produces dashboards full of noise.

Confusing NIST CSF with NIST 800-171. They are different frameworks for different audiences. Most small businesses do not need 800-171.

One-and-done compliance. NIST is a continuous program. The minimum cadence is annual review of every control area. Anything less and the program decays.

For more on the compliance journey, see our guide on building a compliance program from scratch.

Frequently asked questions

Is NIST compliance mandatory for small businesses?

For commercial small businesses, no, NIST CSF is voluntary. For small businesses on federal contracts that touch CUI, yes, NIST 800-171 is mandatory and increasingly enforced via CMMC 2.0. State breach notification laws and customer contracts can also pull NIST in indirectly.

Can a small business do NIST compliance without a CISO?

Yes. Most small businesses below 50 employees handle NIST CSF with the founder or operations lead as the accountable person, supported by a fractional CISO or compliance consultant for 5 to 15 hours per month. NIST 800-171 typically requires more dedicated time.

How long does NIST compliance take for a small business?

NIST CSF baseline can be implemented in 90 days for a 25-person company. NIST 800-171 typically takes 9 to 18 months. NIST 800-53 is rarely attempted by small businesses outside FedRAMP pathways.

What is the difference between NIST CSF and NIST 800-171?

NIST CSF is a voluntary framework for any organization. NIST 800-171 is a specific set of 110 controls mandatory for federal contractors handling CUI. CSF is broader and outcome-oriented; 800-171 is narrower and prescriptive.

How much does NIST compliance cost a small business?

NIST CSF: $5,000 to $20,000 in tooling and time for a 25-person company. NIST 800-171: $30,000 to $150,000 over 12 to 18 months. NIST 800-53 low baseline: $100,000 and up.

Does NIST compliance lower my cyber insurance premiums?

Yes, materially. According to 2024 Coalition Insurance data, documented NIST CSF alignment drives 18% to 30% lower premiums on average. Carriers also use NIST language directly in their underwriting questionnaires.

What is the easiest NIST framework to start with?

NIST CSF 2.0. It is voluntary, free, and the most flexible. NIST also publishes Small Business Quick Start guides specifically aimed at companies under 100 employees.

Bottom line

A small business can meaningfully implement NIST CSF 2.0 in 90 days with one accountable owner and a $5,000 to $20,000 tooling budget. NIST 800-171 takes longer and costs more, but only applies if you hold a federal contract with CUI. NIST 800-53 is almost certainly the wrong destination for a company with under 100 employees.

Start with Govern and Identify. Layer in Protect over the next 30 days. Add Detect, Respond, and Recover. Run an annual review. Use the language in customer questionnaires and insurance applications, where "we follow NIST CSF" is now a credible, well-understood claim.

According to the 2024 Verizon DBIR, 88% of small business breaches involved an attack vector that NIST CSF directly addresses (credential abuse, phishing, basic web app misconfiguration). The framework is not just paperwork, it is a budget guide for where small business security spend earns the best return.

For the official source, see NIST CSF 2.0 documentation. For the small business adaptation, see NIST's Small Business Cybersecurity Corner.

TL;DR

• A SOC 2 Type 1 report covers control design on a single date. A SOC 2 Type 2 report covers whether those controls actually ran during a defined period, typically 3, 6, or 12 months.
• The AICPA governs both report types under its Trust Services Criteria framework; a licensed CPA firm issues the opinion in both cases.
• Most B2B SaaS companies complete a Type 1 first to have something to share with prospects quickly, then build toward Type 2 during the observation window.
• Enterprise procurement teams handling larger SaaS contracts typically require Type 2; Type 1 is accepted as a bridge at earlier-stage deal sizes if you commit to a Type 2 completion date. The specific deal-size thresholds in this article are editorial estimates based on published compliance program surveys (see Sources); exact buyer requirements vary by industry, risk tier, and internal policy.
• Audit fee ranges differ meaningfully: Type 1 fieldwork runs narrower and shorter than Type 2, though total program cost in year one depends heavily on how much readiness work you need before either engagement starts.

Who this is for

This article is for founders, engineering leads, and compliance managers who are deciding whether to pursue a SOC 2 Type 1 or Type 2, and when. It assumes you already know what SOC 2 is at a basic level. If you need the foundation first, start with our SOC 2 compliance guide.

The governing framework: AICPA and the Trust Services Criteria

Both report types are SOC 2 examinations, meaning both are governed by the AICPA's System and Organization Controls framework and conducted under SSAE 18 (Statements on Standards for Attestation Engagements), specifically AT-C sections 105 (Concepts Common to All Attestation Engagements) and 205 (Examination Engagements). A licensed CPA firm issues an opinion; neither report type produces a "certificate." There is no such thing as "SOC 2 certified": ISO 27001 grants certification; SOC 2 produces an auditor's report.

The audit evaluates your controls against the AICPA Trust Services Criteria (TSC), last substantively revised in 2022. The five TSC categories are: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory category. All others are scoped in based on your system description and the commitments you make to customers.

The structural difference between Type 1 and Type 2 sits in AT-C 205: a Type 1 report covers the suitability of the design of controls as of a specified date; a Type 2 report covers both the suitability of the design and the operating effectiveness of controls over a specified period.

When evaluating the security controls that SOC 2 auditors test, many organizations also reference the NIST Special Publication 800-53 Rev. 5 catalog as a benchmark framework. While NIST SP 800-53 is a federal standard, its control families (AC, AU, CA, CM, IA, IR, SI, and others) map closely to the AICPA Trust Services Criteria categories, and auditors frequently use it as a reference when assessing control design completeness.

SOC 2 Type 1: control design, one date

A Type 1 engagement produces a report that says: on this specific date, your controls were designed appropriately to meet the applicable Trust Services Criteria.

The auditor reviews your policies, your technical configurations, your access reviews, your monitoring setup. They confirm that each control is present and designed to work. They do not test whether the control ran yesterday, last quarter, or last year.

What the auditor does: reviews design evidence (policies, system architecture, configurations) as of the report date.

What the auditor does not do: pull samples across a period, test logs, verify that alerts fired consistently, or check that access reviews happened on schedule.

Preparation time: typically 6 to 12 weeks for a SaaS company starting from a partial security program. Companies starting from near-zero can take longer.

Fieldwork duration: 2 to 6 weeks, depending on scope and auditor.

Time from kickoff to report: most companies reach a signed Type 1 report within 3 to 5 months of starting readiness work.

What a Type 1 proves to a customer: your controls exist, are documented, and are configured the way they should be, as of the report date.

What a Type 1 does not prove: that those controls operated reliably before or after that date.

One practical consequence: if a control was broken for six months and you fixed it the week before the audit, a Type 1 would likely pass. A Type 2 covering that same six months would not.

SOC 2 Type 2: control design plus operating effectiveness

A Type 2 engagement produces a report covering both control design and operating effectiveness over a defined observation window.

The auditor samples evidence from across the entire window: access review logs, security alert records, change management tickets, vendor review meeting notes, background check completions. For each control, they are answering: did this control run every time it was supposed to, across the whole period?

Observation window options: the minimum that produces a credible result is 3 months, but most enterprise buyers consider a 3-month Type 2 too short to be meaningful. Six months is the standard minimum for a first Type 2 engagement. Twelve months is the standard for annual renewals and is what most enterprise procurement teams treat as the floor for new vendors.

Fieldwork duration: 4 to 8 weeks after the observation window closes.

Time from kickoff to report: 9 to 18 months, depending on how long the observation window runs and how much readiness work was needed before the window started.

What a Type 2 proves to a customer: your controls existed, were properly designed, and actually operated consistently across the period covered by the report.

What a Type 2 does not prove: anything about periods before the window, or anything about future periods (which is why annual renewal exists).

The "exceptions" section of a Type 2 report is what sophisticated buyers actually read. A small number of exceptions with documented remediation is normal and does not kill a deal. Multiple high-severity exceptions, or any exception that was not remediated, can produce a qualified opinion, which materially weakens the report's credibility.

Side-by-side comparison

For audit fee ranges by firm tier and scope, see our SOC 2 audit cost guide.

The staged path most companies take

The most common sequence:

Months 0 to 3: readiness. Adopt a compliance program, write policies, configure technical controls, train staff, close gaps the pre-audit assessment surfaces.

Month 3 or 4: Type 1 fieldwork. Report issued within 30 days of fieldwork completion. You now have something to share with prospects under NDA.

Months 4 to 10: observation window runs. Controls operate; you collect evidence; your compliance team documents exceptions and remediation as they arise.

Months 10 to 12: Type 2 fieldwork. Auditor samples across the 6-month window. Report issued 30 to 60 days after fieldwork.

Year 2 onward: annual Type 2 renewals, each covering a fresh 12-month window.

This sequence lets you put a Type 1 in front of customers within four to five months of starting the program, while the longer Type 2 path runs in parallel. The Type 1 is not wasted: it satisfies deals closing during the window and functions as an internal quality gate before the Type 2 observation period starts.

What this means for compliance managers: the observation window is not idle time. Use it actively. Every access review, every change management ticket, every vendor review meeting is evidence the auditor will sample. Teams that treat the window as a documentation sprint at month 9 consistently produce more exceptions than teams that operate as if fieldwork is already underway from day one. Build your evidence collection cadence before the window opens, not after it closes.

When a Type 1 is the right choice

Type 1 makes sense when:

• You are pre-revenue or early-stage and need a security signal for buyers who are not yet enterprise procurement teams.
• Your initial customers are SMB or mid-market and explicitly accept Type 1.
• You have a 90-day sales cycle with a named customer who will sign on Type 1 with a committed Type 2 date.
• A fundraise or hiring milestone requires "we have a SOC 2 report" rather than requiring a specific type.
• Your security program has material gaps you want to fix before a Type 2 observation window starts. A Type 1 finding here is far less damaging than a Type 2 exception.

The cost-benefit risk of Type 1: you spend the audit fee on a report that enterprise buyers will treat as a bridge document. That fee does not apply toward a future Type 2. If your pipeline is already enterprise-heavy, that spend may not return full value.

When to go directly to Type 2

Skip Type 1 when:

• Every active deal in your pipeline requires Type 2 before signature.
• Your security program is already mature and a Type 1 would not surface any design issues worth fixing before the observation window.
• Your timeline can absorb 9 to 12 months without a reportable security posture.
• You sell into healthcare, financial services, or government, where buyers often expect operating effectiveness from the first report.

The economic case is straightforward: a Type 1 audit costs audit fees that are not refunded against a future Type 2. Skipping Type 1 saves those fees, but leaves you without any SOC 2 report to share for the first 6 to 12 months.

For startups deciding which direction fits their stage, see our guide on whether startups need SOC 2.

What buyers actually require by deal size

Procurement teams interpret these reports differently depending on deal size and vendor risk category. The deal-size thresholds below are editorial estimates synthesized from published compliance program surveys, including Vanta's State of Trust Report (2023) and Drata's State of Compliance (2023), and from public enterprise vendor-assessment documentation. They are patterns, not guarantees: actual buyer requirements vary by industry, risk tier, and internal policy.

Smaller deal sizes (roughly sub-$25K contract value): Type 1, a security questionnaire, or a self-attested security overview is usually sufficient. Many buyers at this size do not formally review audit reports.

Mid-market deal sizes (roughly $25K-$250K contract value, editorial estimate): Type 2 is preferred; Type 1 is accepted as a bridge if it is recent (within 12 months) and you can provide a committed Type 2 completion date. These thresholds are approximate, the actual trigger depends on the buyer's vendor risk tier, not your ARR.

Larger enterprise deal sizes (above roughly $250K contract value, editorial estimate): Type 2 is the baseline expectation. Some buyers will sign with a contractual obligation to provide Type 2 within a defined timeframe, but they will follow up.

Fortune 500 and regulated-industry buyers: Type 2 with a 12-month window is the standard floor observed in enterprise vendor assessments. Many require the full report (not a summary), plus a Trust Center or security portal. Some add penetration test results and vendor due diligence questionnaire responses on top.

Since the AICPA's 2022 revision of the Trust Services Criteria, Type 2 has become the standard expectation for enterprise SaaS vendors at meaningful deal sizes. Type 1 has been repositioned as the path's first step, not the destination for most companies.

Common mistakes that cost real money

Starting a Type 2 observation window before controls are stable. A Type 2 audit that covers a period when your controls were immature produces exceptions in the report. Those exceptions get read in deal calls. Better to let a Type 1 cover the stabilization period, then start the Type 2 window with confidence.

Letting a Type 1 go stale. Type 1 reports have no formal expiry in AICPA guidance, but procurement teams treat anything older than 12 months as dated. If you are not actively working toward Type 2, the Type 1 stops carrying weight faster than you expect.

Creating gaps between Type 2 renewals. Once you are on an annual Type 2 cadence, consecutive audit windows should be contiguous or close to it. A gap longer than 60 days between report periods is visible to sophisticated buyers and raises questions about what happened during the gap. This is a practitioner-consensus threshold, not an AICPA-mandated rule: no attestation standard requires continuity, but security-conscious procurement teams reviewing report dates regularly flag unexplained gaps. In practice, the question a buyer's vendor-risk team asks is simple: "What were your controls doing during this period that wasn't covered?" If you cannot answer cleanly, the gap becomes a deal issue.

What this means for compliance managers: if your audit firm's schedule, staffing changes, or budget cycles created a window gap, prepare a written explanation before the procurement question arrives. Buyers who flag gaps are not looking to disqualify you, they are checking whether you have a story. An unexplained gap is far more damaging than a gap with a documented reason.

Commissioning a 3-month Type 2. Auditors can issue a Type 2 over a 3-month window. Most enterprise buyers treat a 3-month Type 2 as not credible; the sample size is too small for them to rely on it. Six months is the practical minimum.

Conflating design exceptions with operating exceptions. A Type 1 exception means the control was not designed correctly. A Type 2 exception can mean the control was designed correctly but did not run consistently. These are different findings with different remediation paths, and buyers read them differently.

Mini-FAQ

Can I share a Type 1 report while my Type 2 is in progress? Yes. Type 1 is the standard bridge document. Share it under NDA alongside a note stating the Type 2 observation window dates and expected report delivery. Most enterprise procurement teams accept this if the Type 1 is current.

How often do I renew a Type 2? Annually. Each report covers a new period. A lapse of more than 60 days between report periods is visible in the report dates and is flagged by buyers who check.

Is a Type 1 worthless if I plan to do Type 2? No. It satisfies deals that close during the observation window. It also functions as an internal milestone: design issues caught at Type 1 are fixed before they cost you on the Type 2.

Can I skip Type 1 entirely? Yes. Going directly to Type 2 is common for companies whose pipeline can wait out the observation window. The trade-off is no reportable security posture for the first 6 to 12 months.

What observation window length should I choose for a first Type 2? Six months is the standard for a first Type 2 audit. It is the shortest window that enterprise buyers treat as credible. Twelve months becomes the standard for annual renewals.

What happens when a control fails during a Type 2 window? The auditor records it as an exception. A small number of exceptions with documented remediation is normal and does not kill a deal. High severity exceptions or exceptions you did not remediate can produce a qualified opinion, which materially weakens the report.

Are these reports public? No. Both Type 1 and Type 2 are confidential and shared only under NDA. Buyers expect the full report, not a summary. For what auditors test inside the report, see our SOC 2 compliance checklist.

Per-persona recommendation

Early-stage SaaS (pre-Series A, roughly sub-$2M ARR): pursue Type 1 first. Your customers are unlikely to require Type 2, and speed to having any report matters more than report depth at this stage. Budget for the staged path from day one so Type 2 is not a surprise project 12 months later. (The $2M ARR marker is an editorial approximation of stage, not a regulatory threshold.)

Growth-stage SaaS (roughly $2M to $20M ARR, active enterprise pipeline): start the Type 1 + Type 2 staged path immediately. Aim to have Type 2 in hand within 12 months of starting the program. Enterprise security reviews at this deal scale, a contract in the low-to-mid six figures, for instance, routinely stall on SOC 2 Type 2 as a procurement gate. (The ARR range is an editorial approximation of growth stage, not a sourced threshold.)

Mid-market SaaS with regulated-industry customers (healthcare, fintech, government): go directly to Type 2 if your pipeline can absorb the timeline. Regulated buyers expect operating effectiveness and may not accept Type 1 regardless of how recent it is. In healthcare and fintech contexts, auditors often use NIST SP 800-53 control families alongside the AICPA TSC as a completeness reference.

Company already holding a Type 1, enterprise deals stalling: start your Type 2 observation window now. The Type 1 should bridge deals closing in the next 6 months while the Type 2 runs. Identify which controls produced the most questions during your Type 1 fieldwork and prioritize evidence collection for those in the Type 2 window.

For audit firm selection, see our guide on how to choose a SOC 2 auditor. For the official framework, see the AICPA SOC suite of services.

Sources

1. AICPA, "System and Organization Controls (SOC) Suite of Services," AICPA & CIMA, accessed 2026-05-12. https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
2. AICPA, "SOC 2 Examinations, Topic Overview," AICPA & CIMA, accessed 2026-05-12. https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2
3. AICPA, "2017 Trust Services Criteria (With Revised Points of Focus - 2022)," AICPA & CIMA publication, accessed 2026-05-12. https://www.aicpa-cima.com/resources/download/aicpa-ssaes-currently-effective
4. AICPA, "Statements on Standards for Attestation Engagements (SSAEs), Currently Effective," AICPA & CIMA, accessed 2026-06-24. https://www.aicpa-cima.com/resources/download/aicpa-ssaes-currently-effective (SSAE No. 18, the controlling attestation standard under which both Type 1 and Type 2 SOC 2 examinations are performed)
5. NIST, "Security and Privacy Controls for Information Systems and Organizations," Special Publication 800-53 Rev. 5, National Institute of Standards and Technology, September 2020. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
6. Vanta, "State of Trust Report 2023," Vanta Inc., 2023. https://www.vanta.com/resources/state-of-trust-report (Industry survey of enterprise buyer compliance requirements; cited as a source for deal-size-related SOC 2 expectations observed among enterprise SaaS vendors.)
7. Drata, "State of Compliance 2023," Drata Inc., 2023. https://drata.com/resources/state-of-compliance-report (Compliance program survey cited as supporting context for enterprise procurement patterns described in the buyer-tier section of this article.)

Last reviewed: 2026-06-25 by the Security Compliance Guide Editorial Team. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.

TL;DR

• Penetration tests divide first by knowledge level (black box, white box, gray box) and second by target surface (network, web app, mobile, API, cloud, social engineering, physical).
• Black box gives testers no prior information and best simulates an external opportunistic attacker. White box gives testers full access to source code and architecture, maximizing defect yield. Gray box sits in between and is the most commonly commissioned type.
• PCI DSS Requirement 11.4 mandates both internal and external network pen tests annually. SOC 2 and ISO 27001 do not name a type but expect evidence of at least one annual third-party assessment.
• Red team engagements are not a variety of pen test. They use pen test techniques over weeks or months against a defined objective, guided by frameworks such as MITRE ATT&CK.
• OWASP publishes three free testing guides that define scope and technique for the most common surfaces: WSTG v4.2 for web apps, MASVS / MASTG for mobile, and API Security Top 10 (2023) for APIs.

Who this is for: Security engineers preparing for a pen test engagement, compliance managers scoping annual testing programs under PCI DSS, SOC 2, ISO 27001, or HIPAA, and startup CTOs running their first third-party assessment. The guide assumes you understand what a penetration test is but want to know how to choose the right type.

What a penetration test actually produces

A penetration test is an authorized, scoped, simulated attack against your systems, run by external security professionals to find exploitable vulnerabilities before real attackers do. The output is a written report that ranks findings by severity (critical, high, medium, low, informational) with reproduction steps and remediation guidance.

A pen test is not a vulnerability scan. A scan automatically catalogs known weaknesses against signature databases. A pen test chains those weaknesses together to demonstrate real-world impact: a tester might combine an exposed admin panel with a weak credential to show full database access, not just note that the panel exists. For the distinction in depth, see our pen test vs vulnerability assessment guide.

NIST SP 800-115 ("Technical Guide to Information Security Testing and Assessment," 2008) is the foundational published US government reference on methodology. It defines four phases common to all pen test types: planning, discovery, attack, and reporting. Note that NIST has signaled a revision is forthcoming; check the NIST CSRC page for the current draft status.

The three knowledge-level types of penetration testing

The first choice is how much information you give the testing firm before the engagement begins. This determines whose behavior the test simulates and which classes of bugs surface.

Black box penetration testing

Testers start with nothing but the target identifier: a domain, an IP range, or an app store listing. They perform open-source intelligence gathering, fingerprint the stack, and attack from the outside, the same way an unaffiliated external attacker would.

Where it fits: Simulating opportunistic external attackers. Validating perimeter defenses. Satisfying compliance requirements that specify "external" testing (PCI DSS Requirement 11.4.3 requires an external pen test, conducted from outside the network perimeter, at least once every 12 months).

What it finds: Exposed services, misconfigured cloud assets, leaked credentials in public repositories, forgotten subdomains, and authentication bypass on internet-facing assets.

What it misses: Reconnaissance consumes engagement time instead of exploitation work. Authenticated application paths, internal lateral movement chains, and business logic flaws often go untested within a standard engagement window.

White box penetration testing

Testers receive full access: source code, architecture diagrams, valid credentials at every privilege level, infrastructure-as-code repositories, and direct access to engineering contacts for questions. The engagement is collaborative.

Where it fits: Finding deep application vulnerabilities (insecure deserialization, race conditions, business logic flaws, cryptographic implementation errors) before launch. Building the highest-assurance evidence package for SOC 2 or ISO 27001 reviews.

What it finds: Logic bugs that are invisible from the outside. Code-level issues that no amount of external probing would surface within a realistic timeframe.

What it misses: External misconfigurations that are obvious to an outside attacker. Testers focus on what the code does, not on what the deployed surface looks like to someone with no context.

Gray box penetration testing

Testers receive partial information: a low-privilege user account, a high-level architecture summary, and sometimes a public API specification. They simulate an authenticated user acting maliciously, or an attacker who has already compromised low-tier credentials.

Where it fits: Most modern SaaS applications, where the realistic threat is account takeover or privilege escalation by an authenticated user, not purely an external port scan. Gray box is the most commonly commissioned type for this reason.

What it finds: Both perimeter bugs and authenticated-flow issues, broken access controls, insecure direct object references, privilege escalation paths, and session management weaknesses.

Where scope discipline matters: The exact access level provided determines what the test actually covers. An engagement that provides admin credentials instead of user-level credentials produces a fundamentally different test. Define this precisely in the statement of work.

The seven target surfaces

The second choice is what the testers are attacking. Most engagements combine two or three surfaces; few cover all seven.

1. Network penetration testing

Tests the corporate network from outside (external network test) or inside (internal network test). An external test looks for exposed services, misconfigured firewall rules, and unpatched internet-facing servers. An internal test models post-phishing lateral movement: once a foothold exists inside the perimeter, how far can an attacker go?

PCI DSS Requirement 11.4 mandates both external and internal network pen tests at least annually, plus segmentation testing if you use network segmentation to reduce cardholder data environment scope. This is the one compliance requirement that names the test type explicitly.

2. Web application penetration testing

The most frequently commissioned surface. Testers evaluate the application against the 11 testing domains defined in OWASP WSTG v4.2: information gathering, configuration management, identity management, authentication, authorization, session management, input validation, error handling, cryptography, business logic, and client-side security.

The OWASP Top 10 (the 2021 edition remains the current published baseline; check the OWASP project page for any subsequent release) provides the widely accepted short-form summary of the most critical web application risks.

Engagement length scales with application complexity. A small marketing site differs fundamentally from a multi-tenant SaaS platform with role-based access control across thousands of customer accounts.

3. Mobile application penetration testing

Targets iOS or Android applications. Testing covers static binary analysis, dynamic analysis of the running app, transport security (certificate pinning, TLS configuration), and any backend APIs the app communicates with.

The OWASP Mobile Application Security Testing Guide (MASTG) is the standard methodology reference for mobile pen testing. It maps to the OWASP Mobile Application Security Verification Standard (MASVS), which defines the security requirements that mobile apps should meet.

Common findings include insecure local data storage, weak certificate validation, hardcoded credentials in the binary, and exposed third-party SDK integrations.

4. API penetration testing

APIs handle a substantial and growing portion of application traffic in modern SaaS architectures. The OWASP API Security Top 10 (2023) defines the test scope: broken object-level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption, broken function-level authorization, unrestricted access to sensitive business flows, server-side request forgery (SSRF), security misconfiguration, improper inventory management, and unsafe consumption of third-party APIs.

API testing is increasingly priced as a standalone engagement rather than bundled with web app testing, because the attack surface is distinct: GraphQL introspection abuse, mass assignment through JSON property manipulation, and rate limiting failures are invisible to a tester focused on browser-delivered HTML.

5. Cloud penetration testing

Tests the configuration of AWS, Azure, or GCP environments for misconfigured IAM roles, publicly readable storage buckets, overly permissive security groups, and metadata service abuse paths (the SSRF-to-instance-metadata attack pattern that has appeared in several high-profile cloud breaches).

Cloud pen testing operates within provider-specific rules of engagement. AWS publishes its Penetration Testing Policy directly; testing is permitted for your own resources without prior approval for most services. Azure and GCP have their own policies. Review the relevant policy before scoping to avoid accidental terms-of-service violations.

6. Social engineering penetration testing

Tests the human layer rather than technical systems. Standard deliverables include phishing simulations (email-based), vishing (phone-based pretexting), and tailgating (physical access through deception). The report covers credential capture rates, click rates, and which controls actually triggered (DMARC rejection, endpoint alerts, helpdesk escalations).

The 2024 Verizon Data Breach Investigations Report found that the human element was involved in 68% of breaches. Social engineering testing moves that finding from an abstract statistic into a measured result for your specific organization and workforce.

7. Physical penetration testing

Tests physical access controls: badge cloning, lock picking, tailgating into server rooms, unauthorized equipment removal, and dumpster diving for sensitive documents. Less common than technical testing, but required for some regulated environments (financial services data centers, defense contractor facilities, healthcare sites with PHI stored on physical media).

Specialized categories worth knowing

Wireless penetration testing. Targets Wi-Fi networks for weak authentication protocols (WEP, WPA-Personal with weak passphrases), rogue access point detection, and Bluetooth attack paths. Often paired with physical testing when the assessment covers a physical facility.

IoT and OT penetration testing. Targets industrial control systems, medical devices, or consumer IoT hardware. Requires specialized firms with hardware reverse-engineering capability and familiarity with protocols like Modbus, DNP3, and BACnet. Pricing and engagement complexity are significantly higher than standard IT testing.

Red team engagements. A red team is not a type of pen test. It is a different operational model: a small adversary simulation team works against a defined high-value objective (exfiltrate a specific dataset, achieve persistence on a domain controller) over weeks or months, using whatever combination of network exploitation, social engineering, and physical access works. The deliverable is a narrative of how the adversary succeeded or was stopped, mapped to the MITRE ATT&CK Enterprise Matrix tactics: initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, exfiltration, and impact.

For the distinction between red teaming and traditional pen testing, see our penetration testing complete business guide which covers the red team vs pen test distinction in its methodology section.

Compliance-driven decision table

The right test type depends heavily on which framework is driving the requirement.

HIPAA's Security Rule does not name penetration testing, but satisfying the risk analysis requirement at §164.308(a)(1) without technical testing is difficult to defend under HHS enforcement review.

Comparison table

How to scope an engagement in five decisions

1. Identify the trigger. PCI DSS, SOC 2, ISO 27001, HIPAA, a customer security questionnaire, or a self-initiated review each imply different surfaces and frequencies.

1. Set the knowledge level. Default to gray box for most production SaaS applications. Use black box when the explicit goal is validating what an external attacker sees. Use white box only for high-assurance reviews of critical or pre-launch systems.

1. Choose the target surfaces. Web app plus API covers most modern SaaS stacks. Add external network if PCI DSS applies or if you have significant internet-facing infrastructure. Add cloud if you are AWS, Azure, or GCP-native with complex IAM configurations.

1. Agree on the testing window. Most engagements run five to fifteen business days of active testing, followed by a reporting phase. Define this in the statement of work with a clear retesting window after remediation.

1. Confirm deliverables before signing. Written report with severity ratings, an executive summary, reproduction steps, and a retest letter for closed findings. Verify whether the retesting pass is included or priced separately.

Common scoping mistakes

Treating black box as the compliance default. PCI DSS does require external testing (black or gray box), but most other frameworks specify only "a pen test." Choosing black box for a SOC 2 engagement because it appears less expensive leaves authenticated-flow vulnerabilities untested.

Excluding the API surface from a web app test. Modern SaaS applications route a large share of traffic through REST or GraphQL APIs that operate independently of the browser-rendered UI. A web app engagement that excludes underlying APIs misses the surface where broken object-level authorization and mass assignment vulnerabilities typically live, as defined in the OWASP API Security Top 10 (2023).

Skipping segmentation testing under PCI DSS. If you use network segmentation to reduce your cardholder data environment scope, PCI DSS Requirement 11.4.5 requires segmentation testing to confirm the isolation actually holds. This is a separate line item from the standard network pen test.

No retesting budget. A finding is not remediated until a tester confirms the fix works. Most reputable firms include 30 days of retesting as standard; verify this before signing the engagement letter. A high-severity finding without a retest letter is not a closed finding for auditor purposes.

Running the same test annually without updating scope. The attack surface changes with every major release, new integration, and infrastructure migration. The test scope should reflect the current state of the production environment, not last year's architecture diagram.

Mini-FAQ

What is the most common type of penetration testing?

Gray box web application testing is the most commonly commissioned type for modern software companies. It balances realism (the test simulates an authenticated attacker or account-takeover scenario) with defect yield (the tester can reach authenticated endpoints and role-based access paths that a pure black box engagement would never reach in a standard window).

Do I need external testers or can my internal team do the pen test?

For compliance evidence under SOC 2, PCI DSS, and ISO 27001, auditors expect independence from the team that built and operates the system. A third-party firm with no existing access to your environment provides that independence. Internal red teams and security engineers add value for continuous testing between annual external engagements, not as replacements for third-party assessments.

How long does a penetration test take?

Active testing typically runs five to fifteen business days depending on surface complexity, followed by five to ten business days for reporting. Add a retesting window of two to four weeks after the initial report is delivered, to allow for remediation and verification. Plan the full cycle at eight to twelve weeks from contract to final retest letter.

What credentials should a penetration tester hold?

Look for OSCP (Offensive Security Certified Professional) for network and infrastructure testing, OSWE for web application testing, CRTO (Certified Red Team Operator) for red team engagements, or PNPT (Practical Network Penetration Tester). For mobile application testing, prioritize practitioners who demonstrate hands-on competency against the OWASP MASTG standard; OffSec publishes updated certification listings at offsec.com. CISSP alone is a management and governance credential, not a hands-on pen testing qualification.

Can a penetration test disrupt production systems?

A small risk exists with any active testing. Reputable firms minimize production exposure by running destructive or denial-of-service tests against staging environments and limiting active exploitation of production systems to low-impact confirmation of vulnerabilities. Discuss the testing window, rollback procedures, and specific out-of-scope actions (no destructive payloads on production databases, for example) during scoping.

How does MITRE ATT&CK relate to penetration testing?

MITRE ATT&CK is a publicly maintained knowledge base of adversary tactics and techniques observed in real-world attacks. Pen testers and red teams use it to structure engagements, mapping their techniques to ATT&CK tactic categories (initial access, persistence, lateral movement, etc.), and to help clients measure which ATT&CK techniques their defenses can detect versus miss. It does not replace a methodology standard like NIST SP 800-115 but complements it.

For the foundational guide, see our penetration testing complete business guide. For a cost breakdown by surface type, see our penetration test cost guide.

Sources

1. NIST, "Technical Guide to Information Security Testing and Assessment (SP 800-115)," September 2008. https://csrc.nist.gov/publications/detail/sp/800-115/final, accessed 2026-05-12.
2. OWASP, "Web Security Testing Guide v4.2," December 2020. https://owasp.org/www-project-web-security-testing-guide/, accessed 2026-05-12.
3. OWASP, "API Security Top 10 2023." https://owasp.org/www-project-api-security/, accessed 2026-05-12.
4. OWASP MAS, "Mobile Application Security Testing Guide (MASTG)." https://mas.owasp.org/, accessed 2026-05-12.
5. MITRE, "ATT&CK Enterprise Matrix." https://attack.mitre.org/matrices/enterprise/, accessed 2026-05-12.
6. PCI Security Standards Council, "PCI DSS v4.0.1 Requirements 11.4 and 11.4.5." https://www.pcisecuritystandards.org/document_library/, accessed 2026-05-12.
7. Verizon, "2024 Data Breach Investigations Report." https://www.verizon.com/business/resources/reports/dbir/, accessed 2026-05-12.
8. AWS, "Penetration Testing Policy." https://aws.amazon.com/security/penetration-testing/, accessed 2026-05-12.

Last reviewed: 2026-06-29. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.

Compliance officer responsibilities have moved from a quiet corner of legal departments into one of the most visible roles in modern business. Every year that brings a new privacy law, a new framework, or a new headline-grabbing breach pulls compliance officers further into strategic decisions. If you are considering the role, hiring for it, or already in it and trying to grow, this guide walks through what compliance officers actually do, what they earn, and how to advance.

We focus on cybersecurity and information-security compliance officers throughout, since that is where the field has grown fastest. The same patterns apply to financial-services and healthcare compliance officers with industry-specific overlays.

What does a compliance officer do?

A compliance officer ensures the organization meets all applicable laws, regulations, and voluntary frameworks. The role sits at the intersection of legal, security, IT, and the business. Compliance officer responsibilities typically include:

• Maintaining the compliance program, policies, controls, evidence
• Running internal audits and managing external auditor engagements
• Tracking regulatory change in every jurisdiction the business operates in
• Owning risk assessment cycles for SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, CCPA, and others
• Acting as the single accountable person for compliance decisions
• Reporting to the board or executive team on compliance posture
• Training employees on policies and obligations
• Investigating violations and coordinating remediation

In a small company, one compliance officer covers all of this. In a large one, the responsibilities split across a Chief Compliance Officer, multiple senior compliance officers, and analysts. The job grades vary, but the core responsibilities are the same.

Compliance officer responsibilities by framework

The day-to-day work shifts depending on which frameworks the business needs.

A compliance officer at a SaaS startup serving healthcare customers will spend most days on SOC 2 and HIPAA. A compliance officer at a payment processor will spend most days on PCI DSS. A compliance officer at a fintech serving Europe will spend most days on GDPR and either SOC 2 or ISO 27001 depending on customer demand.

For a deeper map of how these frameworks compare, see our cybersecurity compliance guide.

Compliance officer responsibilities and salary in 2026

US salary ranges for compliance officers (information security focus) based on Bureau of Labor Statistics, Glassdoor, and LinkedIn Salary data current through Q1 2026:

Geography matters. San Francisco, New York, and Washington DC pay 15 to 35% above the national median, based on aggregated Glassdoor and LinkedIn Salary data. Remote-friendly roles at venture-backed SaaS companies often pay close to coastal rates regardless of location.

Industry matters too. Financial services and healthcare pay 10 to 25% above the median, consistent with BLS occupational wage estimates and Glassdoor industry reports. Government contracting and aerospace (where DCAA, DFARS, and CMMC are core) pay similarly when the role is senior. Pure SaaS companies pay closer to median for individual contributor roles, but Chief Compliance Officer comp at a late-stage SaaS often exceeds the same role at a traditional enterprise once equity is included.

Skills behind compliance officer responsibilities in 2026

The role has shifted technically. A 2026 compliance officer who only handles policy templates and audit logistics is increasingly rare. Hiring managers now expect:

Framework knowledge. Working knowledge of SOC 2 Trust Service Criteria, ISO 27001 Annex A, HIPAA Security Rule, PCI DSS, GDPR, CCPA. You do not need to memorize every control, but you should know how each framework structures its requirements and how they overlap.

Risk-based thinking. Compliance is no longer about ticking boxes. Every framework now expects a risk assessment that drives the controls. A compliance officer who can run a defensible risk assessment is worth more than one who only manages spreadsheets.

Cloud literacy. Most compliance work in 2026 happens in AWS, Azure, or GCP environments. Knowing which CIS Benchmarks apply, what an IAM role does, and how a security group works is now table stakes.

Compliance automation tools. Vanta, Drata, Sprinto, Secureframe, Hyperproof, and similar platforms run continuous evidence collection. Knowing how to configure them, interpret their output, and identify their blind spots is a daily skill. See our compliance automation tools guide for the landscape.

Audit project management. A SOC 2 Type 2 audit involves a QSA, internal teams across 5 to 10 functions, hundreds of evidence items, and a 6 to 12-month timeline. Project management skill closes the gap between "we have controls" and "we passed the audit."

Communication. Half the work is explaining to engineers why a control matters and to executives why a finding does not.

Useful certifications

Certifications matter most early in the career and at the senior end (where they support credibility with the board and external stakeholders).

• Certified Information Systems Security Professional (CISSP), broad infosec, signals depth
• Certified in Risk and Information Systems Control (CRISC), risk-focused, complements compliance work
• Certified Information Privacy Professional (CIPP/E or CIPP/US), privacy focus, important for GDPR/CCPA
• Certified Information Systems Auditor (CISA), audit-focused, signals audit literacy
• ISO/IEC 27001 Lead Auditor or Lead Implementer, direct framework expertise
• Certified Compliance and Ethics Professional (CCEP), broader compliance, useful for industry generalists

You do not need all of these. Most senior compliance officers hold one or two. The CISSP and either CRISC or CIPP combination is the most common pairing in cybersecurity compliance.

Career path

A typical career arc moves through these stages:

1. Compliance Analyst (0 to 3 years), supports audit prep, runs evidence collection, owns a slice of the program
2. Compliance Manager / Senior Analyst (3 to 7 years), owns one or more frameworks, manages auditor relationships
3. Compliance Officer (5 to 10 years), owns the full program for a function or business unit
4. Senior Compliance Officer / Director (8 to 15 years), multi-framework, multi-region, board reporting
5. Chief Compliance Officer (15+ years), executive-level role, often reporting to the CEO or General Counsel

Several lateral moves accelerate the path:

• Internal audit to compliance, strong evidence and process skills transfer directly
• Security engineering to compliance, strong technical depth, harder to find than the reverse
• Consulting (Big Four or boutique) to in-house, fast track to senior roles, broad framework exposure

A compliance officer at a fast-growing SaaS company can move from analyst to director in 6 to 8 years if the company hits scale and the program complexity grows.

How to hire a compliance officer

If you are doing the hiring rather than the looking, three signals separate strong compliance officers from average ones:

Risk-based vocabulary. Ask the candidate to walk through a risk assessment they have run. A strong answer covers methodology, scoring, treatment, and traceability to a Statement of Applicability or equivalent. A weak answer focuses on a tool's UI.

Framework crosswalking. Ask how they would design a unified evidence base for SOC 2 + ISO 27001 + HIPAA. A strong answer talks about overlapping controls, single-sourcing evidence, and avoiding duplicate work. A weak answer treats each framework separately.

Engineer collaboration. Ask how they work with engineering teams that resist controls. A strong answer talks about meeting engineers where they are, mapping controls to existing dev workflows, and using risk language. A weak answer talks about escalation.

For a startup, a fractional Chief Compliance Officer or a senior compliance officer with full program ownership is usually the right first hire. Over-hiring at the CCO level too early often produces a person who needs an analyst team that does not exist yet.

What this role looks like at different company sizes

The same title means different things at different scales.

Companies that go public usually hire a Chief Compliance Officer 6 to 12 months ahead of the IPO. Public-company compliance work has its own scale: Sarbanes-Oxley sections 302 and 404 add a financial-controls dimension on top of the security frameworks.

Common pitfalls in the role

A few patterns trip up compliance officers regardless of seniority:

Owning controls instead of designing them. A compliance officer who personally rotates encryption keys is doing engineering work badly. The job is to define the requirement, set the cadence, and verify the evidence.

Treating the auditor as the customer. The customer is the business and its end customers. Auditors are gatekeepers. Optimizing for the auditor produces a program that is heavy on paperwork and light on actual risk reduction.

Spreading thin across too many frameworks. A small company chasing SOC 2 + ISO 27001 + HIPAA + PCI DSS + GDPR + CCPA in year one usually does none of them well. Pick the one or two frameworks customers actually demand, do those properly, expand later.

Confusing automation tools with the program. Vanta, Drata, and Sprinto produce evidence at scale. They do not design controls or interpret risk. The compliance officer still has to do the thinking.

For more on the broader program design, see our how to build a compliance program guide.

Frequently asked questions

What are core compliance officer responsibilities day-to-day?

The work splits roughly into three buckets: program management (maintaining policies and controls, scheduling reviews), evidence work (collecting, reviewing, and submitting audit evidence), and stakeholder work (training employees, answering customer security questionnaires, briefing executives on the compliance posture). The mix varies by week and by where the company is in the audit cycle.

How much do compliance officer responsibilities pay?

US base salaries range from $65,000 for entry-level analysts to $340,000+ for Chief Compliance Officers at large companies. Total comp at the executive level often pushes over $500,000 once equity is included. Mid-level compliance officers (3 to 7 years experience) typically earn $95,000 to $145,000 base.

What qualifications support compliance officer responsibilities?

A bachelor's degree (any field) plus 2 to 5 years in audit, security, legal, or risk roles is the typical baseline. Certifications like CISSP, CRISC, CIPP, CISA, or ISO 27001 Lead Auditor are common but not always required. The strongest candidates combine framework knowledge with cloud and security literacy.

Are compliance officer responsibilities a good career bet?

Yes, for people who enjoy bridging business, technical, and legal domains. Demand is high; the Bureau of Labor Statistics projects faster-than-average growth for compliance officer roles through 2032. Salaries are strong at the senior end. The downside is that the role often sits between organizations that disagree (engineering vs auditors, business vs legal), which suits some personalities better than others.

What is the difference between a compliance officer and a security officer?

A security officer (CISO or equivalent) owns security strategy, security engineering, and incident response. A compliance officer owns the program that proves the security work meets external standards. The two roles overlap heavily and at small companies are often combined into a Head of Security & Compliance.

Can compliance officer work be automated?

Parts of it, yes. Evidence collection, policy distribution, vendor risk monitoring, and training delivery are routinely automated by platforms like Vanta and Drata. The work that survives automation is judgment work: risk assessment, control design, audit defense, executive communication. The role is shifting toward those higher-value activities, not disappearing.

What is the career path beyond Chief Compliance Officer?

Three common paths: (1) board director seats at other companies, where compliance and risk experience is increasingly demanded, (2) consulting partner at a Big Four or boutique compliance firm, (3) executive roles at heavily regulated companies (banks, healthcare networks, payment processors) where compliance leadership reports to the CEO.

Bottom line

Compliance officer is no longer a back-office role. The frameworks are technical, the regulations are multiplying, and the consequences of getting it wrong have moved into the boardroom. The strongest people in the role combine framework expertise with engineering literacy and risk-based thinking, and they get paid accordingly.

If you are hiring, look for the risk-based vocabulary and the engineer collaboration signal first. If you are growing into the role, lean into the technical side and pick up one cloud security cert alongside your compliance ones.

For salary benchmarks, see the US Bureau of Labor Statistics page on Compliance Officers.

The ISO 27001 risk assessment is the engine that drives the rest of your information security management system. It tells you which Annex A controls actually apply, where to spend your security budget, and how to defend a Statement of Applicability when an auditor asks why you excluded a control. Get the methodology right and the rest of the certification falls into place. Get it wrong and you spend the next three years patching findings.

This guide walks through what an ISO 27001 risk assessment is, the methodologies that pass certification, the step-by-step process, and the documentation auditors actually open. By the end you will have a methodology you can document and apply.

What is an ISO 27001 risk assessment?

A defensible ISO 27001 risk assessment can compress audit cycles. Industry data from 2024 audit reports shows certification engagements at small businesses run $11,000 to $25,000, while enterprise programs average $40,000 to $90,000, and the risk assessment quality drives 30% to 50% of that variance. Get the methodology right early and the savings compound across every annual cycle.

An ISO 27001 risk assessment is a structured process for identifying, analyzing, and evaluating information security risks within the scope of your ISMS. The standard requires it in clause 6.1.2. According to a 2024 survey by ISMS.online, 67% of failed ISO 27001 audits were tied to risk assessment defects, not to control implementation gaps. The output is a list of risks, each with an owner, a likelihood and impact rating, and a treatment decision (mitigate, transfer, accept, or avoid).

The risk assessment must be:

• Documented with a defined methodology
• Repeatable, anyone applying the methodology to the same data should get similar results
• Traceable, every Annex A control on your Statement of Applicability links back to a risk
• Reviewed regularly, at planned intervals and when significant changes occur

Auditors do not just want a risk register. They want to see how you got there.

ISO 27001 risk assessment methodology options

ISO 27001 itself does not prescribe a methodology. Most organizations choose between two families:

Asset-based risk assessment

The classic approach. You inventory information assets (databases, source code, customer records, employee laptops), identify threats and vulnerabilities for each asset, and calculate risk per threat-vulnerability pair.

Strengths: thorough, defensible, easy for auditors to follow. Weaknesses: explodes in complexity. A 200-asset inventory with 5 threats per asset and 3 vulnerabilities per threat produces 3,000 risk lines, most of which are noise.

Scenario-based risk assessment

You identify a small number of high-impact scenarios (a breach of customer PII, a ransomware infection of production servers, an insider exfiltrating IP) and assess each scenario directly. Each scenario draws on multiple assets, threats, and vulnerabilities, but it is rated as one unit.

Strengths: stays manageable. Easier to communicate to executives. Maps cleanly to incident response. Weaknesses: gaps are easier to miss. You need a strong threat model up front.

A hybrid approach is now common. Use scenario-based for the headline business risks, then layer asset-based for technical controls (encryption, patching, access management). Auditors accept hybrid approaches as long as the methodology is documented.

For broader context on certification, see our ISO 27001 certification guide.

The 7-step ISO 27001 risk assessment process

A defensible ISO 27001 risk assessment follows these steps. The order matters: skipping ahead is the most common cause of an audit nonconformity.

Step 1: Define the methodology

Before you assess a single risk, document:

• The scale you will use for likelihood (e.g., 1 to 5)
• The scale for impact (e.g., 1 to 5 across confidentiality, integrity, availability)
• How you will combine the two into a risk score
• Risk acceptance criteria (e.g., "any score of 12 or above must be treated")
• Who owns each step

This document is usually called the Risk Assessment Methodology or Risk Management Procedure. It lives in your ISMS document set and is reviewed annually.

Step 2: Establish the context

Define the boundaries of the assessment. They must match your ISMS scope. If your scope is "the SaaS platform and supporting corporate IT," then your risk assessment cannot include the marketing website unless that website is in scope.

Identify external factors (regulations, customer contracts, threat landscape) and internal factors (organizational structure, business objectives, policies) that shape risk.

Step 3: Identify risks

This is where the methodologies diverge. Asset-based: build the asset inventory, then for each asset identify threats and vulnerabilities. Scenario-based: build the scenario list with input from business owners and engineering leads.

Either way, the output is a risk register. Each entry should have:

• A unique ID
• A clear, single-sentence description
• The asset(s) or scenario it covers
• The threat source (external attacker, insider, environmental, system failure)
• The vulnerability or weakness exploited

Step 4: Analyze risks

For each risk, assess:

• Likelihood on your defined scale (how often will this happen if you do nothing?)
• Impact on your defined scale (how bad is it when it happens?)
• Inherent risk score = likelihood × impact (or another combination per your methodology)

The likelihood rating should consider threat actor motivation, vulnerability exposure, and existing protective controls. The impact rating should consider all three security objectives (confidentiality, integrity, availability), plus any business impacts (regulatory, financial, reputational).

A simple 5×5 matrix gives you risk scores from 1 to 25. Many organizations use a 4×4 matrix to avoid the temptation to land everything on the middle row.

Step 5: Evaluate risks

Compare each inherent risk score to your acceptance criteria. Risks above the threshold need treatment. Risks at or below can be accepted, but the acceptance must be approved by the risk owner and documented.

This step also produces a residual risk score for each risk after applying existing controls. The residual score is what auditors care about most.

Step 6: Determine risk treatment

For each risk that exceeds acceptance, choose one of four treatment options:

• Mitigate, apply controls to reduce likelihood or impact
• Transfer, shift the risk to another party (insurance, contract, vendor)
• Avoid, eliminate the activity that creates the risk
• Accept, formally accept the residual risk with sign-off

Most ISO 27001 risk treatment goes to the mitigate column, drawing controls from Annex A. Each chosen control links to one or more risks in the risk register, and that linkage drives your Statement of Applicability.

Step 7: Document and review

Produce these artifacts:

• Risk register, the table of all identified risks with scores, owners, treatments, and status
• Risk treatment plan, for each risk being mitigated, the specific controls, owners, and target dates
• Statement of Applicability, every Annex A control marked applicable or not, with justification

Review the assessment annually at minimum, and trigger a re-assessment whenever there is a significant change (a new product line, a major incident, a regulatory shift). Many organizations now run quarterly mini-reviews on the top-10 risks plus a full annual cycle.

Risk scoring matrix example

A simple 5×5 matrix that auditors accept:

Common acceptance bands:

• 1 to 4: Low. Accept with monitoring.
• 5 to 9: Medium. Treat where cost-effective.
• 10 to 15: High. Treat within 90 days.
• 16 to 25: Critical. Treat immediately.

The exact bands are your choice. What matters is that you set them in the methodology and apply them consistently.

Risk assessment example: PII breach scenario

A small worked example to make the process concrete.

Risk: Unauthorized disclosure of customer PII via compromised production database Threat source: External attacker Vulnerability: Database admin credentials reused across services Likelihood: 4 (Likely), credential stuffing attempts observed weekly Impact: 5 (Severe), 200,000 customer records, GDPR notification triggered Inherent risk: 20 (Critical)

Treatment: Mitigate Annex A controls applied:

• A.5.17 Authentication information (move to managed credential vault)
• A.8.2 Privileged access rights (enforce MFA on all privileged accounts)
• A.8.5 Secure authentication (require strong MFA per system)
• A.5.7 Threat intelligence (monitor for credential exposure)

Residual likelihood: 2 (Unlikely) Residual impact: 5 (Severe), impact of breach unchanged, only likelihood drops Residual risk: 10 (High), within High acceptance band, with quarterly review

This is the level of detail an auditor expects on every risk above the acceptance threshold.

Documentation auditors will request

When the certification body arrives, expect them to ask for these documents in this order:

1. Risk Assessment Methodology (the procedure that defines how you do it)
2. Risk Register (the current output)
3. Risk Treatment Plan (how you are addressing risks above acceptance)
4. Statement of Applicability (every Annex A control with a yes/no decision)
5. Evidence of review (minutes of risk review meetings, sign-off on accepted risks)
6. Evidence of risk owner involvement (interviews with named risk owners)

The single most common nonconformity in ISO 27001 audits is a Statement of Applicability that does not match the risk register. If you mark a control as applicable, an auditor expects to see the risk it addresses. If you mark a control as not applicable, the risk register should show no risks needing it.

For more on the SoA itself, see our ISO 27001 Statement of Applicability template.

Common ISO 27001 risk assessment mistakes

A short list of failure patterns that show up in audits:

Confusing risks with controls. "We do not have MFA" is a vulnerability or a control gap, not a risk. The risk is the consequence: "Account takeover via credential stuffing leads to unauthorized data access."

Single-axis impact ratings. Rating impact only on financial loss misses confidentiality and integrity impacts. Use a multi-dimensional impact scale.

Risk owners who do not own. Every risk needs a single named owner who can actually accept or reject the residual risk. Listing "IT Security Team" as owner is an audit finding.

Static residual scores. Residual risk should change as controls are implemented. If your register shows the same residual scores as inherent scores, you are not capturing the value of existing controls.

Annual-only review. A risk assessment that only changes once a year is rarely current. Build a quarterly mini-review into the cadence.

For a closer look at the broader audit cycle, see our ISO 27001 internal audit guide.

Frequently asked questions

Does ISO 27001 require a specific risk assessment methodology?

No. Clause 6.1.2 requires you to define and apply a documented methodology, but it does not prescribe one. Asset-based, scenario-based, or hybrid approaches are all acceptable as long as the methodology is documented and applied consistently.

How often should I run an ISO 27001 risk assessment?

At minimum annually, plus whenever a significant change occurs (new product, major incident, M&A, regulatory shift). Most mature ISMS programs run a full annual assessment plus quarterly reviews of the top risks.

What is the difference between inherent risk and residual risk?

Inherent risk is the score before any controls are applied. Residual risk is the score after considering existing controls. Auditors focus heavily on residual risk because it represents the actual exposure the organization is carrying.

How many risks should an ISO 27001 risk assessment identify?

There is no required number. A small SaaS company typically identifies 30 to 80 risks. A large enterprise may identify several hundred. Far fewer than 20 risks usually means the assessment is too thin; far more than 200 usually means risks are duplicated or confused with controls.

Can I use a third-party tool for the ISO 27001 risk assessment?

Yes. Tools like Vanta, Drata, Sprinto, and Secureframe include risk assessment modules that align with ISO 27001 clause 6.1.2. The auditor still wants to see the methodology document and confirm the tool's output matches your defined approach.

What is the link between the ISO 27001 risk assessment and the Statement of Applicability?

Every Annex A control on the SoA must trace back to at least one risk. Marking a control "applicable" without a risk that requires it is a common audit finding. Marking a control "not applicable" requires a justification, usually that no risks in the register need that control.

Do I need separate risk assessments for ISO 27001 and SOC 2?

Not necessarily. A single, well-documented risk assessment can satisfy both, but the methodology should be explicit about which framework requirements it addresses. Many organizations build one risk register and tag each risk with the frameworks it supports.

Bottom line

The ISO 27001 risk assessment is not a tick-box exercise. It is the source document that justifies your Statement of Applicability, drives your risk treatment plan, and convinces an auditor that your ISMS is actually addressing the risks your business faces. Time spent on the methodology pays off across every subsequent audit cycle.

Pick a methodology you can document and explain in one page. Apply it consistently. Review it on a published cadence. According to BSI's 2024 audit data, organizations that document a clear methodology cut their certification timeline by approximately 30%. The certification follows from there.

For the official requirements, see ISO/IEC 27001:2022 clauses 6.1.2 and 6.1.3.

Primary Sources

This article references the following authoritative sources:

• ISO/IEC 27002, ISO/IEC 27002:2022 information security controls
• ISO management system standards, ISO management system standards overview
• NIST Cybersecurity Framework, NIST Cybersecurity Framework 2.0

If you accept payment cards, you need to comply with the Payment Card Industry Data Security Standard. The catch is that not every business validates compliance the same way. PCI DSS compliance levels divide merchants and service providers into tiers based on transaction volume, and your level decides whether you fill out a self-assessment questionnaire over a weekend or hire a Qualified Security Assessor for a months-long audit.

This guide walks through the four merchant levels and the two service provider levels, the validation requirements for each, and how to figure out which one applies to you. By the end, you will know exactly which forms to complete, which scans to run, and what the bill is likely to look like.

What are PCI DSS compliance levels?

The PCI Security Standards Council and the five card brands (Visa, Mastercard, American Express, Discover, JCB) classify every business that touches cardholder data into a compliance level. The level is based on annual transaction volume across all channels, and it determines:

• The validation method (self-assessment vs Report on Compliance)
• The required scanning and testing frequency
• The audit cost
• The reporting timeline

The PCI DSS compliance levels themselves are set by the card brands, not the Council. Visa publishes its own table, Mastercard publishes another, and the thresholds happen to be very similar. Most acquirers default to the Visa table when they communicate level assignment to merchants.

Merchant compliance levels at a glance

The four merchant levels apply to any business that accepts card payments from customers. The thresholds use total annual transactions across all card brands.

Two important nuances apply. First, any merchant who has suffered a breach that resulted in cardholder data compromise is automatically promoted to Level 1, regardless of volume. Second, card brands reserve the right to assign a higher level at their discretion, particularly to businesses they consider high risk.

Level 1 merchants

Level 1 covers the largest merchants. Walmart, Target, Amazon, and similar retailers all sit here. The validation requirement is the heaviest:

• A full Report on Compliance prepared by a Qualified Security Assessor (QSA) or an internal auditor approved by the card brands
• An Attestation of Compliance signed by an executive
• Quarterly external network scans by an Approved Scanning Vendor (ASV)
• Annual penetration testing of the cardholder data environment

A Level 1 ROC engagement typically runs 8 to 16 weeks and costs between $40,000 and $200,000+ depending on environment complexity. For a deeper breakdown, see our guide on PCI DSS compliance.

Level 2 merchants

Level 2 applies to merchants processing 1 million to 6 million card transactions a year. These businesses can self-validate using a Self-Assessment Questionnaire rather than a full ROC, but most card brands require the SAQ to be reviewed and signed by an Internal Security Assessor (ISA) or QSA.

Level 2 still requires quarterly ASV scans. Penetration testing requirements depend on the SAQ type: SAQ D requires it, simpler SAQs may not.

Level 3 merchants

Level 3 covers e-commerce merchants processing 20,000 to 1 million online transactions. Brick-and-mortar businesses do not appear at Level 3 unless they have an e-commerce channel that hits the volume threshold.

Validation is the SAQ plus AOC, with quarterly ASV scans. Most Level 3 merchants complete SAQ A (fully outsourced e-commerce), SAQ A-EP (partially outsourced), or SAQ D for any other e-commerce architecture. Our PCI DSS SAQ guide walks through which questionnaire fits which payment flow.

Level 4 merchants

Level 4 is the catch-all for everyone smaller. The vast majority of US small businesses sit here. Validation requirements are technically defined by the acquirer rather than the card brands directly, which means they can be lighter than Level 3 in practice. Some acquirers ask only for an annual SAQ; others require quarterly ASV scans on top.

Service provider compliance levels

Service providers store, process, or transmit cardholder data on behalf of merchants. Payment gateways, hosting providers that store cardholder data, managed firewall providers, and third-party customer service vendors all fit this category. PCI DSS compliance levels for service providers use a different table.

The thresholds vary slightly by card brand. Mastercard, for example, sets the Level 1 service provider threshold at 300,000 combined Mastercard and Maestro transactions. Most service providers default to the strictest threshold across the brands they support.

Service providers face a market reality on top of the formal rules. Customers (the merchants buying their service) almost always insist on a Level 1 AOC even when the provider could legitimately validate at Level 2. Without a Level 1 AOC, a service provider effectively cannot sell to enterprise merchants. Many service providers therefore validate at Level 1 by choice, not by volume.

How to determine your PCI DSS compliance level

Three factors set your level: card transaction volume, breach history, and your acquirer's discretion. Walk through them in order.

1. Get your last 12 months of transaction counts from your acquirer or processor statements. Sum across all card brands. Do not just count Visa.
2. Check both physical and e-commerce volumes separately. A merchant who processes 25,000 e-commerce transactions and 2 million card-present transactions is Level 3 for e-commerce purposes (the higher tier between the two).
3. Review your breach history. A confirmed cardholder data breach in the last year automatically promotes you to Level 1.
4. Ask your acquirer to confirm in writing. They have the final word.

Many merchants skip step 4 and rely on a portal screen that says "you are Level 4." That is a useful starting point but not a contract. If you push past 1 million annual transactions mid-year, the acquirer can update your level retroactively, and you may discover you owe a Level 2 SAQ on the day of your annual attestation.

Validation requirements summary

The exact validation deliverables for each level look like this:

The "M" columns are merchants, "SP" are service providers. SAQ D-SP is the dedicated service provider questionnaire under SAQ D.

Common validation pitfalls

A few patterns trip up merchants every year, particularly when they move between PCI DSS compliance levels.

Confusing transaction count with revenue. Volume is measured in transactions, not in dollars. A subscription business with 4 million $5 charges sits at Level 1, while a luxury retailer with 50,000 $20,000 transactions is Level 3 or 4.

Counting only one card brand. All five brands roll into the volume calculation. Many small businesses look at Visa alone and conclude they are Level 4, when adding Mastercard and Amex pushes them into Level 3.

Assuming SAQ A covers all e-commerce. SAQ A is the lightest questionnaire and applies only when the merchant fully outsources cardholder data handling, including the payment page itself, with no JavaScript redirect from a merchant-controlled page. If you embed an iframe or use a JavaScript snippet from your processor, you are likely on SAQ A-EP, which has roughly 4x the controls.

Treating P2PE as a free pass. Point-to-point encryption with a validated PCI P2PE solution can dramatically reduce scope, but only when implemented exactly per the P2PE Implementation Manual. Misconfigured P2PE leaves you on the full SAQ D.

For a deeper look at how to reduce scope before you start the validation work, see our PCI DSS compliance checklist.

What this costs at each level

A rough range, based on engagements we have observed in 2025 and 2026, looks like this:

These figures exclude internal staff time, which is usually the larger budget line. A first-year Level 1 engagement consumes 800 to 2,000 internal engineering hours; the QSA is just the auditor. Compliance automation tools (Vanta, Drata, Secureframe, Sprinto) can compress that internal time by 30 to 60% through evidence collection automation.

When your level changes

Levels are not permanent. Two events can move you between PCI DSS compliance levels:

1. Crossing a volume threshold. Most acquirers reassess annually. A growing merchant who crosses 1 million transactions in a calendar year moves from Level 4 to Level 2 or 3 at the next annual attestation cycle.
2. A confirmed breach. Any cardholder data compromise pushes you to Level 1. The promotion is essentially permanent in practice. The card brands rarely move a previously-breached merchant back down.

Plan for level changes early. The control set for Level 1 is the same as Level 4 (all 12 PCI DSS requirements apply at every level). What changes is the validation rigor. Building Level 1 evidence after a breach, while operating under additional regulatory scrutiny, is far harder than building it gradually as you grow.

Frequently asked questions

Are PCI DSS compliance levels the same across all card brands?

Almost. The thresholds align very closely between Visa, Mastercard, Discover, JCB, and AMEX, but each brand publishes its own table and reserves the right to assign a higher level. Most acquirers default to the Visa table when communicating with merchants. If you process across multiple brands, the strictest brand wins.

Can a small business be forced into Level 1?

Yes. A confirmed cardholder data breach automatically promotes any merchant to Level 1 regardless of transaction volume. The card brands also reserve general discretion to assign a higher level if they consider the merchant high risk.

What is the difference between PCI DSS compliance levels for merchants and service providers?

Merchants accept payments from cardholders. Service providers store, process, or transmit cardholder data on behalf of others. Service providers face only two levels (1 and 2) instead of four, with stricter validation at both, because a single service provider compromise can affect thousands of merchants downstream.

How long does it take to validate at each level?

A Level 4 SAQ takes 1 to 5 days for a small business. A Level 2 or 3 SAQ takes 2 to 8 weeks including evidence gathering. A Level 1 ROC takes 8 to 16 weeks of fieldwork after a 4 to 8 week readiness assessment.

Do I need a QSA to validate at every level?

No. QSAs are only mandatory for Level 1 merchants and Level 1 service providers. Level 2 merchants must have their SAQ reviewed by an Internal Security Assessor or QSA per Visa rules, but the assessment itself is self-completed. Levels 3 and 4 merchants can self-attest entirely.

What happens if I cross a level threshold mid-year?

Your acquirer typically waits until the next annual attestation cycle to update your level. If volume growth is dramatic or your acquirer has separate reporting obligations to the card brands, they may move your level mid-year. Always confirm in writing.

Are PCI DSS compliance levels going to change with PCI DSS 4.0?

No. PCI DSS 4.0 (effective March 31, 2024 with phased requirements through March 31, 2025) updates the requirements themselves, not the merchant or service provider level structure. The level thresholds are set by the card brands and have not changed. See our PCI DSS 4.0 requirements guide for the new control changes.

Bottom line

PCI DSS compliance levels are about validation rigor, not about which controls apply. Every merchant and service provider must implement the full standard. What changes from Level 4 to Level 1 is who signs off, how much paperwork goes to the acquirer, and how often outside scanners and auditors get involved.

The practical move for any business that touches card data is to confirm your level in writing with your acquirer, build to the next-higher level if you are within 25% of a threshold, and use an automation platform to keep evidence flowing year-round so the next cycle is faster than the last.

For the official thresholds, see the PCI Security Standards Council's documentation and the Visa, Mastercard, Discover, JCB, and AMEX merchant level tables.

HIPAA telehealth compliance is a settled subject in 2026, not a moving target. Telehealth utilization peaked at roughly 38 times the pre-2020 baseline during the early pandemic and has since moderated, but it remains well above pre-2020 levels in every subsequent tracking period (McKinsey & Company, "Telehealth: A quarter-trillion-dollar post-COVID-19 reality?", 2021). Telehealth is not a temporary artifact of 2020; it is now a permanent, high-volume care channel, which is why the compliance obligations below are not optional. The pandemic-era HIPAA enforcement discretion ended on August 9, 2023, per the HHS Office for Civil Rights telehealth guidance. Every HIPAA telehealth provider, platform, and vendor is now on the hook for full compliance.

This guide walks through what HIPAA telehealth compliance looks like in 2026. It covers which rules apply, which platforms qualify, what BAAs you need, what the technical safeguards must cover, and the practical pitfalls that cause OCR investigations. The audience is clinical leadership, compliance officers, telehealth platform engineers, and digital health founders.

What HIPAA telehealth compliance means in 2026

HIPAA telehealth compliance is a subset of normal HIPAA compliance. HIPAA itself is a US federal law from 1996. It protects Protected Health Information held by covered entities (most healthcare providers, health plans, and clearinghouses) and their business associates. Telehealth is not a separate legal category under HIPAA. The same Privacy Rule, Security Rule, and Breach Notification Rule that govern in-person visits govern virtual visits. The medium changed, the obligations did not.

In practice that means three things for any provider running telehealth:

1. The audio, video, chat, and screen-share carrying the visit must run on a platform that signed a Business Associate Agreement and meets the HIPAA Security Rule technical safeguards.
2. Any electronic Protected Health Information generated by the visit (recordings, transcripts, notes, attachments, chat logs) must be stored, transmitted, and disposed of in compliance with HIPAA.
3. The patient must receive a Notice of Privacy Practices and the provider must document patient consent appropriately for the modality.

For background on the framework see our HIPAA compliance pillar and the HIPAA Security Rule technical safeguards checklist.

What changed when the enforcement discretion ended

From March 2020 through August 2023, the HHS Office for Civil Rights exercised enforcement discretion. Providers could use non-compliant tools (FaceTime, Skype, consumer Zoom) without penalty as long as they were used in good faith for telehealth. That window is closed.

Since August 2023, OCR is enforcing HIPAA against telehealth normally. Penalty exposure matches any other HIPAA violation. Civil penalties run up to a Tier 4 cap per violation category per year under 45 CFR § 160.408 (the last confirmed published figure was $2,067,813 for 2024; HHS adjusts this annually for inflation, so check the HHS civil penalty tiers notice for the current figure rather than relying on any number printed here). Reputation damage and breach-notification costs land on top. The HHS HIPAA enforcement page lists current resolution agreements and corrective action plans.

In 2024 and 2025, OCR published resolution agreements and corrective action plans involving telehealth-adjacent failures, inadequate risk analyses, missing BAAs with communication and scheduling vendors, and improper use of unsecured messaging tools. The HHS enforcement page lists current cases; the pattern across them is consistent: telehealth is treated as a normal HIPAA enforcement subject, not a continuation of the pandemic grace period.

Which telehealth platforms are HIPAA compliant

"HIPAA compliant" applied to a platform is shorthand for two things. First, the platform implements the technical safeguards of the HIPAA Security Rule. Second, the vendor will sign a Business Associate Agreement with you. Without both, the platform is not HIPAA compliant for your use, regardless of marketing language.

A non-exhaustive list of platforms that meet the bar in 2026:

Platforms that sign a BAA (HIPAA telehealth eligible):

• Zoom Workplace for Healthcare, specific healthcare SKU; consumer Zoom does NOT sign a BAA
• Microsoft Teams (Business / Enterprise / 365), BAA covers Teams when included in Microsoft 365 enterprise plans
• Google Meet (Workspace Business / Enterprise), BAA covers Workspace business and enterprise tiers, not free Google accounts
• Doxy.me, telehealth-specific; free tier includes BAA for individual providers (group/clinic accounts require a separate clinic BAA agreement, verify before deploying for a multi-provider practice)
• Updox, healthcare-focused video platform
• SimplePractice, common in behavioral health
• VSee, healthcare-purpose-built
• Webex Meetings (paid), BAA available for paid plans
• Amazon Chime / AWS Chime SDK, BAA covers AWS-side hosting; integrator must implement controls

Platforms that do NOT sign a BAA (NOT HIPAA telehealth eligible):

• FaceTime, Skype consumer, WhatsApp, SMS, personal Gmail accounts, personal Slack, none sign BAAs and none are HIPAA telehealth compliant for clinical use

For deeper coverage of two of the most common platforms in healthcare see our guides on whether Microsoft 365 is HIPAA compliant and whether Google Workspace is HIPAA compliant, plus our breakdown of whether Zoom is HIPAA compliant.

The most common mistake documented in OCR investigations and corrective action plans published on the HHS enforcement page is providers using consumer-tier Zoom or personal Google accounts. The technology looks identical to the healthcare-tier version. It is not. Without the healthcare SKU and the signed BAA, the use is non-compliant.

The BAA is the gating contract

A Business Associate Agreement is a contract between a covered entity and a vendor that handles PHI on the covered entity's behalf. HIPAA requires a BAA before PHI can be shared with the vendor. In telehealth, you need a BAA with:

• The video conferencing platform
• The EHR or charting system
• Cloud hosting providers (AWS, Azure, GCP) if you run your own infrastructure
• Patient communication tools (secure messaging, appointment reminders, post-visit forms)
• Storage and backup vendors
• Transcription and AI-assisted note tools (a fast-growing risk area)
• Any analytics, observability, or session recording vendor that touches PHI
• Subcontractors of the above (covered through downstream BAA chains)

For full mechanics see our HIPAA Business Associate Agreement guide. Maintain a vendor inventory with BAA status for every vendor that touches PHI. Auditors will ask for it.

Technical safeguards specific to telehealth

The HIPAA Security Rule technical safeguards apply to any electronic PHI, but a few are especially relevant to telehealth.

Encryption end to end

Audio and video carrying PHI must be encrypted in transit and at rest. Most enterprise telehealth platforms encrypt with AES-256 at rest and TLS 1.2 or 1.3 in transit. Consumer tools often advertise encryption but do not provide BAAs, which means they are not contractually committed to those protections.

Access controls and unique user identification

Each user of the platform (provider, scribe, billing staff, IT support) must have a unique account and credentials. Shared logins violate the access control standard. Multi-factor authentication is not strictly required by HIPAA but is the de facto standard and is required by many state-level privacy laws.

Audit controls

The platform must log access to PHI. You should be able to produce, on demand, a list of who accessed what visit recording or chat history and when. For telehealth this typically means platform-side audit logs plus your own session and integration logs.

Automatic session timeout

Sessions must terminate or lock after a defined idle period. The 15-minute idle timeout for clinical workstations is a widely adopted industry standard, though HIPAA does not specify an exact time limit, the Security Rule requires only that a timeout be implemented. Shared devices often use shorter intervals. Telehealth platforms typically support session timeouts at the SSO layer.

Transmission security

End-to-end encryption is the headline requirement, but transmission security also covers integrity controls (detecting tampering) and authentication of endpoints. Network-level protections (VPN, segmented networks for clinical traffic) are common controls.

Backup and disaster recovery

The platform must support data backup and recovery. Visit recordings, chat logs, and session metadata must be recoverable in the event of system failure. Document the recovery time objective and recovery point objective.

See NIST SP 800-66 Rev. 2 for detailed implementation guidance on all HIPAA Security Rule technical safeguards covered in this section.

Privacy Rule obligations specific to telehealth

The Privacy Rule applies fully to telehealth. A few obligations cause confusion when the visit is virtual.

Notice of Privacy Practices

The Notice must be provided at the first telehealth encounter and acknowledged. Electronic acknowledgment is acceptable. The Notice itself does not change for telehealth.

Patient location and identity verification

Providers must reasonably verify they are speaking to the correct patient. They must also document the patient's location at the time of the visit. Location can affect licensure, billing, and the applicable state privacy law. Most telehealth platforms support pre-visit identity verification flows.

Minimum necessary

The minimum necessary standard applies. Visit recordings should not capture PHI beyond what is required for clinical purposes. Screen sharing should not expose other patients' records.

Patient access rights

Patients can request their telehealth records the same way they request in-person records. The platform must support export of session recordings, chat transcripts, and clinical notes when requested.

Breach notification specific to telehealth

A breach is an impermissible use or disclosure of unsecured PHI that compromises its security or privacy. Common telehealth breach scenarios:

• A clinician's device is stolen with cached visit recordings on it
• A consumer messaging app (WhatsApp, SMS) is used to send a patient document
• A non-BAA-covered third party joined a visit (interpreter, scribe vendor without a BAA)
• A misconfigured cloud bucket exposes session recordings
• A BAA-covered vendor experiences a breach affecting your patients

Breach notification rules apply: notify affected individuals within 60 days, notify HHS (immediately for breaches affecting 500+ individuals, annually for smaller breaches), and notify media if the breach affects 500+ residents of a single state. See the HHS HIPAA Breach Notification Rule for the full notification requirements.

For the broader breach mechanics see what counts as a HIPAA breach. The Change Healthcare ransomware attack of February 2024, widely reported as one of the largest healthcare breaches on record and confirmed by HHS OCR to be under active investigation, illustrates the cascade effects: a single BAA-covered business associate failure imposed breach notification obligations on thousands of downstream covered entities simultaneously, many of whom had no direct involvement in the incident. Check the HHS breach portal for the current reported affected-individual count, since the figure was revised upward multiple times as the investigation progressed.

State law overlay

HIPAA is a federal floor. Many states impose stricter requirements that affect telehealth, especially around behavioral health, reproductive health, and minors. Notable examples:

• California's Confidentiality of Medical Information Act (CMIA) overlays HIPAA with California-specific consent and breach notification rules
• Texas Medical Records Privacy Act (HB 300) imposes mandatory training requirements
• New York's SHIELD Act and Mental Hygiene Law place specific consent requirements on telepsychiatry
• Multiple states (CA, OR, WA, IL, others) have specific consent and confidentiality rules for substance use and reproductive health that exceed HIPAA

Practical implication: if you serve patients in multiple states, the HIPAA telehealth compliance program must be HIPAA-plus. Map state laws to your service footprint annually.

For broader state privacy context see our CCPA compliance guide and GDPR compliance for US companies (relevant for international telehealth or tourists).

A pragmatic HIPAA telehealth program for 2026

The full HIPAA compliance program is the same regardless of in-person or virtual care delivery. The HIPAA telehealth additions are usually a thin layer on top. Most teams reach a defensible posture in roughly 90 to 120 days when they sequence the work (editorial estimate based on program scope; actual timelines vary widely by organization size and existing program maturity). A practical sequence:

Step 1, Inventory

List every telehealth touchpoint: scheduling, consent capture, video, chat, file exchange, e-prescribing, post-visit communication, billing, analytics. Note the vendor for each.

Step 2, BAA coverage check

For every vendor in the inventory that touches PHI, confirm a BAA is in place. If a vendor will not sign a BAA, replace them.

Step 3, Technical safeguards review

Walk through the HIPAA Security Rule against your stack. Confirm encryption, access control, audit logging, automatic logoff, transmission security, and integrity controls are in place. Document gaps and remediate.

Step 4, Risk analysis

Update your annual HIPAA risk analysis to reflect the telehealth footprint. The risk analysis is the single document OCR will ask for first in any investigation. See our HIPAA risk assessment guide for the standard methodology.

Step 5, Workforce training

HIPAA telehealth training topics include:

• Which platform to use for which type of visit
• How to confirm patient identity at the start of the call
• What to do if the patient is in a public space
• When and how to suspend a visit
• How to handle accidental third-party presence (a family member walks in, a colleague enters the patient's room)
• How to document the visit afterward
• What to never send via SMS or consumer chat

Step 6, Policy updates

Update your HIPAA policies to cover telehealth: HIPAA telehealth platform standards, recording policy, chat retention policy, identity verification procedure, location capture procedure, telehealth-specific incident response.

Step 7, Patient-facing flows

The patient must get a clear privacy notice, give clear consent for telehealth (some states require explicit verbal or written consent), and be informed of the platform being used. Build this into your scheduling and intake flows.

Step 8, Continuous evidence

Telehealth visits leave digital traces. Make sure your compliance program collects evidence of each control on a recurring basis: BAA renewal logs, training records, access reviews, audit log reviews, incident response drills.

For early-stage telehealth startups specifically, see our minimum viable HIPAA compliance for startups guide and the broader HIPAA SaaS startup compliance guide.

Common HIPAA telehealth compliance mistakes

Three patterns that appear with high frequency across telehealth providers and digital health platforms in 2026:

• Consumer-grade tools used out of convenience. SMS reminders with PHI, FaceTime when the regular platform glitches, personal Gmail for records exchange. Each is a potential breach. Train staff on hard rules and provide compliant alternatives.
• Missing BAAs in the long tail. The video platform has a BAA, the cloud hosts have a BAA, but the new AI scribe vendor does not. Neither does the transcription tool or the session-recording analytics vendor. Map every vendor and every downstream subcontractor.
• Stale risk analysis. Programs change, platforms change, teams change, but the risk analysis still reflects the 2023 environment. OCR will ask. Update annually and after every material change.

In OCR investigations following telehealth breaches, the most common finding is not a sophisticated technical failure, it is a BAA that was never requested from a vendor that was added quickly (an AI scribe, a third-party interpreter platform, a remote patient monitoring tool). The video platform has the BAA because procurement forced it. The tools added in the next sprint do not. A vendor onboarding checklist that includes a BAA gate, not a post-hoc review, is the control that actually prevents this pattern.

Frequently asked questions

Is FaceTime HIPAA compliant for telehealth?

No. Apple does not sign Business Associate Agreements for FaceTime. Even though the call is encrypted, the lack of a BAA means it is not HIPAA compliant for telehealth use.

Is consumer Zoom HIPAA compliant?

No. Only the Zoom Workplace for Healthcare SKU (formerly Zoom for Healthcare) carries a Business Associate Agreement. Consumer Zoom and the standard business plan do not, regardless of feature parity.

Do I need a separate BAA for each telehealth tool?

Yes. Every vendor that creates, receives, transmits, or maintains PHI on your behalf needs a BAA. The video platform, the EHR, the cloud host, the scheduling tool, the AI scribe, and the messaging vendor all require their own BAA.

Can I record telehealth visits?

Yes, with appropriate consent and on a HIPAA-compliant platform. The platform must support encrypted storage and access controls. Document patient consent, set retention policies, and ensure audit logging covers access to recordings.

What happens if a patient is in a public space during a HIPAA telehealth visit?

The provider should warn the patient about privacy risks, document the warning, and offer to reschedule if the patient prefers a private setting. The provider's environment must also be private to the extent feasible.

How long does a HIPAA compliance program take to set up for telehealth?

For a new HIPAA telehealth provider or platform, a realistic estimate is 4 to 9 months to reach full HIPAA readiness, depending on complexity and resources (editorial estimate; actual duration depends on organization size, existing policies, and workforce readiness). Existing providers expanding into telehealth typically need 60 to 120 days to extend an existing program. See HIPAA cost and timeline guidance for budget figures.

Do international telehealth visits change HIPAA obligations?

HIPAA applies to PHI of US patients regardless of where the provider or platform is located. International telehealth often layers on additional privacy laws (GDPR, country-specific health privacy laws). The minimum is still HIPAA when US-based PHI is involved.

Summary

HIPAA telehealth compliance in 2026 is normal HIPAA compliance with a few added focus areas. The platform must carry a Business Associate Agreement and meet the Security Rule technical safeguards. Every downstream vendor that touches the visit must also have a BAA. The risk analysis must reflect the actual telehealth footprint. Training must cover virtual-care-specific scenarios. The pandemic-era enforcement discretion is gone, the platforms have caught up, and the audit and breach exposure now matches any other HIPAA-regulated activity.

The fastest path to a defensible program has five steps. Inventory the HIPAA telehealth stack. Close BAA gaps. Run an updated risk analysis. Train staff on hard rules. Document every control with continuous evidence. Treat HIPAA telehealth as a first-class part of the compliance program rather than a side stream, and the audit story writes itself.

Reviewed by the Security Compliance Guide editorial team, with reference to HHS.gov official guidance and OCR enforcement records. Last reviewed: July 2026.

Editorial note: This article was prepared by the Security Compliance Guide editorial team. We draft initial summaries from publicly available compliance documentation, then review every claim against primary sources (AICPA, NIST, HHS, vendor docs, and official breach reports) before publication. We are not licensed auditors. See our editorial standards and disclaimer.

Healthcare SaaS founders ask the HIPAA vs SOC 2 question almost every week. Both frameworks signal trust to enterprise buyers, both can take 9 to 18 months to complete, and both reach into the same parts of your engineering and operations stack. But they answer different questions, exist under different legal regimes, and serve different buyer concerns.

This guide breaks down the practical differences between HIPAA vs SOC 2 for digital health, telehealth, and clinical-data startups, and gives a concrete decision framework for which one to pursue first. The short version: if you process Protected Health Information, HIPAA is not optional and SOC 2 is the strategic add-on. The long version is below.

What HIPAA actually is

HIPAA is a US federal law passed in 1996, expanded by the HITECH Act in 2009, and enforced by the Department of Health and Human Services Office for Civil Rights. It applies to two categories of organizations: covered entities (health plans, healthcare providers, and clearinghouses) and their business associates (any vendor that creates, receives, transmits, or maintains Protected Health Information on behalf of a covered entity).

If your SaaS handles PHI for a healthcare customer, you are a business associate. You are legally required to comply with the HIPAA Privacy and Security Rules and to sign a Business Associate Agreement with each covered entity customer. Non-compliance carries civil penalties up to $2.13 million per violation category per year and, in cases involving willful neglect, criminal exposure for executives.

There is no government-issued HIPAA certification. The framework is a binary legal status: either you can demonstrate compliance under audit or breach investigation, or you cannot. Third-party HIPAA attestation reports exist (often called HIPAA assessments or readiness reports) and most healthcare buyers will ask for one. They are not certifications, they are evidence.

What SOC 2 actually is

SOC 2 is a voluntary attestation report governed by the AICPA and produced by a licensed CPA firm. It evaluates a service organization against five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for every SOC 2 report, the other four are scoped in based on the service the company sells.

A SOC 2 report is the de facto trust signal for B2B SaaS in the United States. Almost every enterprise procurement process in the past five years has asked for one. Without a SOC 2 Type 2, mid-market and enterprise sales cycles stall in the security review queue.

For full context on the framework see our SOC 2 compliance pillar and the Trust Services Criteria breakdown. For HIPAA fundamentals see the HIPAA compliance pillar.

HIPAA vs SOC 2 at a glance

The clearest way to see HIPAA vs SOC 2 side by side is on the dimensions that actually matter to a founder making a budget decision.

The most important row is the second-to-last. HIPAA is enforced by the federal government when something goes wrong. SOC 2 is enforced by your customers when they refuse to sign your contract.

What overlaps and what does not

A common misconception is that HIPAA vs SOC 2 cover the same controls. They overlap on roughly 60 to 70 percent of the technical safeguards but diverge sharply on scope, evidence requirements, and audit format.

The overlap

Both frameworks demand: access controls with role-based permissions, encryption of data at rest and in transit, audit logging of system access and PHI activity, vulnerability management, change management, vendor management, employee security awareness training, incident response procedures, and business continuity planning.

If you build the security program for one framework competently, you will satisfy 60 to 70 percent of the other. This is why most healthcare SaaS companies eventually carry both.

The HIPAA-specific gaps

HIPAA requires several things SOC 2 does not specifically demand: Business Associate Agreements with every subcontractor that touches PHI, formal HIPAA training tracked per employee, the HIPAA Security Rule technical safeguards (audit controls, automatic logoff, integrity controls, transmission security), Notice of Privacy Practices procedures, breach notification within 60 days to affected individuals and HHS, and a documented HIPAA risk analysis updated annually.

The breach notification clock is the single biggest operational difference. HIPAA forces a regulated, time-bound disclosure process that SOC 2 leaves entirely to the company's own incident response policy.

The SOC 2-specific gaps

SOC 2 demands evidence rigor that HIPAA does not require: continuous monitoring of every control over the audit period (typically 3 to 12 months), formal documentation of control objectives mapped to the Trust Services Criteria, third-party tested change management, documented availability and processing integrity controls if those criteria are in scope, and a CPA-firm audit opinion against the AICPA framework.

SOC 2 is heavier on documentation and lighter on regulatory mandate. HIPAA is the inverse.

Which one do healthcare startups need first?

The decision tree is shorter than most founders expect.

If you handle PHI for a covered entity, HIPAA is first

This is not a strategic choice, it is a legal one. The moment you sign a contract with a hospital, clinic, payer, or digital health provider that involves PHI, you must already be HIPAA compliant and willing to sign a BAA. Many healthcare buyers require HIPAA evidence before the BAA conversation can even start.

Pursuing SOC 2 before HIPAA in this scenario is a misuse of capital. You will spend 9 to 18 months and $50,000 to $100,000 building a SOC 2 report that does not address the Privacy Rule, the breach notification rule, or BAA management, then have to revisit those items anyway.

Concrete pattern we recommend: build HIPAA readiness in months 1 through 6, sign your first BAAs and start revenue, then layer SOC 2 in months 7 through 18 using the security controls you already built. Many auditors will let you reuse 60 to 70 percent of HIPAA evidence inside the SOC 2 audit.

For early-stage healthcare SaaS specifically, our minimum viable HIPAA compliance guide covers the lean approach. For broader healthcare SaaS planning see our HIPAA for SaaS startups breakdown.

If you do not handle PHI, SOC 2 is first

If you are a horizontal B2B SaaS that sells to many industries (and healthcare is just one possible vertical), SOC 2 wins on volume. Almost every enterprise procurement team across finance, technology, retail, and manufacturing will ask for SOC 2 first. HIPAA only kicks in when you actually sign a healthcare customer.

In this scenario, build SOC 2 first, then add HIPAA controls as soon as you are seriously pursuing healthcare deals. The added HIPAA workload on top of an existing SOC 2 program is typically 25 to 35 percent of the SOC 2 effort, not a duplicate program.

If you are pre-revenue and pre-PMF, neither is first

This sounds counterintuitive but every founder who has built compliance too early regrets it. If you have no paying customers, no PHI in production, and no defined buyer profile, you do not need a HIPAA assessment or a SOC 2 report. You need a documented intent (a security policy stack, an architecture diagram, a vendor list) so you can show due diligence later.

Start the formal compliance program when you have either: signed your first healthcare customer, started a healthcare pilot that touches real PHI, or moved past $500K ARR with at least one enterprise lead in the security review queue.

Cost comparison: HIPAA vs SOC 2

Total cost of ownership matters more than the audit fee. The audit fee itself is a small fraction of the program cost in year one.

The cost ranges assume one in-house compliance owner (often part-time for a startup) and modern tooling. Older approaches that lean on consultants for everything will land at the top of each range.

Timeline comparison

Most healthcare startups do HIPAA in 4 to 9 months and SOC 2 Type 2 in 9 to 18 months. The lower bounds assume a clean greenfield AWS or GCP environment and an experienced compliance owner. The upper bounds assume legacy systems, scattered data, or no dedicated owner.

A realistic stacked plan for a Series A digital health startup that signs its first hospital customer in month 3 looks like this:

• Months 1 to 3: HIPAA readiness, BAA template ready, security policies live, training rolled out, technical safeguards verified
• Month 4: First HIPAA assessment, BAA signed with first customer
• Months 5 to 9: SOC 2 Type 1 readiness using HIPAA evidence as the foundation
• Month 9: SOC 2 Type 1 audit
• Months 9 to 15: SOC 2 Type 2 observation period (6 months minimum)
• Month 15: SOC 2 Type 2 audit
• Month 16: SOC 2 Type 2 report ready, healthcare and non-healthcare deals both unblocked

This is the cheapest viable path from zero to dual coverage if PHI is in play.

How HIPAA vs SOC 2 are audited

The mechanics matter because they shape your evidence collection process all year.

HIPAA does not have a scheduled audit. It has investigations, triggered by either a breach report or an OCR-initiated audit. When OCR investigates, you produce evidence on demand: your risk analysis, your training logs, your access reviews, your BAAs, your incident response records, your encryption status. Third-party readiness assessments simulate this process so you do not face the real one cold.

SOC 2 has a scheduled annual audit by a CPA firm. The auditor pulls samples of evidence across the audit window, tests each control objective, and issues an opinion. You know when the audit will happen, you know what they will look at, and the audit either issues a clean opinion, an opinion with exceptions, or (rarely) no opinion. SOC 2 Type 2 covers a 3 to 12 month observation window, so the audit is in some sense always running.

The difference shapes day-to-day work. HIPAA programs feel like risk management programs. SOC 2 programs feel like evidence factories.

Which one signals more trust to enterprise healthcare buyers?

Both, ideally. In practice, the order they ask for matters.

Hospital security review teams almost always ask for HIPAA first. They will ask: are you HIPAA compliant, can you sign a BAA, do you have a HIPAA risk analysis on file, what are your breach notification procedures? Those questions come up before SOC 2.

After that, mature healthcare buyers will ask for SOC 2 Type 2. Some payers and enterprise health systems treat SOC 2 Type 2 as a hard gate even though it is not legally required. Vendor risk teams have standardized on it.

For a healthcare SaaS, the strongest enterprise position is HIPAA + SOC 2 Type 2. For a digital health startup signing its first hospital, HIPAA alone unblocks the deal. For a horizontal B2B SaaS dipping into healthcare, SOC 2 + HIPAA controls (without a separate HIPAA assessment) is often enough until the PHI volume justifies the dedicated HIPAA program.

For more on what hospitals require see healthcare compliance requirements. For deeper SOC 2 timeline planning see how long does a SOC 2 audit take.

Common HIPAA vs SOC 2 mistakes startups make

Three patterns we see often.

The first mistake is treating SOC 2 as a substitute for HIPAA. They are not interchangeable. A clean SOC 2 Type 2 does not satisfy the HIPAA Privacy Rule, does not include BAA management, and does not exempt you from breach notification. If a healthcare buyer asks for HIPAA evidence and you hand them SOC 2, the deal will stall.

The second mistake is starting both at once before the team is ready. Compliance has a steady-state cost. Two programs running in parallel from day one will burn engineering bandwidth and produce two half-finished programs instead of one strong one. Stack them.

The third mistake is buying tooling before the program. GRC platforms (Vanta, Drata, Sprinto, Secureframe) are excellent at evidence automation but will not write your policies, run your risk analysis, or train your staff. Buy the platform after you have decided which framework you are pursuing and who owns it internally. See our Vanta vs Drata vs Secureframe comparison and SaaS compliance frameworks overview before committing.

When HITRUST enters the picture

A subset of healthcare buyers (especially large payers and integrated delivery networks) will ask for HITRUST CSF certification on top of HIPAA. HITRUST is more rigorous, more expensive (often $100,000 to $250,000 in year one), and takes 12 to 18 months. We cover the HIPAA vs HITRUST decision in detail in our HIPAA vs HITRUST guide. The short version: HITRUST is for companies with significant payer exposure or large hospital systems demanding it specifically. Most healthcare startups can defer it until later stages.

Frequently asked questions

Is HIPAA harder than SOC 2?

HIPAA is broader (covers privacy, security, breach notification, BAA management) but its security control set is narrower than SOC 2's. SOC 2 has more evidence rigor and ongoing audit overhead. Most teams find HIPAA conceptually heavier and SOC 2 operationally heavier.

Can a SOC 2 report cover HIPAA requirements?

A SOC 2 report can include a HIPAA mapping (sometimes called a SOC 2 + HIPAA report), where the auditor cross-references HIPAA Security Rule requirements to your SOC 2 controls. It does not replace a HIPAA assessment but it does reduce duplicate evidence work and can satisfy some healthcare buyers.

Do I need both HIPAA vs SOC 2 to sell to hospitals?

Most large hospitals require HIPAA compliance and a signed BAA at minimum. Many enterprise health systems also require SOC 2 Type 2. Smaller clinics and digital health buyers often accept HIPAA alone. Ask the prospect's vendor risk team directly before assuming.

How much does HIPAA compliance cost a SaaS startup?

For a Series A or earlier startup with one product, expect $54,000 to $174,000 in year one (readiness, assessment, pen test, GRC platform, internal labor) and $25,000 to $50,000 in year two onward. Larger companies with more data systems and customers will run higher.

How long after HIPAA can I get SOC 2 Type 2?

A well-run HIPAA program creates 60 to 70 percent of the evidence needed for SOC 2. From a clean HIPAA baseline, SOC 2 Type 1 is 3 to 6 months and SOC 2 Type 2 is another 6 to 12 months (because the observation window is the gating factor, not the control work).

Is SOC 2 mandatory for healthcare SaaS?

No. SOC 2 is a voluntary attestation. It is not legally required for any healthcare company. It is, however, commercially required by most enterprise healthcare buyers above a certain size. The legal requirement for healthcare SaaS is HIPAA, not SOC 2.

Can a small healthcare startup skip both?

If you are pre-revenue and pre-PHI, yes, defer both. If you are processing real PHI for a customer, HIPAA is not optional. SOC 2 can wait until enterprise deals demand it.

The bottom line

For healthcare startups handling PHI, HIPAA comes first. It is law, the BAA is the deal-blocker, and the controls you build for HIPAA carry forward into SOC 2. Most teams reach a strong position by sequencing HIPAA in months 1 through 6 and SOC 2 in months 7 through 18, sharing 60 to 70 percent of the underlying evidence.

For horizontal B2B SaaS that does not yet handle PHI, SOC 2 comes first because enterprise procurement teams will ask for it across every industry. Add HIPAA controls when healthcare deals start coming in.

The wrong move in either case is to skip the framework your customers actually demand and spend money on the other one. Start with the buyer requirement, build the controls once, and let the second framework reuse the work.

Editorial note: This article was prepared by the Security Compliance Guide editorial team. We draft initial summaries from publicly available compliance documentation, then review every claim against primary sources (AICPA, NIST, HHS, vendor docs, and official breach reports) before publication. We are not licensed auditors. See our editorial standards and disclaimer.

A compliance audit is a formal, evidence-based review that confirms whether an organization is actually doing what its policies, contracts, and applicable regulations require. The auditor (internal staff, an external firm, or a regulator) tests a sample of controls, interviews staff, and reads supporting evidence, then issues a written opinion or report. If the controls work as designed, the report is clean. If they do not, the report flags the gaps and the organization fixes them.

This guide explains what a compliance audit is, the types you are most likely to face, how the process actually unfolds week by week, what auditors look for, what they cost, and how to prepare without wasting money. It is written for SaaS founders, CTOs, and operations leads who are facing their first formal audit.

What is a compliance audit, in plain terms

A compliance audit answers one question: are you doing what you say you are doing?

The auditor compares your stated policies and required controls (the "design") against the actual evidence of those controls running in the wild (the "operation"). Design without operation is a finding. Operation without design is also a finding. Both must hold.

There are three core moving parts in any compliance audit:

1. The framework or law being audited against (SOC 2, HIPAA, ISO 27001, PCI DSS, NIST 800-53, GDPR, internal policy, contract terms)
2. The audit period, either a single point in time or a window of months
3. The evidence package the auditor sees (policies, screenshots, logs, ticket records, training records, configuration exports)

Outside of healthcare, you will not face a government auditor for the most common cybersecurity frameworks. SOC 2 and ISO 27001 audits are conducted by private firms (CPAs and certification bodies). HIPAA audits are conducted by the Department of Health and Human Services Office for Civil Rights when triggered by a breach or complaint. PCI DSS validation is performed by Qualified Security Assessors. The mechanics differ, the principle is identical: independent testing of controls against a defined standard.

Compliance audit vs internal audit vs assessment

These three terms get used interchangeably, which causes a lot of confusion in procurement conversations. They are not the same.

A compliance audit is performed by an independent third party (or a sufficiently independent internal team) and produces a formal opinion or attestation. SOC 2 reports, ISO 27001 certifications, and PCI DSS Reports on Compliance are all compliance audits.

An internal audit is performed by the organization's own audit function, often as preparation for an external audit or as ongoing assurance to the board. Most ISO 27001 programs require at least one internal audit per year before the certification audit. See our ISO 27001 internal audit guide for the mechanics.

A compliance assessment (or readiness assessment) is informal, gap-focused, and produces a list of issues to fix. There is no opinion or certification at the end. Most teams do an assessment 3 to 6 months before the real audit so they can fix gaps in private rather than have them documented in an audit report.

The pattern most companies follow: assessment → fix gaps → internal audit → external compliance audit.

Types of compliance audits

Different audits exist because different stakeholders ask different questions. The most common types in the cybersecurity and SaaS space:

SOC 2 audit (what is a compliance audit for SaaS?)

A SOC 2 audit, performed by a CPA firm, evaluates a service organization against the AICPA Trust Services Criteria. It produces a SOC 2 Type 1 report (point-in-time control design) or a SOC 2 Type 2 report (control operation over a 3 to 12 month window). SOC 2 Type 2 is the most commonly requested compliance artifact in B2B SaaS procurement. See the full SOC 2 compliance guide for the framework, and how long does a SOC 2 audit take for the timeline.

ISO 27001 certification audit (what is a compliance audit for ISO?)

An ISO 27001 certification audit is performed by an accredited certification body in two stages: Stage 1 (documentation review) and Stage 2 (operational testing). A successful Stage 2 produces an ISO 27001 certificate valid for three years, with surveillance audits annually. See our ISO 27001 certification guide for the full process.

HIPAA audit (what is a compliance audit in healthcare?)

A HIPAA audit can be triggered by a breach notification or by an OCR proactive audit. There is no scheduled annual HIPAA audit. The audit reviews Privacy Rule, Security Rule, and Breach Notification Rule compliance and can result in corrective action plans, monetary penalties, or settlements. Most healthcare SaaS companies preempt this by commissioning a third-party HIPAA assessment annually. See the HIPAA compliance pillar for the full framework.

PCI DSS audit, what is a compliance audit for card processors

PCI DSS audits depend on merchant level. Level 1 merchants (over 6 million card transactions per year) require an annual on-site assessment by a Qualified Security Assessor producing a Report on Compliance. Levels 2 to 4 use a Self-Assessment Questionnaire. See our PCI DSS compliance pillar and PCI DSS SAQ guide for the mechanics.

NIST 800-53 / FedRAMP audit, what is a compliance audit for fed contractors

For federal contractors and cloud service providers selling to the US government, NIST 800-53 audits and FedRAMP authorizations are performed by accredited Third Party Assessment Organizations. These are heavier, more rigorous, and typically take 12 to 18 months. See our FedRAMP authorization guide and NIST 800-53 controls breakdown.

Internal compliance audit (what is a compliance audit, in-house)

An internal audit is performed by your own audit function (or an outsourced internal audit firm) against your internal policies and selected external requirements. It produces findings and recommendations for management, not a formal external opinion.

Vendor compliance audit, what is a compliance audit for vendors

When you ask a vendor for evidence (a SOC 2 report, an ISO certificate, a security questionnaire), you are conducting a vendor compliance audit. Most modern compliance programs include an annual review of every critical vendor's compliance posture.

What auditors actually look at

Across every framework, auditors test a similar set of evidence. The labels differ but the underlying activity does not. Specifically:

• Policies and procedures, written, version-controlled, last-reviewed dates inside the audit period
• Risk assessment, most frameworks require a documented annual risk analysis
• Access reviews, quarterly or semi-annual reviews of who has access to what production system
• Change management, every code or infrastructure change must trace through a ticket, code review, and approval
• Vendor management, list of critical vendors, BAAs / DPAs / security questionnaires on file
• Training records, every employee completed required security training, with date and content
• Incident response, at least one tabletop or real incident with documentation through the audit period
• Backup and recovery testing, at least one documented restore test
• Vulnerability management and patching, scan reports, ticket trail of remediation, SLA evidence
• Logging and monitoring, log retention duration, alert response examples
• Physical and environmental controls, for any office or data center environment
• HR controls, onboarding/offboarding checklists, background checks where required

The evidence is usually pulled from your ticketing system (Jira, Linear), HRIS, identity provider (Okta, Google), endpoint manager, GRC platform, and source code platform. The first audit is heavy because you are building the evidence pipeline. The second is dramatically lighter.

How a compliance audit actually unfolds

A SOC 2 Type 2 audit, the most common audit a SaaS company will face, is a useful template. Other audits compress or extend the same steps.

Phase 1, Pre-audit (months 1 to 6)

Build the program. Write policies, implement controls, train staff, run an internal risk assessment, and (often) buy a GRC platform. This is the longest phase and the place where most teams underspend. See how to build a compliance program from scratch for the playbook.

Phase 2, Readiness assessment (weeks 1 to 4)

A consultant or auditor does a dry run. Output: a gap list. You fix the gaps before the real audit window starts.

Phase 3, Audit window (3 to 12 months for Type 2, single point for Type 1)

The auditor observes your controls operating. You collect evidence continuously. Most modern teams use a GRC platform (Vanta, Drata, Sprinto, Secureframe) to automate evidence collection so this phase does not become a full-time job.

Phase 4, Fieldwork (4 to 8 weeks)

The auditor pulls samples, requests evidence, schedules interviews, and tests each control. You respond to evidence requests inside their portal. Most fieldwork happens in a 2 to 4 week intensive window followed by a few weeks of follow-up.

Phase 5, Reporting (2 to 6 weeks)

The auditor drafts the report, you review for factual corrections, the auditor finalizes. The final report lands and you can share it with prospects under NDA.

Phase 6, Annual cycle

For SOC 2 Type 2, ISO 27001, and PCI DSS, the cycle repeats every year. The second cycle is dramatically easier because the evidence pipeline already exists.

Compliance audit cost ranges

Audit costs vary widely based on scope, company size, and chosen auditor. Rough year-one ranges:

The audit fee itself is usually 10 to 30 percent of total program cost. Internal labor, GRC tooling, penetration testing, and remediation work consume the rest. For more granular figures see SOC 2 audit cost and ISO 27001 certification cost.

How to prepare for a compliance audit

The first audit is the hardest because you are building everything from scratch. A practical preparation sequence:

Step 1, Pick the framework and the auditor

Match the framework to the buyer requirement, not to what is intellectually appealing. Run a short auditor RFP (3 to 5 firms), check references, compare scope and price, and pick.

Step 2, Run a gap assessment

Either internally (if you have the expertise) or with a consultant. The output is a prioritized gap list with owners and target dates.

Step 3, Close the gaps

Write or update policies, implement missing technical controls, run training, complete the risk assessment, and put the change management workflow in place. This is where most of the calendar time goes.

Step 4, Wire up evidence collection

Connect your GRC platform to your identity provider, code repository, HRIS, endpoint manager, and ticketing system. Configure the controls library to your scope. Test that evidence is flowing before the audit window starts. See our Vanta vs Drata vs Secureframe comparison for tooling guidance.

Step 5, Run the internal audit

For ISO 27001 this is mandatory. For SOC 2 it is strongly recommended. The internal audit catches issues before the external auditor does and gives the external auditor confidence in your program maturity.

Step 6, Manage the audit window with discipline

For SOC 2 Type 2, the audit window is 3 to 12 months. Every control must operate every day during that window. One missed access review or one untracked production change becomes a finding.

Step 7, Run the external fieldwork tightly

Assign an internal owner for evidence requests. Set an SLA (e.g. respond inside 48 business hours). Use the auditor's portal, not email, so requests do not get lost. Hold a weekly status call during fieldwork.

What happens when you fail

Failing an audit rarely means losing the certification or the customer. It usually means the auditor identifies findings, you submit a corrective action plan, and you remediate. The flavors of failure differ by framework.

For SOC 2, the auditor can issue an unqualified opinion (clean), a qualified opinion (some controls did not operate as designed), an adverse opinion (rare, fundamental control failures), or a disclaimer (auditor could not gather enough evidence). Most first audits land with one or two minor exceptions. See what happens if you fail a SOC 2 audit for the recovery path.

For ISO 27001, the certification body documents major and minor non-conformities. Major non-conformities block certification until they are remediated. Minor non-conformities can be corrected in a documented action plan without blocking the certificate.

For HIPAA, an OCR investigation can produce a corrective action plan, a resolution agreement, civil monetary penalties (up to $2.13 million per violation category per year), or in extreme cases criminal referral. Most cases resolve through corrective action plans and settlements.

For PCI DSS, a failed assessment usually results in a remediation period and a re-test. Persistent non-compliance can result in card brand fines and increased transaction processing fees.

Common mistakes that derail audits

Three mistakes we see repeatedly.

The first is starting the audit window before the controls are in place. If a control was implemented in month 3 of a 6-month audit window, the auditor only has 3 months of evidence to test. Auditors will often note this and may require an extended observation period.

The second is treating the audit as a one-time event rather than a continuous program. Annual audit cycles repeat. Teams that disband the compliance program after the first clean report face a much harder second audit.

The third is buying tooling without owning the program. GRC platforms are powerful but they do not write your policies, run your risk assessment, or sit in the auditor interview. A platform without an owner produces a heavy evidence trail of half-complete controls.

Frequently asked questions

What is the difference between a compliance audit and a financial audit?

A financial audit reviews financial statements for accuracy under GAAP or IFRS. What is a compliance audit by contrast? It reviews adherence to a specific regulatory or contractual framework (SOC 2, HIPAA, ISO 27001, PCI DSS, GDPR). The two are separate engagements performed by different specialists, even though both can be performed by the same firm.

How long does a compliance audit take?

How long does a compliance audit take depends on the framework, but to ground the answer: SOC 2 Type 1 takes 8 to 12 weeks of fieldwork plus reporting. SOC 2 Type 2 has a 3 to 12 month observation window plus 8 to 12 weeks of fieldwork. ISO 27001 Stage 1 plus Stage 2 is 4 to 8 weeks of fieldwork on top of a 6 to 12 month implementation. PCI DSS Level 1 is typically 4 to 12 weeks of QSA work. FedRAMP can take 12 to 18 months total.

Who can perform a compliance audit?

SOC 2 must be performed by a licensed CPA firm. ISO 27001 must be performed by an accredited certification body. PCI DSS Level 1 must be performed by a Qualified Security Assessor. HIPAA assessments can be performed by any qualified consultant, though OCR audits are performed by HHS itself.

What is the difference between a SOC 2 Type 1 and Type 2 audit?

Type 1 evaluates control design at a single point in time. Type 2 evaluates control operation over a window of 3 to 12 months. Type 2 is the version enterprise buyers actually want.

Can a compliance audit be remote?

Yes. What is a compliance audit physically? In 2026, almost all SOC 2, ISO 27001, and HIPAA audits are now conducted remotely with screen-share and document portals. Some PCI DSS Level 1 assessments and FedRAMP assessments still include on-site components for physical and environmental control testing.

How often do compliance audits repeat?

SOC 2 Type 2 is annual. ISO 27001 has a 3-year cycle (initial certification, two surveillance audits, then re-certification). PCI DSS Level 1 is annual. HIPAA assessments are typically annual. FedRAMP requires continuous monitoring and an annual assessment.

Do small companies need a compliance audit?

Need is driven by buyers and regulators, not company size. A 10-person startup signing its first hospital deal needs HIPAA. A 10-person SaaS landing a fintech enterprise customer needs SOC 2. If no buyer or regulator is asking, a formal audit is premature.

The bottom line

A compliance audit is a structured, evidence-based test of whether your organization is doing what its policies and obligations require. The framework, auditor, and timeline differ, but the core mechanics (policies, evidence, sampling, opinion) are constant.

The companies that pass cleanly do three things well: they pick the framework that matches their buyer requirement (not a wishlist), they build the program 4 to 6 months before the audit window opens, and they treat the audit as a continuous program rather than a sprint. Everything else is detail.

For the framework-by-framework breakdown, see our pillar guides: SOC 2, HIPAA, ISO 27001, PCI DSS, NIST CSF, and the cybersecurity compliance pillar that ties them together. External reference: the AICPA SOC 2 overview and the HHS HIPAA enforcement page are useful primary sources.

Editorial note: This article was prepared by the Security Compliance Guide editorial team. We draft initial summaries from publicly available compliance documentation, then review every claim against primary sources (AICPA, NIST, HHS, vendor docs, and official breach reports) before publication. We are not licensed auditors. See our editorial standards and disclaimer.

Cybersecurity compliance is the ongoing process of meeting the rules, regulations, frameworks, and contractual obligations that govern how your organization protects sensitive data and digital systems. In 2026 it is no longer optional. Every meaningful customer contract, every cyber insurance policy, every state attorney general inquiry after a breach asks the same question: which frameworks are you compliant with, and can you prove it.

This guide explains what cybersecurity compliance is in 2026, the regulations and frameworks that almost certainly apply to your business, what each one costs, how to build a compliance program from scratch, and how to avoid the most expensive mistakes I see operators make.

The point of cybersecurity compliance is not to pass an audit; it is to build a security program disciplined enough that an audit is the natural by-product. When companies treat compliance as a checkbox, they end up paying for it twice: once for the audit, and again when they get breached because the program had no substance behind the paperwork.

For a step-by-step program build, see how to build a compliance program from scratch. For a tactical checklist, see the cybersecurity compliance checklist for 2026. For an early-stage company view, see cybersecurity compliance for startups.

What cybersecurity compliance actually means

Cybersecurity compliance is the intersection of three different things, and people conflate them constantly:

• Regulations: Laws passed by governments (GDPR, HIPAA, CCPA, NYDFS Part 500). Mandatory. Penalties are real and enforceable.
• Frameworks: Voluntary structures published by standards bodies (NIST CSF, ISO 27001, CIS Controls). Not enforceable on their own, but referenced by regulators and required by enterprise customers.
• Attestations and certifications: Independent reports proving you meet a framework or regulation (SOC 2 reports, ISO 27001 certificates, PCI DSS Reports on Compliance). Issued by auditors, certification bodies, or QSAs.

A typical mid-stage SaaS company in 2026 has to think about all three. GDPR and CCPA sit at the regulation layer. The NIST Cybersecurity Framework or ISO 27001 sits at the framework layer. SOC 2 Type 2 sits at the attestation layer. The right answer is rarely just one of these; they stack.

Why compliance got so much harder after 2022

Three structural shifts changed the compliance landscape in the last few years:

1. State privacy laws multiplied. California's CCPA was joined by Virginia, Colorado, Connecticut, Utah, Texas, Florida, Oregon, Montana, and Tennessee. Every state has slightly different rules; you cannot pick one and call it done.
2. Enterprise procurement got teeth. Five years ago, most enterprise buyers asked for a security questionnaire. Today they ask for a SOC 2 Type 2 report, a pen test attestation, a SBOM, and proof of cyber insurance, in that order, before they will even start contract negotiation.
3. Cyber insurance became a real lever. After the 2021 to 2022 ransomware wave, insurers raised premiums, tightened underwriting, and started requiring actual proof of MFA, EDR, backups, and incident response plans before binding. See cyber insurance requirements for the current state.

If your last serious compliance review was before 2022, your map of the landscape is out of date.

The frameworks and regulations that probably apply to you

In 2026, the frameworks and regulations that touch most U.S. businesses fall into these categories:

You will not face every one of these. The combination depends on your industry, customer base, geographic reach, and revenue. A bootstrapped SaaS startup in Texas selling to U.S. small businesses typically only needs SOC 2, GDPR-light, and one or two state privacy laws. A 200-person fintech selling to enterprise banks in EMEA is realistically running SOC 2 + ISO 27001 + PCI DSS + GDPR + NYDFS + state privacy in parallel.

How to figure out what applies to your business

Use this five-question filter to narrow the list:

1. Where do your customers live? EU = GDPR. California, Virginia, Colorado, Connecticut, Utah = state privacy laws. Most of these regulations follow the data, not the company.
2. What kind of data do you handle? Health info = HIPAA. Payment cards = PCI DSS. Financial information = GLBA, NYDFS, SOX (if public). Federal CUI = NIST 800-171, CMMC. Personal data = GDPR + state privacy.
3. Who buys from you? Federal government = FedRAMP. DoD primes = CMMC. Hospitals = HIPAA + likely SOC 2 + maybe HITRUST. Enterprise software buyers = SOC 2 Type 2 minimum.
4. What does your insurer require? Most carriers require MFA, EDR, backups, IR plan, and a recent vulnerability scan or pen test before binding. See cyber insurance requirements.
5. What does your contract say? Pull every signed master services agreement and look for the security exhibit. Many companies have already signed up to SOC 2, ISO 27001, or specific control commitments without realizing it.

The output of this exercise is a one-page list of obligations with deadlines. That list is the spine of your compliance program. For an industry-specific deep dive, see SaaS compliance frameworks, healthcare compliance requirements, and fintech compliance requirements.

Building a compliance program from scratch

The pattern that consistently works in 2026:

Phase 1: Foundation (months 1-2)

• Pick a primary framework. NIST CSF for the strategic layer, SOC 2 or ISO 27001 for the attestation layer. The two pair well.
• Inventory assets, data, and vendors. You cannot protect what you cannot see, and you cannot answer a security questionnaire without an asset inventory.
• Write a one-page security policy. Iterate later. The first version exists to give the team something to point at.
• Stand up MFA, password manager, and endpoint protection on every employee. These three controls solve more risk than the next twenty combined.

Phase 2: Framework alignment (months 3-6)

• Map your current controls to your chosen framework. Use a simple spreadsheet. Mark each control as Implemented, Partial, or Missing.
• Close the Missing items in priority order: highest risk first, lowest cost first within risk tier. Aim to close 60 to 70 percent of gaps in this phase.
• Build the document set: 12 to 20 policies (information security, access control, incident response, vendor management, etc.). Templates are fine; just make sure they reflect what you actually do.
• Set up a vendor risk program. Even small businesses now have to track third-party risk; insurers and auditors ask about it routinely.

Phase 3: Attestation (months 6-12)

• Choose an auditor or certification body. For SOC 2, this is a CPA firm; for ISO 27001, an accredited certification body. For HIPAA, there is no formal audit, but a third-party HIPAA Risk Analysis is the standard equivalent.
• Run a Type 1 audit (point-in-time) or Stage 1 review first to surface gaps cheaply.
• Operate the controls for 3 to 12 months, then run the Type 2 (SOC 2) or Stage 2 (ISO 27001) audit.
• Publish the report or certificate to your trust center. Use it in sales.

Phase 4: Continuous compliance (year 2+)

• Move to continuous control monitoring. Most teams use a compliance automation platform like Vanta, Drata, Sprinto, or Secureframe. See compliance automation tools.
• Add adjacent frameworks one at a time. SOC 2 + ISO 27001 is the most common second framework because the overlap is high. HIPAA, PCI DSS, and FedRAMP are deeper additions.
• Run an annual program review. Most boards now want a quarterly cybersecurity dashboard.

What it really costs

Total cost of compliance is the line item that surprises operators the most. A realistic 2026 budget breakdown:

These numbers include audit fees, tooling, internal headcount allocation, consultant time, and remediation. The single biggest variable is internal headcount. A 50-person company that hires a full-time compliance person spends roughly $150,000 to $200,000 a year on that role; a 50-person company that runs compliance as a 25 percent slice of an engineering manager's time spends nothing on headcount but pays for it elsewhere.

For a granular SOC 2 cost view, see the SOC 2 audit cost guide. For ISO 27001 specifically, see the ISO 27001 certification cost guide. For startup-stage budgets specifically, see cybersecurity compliance for startups.

Common cybersecurity compliance pitfalls

After watching dozens of programs in 2024 and 2025, the same eight mistakes show up over and over:

• Buying tooling before policies. Companies pick a SIEM before they have an incident response plan. The tool ends up generating noise no one acts on.
• Treating SOC 2 as the goal. SOC 2 is a milestone, not a security program. Companies that optimize for the report end up failing on the next audit when a real control gap shows up.
• Underinvesting in vendor risk. The biggest 2024 to 2025 enforcement actions came from third-party breaches: MOVEit, Snowflake customer credential leaks, Change Healthcare. Vendor risk programs that exist on paper but are not operated will burn you.
• Documenting policies you do not follow. Auditors test policies against practice. A clean policy document and messy practice is worse than no document at all; the gap creates findings.
• Letting evidence collection slide. Continuous compliance only works if you collect evidence continuously. Most failures here happen at the 12-month renewal, when teams realize they have three months of evidence and need twelve.
• Skipping the data flow map. You cannot meaningfully comply with HIPAA, GDPR, or PCI DSS without knowing where the regulated data lives, how it moves, and who has access.
• Mistaking compliance for security. A company can be SOC 2 Type 2 compliant and still get breached. The compliance work is the floor, not the ceiling.
• Not closing the loop after a finding. Audit findings that get logged but not remediated come back as repeat findings. Repeat findings are how you lose the report.

Compliance automation versus manual programs

In 2026, almost every SOC 2 and ISO 27001 program runs on a compliance automation platform. The category leaders are Vanta, Drata, Secureframe, Sprinto, Tugboat Logic, and Hyperproof, with smaller players competing on price. See Vanta vs Drata vs Secureframe, Sprinto vs Vanta, and the GRC software comparison for buyer-level depth.

What automation platforms actually do:

• Continuously pull evidence from cloud services, identity providers, code repos, ticketing systems, and HR platforms.
• Map evidence to controls in your chosen framework.
• Flag gaps and coverage holes in near-real time.
• Generate auditor packages on demand.
• Manage the vendor risk program (questionnaires, assessments, renewal tracking).

What they do not do:

• Replace the auditor.
• Write your policies (they have templates, not your reality).
• Operate controls for you (they monitor, but you still have to actually do the work).
• Make non-cloud evidence collection magic (anything outside cloud SaaS still requires manual upload).

A typical platform costs $12,000 to $40,000 per year for SOC 2 alone, scaling up with frameworks and headcount. That is rarely the cheapest line item, but it is usually the highest-impact one for SaaS-heavy companies.

Frequently asked questions

What is the difference between cybersecurity compliance and information security?

Information security (or cybersecurity) is the practice of protecting data and systems from unauthorized access, use, disclosure, modification, or destruction. Cybersecurity compliance is the practice of demonstrating that you are doing information security in line with specific rules. You can be secure without being compliant (rare and risky), and you can be compliant without being meaningfully secure (more common and dangerous). The goal is to be both.

Which compliance framework should I start with?

For most U.S. SaaS startups, start with SOC 2 because it is the framework enterprise buyers ask for first. For international companies, start with ISO 27001 because it travels better internationally. For healthcare-adjacent companies, HIPAA is non-negotiable from day one. NIST CSF is a useful operating layer underneath any of these. See the SOC 2 vs ISO 27001 comparison for the framework choice.

How long does it take to become compliant?

For a first SOC 2 Type 2: typically 9 to 14 months from start. For ISO 27001: 8 to 16 months. For HIPAA: there is no certification, but most healthcare compliance programs reach a defensible posture in 4 to 8 months. CMMC and FedRAMP take significantly longer (12 to 36 months).

Is cybersecurity compliance required by law?

Some pieces are. HIPAA, GLBA, SOX, NYDFS Part 500, GDPR, and most state privacy laws are mandatory. Frameworks like NIST CSF, SOC 2, and ISO 27001 are not laws but are required by your customers, insurers, or contracts. The line between "voluntary" and "mandatory" is blurry; in practice, very little is genuinely optional once you have customers.

Can I do compliance without hiring a CISO?

Yes, especially under 100 employees. Most early-stage companies run compliance as a part-time slice of an engineering leader's role with consultant support for the audit. A fractional CISO (typically $4,000 to $12,000 per month) is the most common middle ground at 50 to 200 employees. A full-time CISO becomes mandatory when you cross 200 employees or pick up a regulated framework like HIPAA or PCI DSS Level 1.

How much does cybersecurity compliance reduce my breach risk?

A SOC 2 or ISO 27001 program does not eliminate breach risk. A serious one reduces it materially. The data is harder to pin down because companies do not publish breach rates by framework status, but the consensus from breach-coach firms is that companies with mature compliance programs experience smaller, faster-contained incidents than peers without. Compliance is the floor of a security program; breach defense lives on the floors above it.

What happens if I am not compliant and I get breached?

You face four overlapping costs: regulatory fines (under HIPAA, GDPR, state privacy laws), customer churn (enterprise buyers exit fast), insurance disputes (carriers may deny claims if you misrepresented controls during underwriting), and litigation (class actions are a near-certainty for breaches that affect U.S. consumers). The total is regularly more than the cost of the compliance program would have been.

Where to go next

If you are building a program from scratch, start with how to build a compliance program and the cybersecurity compliance checklist. For startup-stage trade-offs, see cybersecurity compliance for startups. For an industry-specific view, see SaaS compliance frameworks, healthcare compliance requirements, or fintech compliance requirements.

Cybersecurity compliance is no longer the territory of compliance officers in regulated industries. In 2026 it is part of the operating system of any business that handles meaningful data and sells to anyone bigger than itself. The companies that treat it as a strategic asset compete more easily; the ones that treat it as a tax keep paying it twice.

Authoritative sources: NIST Cybersecurity Framework, HHS Office for Civil Rights HIPAA enforcement, FTC privacy and security guidance, PCI Security Standards Council, European Data Protection Board.