The Hidden Complexity: Building a GRC Means Reinventing a Lot of the Wheel

One of the biggest weaknesses in comparing an Excel + Power BI approach with a dedicated GRC SaaS solution is the assumption that the main task is simply to create a risk register and a dashboard.

In reality, once an organisation wants a structured and scalable GRC capability, it has to design much more than a spreadsheet.

It has to design a governance system.

That means answering a long list of questions before the first meaningful dashboard can even be trusted.

Which Taxonomies Should We Use?

A risk register needs categories.

But which ones?

The organisation may need to define or select:

• risk categories;
• threat categories;
• threat actors;
• threat vectors;
• impact types;
• security domains;
• asset categories;
• business units;
• data classifications;
• control families;
• remediation types;
• third-party categories;
• system criticality levels;
• risk responses;
• maturity levels.

Each taxonomy must be researched, selected, documented and maintained.

Should the organisation use its own terminology?

NIST?

ISO?

MITRE ATT&CK?

STRIDE?

Industry-specific classifications?

A combination of several?

This is not technically difficult because Excel cannot store a drop-down list.

It is difficult because someone has to decide what the right taxonomy is, how it should be structured and how different taxonomies relate to one another.

Every organisation that builds its own GRC environment ends up solving many of the same design questions again.

Then Come the Workflows

Once the data model exists, the organisation has to define what happens to the data.

For example, what is the lifecycle of a cyber risk?

Does it move through:

Draft → Assessment → Review → Approval → Treatment → Monitoring → Closure?

Who is allowed to move it from one state to another? What happens when additional information is required? Can a risk owner close a risk directly? Does closure require validation? Can a closed risk be reopened? What happens when a remediation deadline is missed? Who receives the notification? Who can accept a risk? Who can request changes?

At this stage, the organisation is no longer simply configuring Excel.

It is designing a workflow engine.

If Excel, Power Automate, email, Teams or a ticketing platform are used to implement those workflows, the process still has to be designed, tested, documented and maintained internally.

Roles and Permissions Must Also Be Invented

A serious GRC environment cannot assume that every user has the same privileges.

The organisation may need to distinguish between:

• administrators;
• CISOs;
• risk managers;
• risk owners;
• control owners;
• system owners;
• third-party owners;
• auditors;
• reviewers;
• contributors;
• read-only users;
• external stakeholders.

Then another set of questions appears.

Who can create a risk? Who can edit it? Who can see confidential risks? Who can approve an assessment? Who can modify a remediation deadline? Who can access evidence? Who can update a policy? Who can approve a framework assessment? Who should only see their own assigned items?

With spreadsheets and generic collaboration tools, these rules have to be translated into file permissions, SharePoint permissions, report permissions, workflow logic or separate files.

The more granular the governance model becomes, the more difficult this architecture becomes to maintain.

Data Relationships Are Another Layer of Complexity

Cyber risk information is highly relational.

A risk may relate to:

• one or more systems;
• one or more third parties;
• several controls;
• multiple policies;
• a framework requirement;
• a remediation plan;
• evidence;
• an audit finding;
• one or more owners.

A system may itself relate to:

• business units;
• countries;
• data classifications;
• third parties;
• environments;
• criticality;
• applications;
• risks.

This quickly stops looking like a spreadsheet.

It starts looking like a relational database.

With Excel + Power BI, the organisation has to define:

• unique identifiers;
• lookup tables;
• relationship tables;
• naming conventions;
• referential integrity rules;
• duplicate management;
• data validation;
• archival rules;
• historical records.

Power BI can model these relationships very well.

But again, someone first has to design them correctly.

Governance Rules Must Be Defined Too

A mature GRC environment also requires rules.

For example:

• How often must a risk be reviewed?
• When is a review overdue?
• What constitutes a critical risk?
• Which remediation actions require validation?
• What evidence is acceptable?
• How long should evidence be retained?
• When must a third party be reassessed?
• Which systems require a risk assessment?
• How are exceptions handled?
• What happens when a control is not applicable?
• Who can accept residual risk?

