Compliance work fails in a predictable way. An organisation buys a policy template pack, fills in the blanks, files it, and believes the obligation is discharged. Then an assessor asks not for the policy but for evidence that the control it describes has been operating — twelve months of access reviews, patch records, training completions, log retention — and the gap between what was written and what was done becomes the finding.
We treat compliance as an engineering problem. Controls get implemented in the environment, the environment produces evidence as a by-product, and the documentation describes something that is actually true.
How an engagement runs
Every framework engagement follows the same shape. Scope — establish what is in and out, because scope determines cost more than any other decision. Gap assessment — measure the current state against the control set, honestly, including the uncomfortable parts. Remediation — close gaps in risk order rather than in the order they appear in the standard. Evidence — instrument the controls so they generate proof continuously. Readiness — a dry run before the real assessor arrives.
HIPAA
The Security Rule is less prescriptive than most people expect and more demanding in practice. The core obligations — a genuine risk analysis, access controls, audit controls, encryption decisions documented with reasoning, and business associate agreements that reflect reality — are where findings cluster. The risk analysis in particular is the single most commonly cited deficiency, usually because it was performed once, years ago, and never revisited after the environment changed.
PCI DSS 4.0
Version 4.0 brought several requirements that were future-dated and are now simply in force, along with a stronger emphasis on continuous rather than annual validation. The most valuable work here is usually scope reduction: every system that touches cardholder data pulls a large control set with it, and re-architecting so that fewer systems touch it is cheaper than protecting all of them.
SOC 2 Type II
Type II differs from Type I in one critical respect: it examines whether controls operated effectively over a period, typically six to twelve months. That makes it a scheduling problem as much as a security one. Controls need to be live and generating evidence before the observation window opens, which is why the organisations that struggle are the ones that start three months before a customer deadline.
NIST 800-171 and CMMC 2.0
If you handle Controlled Unclassified Information under a federal contract, this is not optional and the timeline is real. CMMC Phase 2 makes third-party certification by an accredited C3PAO mandatory for contracts involving CUI as of November 10, 2026 — self-attestation on the things that matter goes away.
The work starts with the CUI boundary. Draw it too wide and you are hardening machines that never see CUI; draw it too narrow and an assessor finds CUI somewhere unprotected, which is worse. From there it is the 110 requirements of NIST SP 800-171, a System Security Plan that matches reality, and a Plan of Action and Milestones that is genuinely being worked rather than maintained as a fiction.
One honest caveat we give every prospect: getting to a defensible Level 2 posture from a cold start realistically takes nine to twelve months, because evidence has to accumulate. That is precisely why starting now rather than next quarter is the whole point.
GLBA Safeguards Rule
The FTC's amended Safeguards Rule reaches considerably further than banks. Mortgage brokers, tax preparers and CPAs, auto dealers arranging financing, investment advisers, collection agencies — all can meet the definition of a financial institution. The rule requires a named Qualified Individual, a written information security programme, a risk assessment, vendor oversight, and breach notification to the FTC within thirty days of discovering an event affecting five hundred or more consumers.
The Ohio angle worth knowing about
Ohio businesses have an incentive that businesses in most other states do not. The Ohio Data Protection Act provides an affirmative defence against certain tort claims arising from a data breach, available to organisations that maintain a written cybersecurity programme reasonably conforming to a recognised framework — NIST, CIS Controls, ISO 27001, and several others qualify.
It is a safe harbour rather than immunity, and whether it applies to a given claim is a question for your counsel. But the practical implication is straightforward: the same work that reduces your risk of a breach also improves your legal position if one happens anyway. Very few Ohio businesses we speak to know this provision exists.
What you end up with
A control set that operates, documentation that describes it accurately, evidence that accumulates without anyone having to remember, and a readiness assessment before you spend money on an external auditor. Framed commercially: fewer findings, shorter audits, better insurance conversations, and a defensible position if something goes wrong.
Facing an audit, a customer security questionnaire, or a contract requirement with a date on it?
This page is general information about regulatory frameworks and is not legal, compliance, audit, or insurance advice. Any engagement is governed by the executed Torchsec service agreement.