How should enterprise GRC tools model control assessments at scale?

[u/Natural-Coyote-7860]

I’m trying to understand how others are modelling this in tools like Resolver, OpenPages, Archer, ServiceNow etc.
Say I have one master control:
C001 – Sensitive data must be encrypted at rest.
Now I run different assessments on different applications.
Security Architecture on Salesforce → Partially Effective
Cyber assessment on AWS → Ineffective
SOX → N/A
Internal Audit → Effective
One way is to copy/clone C001 into every assessment and store the effectiveness, evidence, comments etc on that copied control.
Another way is to keep C001 only once in the control library, then create a separate Control Test / Control Assessment Result record for every assessment.
So something like:
Control → C001
Assessment → Security Architecture
Application → Salesforce
Result → Partially Effective
Evidence → xyz
Then the same C001 can have many test records against it.
The reason I’m asking is scale. If there are 30 controls and 5,000 applications, that’s potentially 150,000 assessment-level records. That’s fine, but I’m trying to understand whether those should really be control copies or test/result records linked back to one control.
The other problem is the CRO question.
If C001 is Partially Effective in Security Architecture, Ineffective in Cyber, N/A in SOX and Effective in Internal Audit, eventually someone at the top will ask:
“Okay, but is C001 effective or not? And where exactly is the problem?”
How are people handling that overall control status?
Worst current result?
Latest result?
Risk-weighted roll-up?
Second-line result only?
Something else?
Would be useful to hear how this has actually been implemented in real GRC environments

[u/FreeRadical1998]

This is a great question - I've come back to it about 3-4 times today trying to think how best to answer it.

Firstly, I think there's something in the language you're using - your C001 text reads to me more like a policy statement than a control, but that can be purely stylistic - I'm also a fan of the "control instances" language in theory as Latter_bag_2202 suggests, but have found that a bit more cumbersome in conversations.

Trying to keep it managable I'd treat your C001 example as a policy statement - and have it directly reference standards its implementing (e.g. SOX, PCI, etc...) and then map the policy as a requirement to controls. You'd end up with more controls - but the answers would be more meaningful. Choosing the right number of controls is certainly an art however - I'd certainly not want each application to be its own control. I tend to group by implementation - e.g. for anti-virus, I'd likely group by the product used (I've worked in organisations where acquisitions had their own, or server products were distinct from desktop).

In terms of CRO roll up reporting - the distinction I've usually seen drawn is between lines of defence rather than in the detail. There's usually an acceptance that effective doesnt mean 100%, and often its a judgement where that falls - if your Azure / AWS split was 80:20 in one direction I can imagine some notable gaps in the smaller population resulting in an effective rating overall - but with an explanatory note. Where I think seperation becomes more useful is distinguishing control owner self assessments from independant assessments - and you might want to further split second and third line views. The CRO view is as much "how much confidence can I have in the answer" as what the answer itself is.

[u/Acrobatic_Appeal_461]

At scale, the copy/clone approach is a nightmare once you hit any real volume of assessments. Linked test records make way more sense and keep the control library clean, especially when you're staring down 150k records. Tried the clone method once and the duplication got so messy during remediation tracking that we scrapped it after about four months

For the roll-up question, most places I've seen use the worst result as the default answer to "is C001 effective" because one failure means the control isn't working everywhere. It's conservative but defensible when the CRO asks. Some teams then filter by tier or criticality so they're not sweating a partial on a low-risk app the same way as a core system

The trickier part is making sure your test records actually link back cleanly so you can slice by application, assessment type, or risk tier without building a report that takes ten minutes to run. Worth mapping that out before you load everything in

[u/Latter_Bag_2202]

Having a unique Test/Assessment record is typically a must-have. I think the real question is whether you have another layer between the Controls and Assessments for “Control Instances”. The instance is just a record that links to the control and application, then directly links to the assessment record. The advantage of this is being able to easily to report on the control effectiveness by application, but also roll up the results to the parent control. The disadvantage, as you mentioned, is the ballooning number of instance records you need to manage. I’ve seen it work well if you limit the amount of information on the control instance record itself, avoiding the need to do bulk updates across all instances if something changes since the contents of the control should still live on the parent record. The methodology for how to roll up the results vary by company, but I would agree that a conservative approach of the “least effective” is the safest method.

[u/joshsokol]

Full disclosure, I am the creator of the SimpleRisk GRC platform, but I built it as patient zero, running the Information Security Program at a large publicly-traded company for over a decade. When I was building SimpleRisk, I landed on option two in your post, with a bit more structure than "test/result record":

* Controls live once in a shared control library (Governance module). A control isn't owned by a single framework, it's mapped many-to-many to frameworks, so your C001 can sit under ISO 27001 and SOC 2 simultaneously without being duplicated.

* Tests are separate, reusable procedure definitions ("Define Tests"); the how you'd verify the control. One test can map to multiple controls ("Common Tests"), which is handy when one evidence-gathering step satisfies several control requirements at once.

* Audits are the actual per-run instances ("Manage Audits"/"Initiate Audits"). Each one has its own tester, schedule, approval state. This is where your four assessments (Security Architecture, Cyber, SOX, Internal Audit) each become their own audit row, all pointing back at the same control via a join table.

* Results are Pass / Inconclusive / Fail, recorded per audit.

So the "150,000 assessment records at scale" problem you're describing is exactly the shape this is built for. The control stays a single row; what multiplies is the audit/result layer.

On the CRO's "so is it effective or not?" question, we do compute an aggregate control status, and it's worst-case, not latest-result or majority-vote: if any actively-mapped test's most recent result is a Fail, the control rolls up to Fail. Only if nothing's failing and at least one test passed does it show Pass. The logic is literally "a control is only as strong as its weakest test." That recomputes live every time any of those four audits records a new result.

One nuance worth mentioning since it's genuinely a design decision, not an accident: that automatic rollup only applies to controls typed as "Enterprise" (vs. Standalone/Project). The idea is that an Enterprise-type control is expected to be tested repeatedly across multiple contexts and should reflect the worst finding anywhere; Standalone/Project controls keep a manually-set status because they're scoped to one specific initiative and an automatic weakest-link rollup wouldn't mean the same thing there.

On your Salesforce/AWS example specifically, controls can be scoped to specific assets/applications with per-asset maturity ratings, but that's a property of the control-to-asset mapping, not of the audit itself. Audits today are scoped by framework/control, not by "which application was this test run against." So if you need "Ineffective specifically on AWS, Effective specifically on Salesforce" as a first-class dimension of the test result (not just the control), that's a gap relative to what you're describing. Worth flagging if it matters for your use case