These rules are often invisible in the first version of an Excel risk register.

They emerge gradually as the organisation matures.

Each new requirement then results in another formula, worksheet, Power Automate flow, process document, permission rule or manual workaround.

The Organisation Is Effectively Building a Product

This is the point that is often missed.

A well-designed Excel + Power BI GRC environment can absolutely work.

But beyond a certain level of maturity, the organisation is effectively developing its own internal software product.

That product requires:

• a data architecture;
• taxonomies;
• workflows;
• user roles;
• permissions;
• validation rules;
• dashboards;
• reporting logic;
• integrations;
• documentation;
• testing;
• change management;
• support;
• governance.

The tools may be Excel, Power BI, SharePoint, Power Automate and Teams.

But the architecture surrounding them still has to be created.

This is why the phrase "we can do this in Excel" can be technically correct while operationally incomplete.

The spreadsheet may be easy to create.

The governance model around it is not.

Excel is not the problem. The problem is that once you want a mature GRC capability, you are no longer building a spreadsheet — you are building a GRC product.

Reinventing the Wheel Has a Cost

This is also where standardisation becomes important.

Every organisation building its own GRC environment has to make decisions that many other security teams have already made:

• how risks are structured;
• how threats are classified;
• how remediation is tracked;
• how assessments move through validation;
• how controls relate to frameworks;
• how systems and third parties connect to risks;
• how ownership works;
• how evidence is attached;
• how reviews are scheduled;
• how activity is recorded.

There is nothing wrong with designing these things internally.

Some organisations have unique requirements and need that flexibility.

But organisations should recognise what they are doing.

They are not simply avoiding the purchase of a GRC platform.

They are choosing to design and maintain their own GRC platform using general-purpose tools.

The Hidden Effort Is in the Design

The challenge is not only maintenance.

It is also the amount of design required before the environment becomes reliable.

That includes activities such as:

• selecting and creating taxonomies;
• designing the GRC data model;
• defining workflows;
• creating roles and permissions;
• defining validation rules;
• establishing naming conventions;
• creating status models;
• defining review cycles;
• documenting governance processes;
• designing reporting structures.

These tasks are often performed by senior cybersecurity, risk or compliance professionals.

And that matters.

The more time they spend designing and maintaining the supporting architecture, the less time they spend on the actual purpose of GRC: understanding and reducing risk.

The SaaS Difference

A dedicated GRC SaaS platform does not remove the need to make governance decisions.

The organisation still needs to determine its risk appetite, owners, control objectives and internal processes.

But it does not need to start from a blank worksheet.

The underlying structures already exist.

For example, the platform can already provide structured concepts for:

• risks;
• remediation;
• systems;
• third parties;
• policies;
• controls;
• frameworks;
• evidence;
• audits;
• ownership;
• workflows;
• review schedules;
• activity history.

The organisation configures and adapts those structures rather than designing the entire technical model from scratch.

The comparison is therefore not:

Flexible Excel versus rigid SaaS.

It is closer to:

Build the operating model yourself versus start from an existing GRC operating model and configure it to your needs.

The Real Question Becomes Build or Configure?

This leads to a better question for the CISO.

Not:

Can we build this in Excel and Power BI?

The answer is almost always yes.

The more useful question is:

Should our cybersecurity team spend its time designing taxonomies, workflows, permissions, relationships and reporting logic that already exist in dedicated GRC platforms?

For some organisations, the answer may still be yes.

For highly customised environments, unique processes or very small scopes, building internally can be justified.

But for many security teams, repeatedly solving the same structural problems provides little competitive advantage.

The question is not "Can we build it?" but "Why are we rebuilding something that already exists?"

The value of a cybersecurity team is rarely in designing another risk-status workflow or another control taxonomy.

Its value is in understanding, reducing and communicating cyber risk.

And that leads to perhaps the most important question of all:

Are we managing cyber risk — or are we spending an increasing amount of our time managing the tools we built to manage cyber risk?