"Compliance" gets used as a catch-all term, but for a business it has a specific, practical meaning: meeting a defined set of external requirements — regulatory, contractual, or voluntary — that someone else gets to verify. This article establishes what those requirements actually are, how the major frameworks relate to one another rather than compete, and why compliance readiness is best treated as an ongoing operational discipline instead of a project that ends when an audit passes.
What "compliance" actually means
A business is compliant with something specific — not compliant in the abstract. That something is usually one of three types of requirement:
- Regulatory — a law or regulation requires it, often tied to the type of data handled. HIPAA applies because you handle protected health information; there is no opt-out if you meet the applicable definition of a covered entity or business associate.
- Contractual — a customer, partner, or payment processor requires it as a condition of doing business. PCI DSS is not a law; it's a contractual requirement enforced by the payment card brands and your acquiring bank.
- Voluntary — an organization pursues it because customers, insurers, or the market increasingly expect it, even without a legal or contractual mandate. SOC 2 attestation is the clearest example: no law requires it, but enterprise customers increasingly won't sign a contract without it.
Each type creates real pressure, but the pressure comes from a different place, which matters when deciding what to prioritize first.
How the major frameworks relate to each other
Organizations often encounter NIST, HIPAA, PCI DSS, SOC 2, CIS Controls, and cyber insurance questionnaires as if they were competing standards to choose between. In practice they occupy different layers and are frequently used together.
| Framework | Type | Who It Applies To | Typical Trigger |
|---|---|---|---|
| NIST CSF | General risk-management umbrella | Any organization wanting a structured way to organize a security program | Self-initiated, or requested by an auditor/vendor risk questionnaire |
| HIPAA | Regulatory mandate | Healthcare providers, health plans, and their business associates | Handling protected health information (PHI) |
| PCI DSS | Contractual mandate | Any organization that stores, processes, or transmits cardholder data | Accepting card payments |
| SOC 2 | Voluntary attestation | B2B service and software providers | Enterprise customer due-diligence requirements |
| CIS Controls | Prioritized technical baseline | Any organization, especially small-to-midsize with limited security staff | Self-initiated, often after an incident or assessment |
| Cyber insurance requirements | De facto framework | Any organization carrying (or seeking) a cyber policy | Policy application, renewal, or claim |
NIST CSF functions as the general umbrella — a vocabulary and structure that the other frameworks implicitly map to, even when they don't reference it directly (see NIST Cybersecurity Framework Overview). HIPAA and PCI DSS are mandates tied to specific data types — protected health information and cardholder data, respectively — and neither is optional once the trigger condition applies. SOC 2 is voluntary in principle but has become a practical requirement for any company selling software or services to larger enterprises. CIS Controls provide a prescriptive, prioritized technical baseline that is useful regardless of which regulatory or contractual framework ultimately applies. Cyber insurance requirements are the newest and fastest-growing category — insurers now routinely require MFA, endpoint detection, and documented backup practices as a condition of coverage, functioning as a framework in practice even though no single published standard defines it.
Compliance readiness is a discipline, not an event
The most common mistake in how organizations approach compliance is treating it as a project with a defined end: prepare for the audit, pass the audit, move on. Every framework above actually requires continuous conformance — HIPAA's Security Rule expects ongoing risk analysis, SOC 2 Type II attestations cover a period of time (not a point-in-time snapshot), and PCI DSS requires quarterly and annual validation activities on a recurring cycle. An organization that scrambles to assemble evidence right before an assessment, then lets controls lapse afterward, will fail the next cycle even if it passed the last one.
What sustains compliance between assessments is governance — the operating model of accountability, policy review, and control ownership that keeps requirements met continuously rather than reconstructed under deadline pressure. This distinction matters enough that it gets its own treatment: see Governance vs. Compliance for what a functioning governance model actually looks like and why compliance-only organizations tend to drift out of conformance between audits.
Where to start
Most organizations don't need to pursue every framework at once. The practical starting point is understanding which frameworks actually apply based on the data handled and the customers served, then building a technical baseline (CIS Controls, organized under a NIST CSF structure) that supports whichever regulatory or contractual mandates follow. A framework selector and readiness assessment can shortcut a lot of this analysis rather than guessing from framework names alone.
Common mistakes
- Treating an audit pass as "done." Every major framework expects continuous conformance, not a one-time snapshot.
- Assuming frameworks compete rather than layer. Most organizations end up conforming to a NIST-organized technical baseline, one or two regulatory/contractual mandates, and increasingly a cyber insurance questionnaire — simultaneously, not as alternatives.
- Pursuing a framework because a peer company has it, without confirming it actually applies. HIPAA and PCI DSS have specific applicability triggers; SOC 2 is worth pursuing when customers actually require it, not preemptively.
- Skipping the technical baseline in favor of framework-specific paperwork. CIS Controls (or a similar prioritized baseline) tend to satisfy a large share of the technical requirements across every regulatory and contractual framework at once.
FAQ
Do we need to comply with every framework in the table above? No. Which frameworks apply depends on the data you handle (HIPAA for PHI, PCI DSS for cardholder data) and what your customers or insurer require (SOC 2, cyber insurance questionnaires). NIST CSF and CIS Controls are broadly useful regardless, since they organize the underlying technical work.
Is passing an audit the same as being compliant? Not in any durable sense. An audit or attestation confirms compliance at a point in time (or, for SOC 2 Type II, over a defined period). Staying compliant between assessments depends on governance — see Governance vs. Compliance.
Where should a small business with no dedicated compliance staff start? Start with a readiness assessment to identify which frameworks actually apply, then build toward CIS Controls Implementation Group 1 as a technical baseline — it satisfies a meaningful share of requirements across every other framework and is achievable without a large security team.