Control-centric vs obligation-centric compliance

Caution

This is an informal framing, not a formal standard. It’s a practical distinction for choosing tools — coined to separate two jobs the word “compliance” blurs together. It is not the IIA Three Lines Model (that’s an accountability structure — 1st/2nd/3rd line), and the older “Lane 1 / Lane 2” shorthand was dropped precisely because the numbering invited that confusion.

The distinction

“Compliance management” is really two different jobs, distinguished by their atomic unit:

	Control-centric compliance	Obligation-centric compliance
Atomic unit	a control (you point the tool at requirements)	a regulatory obligation (the tool points you at what changed)
The job	maintain a control library; map controls to many frameworks at once; collect evidence once + reuse; stay audit-ready	track laws + regulatory changes; maintained reg-content feeds; obligation library; policy mapping; complaint + exam management
Typical owner	ISRM / GRC engineer	compliance officer
Example questions	”Which controls satisfy CRI + ISO 27001 + 800-53 at once?” · “Which controls have no evidence?"	"What did the CFPB just change in Reg E, and which policies are now stale?”
Representative tools	Hyperproof, Anecdotes, Vanta, Drata, CISO Assistant, RegScale, Crosswalker	Ncontracts/Ncomply, 360factors Predict360, Quantivate, SBS TRAC

Why it matters

You generally need one tool in each — they don’t substitute. A control-centric tool, however good at crosswalks and evidence reuse, won’t watch the Federal Register for you or maintain consumer-regulation content. And an obligation-centric reg-CMS won’t give you a relatable control library mapped across frameworks.

The two connect at the control: an obligation maps down to the control(s) that satisfy it. That down-map is what lets a reg change surface exactly which controls and evidence are affected — the join a unified risk model provides.

The grey area: control-shaped regulations

Some regulatory expectations are control-shaped — “you must have these safeguards” (e.g. GLBA 501(b) Safeguards, FFIEC IT examination expectations, NCUA cyber guidance). Those express cleanly as controls + evidence, so a control-centric tool handles them well. The consumer/transactional regulatory pile (lending, deposits, disclosures) is not control-shaped and stays in the obligation-centric system. So the boundary isn’t “cyber vs not” — it’s “control-shaped vs obligation-shaped.”

Where Crosswalker sits

Crosswalker is control-centric. Its atomic unit is a control/concept, related to many authorities via typed crosswalk edges. It does not do obligation-centric compliance (no maintained regulatory-change content). It’s in the company of CISO Assistant (OLIR-based) and the SCF (STRM-based); its differentiator is plain-text ownership in your own knowledge base.

What this is not

• Not the IIA Three Lines Model. That’s a formal accountability structure — 1st line (operational management), 2nd line (risk + compliance oversight), 3rd line (internal audit / assurance). It answers who is responsible; this distinction answers what a tool’s atomic unit is. They’re orthogonal — a 2nd-line compliance function can use either a control-centric or an obligation-centric tool (usually both). See how the unified risk model relates to governance models.
• Not a published taxonomy. No standards body defines “control-centric / obligation-centric.” It’s a pragmatic lens; treat it as such.

Related

• Related tooling (GRC, audit, compliance, risk) — the named tools in each category
• Unified risk model — where the two connect (at the control)
• For regulatory compliance · For GRC / ISRM — the audience entry points