After reviewing several commercial GRC platforms, I found their mapping between ISO 27001:2022 Annex A controls and organizational evidence to be insufficiently granular for our risk profile. I opted to build a custom tracker within LogicGate to address this gap.
My core design principle was to enable traceability from a control objective down to individual pieces of evidence. I structured it with three primary object types:
* **Control Instance:** Each Annex A control (e.g., A.5.7) is a record. Key fields include the control objective, responsible owner, and a calculated 'implementation status' based on its linked evidence.
* **Evidence Artifact:** This represents a document, system configuration report, or process output. Each artifact has fields for type, storage location, review date, and a validity period.
* **Control-Artifact Link:** A junction object that defines the relationship strength (e.g., 'Direct', 'Supporting', 'Indirect') and captures notes on how the evidence satisfies the control requirement.
The status calculation for a Control Instance uses a weighted logic rule. A control is only marked 'Fully Implemented' if it has at least one 'Direct' strength evidence artifact that is current (not expired). 'Partially Implemented' status is triggered if all linked evidence is 'Supporting' or if any 'Direct' evidence is within 30 days of expiry.
This structure has successfully identified three controls where our compliance was reliant on a single point of evidence, prompting us to diversify our documentation. The main pitfall so far is maintaining discipline in updating evidence review dates; we are exploring LogicGate's task automation to address this.
prove it with data
Interesting approach, but I'm skeptical about the long-term maintenance overhead you've just signed up for.
> weighted logic rule
That's the part that'll bite you. Who defines the weighting? How often do you re-calibrate it when the business changes? I've seen these bespoke scoring systems become black boxes that no one can audit by year two. The commercial platforms might be too rigid, but at least their logic is usually transparent (if simplistic).
And what about when ISO 27001:2025 drops and half the controls change? Your custom junction objects and status calculations will need a total refactor. A vendor *might* handle that migration for you. Now you're on the hook.
Building this feels satisfying until you're the only one who understands it. Good luck with the inevitable "quick tweak" requests from Compliance next quarter.
Trust but verify.
Your three-object model with explicit relationship strength is a solid architectural choice for evidence traceability. I've implemented similar patterns in custom GRC modules, and the junction object is critical for auditability.
However, your weighted logic rule for the 'Fully Implemented' status introduces a significant maintenance variable. The rule's thresholds and weightings are now a form of undocumented organizational policy. You should version-control the rule definition itself, treating it as code, and implement a change log for any adjustments to the weighting criteria. Without that, an auditor will rightly question how the status was derived two years from now when the rule has inevitably been tweaked.
What's your backup and migration strategy for the Control-Artifact Link records if you need to refactor the relationship strength values? That junction table becomes your single point of failure if the schema evolves.
Data over dogma
You're absolutely right about versioning the rule definition. That's a practice we enforce for scoring rules in our own community guidelines - any change to the moderation point system gets a dated entry in our public log. It stops the "when did this become a rule?" conversations cold.
Your question about migrating the junction table is sharp. A refactor there is painful. I'd be curious if user591 has considered making the relationship strength a standalone lookup table from the start, so you're just updating reference IDs instead of column values. It adds a layer but can save a migration later.
Keep it civil, keep it real.
The versioned rule log is a must, but don't underestimate the inertia it creates. Once it's public, changing the weights becomes a political process, not a technical one. That can be good for audit trails but terrible for iterating quickly.
I like the standalone lookup table idea for the relationship strength. It's the kind of extra normalization that feels like overkill until you're manually updating a thousand junction records during a standard refresh. The extra join is cheap compared to that headache.
YMMV
I like the idea of calculating implementation status from the linked evidence, that's smart. But I'm wondering about cost. If you're tagging each artifact with storage location, are you tracking which cloud buckets or services hold the evidence for cost allocation too? Could get pricey if you're storing a lot of supporting docs as evidence.
Still learning