Regulatory Change Is an Operating-Model Problem

Category: Operating Models Author: Cody Swidler Tags: regulatory change, horizon scanning, compliance operations, requirement decomposition, control mapping

Here's a sequence I've watched play out at more than one regulated company. A significant regulation is announced with a two-year runway. Legal circulates a memo summarizing it. The memo is discussed at a leadership meeting, someone says "we should be in good shape on most of this," and the item moves to the parking lot. Twenty months later, an examiner asks for the implementation evidence, and the organization discovers — under the worst possible spotlight — that "we should be in good shape" was the entire program. The memo was the deliverable. Nothing downstream of it ever happened.

The failure wasn't awareness. Everyone knew the regulation existed; it had been in every industry newsletter for a year. The failure was that awareness had nowhere to go. There was no machinery that turned "this regulation exists" into "these fourteen requirements apply to us, nine are already covered by existing controls, five need work, and here are the five owners and dates." Regulatory change management fails at the handoffs — which makes it an operating-model problem, the same species of problem I described in the GRC operating model is the program.

Horizon Scanning Without Ownership Is a Newsletter

Most organizations believe they do horizon scanning because someone subscribes to regulatory alerts. But scanning is the cheapest step in the chain, and on its own it produces exactly nothing. The question that matters is what happens to an item after it's spotted: who is accountable for deciding whether it applies, by when, and in front of which forum? If the answer is "it gets forwarded to the relevant team," you don't have a process — you have a distribution list, and distribution lists don't produce implementation evidence.

The fix is unglamorous: an intake queue with an owner and a clock. Every scanned item gets a disposition — applicable, not applicable, monitor — made by a named person within a defined window, and recorded with the reasoning. "Not applicable" is a decision worth documenting as carefully as "applicable," because examiners ask about the regulations you dismissed, and "we assessed it in March, here's the rationale" is a very different conversation from a shrug.

Decompose Before You Assign

The step organizations skip most reliably is decomposition. A regulation is not a requirement; it's a container of requirements — dozens of discrete, testable obligations wearing one name. Until someone breaks the container into rows — this article requires an incident classification scheme, this one requires subcontractor visibility, this one requires board-level reporting — the regulation can only be assigned as a whole, which means it gets assigned to whoever is least able to dodge it, which is how a governance regulation ends up owned entirely by IT. That's precisely the misread I wrote about in DORA is not an IT problem: hand the container to one function and every requirement inside inherits that function's blind spots.

Decomposed requirements, by contrast, route naturally. The incident-reporting clause goes to the incident process owner. The third-party clauses go to TPRM. The governance clauses go to the corporate secretary and the risk committee. Each row gets an owner who can actually implement it, and the regulation's implementation status becomes something you can compute — a coverage percentage over rows — instead of something you can only assert.

Map to What You Already Have

Here's where the operating model pays for itself. If you maintain a unified control library — one set of controls, cited across every framework you answer to — then a new regulation is a mapping exercise before it's a build exercise. Walk the decomposed requirements against the library: this clause is satisfied by the access-review control you already run for SOC 2; this one by the DR testing you already do for ISO 22301; this one by nothing, which is a genuine gap. At every organization where I've run this exercise, somewhere between sixty and eighty percent of a new regulation's requirements were already covered by existing controls. The program that maps first spends its two-year runway on the real twenty to forty percent. The program that doesn't map builds a parallel compliance effort for obligations it already met, and its people can feel the redundancy, which is where compliance cynicism comes from.

The gaps that survive the mapping become tracked work — owner, target date, status, the same remediation discipline you'd apply to an audit finding. And the new requirement rows join the library's citation columns, so the next assessment, the next audit, and the next regulation all read from the same source of truth.

Give the Chain a Governance Home

Finally, the chain needs a forum — not a new committee, almost certainly an agenda item on one you already run. Quarterly, the regulatory change pipeline gets fifteen minutes: what entered intake, what was dispositioned and how, which implementations are on track, which are slipping past dates that regulators can see. The forum matters because regulatory implementation constantly loses prioritization fights with revenue work, and it should lose some of them — but deliberately, on the record, with the risk of the delay owned by someone with the authority to accept it. Silent slippage is how two-year runways evaporate.

None of this is intellectually hard. Scan with ownership, disposition on a clock, decompose into rows, map against the library, track the gaps, review on a cadence. Six steps, every one of them boring. But regulatory change is a domain where boring machinery beats brilliant memos every time — because the memo tells you what the regulation says, and the machinery is the only thing that can tell an examiner what you did about it.

Cody Swidler is the founder of PivotRisk and a Principal Program Manager, Enterprise Resiliency at Apex Clearing. He has built and scaled GRC, resilience, and risk programs across Microsoft, Twilio, Box, Zayo, and Miro.