Most companies do not start with a cybersecurity problem. They start with a question: does any of this actually apply to us?
The honest answer is that "cybersecurity regulation" is not one thing. It is a mix of laws, contracts, frameworks, vendor requirements, and insurance conditions, and each one gets triggered differently. A company can be exempt from a law and still be contractually obligated to meet a security standard. A company can have no regulator at all and still lose a deal for lacking a SOC 2 report. This article walks through where these obligations actually come from, so you can tell which ones might apply to you before you invest in the wrong program.
Is my business directly regulated?
Direct regulation usually comes from the type of data you handle or the industry you operate in. Healthcare organizations and their business associates fall under HIPAA. Financial institutions and companies that function like one fall under the FTC Safeguards Rule or GLBA. Insurance carriers and agencies are subject to state-level model laws in many jurisdictions. Federal contractors and subcontractors handling certain data types may fall under CMMC and NIST 800-171. If none of these describe you, you may not have a direct regulator, which is not the same as having no obligations at all.
Can a customer contract create obligations even if no law does?
Yes, and this is one of the most common triggers companies miss. Enterprise customers routinely require a SOC 2 report, a security questionnaire, or specific contractual security addenda before they will sign. These are not government regulations, but they function the same way: miss them and you lose the deal or breach the agreement. For many growth-stage companies, a customer contract is the first real cybersecurity obligation they encounter, well before any regulator is involved.
Can a vendor or supply chain relationship create obligations?
Obligations can also flow down from someone else's requirements. If you are a subcontractor to a company that holds CMMC obligations, those requirements can flow down to you contractually. If you handle protected health information on behalf of a covered entity, you may become a business associate under HIPAA even though you are not a hospital or insurer yourself. The obligation did not originate with you, but it applies to you anyway.
Does cyber insurance create its own requirements?
Often, yes. Cyber insurance applications ask specific questions about controls such as multi-factor authentication, backup practices, and endpoint protection. The answers you give become representations. If those representations turn out to be materially inaccurate, or if a required control was not actually in place, it can affect how a claim is evaluated. This means your insurance policy can effectively create security requirements that exist independently of any law or regulation.
Are SOC 2 and ISO 27001 laws?
No. SOC 2 and ISO 27001 are frameworks and attestation standards, not statutes. Nobody is legally required to have a SOC 2 report the way they are required to comply with HIPAA. But because customers and partners often require them contractually, they function as a practical requirement even though they carry no legal force on their own. This distinction matters because the evidence, the timeline, and the deliverable look different depending on whether you are meeting a legal requirement or a contractual one.
When do HIPAA, GLBA, FTC Safeguards, PCI DSS, or CMMC actually apply?
Each has its own trigger, and the details matter more than the name of the law:
- HIPAA applies to covered entities and business associates that handle protected health information.
- GLBA and the FTC Safeguards Rule apply to financial institutions and companies performing financial-institution-like functions, including some retailers and dealers.
- PCI DSS 4.0 applies to any organization that stores, processes, or transmits payment card data, regardless of industry.
- CMMC and NIST 800-171 apply to federal contractors and subcontractors handling certain categories of government data.
None of these self-identify. Determining which one, if any, applies to your business requires looking at what data you handle, who your customers are, and what your contracts say.
What information has to be reviewed to know for sure?
An accurate answer usually requires looking at the data types you collect and store, your customer base and their contractual requirements, your vendor and subcontractor relationships, any insurance applications you have completed, and any recent organizational changes such as new markets, new data types, or new contract terms. Guessing based on industry alone is where most companies get this wrong in both directions, either assuming they are covered by a law that does not apply, or missing a contractual obligation that does.
Who can make the final legal determination?
This article, and any assessment based on it, provides directional guidance rather than a legal opinion. Formal determinations about whether a specific law applies to your specific business should be confirmed with qualified legal counsel where the answer carries legal or contractual weight. What an applicability review can do is identify which obligations are confirmed, which are strongly indicated, which are conditional, and which require outside confirmation, so that counsel and leadership know exactly what to verify.
What should an applicability register contain?
A useful register lists each potential obligation, the source it comes from (statute, contract, framework, insurance representation, or vendor requirement), the classification (confirmed, strongly indicated, conditional, not presently indicated, or undetermined), and the evidence needed to resolve anything marked conditional or undetermined. This turns a vague sense of "we probably need to do something" into a specific, prioritized list.
What's the next step once obligations are identified?
Once you know what actually applies, the next step is deciding what to build first. That is a different exercise from figuring out what applies in the first place, and it is where most companies waste time and budget by skipping straight to a framework before confirming it is the right one. The Cybersecurity Regulatory Applicability & Readiness Assessment is built specifically to answer the applicability question first, with a scope analysis, an applicability register, and a readiness roadmap as the deliverables.
Start with the Applicability Assessment