SaaS Compliance Frameworks: SOC 2, ISO 27001, HIPAA, PCI DSS, NIST CSF, and GDPR Explained

Which Compliance Frameworks Do SaaS Companies Actually Need?

TL;DR

• SOC 2 Type 2 is the baseline for any B2B SaaS company selling to mid-market or enterprise buyers. It is an attestation, not a certification: a licensed CPA firm examines your controls, not a standards body.
• HIPAA is a federal legal obligation, not a voluntary framework. Any SaaS that handles Protected Health Information from a covered entity must sign a Business Associate Agreement and implement the Security Rule's administrative, physical, and technical safeguards.
• ISO 27001:2022 is a formal certification awarded by an accredited third-party body. It is most relevant when European or Asian enterprise buyers require it, or when SOC 2 attestation is not accepted as a substitute.
• PCI DSS v4.0 applies the moment a SaaS stores, processes, or transmits cardholder data. Using a tokenization provider like Stripe or Adyen reduces scope but does not eliminate it.
• GDPR applies based on the location of your users, not your company. Under Article 3 of the GDPR, a US-based SaaS offering services to EU residents must comply regardless of where it is incorporated.

Who this is for

This article is written for founders, engineering leads, and product managers at B2B SaaS companies who need to understand which compliance frameworks apply to their business and in what order to pursue them. It assumes no prior compliance background. If you already have SOC 2 and want operational depth, see the linked articles throughout.

Why SaaS compliance is not the same as general IT compliance

SaaS companies handle customer data across multi-tenant infrastructure at a scale and geographic distribution that most on-premises software vendors do not. Three pressures are specific to SaaS:

Enterprise procurement gates. Mid-market and enterprise security questionnaires ask for SOC 2 reports, ISO 27001 certificates, and penetration test results before legal review will approve a contract. Without them, deals stall regardless of product quality.

User-location-based regulation. GDPR, CCPA, and emerging US state privacy laws apply based on where your end users are located, not where your company is registered. A US SaaS company with EU users has GDPR obligations the day the first EU user signs up.

Shared responsibility does not mean shared compliance. AWS, Google Cloud, and Azure each maintain their own SOC 2 and ISO 27001 certifications for the infrastructure layers they control. Those reports do not cover your application, your data access controls, or your customer data handling. Each SaaS company owns the compliance posture of its own application layer.

SOC 2

What it is

SOC 2 is an attestation framework defined by the AICPA's Trust Services Criteria. A licensed CPA firm examines whether your controls for one or more of the five Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy — were designed (Type 1) or operated (Type 2) effectively over a defined period.

The key distinction from certification frameworks: the AICPA does not issue a certificate. The auditor issues a report. That report is the attestation. Buyers request the report, not a certificate.

Type 1 vs. Type 2

A Type 1 report evaluates whether controls are suitably designed at a single point in time. A Type 2 report evaluates whether those same controls operated effectively over an observation period, typically three to twelve months. Enterprise buyers almost always require Type 2. Type 1 is useful as a stepping stone when you need something to show before the Type 2 observation window closes.

When it applies to SaaS

SOC 2 is effectively required for B2B SaaS the moment a deal involves a mid-market or enterprise buyer. The signal is a security questionnaire that asks whether you have a current SOC 2 report. That questionnaire can arrive at any revenue stage.

For most B2B SaaS, the first questionnaire arrives between $300K and $2M ARR. At that point, an in-flight Type 2 engagement — even one that has not yet produced a report — is often enough to satisfy procurement if you can share your Type 1 and your remediation plan.

What the five Trust Services Criteria cover

The Security criterion (also called the Common Criteria) is required in every SOC 2 engagement. The other four are optional and scope-dependent:

• Security: Logical and physical access controls, system monitoring, change management, incident response.
• Availability: System uptime commitments, redundancy, disaster recovery.
• Processing Integrity: Completeness and accuracy of data processing.
• Confidentiality: Protection of information designated as confidential under contract.
• Privacy: Handling of personal information collected from individuals.

Most early-stage SaaS companies scope Security and, if handling personal data, Privacy. Availability is added when uptime SLAs are contractually significant.

Timeline and cost

