GRC framework: how to structure one in a regulated firm

The board has asked to see your GRC framework. What you have is a folder of policies, a risk register in a spreadsheet and an ISO 27001 certificate, and none of them refer to each other. A regulator, auditor or enterprise client reading all three sees three documents, not a framework.

A GRC framework for a firm of 25 to 250 people does not start with a platform. It starts with five layers, named owners and one control library that every obligation maps to. This guide gives you that structure, six steps to build it and a worked example you can walk a supervisor through.

What is a GRC framework?

A GRC framework is the structure that connects who decides (governance), what could go wrong (risk) and what the firm must meet (compliance) through one set of owners, one control library and one reporting line. Standards such as ISO 27001 plug into it rather than replace it, and FCA SYSC 4.1.1R describes the same elements.

A framework is an operating structure, not a document. It answers three questions in one place: who is accountable for a risk, which obligations that risk touches, and what evidence shows the control is working.

The practical test is whether one change travels through all of it. When a client adds a security clause, the obligations register changes, the affected controls change, and the next board report shows the effect. If that means editing five documents, you have five frameworks.

What are the five layers of a GRC framework?

The five layers are governance, risk, compliance, a single control library, and assurance and reporting. Each layer has a named owner and a defined artefact: the policy hierarchy, risk register, obligations register, control library and board report. Evidence and monitoring run underneath all five.

Read the table top to bottom as an order of dependency. Governance sets direction, risk decides what matters, compliance lists what the firm owes, and the control library is where one control answers many obligations. Assurance proves it to the board.

Evidence sits underneath. Each control produces evidence on a schedule, and that evidence feeds the board report instead of being assembled the week before an audit.

What does a GRC framework diagram look like?

A GRC framework diagram shows external obligations (regulations, standards, client requirements) flowing into one obligations register, then through a shared control library to owners, evidence and board reporting. Draw it as five horizontal layers with obligations entering from the top and evidence rising from below.

Four moves produce a diagram that holds up in front of a supervisor:

1. Top band. One box per external obligation: FCA rules, UK GDPR, ISO 27001, SOC 2, key client contracts, and DORA where it applies to you.
2. Middle bands. The five layers in order, each labelled with its owner and artefact from the table above.
3. Mapping lines. Many-to-many lines between the obligations register and the control library. This is the picture that shows one control satisfying several obligations.
4. Bottom and side. Evidence sources and monitoring feeding upward into assurance, and the board report leaving to the regulator, auditor and client.

Keep it to one page. A diagram a COO can walk a supervisor through in two minutes does more than a forty-page framework document nobody has read.

How is a GRC framework different from a standard or a regulation?

A regulation or standard states what the firm must meet; a GRC framework is how the firm organises itself to meet all of them once. ISO 27001, SOC 2, Cyber Essentials, DORA and UK GDPR are inputs to the obligations register, not the framework itself.

ISO 27001 is a standard for an information security management system, and clause 4.4 is where it asks you to run one. In this architecture, that system is the slice of the framework that covers information security. A SOC 2 report is an attestation to clients about controls, and it draws on the same control library.

Treat each input as a set of rows in the obligations register: source, clause or article, the requirement in plain words, and the controls that meet it. Cyber Essentials and UK GDPR enter the same way. A firm using AI adds ISO 42001 and, where it is in scope, the EU AI Act.

Choosing which standards to pursue is a separate decision from structuring the framework. This guide assumes you already know the obligations you carry.

How does FCA SYSC 4.1.1R anchor a GRC framework in the UK?

SYSC 4.1.1R requires robust governance arrangements: clear lines of responsibility, effective processes to identify, manage, monitor and report risks, and internal control mechanisms. These map directly onto the governance, risk and control layers. DORA Article 6 applies only to firms in its scope, and the Cyber Governance Code is voluntary guidance for boards.

The rule's wording lines up with the layers one for one:

• "A clear organisational structure with well defined, transparent and consistent lines of responsibility" is the governance layer: who is accountable, written down.
• "Effective processes to identify, manage, monitor and report the risks" is the risk layer for identification and management, and the assurance layer for monitoring and reporting.
• Internal control mechanisms are the control library, with each control owned and evidenced.

Article 6(1) of DORA requires financial entities to have a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system. That describes the structure here: ICT risk sits inside the firm's risk method, not beside it. DORA is EU regulation, so a UK-only firm is outside it, but one with an EU-regulated entity or EU operations should check its scope.

The Cyber Governance Code of Practice is government guidance setting out the governance actions directors are responsible for in governing cyber risk. It is voluntary. Use it to shape director-level reporting and the cyber element of risk appetite.

SYSC 4.1.1R applies directly to common platform firms (broadly, banks and MiFID investment firms). SYSC 1 Annex 1 sets out how it applies to other firm types, so check whether it binds yours as a rule or as guidance. The FCA and PRA rulebooks go well beyond SYSC 4; this section anchors the structure and nothing more.

