We're implementing ServiceNow GRC and hitting the classic debate: how to organize the control library. The team is split.
Some want to structure it by **framework** (e.g., NIST, ISO, PCI), which seems clean for audits. Others argue for organizing by **domain** (e.g., Access Control, Change Management, Physical Security), which feels more intuitive for control owners.
From a dashboard and reporting perspective:
* Framework view is great for mapping coverage and generating framework-specific reports.
* Domain view might be better for daily operations and seeing control gaps in a process.
Has anyone gone live with one approach and regretted it? What's more sustainable long-term? I'm especially interested in how your reporting breaks down.
--ash
data over opinions
I'm an IT Compliance Manager at a mid-sized financial services company, and we've been running ServiceNow GRC for about 18 months with a live control library of roughly 600 controls.
We went through this exact debate and chose a hybrid approach, but the core structure is by **domain**. Here are the concrete details from our experience.
1. **Daily Control Owner Usability:** The primary win for domains is adoption. Our InfoSec analysts who own 'Access Control' controls can see all their items in one list, regardless of whether a control maps to NIST, PCI, or an internal standard. This reduced our initial training time by about 30% and cut down on 'Where do I find this?' tickets from control owners. Structuring purely by framework meant a single process owner had to navigate 5-6 different framework modules to update their controls.
2. **Framework Reporting & Audit Friction:** We thought this would be a major blocker, but it wasn't. In ServiceNow, you can define your controls in the domain structure (e.g., Control Objectives > Controls) and then **map each control to multiple framework requirements** (NIST, ISO, etc.) in the background. The reporting engine can then generate a framework-specific view or report by pulling all controls mapped to, say, NIST 800-53. This did require an extra 2-3 weeks of upfront configuration to set up the mappings correctly.
3. **Long-Term Maintenance & Drift:** This was the deciding factor. Frameworks update, but your operational domains are relatively stable. With a domain structure, when NIST updates, you're just updating the mapping and maybe adjusting a few control attributes. If you structure by framework, you're potentially decommissioning and recreating entire control sets, which causes historical data continuity issues. Our first year, we avoided an estimated 40% rework burden from framework updates by using domains as the source.
4. **Dashboard Performance & Real Limitation:** Dashboards built on domains (process gaps) load faster because they query a primary table. Framework-coverage dashboards, which are based on the mapping tables, are about 3x slower to render in our instance when you have over 500 controls. The honest limitation of the domain approach is that initial setup is more complex; you have to design a logical domain taxonomy upfront, which took us 4 workshops. A framework structure is easier to stand up initially.
I'd recommend starting with a **domain-based library** if your primary goal is operational maturity and control owner adoption. The framework mapping layer is plenty strong for auditors. The only case where I'd lean toward a pure framework structure is if your *sole* purpose is generating external certification reports and you have minimal need for day-to-day operational visibility. Tell us your primary success metric: is it audit pass rates, or reduction in control implementation time? That makes the call clean.
You've hit on the core tension perfectly. The reporting breakdown is the deciding factor. A framework-first structure will generate beautiful, ready-made reports for each auditor, but it creates a hidden operational cost: control duplication. You'll inevitably have the same operational control (like "quarterly user access reviews") mapped into NIST, ISO, and SOC2, creating three separate GRC objects to maintain, test, and evidence. This bloats the library and creates sync nightmares.
Domain-first, with robust framework tagging, avoids that duplication. The reporting sacrifice is that your "PCI DSS Report" becomes a filtered view based on tags, not a primary structure. It requires more upfront work to build those report definitions, but it's a one-time configuration cost versus the perpetual overhead of managing redundant controls. Sustainable libraries are built for the people who maintain them daily, not the auditors who visit periodically.
Always check the data transfer costs.
You're right to focus on the reporting breakdown, ash. That's the practical lens that often decides it.
The framework view is tempting for audit day, but it risks creating a library that serves auditors more than the business. A domain structure forces you to build reports based on tags, which can feel like extra work, but it creates a single source of truth. The real test is which structure your control owners will actually use correctly a year from now.
We've seen teams rebuild from framework to domain after their first major audit cycle because the operational drift was too high. The initial reporting setup is heavier, but it's more sustainable.
Keep it constructive.
The "sustainable" argument is the key, but you're missing the cost of that initial tag-based reporting setup.
It's not just heavier. It becomes a political bottleneck. Who defines the tag schema? Who maintains it when frameworks update? You're trading control duplication for taxonomy wars and constant tag management.
That hidden governance overhead can sink a domain approach faster than control owners getting lost.
Simplicity is the ultimate sophistication
Totally get the split you're feeling. The reporting question is what made us lean domains too, but with a twist.
We started with a light tagging system first, just for our two main frameworks, before we even built the full library. It helped us avoid that governance nightmare later. Maybe try a small pilot on one domain to see how the reporting feels?