GRC implementation: how to build a GRC programme in your first 90 days

Your largest prospect's security review has come back with a page of questions, and nobody owns the answers. A client audit left findings that are still open. The board wants to know who is in charge of risk, and GRC implementation has just become your job.

This guide is for the newly accountable Head of Compliance, Head of Security, COO or CTO at a UK B2B technology firm of 25 to 250 people that sells into regulated industries. It sets out a 90-day sequence: where your obligations come from, what to do in each 30-day phase, who owns what, and what to leave until the basics run.

What does GRC implementation mean for a small firm?

GRC implementation means turning governance, risk and compliance from scattered tasks into one operating cycle with named owners. A firm of 25 to 250 people can stand up the core in about 90 days by working in a fixed order: obligations, owners, risks, controls, policies, then reporting. Each step feeds the next one.

The order matters more than the tooling. Owners come before risks, because a risk without an owner never gets treated. Controls come before policies, because a policy should describe what the firm actually does, not what it hopes to do.

This page assumes you already know what GRC is and need to build the programme. It stays with the sequence and links out for the detail behind each step.

Where do a B2B tech supplier's GRC obligations come from?

A B2B technology supplier's GRC obligations come from four places: customer contracts and their security schedules, the standard you certify or report against, UK GDPR, and, for suppliers to financial services, the contract terms DORA requires those clients to impose. Most of them arrive through a customer, not a regulator.

• Customer contracts and security schedules. Enterprise contracts carry security clauses such as breach notification windows, audit rights, subcontractor approval and data location. Each clause is an obligation, whether or not anyone has read it since the contract was signed.
• ISO 27001 or SOC 2. The standard your customers ask for gives the programme its skeleton. ISO 27001 starts by asking you to understand your context and the issues that affect your security. SOC 2 measures you against the AICPA's Trust Services Criteria.
• UK GDPR. Where you process personal data for a customer, you are usually its processor. Article 28 requires the controller to use only processors that provide sufficient guarantees, and requires a binding contract to govern the processing. Article 5(2) makes the controller responsible for showing compliance, which is why customers ask you to prove yours.
• DORA, through your financial-services clients. The EU's Digital Operational Resilience Act applies to financial entities. Article 30 sets the key provisions their contracts for ICT services must contain, so those terms reach you through the contract. Direct oversight applies only to ICT providers that the European Supervisory Authorities designate as critical.

UK-regulated clients bring their own duties as well. The FCA's SYSC 4.1.1R requires firms to have a clear organisational structure with well defined lines of responsibility, and effective processes to identify, manage, monitor and report their risks. Their supplier questionnaires follow from that.

Your first regulator is usually a customer's procurement team.

What does a 90-day GRC implementation plan look like?

A 90-day GRC implementation plan runs in three 30-day phases. Days 1 to 30 build the obligations register, fix the scope and name owners. Days 31 to 60 add the risk register, a control baseline and a minimum policy set. Days 61 to 90 set the reporting cadence, hold the first management review and start the evidence routine.

We recommend treating 90 days as the time to get the cycle running, not to finish it. A certificate or an attestation report comes later, once your controls have run long enough to leave evidence.

What happens in days 1 to 30?

Days 1 to 30 are about knowing what you owe and who owns it. Build an obligations register from your contracts, your target standard, UK GDPR and any terms your clients impose. Fix the scope: the products, teams and locations the programme covers. Then name one owner for each obligation area before any other work starts.

1. Collect the obligations. Pull the security schedules from your largest customer contracts, the requirements of your target standard, your UK GDPR duties, and any DORA-driven terms from financial-services clients. Record each one with its source and, where there is one, its deadline.
2. Fix the scope. Name the products, services, teams and locations in scope. A tight scope you can run beats a wide one you cannot.
3. Name the owners. Give each obligation area one accountable person. Ownership is a name, not a department.
4. Agree the sponsor. Choose one executive who can unblock budget and decisions, and who will receive the reports in the third phase.

The obligations register needs a working first version here, not a finished system. Keeping it current as contracts and laws change is the job of a compliance management system, which can follow once the cycle runs.

What happens in days 31 to 60?

Days 31 to 60 turn obligations into a managed set of risks and controls. Build a risk register and decide a treatment for each top risk. Map a control baseline to your chosen standard, ISO 27001 or SOC 2, and write the minimum set of policies those controls need. Each risk, control and policy gets an owner from phase one.

