Skip to content
Notifications
Clear all

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

49 Posts
48 Users
0 Reactions
9 Views
(@consultant_carl_42)
Estimable Member
Joined: 2 months ago
Posts: 154
 

That dashboard trick with saved filters is a decent bandage, but it assumes your control tags are perfect and never need manual review. I've watched teams implement exactly that, only to find their "PCI Coverage" dashboard missing half the relevant controls because someone tagged the domain but forgot the framework attribute during a quarterly review.

The reconciliation lag doesn't vanish, it just moves upstream. Now your team isn't reconciling control entries, they're reconciling metadata quality across hundreds of tags. That's arguably worse because it's invisible until you run a report and the numbers don't add up.

You still need a human process to validate that your filtered views actually match the framework's intent. A saved search for `framework=pci` is only as good as the discipline behind the tagging.


Test the migration.


   
ReplyQuote
(@frankd)
Trusted Member
Joined: 1 week ago
Posts: 64
 

You're right about the discipline problem, but that's exactly why you anchor the process to the control owner's quarterly review. We mandate that review as a workflow step where they *must* confirm the framework tags on all their owned controls before submission. The metadata reconciliation isn't invisible, it's a scheduled, auditable task.

If they can forget a tag in a domain structure, they'll definitely forget to update a duplicate control in three separate framework silos. The tag validation is a single, consolidated checklist item. The framework duplication is a fragmented, error-prone chore.


buyer beware, but buy smart


   
ReplyQuote
(@finops_auditor_ray)
Estimable Member
Joined: 4 months ago
Posts: 160
 

The "clean for audits" angle isn't just a trap, it's expensive. You'll pay for that neatness in manual reconciliation labor every quarter.

Your reporting question is the litmus test. If a domain structure breaks your reporting, then your reporting tool is bad. Fix the tool, don't cripple the process. Good reporting is just saved filters over tagged data.

We tried framework-first. The dashboards looked perfect right up until the first control change, then everything fell apart because updating it was a three-step chore. Go with domain. Your control owners already told you the answer.


show me the bill


   
ReplyQuote
(@devops_barbarian_v3)
Reputable Member
Joined: 3 months ago
Posts: 163
 

Hard CI validation on the mandatory fields is the real win. But don't just check for presence, check the tag *values* against a known-good dictionary in the pipeline. Stops the "framework: pci-dss" vs "framework: pci" drift before it merges.

That cross-framework view is gold. An auditor seeing the same control mapped to NIST, PCI, and SOC2 in one place? It shuts down the checkbox-compliance argument immediately. Makes them ask better questions.



   
ReplyQuote
Page 4 / 4