Type 1 typically takes two to four months from auditor engagement to report issuance. Type 2 requires an observation period of three to twelve months, then two months of reporting. Most SaaS companies plan for a combined 12 to 18 month path from first engagement to a clean Type 2 report.

Audit fees and compliance automation tool costs vary by firm size, scope, and auditor. All cost figures for this article have been removed because vendor pricing changes frequently. See the current pricing pages for compliance automation platforms (Vanta, Drata, Secureframe, Sprinto) and request quotes from CPA firms directly. See SOC 2 audit cost for a framework to evaluate quotes.

ISO 27001:2022

What it is

ISO/IEC 27001:2022 is an international standard published by the International Organization for Standardization that specifies requirements for establishing, implementing, maintaining, and improving an Information Security Management System (ISMS). Unlike SOC 2, ISO 27001 results in a formal certificate issued by an accredited certification body after a successful audit.

The 2022 revision reduced the number of controls in Annex A from 114 (in the 2013 edition) to 93, reorganized them into four themes (Organizational, People, Physical, and Technological), and added 11 new controls addressing areas such as threat intelligence, information security for cloud services, and data masking.

Attestation vs. certification: the practical difference

SOC 2 produces an attestation report from a CPA firm. ISO 27001 produces a certificate from an accredited certification body. Buyers who specifically require ISO 27001 are asking for the certificate, which has a three-year validity cycle with annual surveillance audits. Buyers who accept either SOC 2 or ISO 27001 are typically satisfied by either document.

When it applies to SaaS

European enterprise procurement, financial services buyers, and government-adjacent organizations frequently require ISO 27001 certification. Asian enterprise markets, particularly in Japan and South Korea, also commonly require it.

A SaaS company with primarily US mid-market customers and no European revenue can usually defer ISO 27001 until expansion or specific buyer requirements force the issue. Adding ISO 27001 after SOC 2 is operationally efficient because the Security criterion in SOC 2 maps to a large subset of ISO 27001 Annex A controls. Compliance automation platforms that support both frameworks collect shared evidence once and apply it to both.

Timeline

Six to twelve months from engagement to initial certification is a standard planning assumption. The certification cycle is three years, with surveillance audits in years two and three and a full recertification audit in year four.

HIPAA

What it is

The Health Insurance Portability and Accountability Act is a federal law administered by the Department of Health and Human Services Office for Civil Rights. Unlike SOC 2 and ISO 27001, HIPAA is not optional: it is a legal obligation for covered entities and their business associates. There is no HIPAA certification from any government body. Vendors that claim to be "HIPAA certified" mean they completed a third-party readiness review.

Who it applies to

HIPAA applies to covered entities (healthcare providers, health plans, healthcare clearinghouses) and their business associates. A SaaS company becomes a business associate when it creates, receives, maintains, or transmits Protected Health Information on behalf of a covered entity. The trigger is not the type of product; it is whether PHI flows through your system.

The Business Associate Agreement

A covered entity cannot share PHI with a SaaS vendor until a Business Associate Agreement is signed. The BAA establishes each party's responsibilities for PHI, required safeguards, breach notification obligations, and what happens to PHI when the relationship ends. A SaaS company that cannot produce a BAA will not close any healthcare deal, regardless of its security posture.

What HIPAA requires technically

The HIPAA Security Rule specifies three categories of safeguards:

• Administrative safeguards: Security management processes, workforce training, access management policies, contingency planning, and periodic evaluation.
• Physical safeguards: Facility access controls, workstation use policies, device and media controls.
• Technical safeguards: Access controls (unique user IDs, emergency access, automatic logoff, encryption), audit controls, integrity controls, and transmission security.

The Security Rule uses the phrase "required" for some specifications and "addressable" for others. Addressable does not mean optional: it means the covered entity or business associate must either implement the safeguard or document why an equivalent alternative achieves the same protection.

Penalties

HHS OCR enforces HIPAA through civil money penalties in four tiers based on culpability: unknowing violation, reasonable cause, willful neglect corrected, and willful neglect not corrected. The dollar amounts per violation and annual caps are set by statute and adjusted periodically. For current figures, see the HHS Civil Money Penalties page. As of this article's review date, the tier structure remains in force and the annual cap for violations in the highest tier (willful neglect not corrected) is the highest in the schedule.

Healthcare SaaS companies routinely pursue SOC 2 and HIPAA in parallel, as the technical control requirements overlap significantly.

