GRC tool, spreadsheet swamp or GRC-GPT? How to choose the right foundation for your control framework

This is the final part of our series on sustainable compliance. In Part 1 we laid the foundation: an integrated risk and control framework with many-to-many links. In the parts that followed, we kept that framework alive as an ecosystem, fed by the PDCA cycle. Now the final question: what do you grow that ecosystem on? In other words: which foundation do you choose to operationalise your framework, and how do you avoid getting bogged down in spreadsheets, complexity or vendor lock-in?

The soil your ecosystem grows in

A healthy ecosystem needs fertile soil. For your compliance framework, that soil is the tooling: the place where owners, requirements, risks, controls and evidence come together and stay linked to one another. Choose the wrong soil and even the best-designed framework withers.

The market now offers dozens of GRC solutions, and its revenue has been growing at double-digit rates for years. [1] But more choice is not the same as an easier choice. The question is not “which tool is best?” but “which foundation suits our ecosystem?”

Diagnosis first, then tooling

The biggest mistake is to start with the tool. Organisations looking for a GRC solution almost always run into internal challenges first.

  • Governance: functions or teams such as privacy, security, legal, finance and quality each have their own owner, their own tool or way of working, and their own budget. There is rarely a single budget holder, and rarely a single shared vision, strategy and risk methodology across the three lines of defence.
  • Policy and processes: each domain applies its own scope, level and often even risk process, from enterprise risk and financial risk to operational risks (such as customer requirements) and project risks. Alongside these sit separate registers. Linking them together (many-to-many) is enormously valuable, but also complex. The same applies at the level of controls.
  • Culture: one department works with manual checks in Excel, another is fully automated. Different ways of recording, different risk appetites, different testing standards, and the question of whether everyone can work with the tooling at all (adoption and buy-in).
  • Monitoring and reporting: is there one PDCA cycle, one integrated assurance framework and one committee in which the second and third lines work together? Or does management receive five separate reports that cannot be compared with one another?

Choosing a tool before you have mapped these challenges and aligned on a vision is like planting a tree in a spot with barely any soil: it will hardly grow to its potential. So map your ecosystem first.

Three archetypes: the swamp, the greenhouse and the robot gardener

Broadly speaking, we see three routes, each with its own soil conditions:

  1. The spreadsheet swamp. Cheap, accessible and familiar. But spreadsheets have no real relationships: links are manual, versions drift apart, and at the first serious audit you sink. Fine to start with, but fatal as soon as you want to scale up or need to demonstrate compliance.
  2. The specialist GRC tool (the greenhouse). Powerful and controlled, with built-in workflows, dashboards and standards libraries. But often expensive per licence, complex to manage, and, more importantly, such tools pull people towards compliance rather than bringing compliance to the people. As a result, adoption often stays limited to a handful of specialists.
  3. The “GRC-GPT” (the robot gardener). The spoiler from Part 3: AI that helps maintain your ecosystem. Think of agents that map new legislation to existing controls, summarise evidence or flag deviations. Promising, but the risk management itself remains human work (as outlined in my introductory blog). AI speeds up a well-designed framework; it does not repair a shaky foundation.

The considerations that really matter

Work through these questions before you choose:

  • Scope and responsibility? What scope will you apply this to, and who is responsible for the tool, the content and its management? Try to place as much as possible within a single team, and assign roles and tasks clearly (RASCI).
  • For whom? Should the entire organisation work with it, many risk and control owners, so it needs to be accessible and widely adopted, or will it be a specialist tool that is allowed to be more complex?
  • What do you already use? Do you already work in Microsoft 365 or Atlassian? Then build on where people already work; that shrinks your biggest adoption problem in one go. Check which APIs and integrations are needed and available.
  • Which related processes will you link? Contract management, supplier management, privacy assessment tools: how do you integrate them so that you do not record things twice and the ecosystem remains a single whole?
  • Where does your data live and who can access it? Risk and audit information is confidential. Determine who has access, and choose deliberately between cloud and on-premise. With cloud, where the data resides also matters (data sovereignty and sensitivity).
  • Do it yourself or outsource? Both implementation and maintenance. Running it in-house gives control and builds knowledge; outsourcing relieves the burden but creates dependency.
  • Standard or bespoke? A standard solution lets you start within days. Bespoke fits your organisation more closely, but costs more to maintain and leads more quickly to vendor lock-in.
  • AI now or later? Do you invest in AI agents straight away to future-proof things, or do you get the content right first and build in AI later?
  • Reporting: do you run dashboards within the solution itself, or combine it with tooling such as Power BI for your management information?

There is no universal answer. A small healthcare provider with a single compliance officer will naturally make different choices than a listed multinational with a mature three lines of defence.

The common thread: let the tool serve the ecosystem

What every sound choice has in common: the tool follows the framework, not the other way around. Start with your vision, requirements, risks and controls (Part 1), set up your PDCA cycle (Part 2 and Part 3), and only then choose the soil that best supports it. That way you avoid forcing your ecosystem into the structure of a tool, and having to start all over again in two years’ time.

For organisations that already work in Atlassian and want a working foundation quickly, we developed the ICTRecht GRC Blueprint, for example: not yet another GRC tool, but structure and templates in the environment where people already work.

In closing: from isolated projects to a living ecosystem

With that, we close the series. Sustainable compliance is not an end point but a rhythm: fed by the right people, the right processes and the right foundation. In summary, my tips:

  • Work from a single vision, strategy and clear governance with well-defined responsibilities.
  • Build one integrated framework instead of a project per law, with many-to-many links between requirements, risks and controls.
  • Work risk-based, with a defined risk appetite as your compass and a consistent risk methodology.
  • Keep the framework alive with the PDCA cycle and a rolling roadmap that you review every quarter.
  • Assign roles clearly via the three lines model, and make it concrete per control owner: what, why, how and when.
  • Align the second and third lines in one integrated assurance framework, so that you do not test the same things twice.
  • Test design, existence and operating effectiveness, not focused on green checkmarks.
  • Give every deficiency an owner, deadline and priority, even when you consciously accept the risk.
  • Make sure evidence is created during the work, not just before the audit.
  • Stay pragmatic, but not non-committal. It should reassure stakeholders, give them insight and win their confidence.
  • Only choose your tooling after the diagnosis, and let the tool serve the framework, not the other way around.

Curious which foundation suits your ecosystem? We are happy to think along with you, with no obligation, and to help translate these considerations into a solution that fits your organisation and ambitions.

Contact us


[1] Grand View Research, “Enterprise Governance, Risk & Compliance (eGRC) Market Size, Share & Trends Analysis Report”. See: grandviewresearch.com.

Back to overview