Governance, risk and compliance software promises a single place to hold the risk register, the controls, the policies, the incidents and the audit findings — replacing the spreadsheets and shared drives most organisations actually run on. The promise is real. The reason so many implementations disappoint is that organisations buy the platform before deciding how they want to work, and end up with the same disorder in a more expensive container.
What a GRC platform actually holds
The core is a set of linked registers:
- Risks — with owners, inherent and residual scoring, appetite thresholds and review dates;
- Controls — mapped to the risks they mitigate, with owners, frequency, and evidence of operation;
- Obligations — the regulations, standards and contractual requirements the organisation is subject to, mapped to the controls that satisfy them;
- Issues, incidents and breaches, with root cause, remediation actions and dates;
- Assurance activity — internal audit findings, external audit points, regulatory correspondence and the actions arising;
- Policies, with version control, approval workflow and attestation tracking.
The value is in the mapping rather than the storage. Once obligations link to controls and controls link to risks, three questions become answerable that are almost impossible with spreadsheets: which risks have no effective control, which controls exist for no identified reason, and what would break if a particular control failed.
Where implementations go wrong
The pattern is consistent enough to predict.
Migrating the mess. An organisation with 400 risks in a spreadsheet, most of them duplicates written by different departments, imports 400 risks into the platform. The taxonomy problem was the real problem, and software does not solve it.
Scoring theatre. Elaborate scoring models that generate precise numbers from arbitrary judgements. A five-by-five matrix applied inconsistently by thirty people produces a heat map that looks authoritative and means nothing. Fewer risks, described more precisely, beat a large register scored to two decimal places.
No owner. Risks and controls assigned to departments rather than named individuals, so nobody updates them and the platform becomes stale within two quarters.
Compliance as an end. Attestation campaigns that generate completion statistics rather than behaviour change, and control testing that records that a control was performed without asking whether it worked — the distinction our guide to control testing sets out.
Buying for the regulator. A platform bought because a supervisor asked how risks are managed, configured to produce a report, and never used to make a decision.
What to sort out first
Three things should exist before procurement, and they are the actual work:
A risk taxonomy. An agreed, hierarchical list of risk categories the organisation uses consistently, so that the same risk is not recorded four times in four languages. This is what makes aggregation and reporting possible.
A control library. The controls that matter, described once, owned by named people, with defined frequency and defined evidence. Mapping obligations to a clean control library is what removes duplicated testing — the same control satisfying an ISO standard, a regulatory requirement and an internal policy, tested once rather than three times.
An operating rhythm. Who reviews what, how often, and where it goes. Monthly at management level, quarterly to a committee, annually for the full refresh. Software supports a rhythm; it does not create one.
Choosing a platform proportionately
Match the tool to the organisation. A mid-sized business with a handful of obligations and one compliance manager is usually better served by a well-structured set of documents with disciplined review than by an enterprise platform it will use at 10% of capacity. A regulated firm with multiple frameworks, hundreds of controls and recurring assurance activity has a genuine case for one.
When evaluating, weight three things heavily: how easy it is for a non-specialist control owner to complete their task, because adoption fails at that point; whether the reporting can be configured to what your board and regulator actually ask for; and how the data comes out, since exporting a full, structured extract is what protects you if you change vendors.
Integration matters less than vendors suggest. Pulling control evidence automatically from finance and IT systems is valuable where it exists, but most organisations get the majority of the benefit from having one accurate register that people use.
Acumon works on the framework underneath the software — risk taxonomies, control libraries and assurance mapping — through risk management, corporate governance and outsourced internal audit work, with the governance model set out in our guide to the three lines. Fix the taxonomy first; the platform is the easy part.