PCI DSS v4.0

What it is

The Payment Card Industry Data Security Standard is maintained by the PCI Security Standards Council, a body founded by American Express, Discover, JCB, Mastercard, and Visa. Version 4.0 was published in March 2022; version 4.0.1 (a minor revision correcting errors) followed in June 2024. PCI DSS v3.2.1 was retired on March 31, 2024, making v4.0 the current required standard.

Who must comply

PCI DSS applies to any entity that stores, processes, or transmits cardholder data or sensitive authentication data. For SaaS, the relevant question is: does your system ever see raw card numbers, CVV codes, or magnetic stripe data?

If you use a tokenization provider (Stripe, Adyen, Braintree, Square) and never touch raw card data — meaning card entry happens inside a hosted payment form or an iFrame the tokenization provider controls — your cardholder data environment scope is minimal. You complete a Self-Assessment Questionnaire (the specific type depends on your integration method) rather than a full Report on Compliance.

If your SaaS stores or processes raw card data directly, the scope is much larger and typically requires a Qualified Security Assessor to conduct an on-site assessment.

The 12 requirement areas

PCI DSS v4.0 organizes requirements across 12 areas:

1. Install and maintain network security controls
2. Apply secure configurations to all system components
3. Protect stored account data
4. Protect cardholder data with strong cryptography during transmission
5. Protect all systems and networks from malicious software
6. Develop and maintain secure systems and software
7. Restrict access to system components and cardholder data by business need to know
8. Identify users and authenticate access to system components
9. Restrict physical access to cardholder data
10. Log and monitor all access to system components and cardholder data
11. Test security of systems and networks regularly
12. Support information security with organizational policies and programs

Timelines

For SaaS companies using hosted payment forms with a tokenization provider, initial SAQ completion can take days to a few weeks. For direct card processing environments, a 12 to 18 month implementation with annual reassessment is a standard planning assumption.

NIST CSF 2.0

What it is

The NIST Cybersecurity Framework 2.0, published by the National Institute of Standards and Technology in February 2024, is a voluntary framework designed to help any organization — private sector, government, large, or small — manage cybersecurity risk. It is not a regulatory requirement for most private companies, though some government contracts and regulated industries reference it.

CSF 2.0 added a sixth core function, Govern, to the five functions in CSF 1.1. The six functions are:

1. Govern: Establish and monitor organizational cybersecurity risk management strategy, expectations, and policy. This was the primary addition in CSF 2.0.
2. Identify: Understand the organization's current cybersecurity risks (asset management, risk assessment, improvement planning).
3. Protect: Use safeguards to manage cybersecurity risks (identity management, access control, awareness training, data security, platform security, technology infrastructure resilience).
4. Detect: Find and analyze possible cybersecurity attacks and compromises (continuous monitoring, adverse event analysis).
5. Respond: Take action against detected cybersecurity incidents (incident management, analysis, mitigation, reporting, communication).
6. Recover: Restore assets and operations affected by a cybersecurity incident (incident recovery, communication).

When it applies to SaaS

NIST CSF 2.0 is voluntary. A SaaS company might adopt it for three practical reasons:

• US federal government sales. Federal agencies and contractors that reference NIST frameworks expect vendors to be able to map their controls to CSF categories. FedRAMP authorization, required for federal SaaS sales, references NIST SP 800-53, which maps closely to the CSF.
• Board and investor reporting. CSF provides a common language for reporting cybersecurity posture to non-technical stakeholders.
• Internal program structure. CSF is a useful organizing framework for building an internal security program before formal SOC 2 or ISO 27001 work begins.

For most early-stage SaaS, CSF is background structure rather than a compliance target. It does not produce a report or certificate that satisfies enterprise procurement.

GDPR

What it is

The General Data Protection Regulation is an EU regulation directly applicable across all EU member states. The European Data Protection Board publishes authoritative guidelines on GDPR interpretation, including the guidelines on territorial scope that govern when non-EU companies must comply.

Territorial scope: when it applies to US SaaS

GDPR Article 3 establishes two independent criteria:

The establishment criterion. If a SaaS company has any place of business in the EU — including a single employee or office — GDPR applies to all processing activities carried out in the context of that establishment.