How do you structure a GRC framework in six steps?

Structure it in six steps: scope your obligations, name owners, set the risk method, build one control library, map each obligation to controls, and set the reporting cadence. A lean firm of 25 to 250 people can do this with a shared register and clear ownership before buying any tooling.

1. Scope your obligations. List every regulation, standard, client contract clause and certification the firm carries, one row each, with source and clause. Start with what the FCA, your clients and your insurer already ask for.
2. Name owners. Give each layer and each obligation a named role, not a team: a senior owner for governance, a risk owner, a compliance lead, and control owners in IT, HR and operations. In a small firm one person often holds two roles; write that down.
3. Set the risk method. Agree one scale for likelihood and impact, a written risk appetite the board approves, and the register fields: risk, owner, linked controls, residual rating, review date. Which published method you adopt matters less than using one everywhere.
4. Build one control library. Write each control once, in plain words, with an ID, an owner, a frequency and the evidence it produces. Merge duplicates so that "review access quarterly" exists in one place, not in three standards' worth of binders.
5. Map each obligation to controls. Every obligation links to at least one control, and every control links to at least one obligation or risk. Unmapped obligations show where a control is missing; orphan controls show what you can retire.
6. Set the reporting cadence. Decide what the board sees and when, for example a monthly management pack and a quarterly board report covering control health, risks outside appetite and changes to obligations. Run monitoring and evidence collection on the same rhythm.

Tooling comes later. A clean structure is what makes any tooling cheap to configure.

What are practical GRC framework examples for a regulated firm?

A practical example traces one access-control requirement through the framework: the regulation or standard that demands it, the control ID, the operational owner, the automated evidence and the board metric. One line of lineage shows the five layers working together in practice.

Take a requirement every regulated firm and its clients ask about: only authorised people can reach systems holding client data, and access ends when a role does.

• Obligations. UK GDPR's security obligation, the access controls in ISO 27001, the logical access criteria in SOC 2 and the access clause in a client's outsourcing agreement each say a version of this. Each is a row in the obligations register, rooted in the internal control requirement of SYSC 4.1.1R.
• Control. AC-01, "Joiner, mover and leaver access": access is granted on approval, reviewed quarterly and removed when a role ends. The ID is illustrative.
• Owner. The head of IT owns the control. HR owns the leaver notification that triggers it.
• Evidence. An identity system export comparing active accounts with the HR leaver list, collected automatically each month and stored against AC-01.
• Board metric. Leaver accounts disabled within the agreed window, and access reviews completed on time, shown against risk appetite.

The governance layer holds the policy that says access follows role. The risk register holds "unauthorised access to client data", linked to AC-01.

The lineage runs both ways. Start from the obligation and you reach the board metric. Start from a failing metric and you reach every obligation it puts at risk.

When the supervisor, the auditor and the client each ask about access, you hand all three the same line.

How does a GRC framework in cyber security use continuous monitoring?

In cyber security, GRC stands for governance, risk and compliance applied to information and technology risk. The framework sits above security operations: continuous monitoring and automated evidence feed the control library, so assurance reflects how controls actually perform. Engineering detail sits in the monitoring and evidence-collection layer beneath it.

Continuous monitoring means controls report their own status on a schedule. Identity systems list stale accounts, endpoint management reports unpatched devices, and cloud configuration checks flag drift. Each result attaches to a control ID in the library.

That changes the assurance layer. Instead of sampling evidence before an audit, the board report draws on the current state of each control, and a failing check opens or updates an entry in the risk register.

The monitoring is what makes the framework's claims testable. Start with the controls guarding client data and access, automate their evidence first, and extend as the library settles.

What are the common mistakes when building a GRC framework?

The four common mistakes are building one framework per standard, leaving policies without an owner, keeping a risk register disconnected from controls, and reporting document counts rather than risk outcomes. Each one produces duplicated work and leaves nothing coherent to show a regulator or auditor.

One framework per standard. An ISO 27001 manual, a SOC 2 binder and a Cyber Essentials file each describe access control in their own words, with separate owners, separate evidence and no single answer for the board. The fix is step four: one library, many mappings.

Policies with no owner. A policy gets approved, filed and never reviewed, because no one's name is on it.

A policy with no named owner is a document, not a control.

Give every policy an owner, a review date and the controls that implement it.

A risk register disconnected from controls. A line reading "data breach: high" with no linked control cannot tell the board whether anything reduces it. Link each risk to the controls that treat it and the evidence that they work.

Reporting that counts documents. "Twelve policies approved" says nothing about exposure. Report outcomes: controls passing, risks outside appetite, overdue actions and obligations with no control.

Fix these four and the framework stops being a pile of artefacts. It becomes one structure the board can read and a supervisor can test.

Frequently asked questions