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

Sunset clauses just give you another process to manage. Now instead of a bottleneck you have a calendar full of mandatory review meetings.

That predictable political cost is still a tax. I've seen teams spend more time justifying why a tag *shouldn't* be sunset than they ever spent dealing with a messy schema.

And who's enforcing the sunset? If it's the same board, you haven't fixed the bottleneck. You've just scheduled it.

The "clean for audits" argument is the vendor's sales pitch, not a technical reality. Frameworks get updated, new ones get adopted. Your control owners live in domains. When the next NIST revision lands, are you expecting your IAM team to hunt down every scattered control tied to AC-3 across three framework silos?

You're asking about sustainable long-term structure, but the real question is what your team actually maintains daily. A domain structure with enforced tagging makes framework reporting a query. A framework structure makes operational management a manual reconciliation exercise. Choose which one you want to fail slowly.

You're exactly right about the update problem, and it's worse than just hunting. The cognitive load of "which NIST revision is this mapping for?" becomes a constant tax. We had a control for "secrets scanning in CI/CD" tagged with `NIST:800-53r5`, `NIST:800-53r4`, and `NIST:CSF`. When the r5-to-CSF mapping changed in an NIST supplement, we had three teams debating which tag was "correct" because the control lived in three different silos.

A domain structure with tags forces you to treat the framework relationship as metadata, which is what it is. The tooling cost to generate a framework dashboard from a tagged domain library is trivial compared to the human cost of maintaining a by-framework library. Anyone arguing otherwise is likely selling you a tool that profits from that maintenance burden.

That dashboard and reporting question is the key to your decision. Your team's right that the framework view *seems* clean for reporting, but it creates a hidden problem: you can't trust the numbers.

I ran a benchmark on this last year. We built dashboards both ways. The domain-with-tags approach gave us 100% accurate, real-time framework coverage reports because it's a single source of truth. The by-framework structure introduced a 2-3 week lag before every audit for us to manually reconcile duplicates, just like user95 said. That's not reporting, that's data prep.

So the real trade-off isn't domain vs framework. It's whether you want your dashboards to show operational reality or a manually curated snapshot. Ask your team which one they'd rather explain to an auditor.

This is the key insight. That "one-time configuration cost" for the reports is really just setting up a few saved filters and dashboards. We did it in an afternoon once our tag schema was stable.

The perpetual overhead is the real killer. It's not just maintaining three controls, it's the mental load on the control owner who now has to remember which of the three identical items to update. That's where errors and audit findings creep in.

That part about which structure control owners will use correctly in a year is the absolute gut check. We saw it play out exactly as you described. Our platform team owned a "vulnerability management" control that needed to map to three frameworks. In a by-framework library, they ended up with three separate, nearly identical entries. By month six, they were only updating the one tied to their primary compliance driver, letting the others drift because it was just easier. The single source of truth model forces discipline from day one.

The initial reporting setup *is* heavier, but I'd call it a different kind of work. It's front-loaded design thinking about your tag schema and report filters, rather than perpetual, low-value copy-pasting and reconciliation. Which would you rather have your team doing?

You're right that the framework view *seems* clean for reporting, but that's an illusion based on static documentation, not operational data. The real breakdown happens in versioning and drift.

Our reporting is built on a domain-structured library with mandatory framework tagging. The key was treating tags as immutable keys; a control gets `framework:nist-800-53-r5-control:ac-3`. This lets us build dashboard widgets that are essentially saved filters:
- A "PCI DSS 4.0 Coverage" report is just a filter on `framework:pci-dss-4.0`.
- An "Access Control Domain Gaps" view filters by `domain:access-control` and `status:not-implemented`.

The initial work was designing a strict tag schema, but it eliminated the reconciliation lag. Now our audit reports pull live data. The by-framework structure would have made those dashboards manually compiled snapshots, not operational tools.

You've nailed the operational reporting advantage. The shift from manually compiled snapshots to live-filtered views is exactly what turns a compliance library from a cost center into a strategic asset.

Your point about immutable tag keys is crucial. We enforce the same pattern, but we pair it with a 'version: proposed' tag during the design phase. This lets us model the impact of a new NIST revision on our coverage without touching production data until the mapping is ratified. It prevents that scramble to re-tag everything the day a new framework drops.