The targeting criterion. If a SaaS company has no EU establishment, GDPR still applies if it offers goods or services to EU residents or monitors the behavior of EU residents. The EDPB's Guidelines 3/2018 on territorial scope clarify that simply having a website accessible from the EU is not enough — there must be evidence of targeting EU residents. Accepting EU users, pricing in euros, or offering EU-language versions of the product all satisfy the targeting threshold.

For most SaaS companies, the practical answer is: if you have any EU signups and you have not actively blocked EU access, GDPR obligations attach.

What GDPR requires technically

The core technical requirements relevant to SaaS include:

• Lawful basis. Every processing activity must have a legal basis (consent, contract, legitimate interest, legal obligation, vital interests, or public task). Most SaaS-to-business processing is covered by contract.
• Data Processing Agreements. When a SaaS company processes personal data on behalf of a business customer (acting as a data processor), a DPA is mandatory. Enterprise buyers in regulated industries will require a signed DPA before any data flows.
• Data subject rights. Users have rights to access, correct, delete, port, and restrict processing of their data. SaaS companies must build or configure workflows to fulfill these rights within the statutory timeframes.
• Breach notification. A personal data breach must be reported to the relevant supervisory authority within 72 hours of becoming aware of it, where feasible, and to affected individuals without undue delay if the breach is likely to result in high risk to their rights.
• Privacy by design. Data protection measures must be built into the product from the start, not added after.

CCPA and US state privacy laws

California's Consumer Privacy Act applies to for-profit businesses meeting certain thresholds (gross annual revenue above $25 million, buying or selling data of 100,000+ consumers, or deriving 50%+ of revenue from selling personal information). Virginia, Colorado, Connecticut, Utah, Texas, Florida, and Oregon have enacted similar laws with varying thresholds and requirements. For most SaaS companies, implementing GDPR-compatible controls establishes a baseline that satisfies most US state privacy laws with incremental additions for California-specific rights.

Framework overlap: what you can share across programs

These frameworks are not independent. Evidence collected for one frequently satisfies requirements in another:

Compliance automation platforms (Vanta, Drata, Secureframe, Sprinto, and others) map control evidence across multiple frameworks simultaneously. Running SOC 2 and ISO 27001 together typically takes 30 to 50 percent less total effort than running them sequentially, because the evidence overlap is substantial.

Decision matrix by persona

"We are pre-seed. Do we need compliance now?"

No formal audit is required. Document your existing security practices (access controls, backup procedures, incident response). This makes a future SOC 2 engagement faster and cheaper by establishing a baseline. If any early customer asks for a security questionnaire, answer it accurately — do not claim compliance you do not have.

"We are seed stage, selling to mid-market B2B."

Start a SOC 2 Type 1 engagement. The observation window for Type 2 begins the day you close your first control gap, so starting early means finishing earlier. Pick a compliance automation platform first to automate evidence collection.

"We handle health data for a hospital, clinic, or health plan."

HIPAA is not optional. Sign BAAs before any PHI flows. Build the Security Rule safeguards in parallel with (or before) SOC 2. HITRUST is not required by most buyers but some large health systems request it; confirm with your specific prospects before investing.

"Our SaaS processes payment cards directly."

Scope your cardholder data environment. If you can move to a hosted payment form or iFrame from a tokenization provider, do so first — it dramatically reduces compliance scope. Then complete the appropriate SAQ annually. If you store or process raw card data, engage a Qualified Security Assessor.

"We are expanding into Europe or already have EU customers."

Implement GDPR baseline controls: DPA template, lawful basis mapping, data subject rights workflows, and breach notification procedures. Appoint an EU representative if you have no EU establishment and are targeting EU residents. If European enterprise buyers are a significant pipeline segment, ISO 27001 becomes a near-term requirement alongside or shortly after SOC 2.

"We sell or plan to sell to US federal agencies."

FedRAMP authorization is required for direct federal sales. The process references NIST SP 800-53 controls. FedRAMP is a multi-year investment; confirm agency intent before starting. For state and local government, StateRAMP is a separate framework; FedRAMP authorization does not automatically satisfy state procurement requirements.

Common sequence for B2B SaaS

The order below holds for the majority of B2B SaaS companies that are not healthcare- or payments-specific:

