Is all compliance regulatory compliance? The short answer is no.

Regulatory compliance refers to requirements your business is legally obligated to follow based on local, state, federal, or international laws. But many widely used security and privacy standards are not mandated by law—they’re often contractual (required by customers, banks, or partners) or market-driven (expected to close deals and reduce risk).

This guide covers:

What “regulatory” vs “non-regulatory” compliance means in practice
How the most common frameworks fit: SOC 2, ISO 27001, GDPR, HIPAA, PCI DSS, and CCPA
How to choose what to do first (without wasting time on low-ROI work)

Related guides:

When you realize “compliance” can mean laws, contracts, and buyer expectations

GIF via GIPHY

Key takeaways

Not all compliance is regulatory compliance. Many standards are voluntary, contractual, or buyer-driven.
Regulatory frameworks usually trigger based on scope. It’s not “industry” alone—it’s what data you handle, who you serve, and where they live.
Non-regulatory standards still matter. SOC 2 and ISO 27001 are often essential to enterprise sales and vendor reviews.
“Must comply” isn’t always binary. Some requirements apply partially based on business model, data flows, and third parties.
Treat compliance as a system. The fastest teams standardize owners, evidence, recurring reviews, and a source of truth (instead of scrambling per questionnaire).

Is all compliance regulatory compliance?

No. “Compliance” is an umbrella term that can mean:

Regulatory compliance: laws and regulations you’re legally required to follow.
Contractual compliance: obligations you agree to in contracts (e.g., payment processing agreements, customer MSAs, DPAs, BAAs).
Standards-based compliance: voluntary frameworks you adopt to demonstrate security/privacy maturity (often requested by buyers).
Policy-based compliance: internal requirements you set (and must follow) to reduce risk and show consistency.

In practice, your compliance program should answer two questions:

What are we obligated to do? (laws + contracts)
What do we need to prove to move business forward? (buyers + partners)

Quick comparison table (regulatory vs non-regulatory)

Framework	Is it “regulatory” (law)?	Why teams pursue it	Typical trigger (high level)
SOC 2	No	Buyer trust, enterprise sales, vendor risk reviews	Customers require it to assess risk
ISO 27001	No	Global credibility, structured ISMS, procurement	Customers/partners want an ISO-certified ISMS
GDPR	Yes (EU law)	Legal requirement + privacy trust	You handle personal data of EU/EEA individuals
HIPAA	Yes (US law)	Legal requirement + healthcare contracts	You handle PHI as a covered entity or business associate
PCI DSS	Not a government law (industry standard)	Required by card brands/banks; breach risk reduction	You store/process/transmit cardholder data (or impact its security)
CCPA/CPRA	Yes (California law)	Legal requirement + privacy expectations	You meet applicability thresholds and handle CA residents’ data

Note: These triggers are simplified. Applicability depends on your exact facts, data flows, and contractual obligations.

SOC 2

SOC 2 is one of the most common assurance reports for internet businesses in the U.S., but it does not fall under regulatory compliance. A SOC 2 report is often the primary document used by customers and partners to assess a company’s security risk.

Even though SOC 2 isn’t legally mandated, it’s frequently essential for growth because it signals that you’ve built a security program with defined controls, operating procedures, and evidence.

SecureSlate SOC 2 guides:

ISO 27001

ISO 27001 is an international gold standard for information security management. It defines how to build and operate an Information Security Management System (ISMS) so you can systematically manage risk across people, process, and technology.

Like SOC 2, ISO 27001 is typically not regulatory compliance. But ISO 27001 certification can be a powerful way to demonstrate security maturity to global customers and partners—especially in procurement-heavy markets.

SecureSlate ISO 27001 guides:

The General Data Protection Regulation (GDPR) is the cornerstone of the European Union’s digital privacy legislation. GDPR requirements govern the collection, processing, consent, and sharing of personal information to give EU/EEA individuals more control over their data.

Because GDPR is a law, it falls under regulatory compliance. If your organization processes personal data of EU/EEA individuals (including via a website or product), GDPR obligations may apply—even if your company isn’t based in the EU.

SecureSlate GDPR guides:

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) is a U.S. regulatory compliance framework that applies to entities handling protected health information (PHI).

HIPAA matters even beyond “traditional healthcare.” If you build, host, process, or support systems that touch PHI for a covered entity, you may be a business associate (or a subcontractor) with obligations under HIPAA—often reinforced via contracts like Business Associate Agreements (BAAs).

SecureSlate HIPAA guides:

PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is required for businesses that accept, process, store, transmit, or otherwise impact the security of cardholder data. PCI DSS was created by major card brands to reduce fraud and breaches.

PCI is a common source of confusion because it’s generally not a government regulation. It’s an industry standard enforced through contracts and bank/payment processor requirements. In some places, elements of PCI expectations are referenced in laws, but most organizations treat PCI as a contractual requirement that becomes mandatory if you want to handle card data.

SecureSlate PCI DSS guides:

CCPA

The California Consumer Privacy Act (CCPA), as amended by the CPRA, is a California state law that grants residents rights to know about, delete, and opt out of certain processing and sharing/sale of their personal data.

CCPA is regulatory compliance. It can apply to businesses outside California if they meet applicability thresholds and handle California residents’ personal information. In practice, CCPA is often a “go-to-market” requirement because California is a huge market and privacy expectations influence customer trust.

SecureSlate CCPA guides:

How to prioritize which standards to pursue

If you’re trying to save time and money, prioritize based on triggers and deal impact:

Start with obligations:
- Do we handle PHI? (HIPAA)
- Do we handle card data? (PCI DSS)
- Do we process EU/EEA personal data? (GDPR)
- Do we meet CCPA applicability thresholds? (CCPA/CPRA)
Then prioritize buyer friction:
- Are enterprise customers asking for SOC 2 or ISO 27001?
- Are questionnaires stalling deals because evidence is scattered?
Reduce scope before you “do compliance”:
- Tokenization/outsourcing can reduce PCI scope.
- Data minimization can reduce privacy exposure.
- Vendor architecture choices can change who does what (shared responsibility).

Streamline continuous compliance with SecureSlate

Whether a framework is regulatory or not, execution usually looks the same: define scope, assign owners, implement controls, and maintain evidence.

SecureSlate helps teams:

Map controls to frameworks (SOC 2, ISO 27001, privacy, and more)
Track ownership, review cadences, exceptions, and remediation
Centralize evidence for audits and security questionnaires
Maintain a clear trail of proof as your systems and vendors change

Get started for free: Create your SecureSlate account

FAQ

If a standard isn’t a law, do we still “have” to do it?

Sometimes yes—because customers, banks, or partners can make it a contractual requirement. “Not regulatory” doesn’t mean “optional” if it blocks revenue or increases risk.

Is PCI DSS regulatory compliance?

Usually no. PCI DSS is generally an industry standard enforced through contracts with card brands, banks, and payment processors. Depending on where you operate, parts of it may be referenced in laws—but most teams treat it as contractual.

Can a non-regulatory framework help with regulatory compliance?

Often. SOC 2 and ISO 27001 can improve security governance, documentation, and evidence—helpful for meeting regulatory expectations. But they don’t automatically make you compliant with GDPR, HIPAA, or other laws.

What’s the fastest way to figure out what applies to us?

Start with a data flow inventory: what data you collect, where it goes, who can access it, and which vendors touch it. Most applicability questions become clearer once you can trace the data.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. Compliance obligations depend on your facts and jurisdiction; consult qualified counsel for advice.

Is all compliance regulatory compliance? Regulatory vs non-regulatory standards (with examples)