US Cybersecurity Compliance: Building a Defensible Control Model

There is no US cybersecurity law. There is a stack.

A company operating in the United States answers to securities regulators, sector regulators, state financial and privacy authorities, its customers’ contracts and, if it supplies the Department of Defense, a certification regime. Each has its own vocabulary. Each runs its own clock. None was written to fit with the others.

The common response is to run each obligation as a separate project. The result is duplicate controls, different standards in different business units, and an audit season in which the same evidence is rebuilt for every requester. It also hides a bigger problem: nobody can say whether the program as a whole is adequate.

The better answer is one control model. Obligations map into it. Evidence comes out of it. The rest of this article covers how to build that model and what makes it hold up when a regulator, a plaintiff or a customer tests it.

What “defensible” means in practice

Regulators and courts seldom ask only whether you were breached. They ask whether your security program was reasonable for your risk, whether it matched what you told people, and whether you can show it operated. That is our reading of how these regimes work in practice, and it gives three tests.

• Risk-based. Controls trace to a documented assessment of your own risk, not to a borrowed checklist.

• Consistent with your statements. What you tell regulators, investors, customers and insurers matches what actually operates. The SEC’s case against SolarWinds and its CISO shows where the exposure sits. A court cut most of the case back, and the SEC and SolarWinds later jointly dismissed the rest. The claims that survived the court’s ruling concerned the company’s public security statements, not the breach itself.

• Evidenced. A control that works but leaves no record will not defend you.

The obligation layers

The table below covers the layers most multinationals and larger US businesses meet. Applicability depends on your entity type, sector and data, so treat it as a map of where to look, not a determination.

Build one model, then map

1. Choose a spine. The NIST Cybersecurity Framework 2.0 is the usual choice. It has six functions (Govern, Identify, Protect, Detect, Respond, Recover), several state safe-harbour laws name it, and its Govern function gives board oversight a home. Pair it with a control catalog such as NIST SP 800-53, ISO/IEC 27001 or the CIS Controls. The framework organizes. The catalog specifies.

2. Build the obligation register around applicability. For each obligation record the test for whether it applies, the owner, the controls that satisfy it, the evidence and any notification clock. Applicability is where registers fail. NYDFS reaches licensed entities. HIPAA reaches covered entities and their business associates. CMMC follows the systems that handle federal contract information or controlled unclassified information. Scope controls to systems, not to the whole company.

3. Adopt the strictest common requirement where uniformity is cheaper. Multi-factor authentication is the clean example. One enterprise standard costs less than a carve-out for each legal entity. Do not do this everywhere. Some of the strictest requirements, such as CMMC’s, belong in a scoped enclave rather than across the whole estate.

4. Run one incident decision path. Detection feeds triage. Triage feeds a legal and business determination. That determination starts every clock at once: SEC materiality, FTC and state notices, regulator-specific notices and contractual notice. A process that waits for forensic certainty before deciding materiality is the exposed one. Rehearse it with legal in the room.

5. Make evidence a by-product. Every control has an owner, a test and a record that operation produces. Exceptions carry an expiry date and a named risk acceptor. Examiners, auditors and customers then draw from one evidence set instead of commissioning their own.

Where control models fail

Mapping without ownership. A spreadsheet links controls to regulations, nobody maintains it, and it is stale within a quarter as rules move.

Policy ahead of practice. Program documents describe a standard the environment does not meet. The documents then become the evidence against you.

Acquisition drift. An acquired business brings its own regulators, systems and scope. Unless integration includes control mapping, the model lags the deal.

Attestations standing in for validation. A vendor’s assurance report shows the vendor’s scope. Your risk sits in yours.

Untested decision rights. The materiality call is made once, under pressure, by people who have never made it together.

Questions for security leadership

1. For each material obligation, can we show which control satisfies it and where the evidence sits?

2. Which obligations set the highest bar, and have we adopted that bar wherever uniformity is cheaper?

3. Who makes the materiality decision, how quickly, and when did they last rehearse it?

4. Does anything we say publicly about security go further than our environment demonstrates?

5. Which rules are still moving, including CIRCIA, HIPAA, CMMC phasing and state law, and who is watching them?

Sources

1. U.S. Securities and Exchange Commission, Public Company Cybersecurity Disclosures; Final Rules (fact sheet) — sec.gov

2. Winston & Strawn, SEC and SolarWinds Litigation Dismissed Following Joint Stipulation — winston.com

3. Hogan Lovells, NYDFS final set of cybersecurity requirements under amended Part 500 — hoganlovells.com

4. McDonald Hopkins, FTC Announces Amendment to Safeguards Rule Provision — mcdonaldhopkins.com

5. Davis Wright Tremaine, HHS Updates HIPAA Rulemaking Timeframes — dwt.com

6. McDonald Hopkins, CMMC Phased Roll-Out Finally Begins — mcdonaldhopkins.com

7. Nextgov, CISA expects to finalize key cyber reporting rule — nextgov.com

8. CISA, Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) — cisa.gov

9. Wilson Elser, States Enact Safe Harbor Laws That Provide Affirmative Defenses in Data Breach Litigation — wilsonelser.com

10. NIST, Cybersecurity Framework — nist.gov