1. Security hygiene baseline (any stage): Document access controls, backup procedures, endpoint management, and incident response. No audit required; just documentation.
2. SOC 2 Type 1 (seed to Series A): Engage an auditor. Close control gaps identified in scoping.
3. SOC 2 Type 2 (Series A): Complete observation period. Maintain a clean report annually.
4. HIPAA (when first healthcare buyer appears): Build in parallel with SOC 2 if possible, since control overlap is high.
5. PCI DSS (when first payment processing use case appears): Scope minimization first; then appropriate SAQ or QSA assessment.
6. ISO 27001 (Series B, European expansion, or specific buyer requirement): Build on SOC 2 evidence base.
7. FedRAMP (confirmed federal pipeline): Multi-year investment; begin only with sponsor agency.

Five common mistakes

Pursuing ISO 27001 before SOC 2 when your customer base is US mid-market. ISO 27001 certification takes longer to obtain, costs more, and does not substitute for SOC 2 in US procurement questionnaires. The sequence matters.

Treating SOC 2 Type 1 as the finish line. Enterprise buyers require Type 2. Plan for the observation period from the start; a Type 1-only program creates a gap that will delay deals at Series A.

Skipping the BAA thinking HIPAA is covered by SOC 2. SOC 2 demonstrates security controls. It does not establish the legal relationship HIPAA requires. Healthcare deals stall until a signed BAA is in place regardless of your SOC 2 status.

Assuming tokenization eliminates PCI scope. Using Stripe or Adyen reduces your scope but does not eliminate it. You still complete an SAQ annually and must ensure no cardholder data leaks into your logs or databases.

Ignoring GDPR until a European enterprise asks about it. The obligation attaches when EU users sign up, not when an enterprise buyer asks. A data breach affecting EU users before GDPR controls are in place carries the full regulatory risk.

Mini-FAQ

Is SOC 2 required by law?

No. SOC 2 is a voluntary attestation. It is required in practice by enterprise buyers who make it a procurement condition, but there is no statute that mandates SOC 2 compliance.

Can the same controls satisfy both SOC 2 and ISO 27001?

Yes. The SOC 2 Security criterion (Common Criteria) maps to a large portion of ISO 27001 Annex A controls. Compliance automation platforms support concurrent evidence collection, which is why teams running both frameworks simultaneously save significant effort compared to running them sequentially.

Does GDPR apply if I only have one EU customer?

Article 3 of the GDPR's targeting criterion does not have a minimum user threshold. The EDPB's guidelines note that simply having a website accessible from the EU is not sufficient — there must be evidence of intent to serve EU residents. Actively onboarding EU customers satisfies that threshold.

Is there official HIPAA certification from HHS?

No. HHS does not issue HIPAA certifications. HITRUST CSF certification is the most widely recognized third-party attestation in the healthcare space, but it is not legally required by HIPAA. Many healthcare SaaS buyers accept a current SOC 2 Type 2 report plus a signed BAA as sufficient evidence of security posture.

What is the difference between NIST CSF and NIST SP 800-53?

NIST CSF 2.0 is a high-level voluntary framework organized around six functions. NIST SP 800-53 is a detailed control catalog with hundreds of specific controls, primarily designed for federal systems. FedRAMP uses SP 800-53 as its control baseline. Most private-sector SaaS companies reference CSF for structure and SP 800-53 only when pursuing FedRAMP.

Do US state privacy laws (CCPA, Virginia CDPA, etc.) require the same technical controls as GDPR?

The technical control requirements are similar: data subject rights (access, deletion, correction, portability), data processing agreements with vendors, reasonable security measures, and breach notification. The thresholds for applicability and some specific rights differ by state. Building GDPR-compatible infrastructure first provides a compliant foundation for US state laws with incremental adjustments.

Sources used

1. AICPA's Trust Services Criteria — accessed 2026-05-12
2. ISO/IEC 27001:2022 — accessed 2026-05-12
3. Department of Health and Human Services Office for Civil Rights — accessed 2026-05-12
4. HHS Civil Money Penalties page — accessed 2026-05-12
5. PCI Security Standards Council — accessed 2026-05-12
6. NIST Cybersecurity Framework 2.0 — accessed 2026-05-12
7. European Data Protection Board — accessed 2026-05-12
8. Guidelines 3/2018 on territorial scope — 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.