What Cybersecurity Regulations Apply to My Business?

What are the different sources of a cybersecurity obligation?

Short answer: laws and regulations, regulator guidance, contracts, insurance representations, and voluntary frameworks. They are not interchangeable.

• Laws and regulations are issued under legal authority and enforced by a government body, such as the FTC Safeguards Rule at 16 CFR Part 314.
• Regulator guidance explains expectations and practices without itself being the enforceable text, for example IRS Publication 4557 and IRS Publication 5708.
• Contracts including customer addenda, vendor flow-down terms, and questionnaire commitments create obligations between private parties.
• Insurance representations are the statements made on an application and the conditions written into a policy.
• Voluntary frameworks such as the NIST Cybersecurity Framework are structures for organizing security work. They become obligations only when a law, contract, customer, or insurer requires them.

Is my business directly regulated?

Short answer: it depends on the information handled and the activities performed, not on the industry label.

Organizations that handle protected health information as covered entities or business associates may fall under HIPAA. Businesses that meet the definition of a financial institution may fall under the FTC Safeguards Rule, which the FTC describes in its business guidance and which is codified at 16 CFR Part 314. Firms that prepare tax returns handle taxpayer information addressed in IRS Publication 4557. Insurance licensees may be subject to state insurance data-security laws, which are adopted state by state rather than nationally, as reflected in NAIC data privacy and insurance material. If none of these describe the organization, that is not the same as having no obligations.

Can a customer contract create obligations even if no law does?

Short answer: yes, and this is one of the most commonly missed triggers.

Larger customers often require a security questionnaire or a specific security addendum before signing. Those are not government regulations, but they can function the same way in practice: miss them and the agreement is at risk. For many growing companies, a customer contract is the first real cybersecurity obligation encountered, well before any regulator is involved.

Can a vendor or supply chain relationship create obligations?

Short answer: yes, obligations can flow down from someone else's requirements.

A subcontractor may accept security terms that its prime contractor is required to pass along. An organization that handles protected health information on behalf of a covered entity may be treated as a business associate under HIPAA even though it is not a provider or insurer. The obligation did not originate with the business, yet it can still apply to it.

Does cyber insurance create its own requirements?

Short answer: often in practice, through application representations and policy conditions.

Cyber insurance applications commonly ask about controls such as multi-factor authentication, backup practices, and endpoint protection. The answers given become representations. If a representation is materially inaccurate, or if a described control was not operating as stated, that can matter when a claim is reviewed. How it matters depends on the application, the policy language, the facts, and applicable law.

Connecting those representations to what is actually operating and documented is the work of cyber insurance readiness.

What information has to be reviewed to answer the question well?

Short answer: the business facts, before any framework is selected.

That usually means the information collected and stored, the services performed, the customer base and its contract terms, licenses and jurisdictions, vendor and subcontractor relationships, completed insurance applications and current policy conditions, and recent changes such as new markets, new information types, or new contract language. Guessing from industry alone is where organizations get this wrong in both directions, either assuming a law applies when it may not, or missing a contractual obligation that does.

Who can make the final legal determination?

Short answer: qualified legal counsel, a regulator, or a contracting authority, depending on the question.

This article, and any assessment based on it, provides general information rather than a legal opinion. What an applicability review can do is separate what is confirmed, what is strongly indicated, what is conditional, and what remains unresolved, so leadership and counsel know exactly what to verify.

What should an applicability register contain?

Short answer: each potential obligation, its triggering authority or agreement, its classification, and the evidence needed to resolve it.

A useful register records the source of each obligation (statute, regulation, regulator guidance, contract, insurance representation, or vendor requirement), the classification (confirmed, strongly indicated, conditional, not presently indicated, or undetermined), the internal owner, and the evidence still needed. That turns a vague sense that something must be done into a specific, prioritized list.

What is the next step once obligations are identified?

Short answer: decide what to build first, using the classifications and the evidence gaps.

Deciding what to build is a different exercise from determining what applies. The cybersecurity regulatory applicability assessment is built to answer the applicability question first, with a scope analysis, an applicability register, and a prioritized roadmap as deliverables.

For industry-specific views, see cybersecurity requirements for tax preparers and accounting firms and insurance agency cybersecurity requirements and readiness. To discuss a specific situation, contact Infosec Check.

Frequently asked questions

Authoritative sources

• FTC Safeguards Rule: What Your Business Needs to Know

  Issuer: Federal Trade Commission

  Supports: How the Safeguards Rule describes covered financial institutions and program elements.

• 16 CFR Part 314, Standards for Safeguarding Customer Information

  Issuer: Electronic Code of Federal Regulations

  Supports: The regulation text referenced when discussing Safeguards Rule requirements.

• Publication 4557, Safeguarding Taxpayer Data

  Issuer: Internal Revenue Service

  Supports: IRS guidance for firms that handle taxpayer information.

• Publication 5708, Creating a Written Information Security Plan

  Issuer: Internal Revenue Service

  Supports: IRS guidance on documenting a written information security plan.

• Data Privacy and Insurance

  Issuer: National Association of Insurance Commissioners

  Supports: Background on insurance data-security model law activity, which is adopted state by state.

• Cybersecurity Framework

  Issuer: National Institute of Standards and Technology

  Supports: An example of a voluntary framework that becomes a requirement only when adopted or required.

Primary sources are cited for the specific point noted. They do not determine how a rule, contract, or policy applies to a particular organization.