• The risk register. Identify risks within the scope, score them on one agreed scale and record a treatment decision for each: reduce, accept, transfer or avoid. ISO 27001 sets out how to plan actions to address risks and opportunities, and our risk management policy template gives you the method in writing.
• The control baseline. Map the controls you already run before adding new ones. Many firms do more than they have written down: access reviews in someone's calendar, backups that run every night, a joiner checklist in HR. If ISO 27001 is your standard, our ISO 27001 implementation guide covers its phases in detail.
• The minimum policy set. We recommend starting with seven: information security, access control, acceptable use, incident response, supplier security, risk management and data protection. Write each one to match what the firm does, keep it short, and give it an owner and a review date.

A policy that describes what nobody does is a finding waiting for an auditor.

What happens in days 61 to 90?

Days 61 to 90 make the programme repeat. Set a reporting cadence to the executive team and the board, hold the first management review, and start an evidence routine so that proof of each control is collected as the work happens. By day 90 the cycle has run once, and everyone knows when it runs again.

• The reporting cadence. The UK government's Cyber Governance Code of Practice asks boards to require formal reporting at least quarterly, with suitable metrics and agreed tolerances. The Code is designed for medium and large organisations and encourages smaller ones to apply its principles, so a quarterly report is a sensible default across the 25 to 250 range. Keep the first one short: top risks, open findings, obligations at risk and the decisions needed.
• The first management review. A management review asks whether the programme is working and what should change. ISO 27001 sets out what a management review must consider. Hold one even while the programme is young, because its minutes are early evidence that leadership is engaged.
• The evidence routine. Agree what proves each control works, who collects it and when. A simple calendar beats an annual scramble before the audit.

The first review also sets the agenda for the next 90 days. Its findings show which controls are not working, which gaps are still open and which manual steps repeat often enough to be worth automating later. Improving the programme is that loop, run every cycle, not a separate project.

Who owns what in a lean GRC programme?

In a lean GRC programme, one person leads, an executive sponsors, and the people who already run each process own its controls. A firm of 25 to 250 people rarely needs a dedicated GRC team. It needs clear names for who sets direction, who coordinates the programme, and who does the work each control describes.

The table is a starting point, not an organisation chart. In a firm of 30 people one person may hold two rows; what matters is that every row has a name.

What should you defer until the basics run?

Defer three things until the core cycle runs: buying a GRC tool, adding a second framework, and automating any process that is not yet defined. Each one is worth doing later. Done first, each one multiplies the work, because it fixes a process in place before you know what the process should be.

• The tool purchase. A tool holds registers, workflows and evidence. It cannot decide who owns a risk. Run the first cycle in shared documents, then choose a tool that fits the process you now know.
• A second framework. Get one standard running before adding another. The second then reuses the registers, owners and controls you already have, rather than starting a parallel programme.
• Automating an undefined process. Define the process, run it by hand for a cycle, then automate the parts that repeat. Automation is how a mature programme scales, not how a new one starts.

How do you fit GRC into the way the business already runs?

Fit GRC into the business by attaching each review to a meeting, plan or process that already exists, rather than running a parallel calendar. Put risk on the leadership agenda, tie control changes to your change process, and update obligations when contracts are signed. Integrated GRC shows up where decisions are already being made.

• Leadership meetings. Add a standing risk item to the monthly leadership meeting. A few minutes on the top risks keeps the register current.
• Planning. Review the risk register when the business plans its next quarter or year, so new products and markets bring their risks with them.
• Change. Ask the risk question inside your existing change and release process, not on a separate form.
• Contracts and suppliers. Update the obligations register when a customer contract is signed or renewed, and when a new supplier joins.
• People. Add GRC steps to the joiner, mover and leaver checklists that HR already runs.

Why do GRC programmes stall?

GRC programmes stall for five common reasons: nobody owns them, teams work in silos, the framework is chosen before the obligations are known, a tool is bought before the process exists, and the board never sees a report. Most are sequencing problems, and the 90-day order is built to avoid all five.

• No owner. The programme sits with "the security team" or "compliance", so every decision waits for a meeting that never happens.
• Silos. Security, legal, HR and finance each keep their own list of risks and obligations, so nobody sees the whole picture.
• Framework-first thinking. Choosing a framework before knowing what customers require leads to controls nobody asked for and gaps in the ones they did.
• Tool-first buying. The tool becomes the project, and configuration replaces decisions.
• No board reporting. Without a regular report, the programme loses its sponsor at the first competing priority.

A programme the board never hears about is a project with no end date.

Frequently asked questions