Regulatory compliance

Compliance failures are rarely defiance. They are almost always an obligation nobody knew applied, in a jurisdiction nobody was watching, discovered by someone external.

This structures the work and names what to ask. Which regulations apply, and what they require, are legal determinations that vary by jurisdiction and change — they belong with qualified counsel. Nothing here substitutes for that.

Start with an obligation map, not a framework

The first question is not "are we SOC 2 compliant" but "what are we actually obliged to do, by whom, and what happens if we do not." Build the map from facts about the business:

• What you sell, and to whom. Selling to regulated customers pulls their obligations onto you through contract even when the regulation does not reach you directly.
• What data you hold. Personal data, health data, payment data and children's data each carry distinct regimes — see legal-risk:privacy-and-data-protection.
• Where you operate and where your customers are. Obligations follow the customer more often than companies expect.
• How you are funded and structured. Public, regulated, or government-adjacent adds regimes.

Distinguish three things that get conflated: law you must follow, certifications you choose to obtain commercially, and contractual commitments you signed. Only the first carries state enforcement; all three carry consequences.

Certifications are evidence, not compliance

SOC 2, ISO 27001 and their equivalents demonstrate that controls exist and operate. They do not establish that you meet any legal obligation, and a clean report is not a defense to a regulator.

Where they earn their cost is commercially — an enterprise prospect makes the certification a condition of the deal, and the certification is what unblocks it. Scope them to what the market asks for rather than to everything, since scope drives cost more than any other decision.

The program is monitoring, not documentation

A compliance program that produces policies and stops is a shelf. What makes it real:

• An owner per obligation — a named person, not a department.
• Controls that produce evidence as a by-product of the work, rather than evidence assembled before an audit. See finance:internal-controls-and-audit for the control design pattern.
• Monitoring that would detect failure before an external party does, with the frequency matched to how fast the obligation can be breached.
• Horizon scanning. Regulation changes; a map built once is wrong within a year.

When a regulator arrives

Respond promptly, accurately, and narrowly — answer what was asked. Route everything through counsel before it goes out, preserve records from the moment you are aware, and never let an informal conversation become an undocumented commitment.

Findings get root-caused like any other failure. A remediation that consists of retraining people on a process that made the failure easy will produce the same finding next cycle.

Sources

references/sources.md in this skill lists the outside authorities that settle the questions here — what each one is authoritative for, and what you may do with it. Check them before answering on anything they cover, and cite what you used. Most are free to read and not free to reproduce; the use note on each is binding.

Tooling

Compliance automation — Vanta, Drata, Secureframe, Keel GRC, and similar — collects evidence continuously and maps one control across several frameworks. It earns its cost on the second audit far more often than the first.

Policy and attestation lives in those same tools, or in the HRIS, or in Confluence. What matters is that a policy carries a version, an owner, and a record of who acknowledged it.

Never

• Treat a certification as evidence of legal compliance.
• Build a compliance program without a named owner per obligation.
• Assemble control evidence retrospectively for an audit.
• Answer a regulator without counsel reviewing the response.