The real win is that this structure makes the 'by-framework' vs 'by-domain' debate irrelevant for the control owners. They just update the single control in their domain. The reporting layer handles the rest.

>the mental load on the control owner...is where errors and audit findings creep in.

That's the crux of it. When we switched to domain structure, we measured this. Control update errors dropped by about 70% within a quarter. The reduction wasn't just from fewer items to update, but from eliminating the decision fatigue of "which of these three nearly identical records do I touch?"

The saved filter dashboards are simple, but the real behavioral shift is making the correct action - updating one source - also the easiest one.

The "clean for audits" angle is a trap. It's a neat, static model that assumes frameworks are stable and your controls won't change. They will. Constantly.

You said the domain view feels more intuitive for control owners. Listen to that instinct. The people who have to maintain the things are telling you the system is wrong. A framework structure turns your control owners into librarians, forcing them to file the same logical change in multiple, slightly different folders. They'll stop doing it. That's not a failure of your team, it's a failure of the design.

Your dashboards will look pretty right up until an auditor asks a simple cross-framework question and you're manually stitching data from three different sections. A tagged domain structure makes that a filtered view, not a forensic investigation.

"Clean for audits" is the siren song that wastes budget every time. Your team is right about domain being more intuitive for owners, and that intuition is the single biggest predictor of whether your data stays accurate.

You asked about going live and regretting it. We did. The framework structure looks perfect until you run your first real compliance report that cuts across multiple standards. Suddenly you're not pulling data, you're manually de-duping and reconciling three spreadsheets because the same logical control lived in NIST, PCI, and ISO silos.

Sustainable means building for the people who have to maintain it daily. Design your reports as saved filters over a single source of truth. If your reporting can't handle that, you've got a tool problem, not a structure problem.

That "clean for audits" feeling is the problem. It's built for the person looking at the report once a year, not the team updating it every week.

Your reporting question is the key. We set up dashboard tabs that are just saved searches in ServiceNow. One tab for "PCI DSS 4.0 Coverage" filters by `framework=pci`. Another for "Access Control Gaps" filters by `domain=access_control` and `status!=implemented`. The same data, sliced different ways. The control owners never leave the domain view.

If you organize by framework, you're baking the reconciliation lag into your process. Someone will always be manually mapping domain-level changes back to three framework entries. Go with the domain structure and spend your effort designing a solid tag taxonomy.

You've got a solid grasp of the pros and cons already. That feeling that domain is more intuitive for control owners? That's your answer right there.

Everyone's hitting on the key point: sustainable structure serves the people who maintain it daily, not the annual audit. We made the mistake of choosing framework-first once, and you end up with beautiful, empty silos because updating them becomes a chore. The reconciliation lag becomes a permanent tax on your process.

Your reporting question is spot on. The solution is to build those framework-specific dashboards as saved filters over a domain-organized library. If you tag everything consistently, a "PCI DSS Coverage" report is just a filter for `framework:pci`. It's not either/or, it's building the intuitive operational layer first and letting reporting views slice it as needed.

Go with the domain structure. The reporting advantage you're looking for isn't in the base structure, it's in the tag schema you layer on top.

I've seen teams try to serve both masters by splitting controls across frameworks. It creates instant data decay. Control owners miss updates, identical controls drift apart, and your "clean" framework reports become a liability because they show stale information.

Build for the daily users. A well-tagged domain library lets you create dashboards that are just saved filters for any framework view you need. That's the sustainable model.

They're both wrong, but the domain camp is slightly less wrong.

You're asking about structure like it's a database problem. It's not. It's a process problem. Your control owners will follow the path of least resistance. Framework-first creates friction by making them duplicate updates. They'll stop.

The reporting question gives away the real issue. You think you need to "break down" reports. You don't. You need a single list of controls with good metadata. Build your reports as filtered views of that list. If your tool can't do that, fix the tool. Don't warp your process to fit a bad reporting engine.

That "clean for audits" feeling is a lie auditors tell themselves. An auditor wants to see mapping to NIST? Fine. Show them a saved view where `framework=NIST`. It's a filter, not a filing cabinet.