What is the best way to structure our control library - by framework or by domain?

Exactly. That blast radius problem is real. We ended up having to build a similar phased rollout for our compliance dashboards.

Our twist was adding a grace period warning in the dashboard UI itself, not just breaking the build. If a user's query was using a deprecated hash, they'd see a clear banner: "This data view is based on an outdated control schema. It will stop updating in 7 days." That gave teams a self-service heads up without a centralized support ticket flood.

It turns silent technical debt into visible, manageable tech debt.

Great question, and you've nailed the core tension perfectly. The "sustainable long-term" question usually tips toward the domain approach, because control owners will actually maintain what they understand.

That said, the reporting breakdown is key. In my experience, the domain structure works *if* you treat framework mapping as a first-class data governance task from day one. It can't be an afterthought. Your framework tags need to be a validated, picklist-driven attribute on every control, or your audit reports will be a mess. It adds overhead, but it's essential overhead.

What's your team's capacity for maintaining that central taxonomy? That's often the make-or-break factor people discover too late.

So your "hard validation rule" is now a mandatory CI check? I'm sure that junior PM was thrilled.

I've seen that exact scenario create the opposite problem: a team so afraid of the CI failure that they slap any framework tag on there just to make the pipeline green. You get perfect tagging compliance and completely meaningless mappings. Auditors might love a cross-framework view, but they love accurate data more. A false signal dressed up with pretty validation is still a false signal.

Spot on about capacity being the make-or-break factor. Our team learned this the hard way. We started with a strict validated list for framework tags, but the team responsible for the "compliance-schema" repo had zero bandwidth. It was a classic "everybody's responsibility is nobody's responsibility" scenario.

We finally solved it by making the framework taxonomy part of the same repo as our main controls, using a simple YAML file. Any team adding a new framework could submit a PR there. It's not perfect, but it pulled taxonomy maintenance out of the abstract and into our normal workflow.

The real risk I'd add is what happens when that single, validated list inevitably gets out of sync with reality. Like when a framework updates a control identifier. If you're not on top of it, your entire reporting layer is instantly wrong.

That framework versioning risk you mentioned is huge. We had a PCI DSS update completely change the control numbering structure last year. Our validated list was pristine... and perfectly aligned with the old version.

The fix we landed on wasn't technical, it was procedural. Our quarterly vendor risk review now has a mandatory first step: check the official sites for our top 5 frameworks and note any updates. It's a 15-minute task per quarter that prevents months of cleanup. It puts the maintenance burden on a calendar, not on someone's "when I get to it" list.

Mandatory is the only way to enforce it, but I've seen teams get so focused on the validation rule that they forget to validate the validator. A junior PM slapped with a CI failure will often pick the first framework tag from the dropdown just to make it pass, creating garbage data that's even harder to untangle later. You can't just gate the field, you have to gate the logic behind it.

Oh, this debate is so familiar. We went with the domain structure after seeing a framework-first library become a ghost town nobody maintained.

The trick was investing early in the reporting layer. We built dashboard views that could pivot the same data: a domain owner sees their controls, an auditor gets a filtered, framework-specific report. It required treating framework as a strict, validated metadata field from day one, not a tag you add later.

The sustainability question really comes down to who owns the taxonomy. If your domain teams don't feel responsible for keeping framework tags accurate, your audit reports will be beautiful and wrong.

Your move from regex to a validated YAML schema is the right upgrade. The critical piece you mentioned is the pre-approved list from a central config file. That's where most teams hit a snag. Who owns that list? If it's not as easy to update as writing a control, teams will work around it.

I've seen that central config become a bottleneck, so we versioned it alongside the control library itself. Any PR that adds a new framework tag includes the taxonomy update, or it doesn't merge. It keeps the validation from becoming stale policy.

We landed on the domain approach after our framework-first library fell out of date within a year. The real key for us was building that "pivot" capability into our ServiceNow GRC dashboards from the start.

We created a single control record, owned by a domain, but with mandatory, validated framework attributes. That let us build report definitions that filtered by framework, so the audit team still got their clean, single-framework view. It put the maintenance burden on the domain teams who actually understood the controls.

The initial setup is heavier, but it solved the long-term problem: controls were maintained because people understood them, and reporting stayed accurate because the framework data was a required field, not an afterthought.

You're asking which structure is more sustainable, but what if the question itself is a trap? Both approaches fail if you treat them as static choices.

Domain structure is intuitive until the domains change. Framework structure is clean until a new regulation lands. The real regret isn't picking wrong, it's assuming any structure won't drift.

How do you plan for the next re-org or framework update? That's where the breakdown happens.