Compliance › Governance

GRC implementation: how to avoid the challenges that stall it

Most GRC implementations stall for organisational reasons, not software. This guide shows how clear ownership, simpler processes and documentation you can maintain keep yours moving, with RACI, roadmap and KPIs mapped to NIS2, DORA, GDPR and ISO 27001.

GRC implementation as three connected platforms: two colleagues handing over a task card, a four-step staircase and an annual wheel with task cards in four quarters

Most GRC implementations don't fail on launch day. They stall quietly, months later. The platform is live, the frameworks are loaded and the kick-off went well. Then control owners stop updating their tasks, the old spreadsheet is still running in parallel, and the first internal review finds documentation nobody has touched since go-live.

The causes are rarely technical. They're organisational: nobody knows who owns what, the first phase tried to cover every framework at once, and documentation has no owner and no review date. That's the pattern we see across the 400+ organisations using .legal, and it matches what practitioner research and Danish public-sector audits describe.

This guide shows how to prevent it. It explains what a GRC implementation actually involves, the challenges that stall it and the three levers that fix them: clear ownership, simpler processes and documentation you can maintain. Each lever is tied to the EU rules that already require it, with article numbers, and the guide ends with a 12-month roadmap and the KPIs that tell you it's working.

The short answer: why GRC implementations stall

A GRC implementation stalls when the organisation treats it as a software installation instead of a change in how responsibility, processes and documentation work. Three things prevent it.

Clear ownership. The management body is accountable and approves. Every control, risk and record has one named owner who does the work.
Simpler processes. Start with the framework you're legally obliged to meet, run it end to end in one area, then expand by reusing controls.
Maintainable documentation. Every document has an owner, a review date and a place in the annual wheel, so it's still current a year after the first audit.

There's no reliable published failure rate for GRC projects, so be sceptical of anyone who quotes one. What is well documented is that people and change management decide the outcome. In Prosci’s research on change management, 88% of projects with excellent change management met or exceeded their objectives, against 13% where change management was poor.

What a GRC implementation involves

GRC stands for governance, risk and compliance. OCEG, the organisation that formalised the discipline, describes it as the integrated capability to reliably achieve objectives, address uncertainty and act with integrity. Its GRC Capability Model groups the work into four components: Learn (understand context, culture and stakeholders), Align (set strategy and objectives), Perform (prevent, detect and remediate) and Review (check that the design and operation are effective).

A GRC implementation is the process of putting that capability into daily operation. It's often confused with three related terms, and the confusion is where most scope problems begin.

Term	What it is	Example
GRC framework	The structure of requirements and controls you work against	ISO/IEC 27001, NIS2 Article 21, the OCEG model
GRC programme	The standing organisation, roles and recurring work that keep you compliant	Named owners, an annual wheel, quarterly management reporting
GRC implementation roadmap	A time-bound plan for getting the programme running	A 90-day pilot, then a 12-month expansion
GRC software	The tool that supports the programme	A platform with frameworks, tasks, a risk register and reporting

The order matters. Software supports a programme, it doesn't replace one. If you buy a tool before you've decided who owns what, you'll configure it around the old spreadsheet and inherit all its problems. Our introduction to governance, risk and compliance covers the concept, and our guide to GRC software covers the tooling.

Common GRC implementation challenges

These are the challenges we meet most often, cross-checked against practitioner research. Each one shows a recognisable symptom long before the project formally stalls, which is useful, because it means you can catch it early.

Challenge	Early symptom	Root cause	Where it’s fixed
No named owners	Tasks assigned to "Compliance" or a shared team inbox	Accountability never leaves the compliance function	Lever 1
No management mandate	Steering meetings cancelled, decisions escalate and stop	Management sees GRC as a compliance project, not a legal duty	Lever 1
Scope too wide	Four or five frameworks in phase one, nothing finished after six months	Wanting to "do it properly" from day one	Lever 2
Silos	Privacy, security and risk teams document the same system separately	Each framework runs as its own project	Lever 2
Over-customisation	Months spent configuring the tool to mirror old spreadsheets	The tool is bent to fit a legacy process	Lever 2
Parallel spreadsheet	The old Excel file is still updated "just in case"	No retirement date was ever set	Lever 3
Documentation decay	Evidence older than its review interval, records out of date	No owner or review date per document	Lever 3
Weak change management	Owners never log in, training is skipped	The rollout was treated as an IT project	Roadmap

The research points the same way. A December 2025 post on ISACA’s blog names three stubborn causes of GRC failure: a siloed approach, a reactive approach and manual procedures. Survey data shows the scale of the manual burden. In Drata's State of GRC 2025, a survey of US companies, 48% of GRC professionals said they struggle to keep pace with updates to existing frameworks. Hyperproof's 2025 benchmark found that 52% of respondents spend 30-50% of their time on administrative tasks such as manual data entry. And in the independent State of GRC 2026 practitioner survey (795 respondents), spreadsheets were still the most common primary GRC tool, named by 93 respondents, ahead of ServiceNow at 86.

Is there a GRC failure rate? Not a reliable one. You'll find figures such as "58% of GRC implementations fail" on vendor websites, but we haven't been able to trace any of them to a primary source, so we don't use them. The evidence on change management is much stronger, and it says the same thing: outcomes are decided by people and process, not by the tool.

Infographic of eight common GRC implementation challenges with early warning symptoms and the lever that fixes each one

Lever 1: clear ownership

Ownership decides whether the other two levers work. The good news is that EU law has already settled half of the question for you.

Accountability sits with management, by law

Across four regimes, the legislator puts accountability on the management body, not on the compliance officer.

Rule	Provision	What it requires
NIS2	Article 20(1)	Management bodies approve the cybersecurity risk-management measures under Article 21, oversee their implementation and can be held liable for infringements
NIS2	Article 20(2)	Members of management bodies must follow training
DORA	Article 5(2)	The management body defines, approves, oversees and is responsible for the ICT risk management framework, and bears ultimate responsibility for ICT risk
DORA	Article 5(4)	Management body members must keep sufficient knowledge and skills to understand and assess ICT risk
GDPR	Articles 5(2) and 24(1)	The controller is responsible for, and must be able to demonstrate, compliance. Measures must be reviewed and updated where necessary
ISO/IEC 27001:2022	Clauses 5.1 and 5.3	Top management ensures that responsibilities and authorities for information security roles are assigned and communicated

National transposition matters too. In Denmark, the NIS2 Act (Act no. 434 of 6 May 2025) has applied since 1 July 2025 and carries the management responsibility into national law. Check your own member state's act for local detail. Our NIS2 implementation guide goes through the steps.

Two levels: accountable and responsible

Stalled implementations usually collapse ownership into a single level. Either the board "owns everything" and nothing happens, or the DPO or CISO owns everything and becomes the bottleneck. The fix is two levels. The management body is accountable: it approves, oversees and receives reports. Named people in the business are responsible: they own a system, a process, a supplier or a control, and they do the daily work.

A simple RACI matrix makes this concrete. R = responsible (does the work), A = accountable (signs off), C = consulted, I = informed.

Activity	Management body	Compliance / risk lead	CISO	DPO	System, process or control owner	Internal audit
Approve risk appetite and key policies	A	R	C	C	I	I
Approve NIS2 / DORA risk measures	A	R	R	I	C	I
Keep the GDPR Article 30 record current	I	A	C	C	R	I
Operate a control and keep its evidence	I	C	A	–	R	I
Assess and treat a risk	I	A	C	C	R	I
Classify and report a significant incident	I	C	A/R	C	C	–
Internal audit and annual review	I	C	C	C	C	A/R

In a smaller organisation one person may hold several of these roles. That's fine, as long as every activity still has one named owner and nobody is both doing the work and independently checking it.

Two-level accountability: three members of the management body review a document at the top, linked to five owners below working on a server, a process flow, a supplier parcel, a control checklist and an office building

Map the roles to the Three Lines Model

The IIA Three Lines Model (2020) gives the RACI a recognised structure. The governing body is accountable to stakeholders for oversight. Management delivers the organisation's objectives and owns the risk as the first line. Second-line roles, such as compliance, risk, information security and the DPO, provide expertise, monitoring and challenge. Internal audit is the independent third line. Mid-sized organisations without internal audit often rely on an external auditor or an ISAE 3402 assurance engagement for that independent view.

Don't make the DPO the owner of everything

Under GDPR Article 39 the DPO informs, advises and monitors compliance, and Article 38(6) requires that other tasks don't create a conflict of interest. The record of processing is the controller's duty, not the DPO's. If the DPO maintains the record alone, you've turned an adviser into an operator and created a single point of failure. Let process owners keep their part of the record, and let the DPO check it.

Lever 2: simpler processes that start small and mature later

The most common scoping mistake is trying to implement every framework, in every business unit, in the first phase. It feels thorough. In practice it means nothing is finished, nobody sees progress and the project loses its sponsor.

Use a GRC maturity model to set the target

Maturity models inspired by OCEG and CMMI describe how GRC develops from ad hoc to optimised. They're not a certification, but they help you agree a realistic target with management.

Level	What it looks like	Typical evidence	Next move
1. Ad hoc	Compliance depends on individuals and personal folders	Scattered files and emails	Name owners and pick the first framework
2. Fragmented	Each framework is run separately by its own team	One spreadsheet per team	Bring one framework into a shared system
3. Standardised	One method, defined roles and an annual wheel for at least one framework	Task completion log, risk register	Add the next framework by reusing controls
4. Integrated	A shared control catalogue across frameworks, with regular management reporting	One evidence item mapped to several requirements	Measure effectiveness with KPIs
5. Optimised	Continuous improvement driven by metrics and audit results	Trend reports, lessons learned	Keep refining

For most mid-sized organisations, level 3 in the first year and level 4 in the second is a sensible target. Level 5 is a choice, not an obligation.

GRC maturity model as five rising platforms, from scattered sheets through sorted stacks and assembled blocks to a finished structure, with a flag on the third level as the year-one target

Pick your first framework by obligation, not ambition

Start where the law already requires you to be. That gives the project a deadline, a sponsor and a reason nobody can argue with.

In NIS2 scope: start with the Article 21 risk-management measures, using ISO/IEC 27001 as your control set.
A financial entity under DORA: start with the ICT risk management framework in Articles 5-16.
Everyone processing personal data: start with the GDPR record of processing activities and the Article 32 risk assessment.
Driven by customer demands: start with ISO 27001, which most customers and tenders ask for by name.

Then go narrow and deep. Take one framework through one business unit or a handful of critical systems, all the way from mapping to the first review. A finished pilot teaches the organisation more than a half-finished programme covering everything.

Reuse controls, but check the gaps

Frameworks overlap heavily, and that overlap is officially documented. In June 2025 ENISA published technical implementation guidance for Implementing Regulation (EU) 2024/2690, mapping each requirement to ISO/IEC 27001:2022, NIST CSF 2.0 and other standards. ENISA also says explicitly that the mapping shouldn't be read as equivalence. Reuse your evidence, then check the gaps.

Topic	ISO/IEC 27001:2022	NIS2	DORA	GDPR
Risk assessment	Clauses 6.1.2, 8.2	Art. 21(2)(a)	Art. 6, 8	Art. 32, 35
Incident handling	A.5.24-A.5.28	Art. 21(2)(b), Art. 23	Art. 17-19	Art. 33-34
Business continuity	A.5.29-A.5.30	Art. 21(2)(c)	Art. 11	Art. 32(1)(c)
Supplier security	A.5.19-A.5.23	Art. 21(2)(d)	Art. 28-30	Art. 28
Training and awareness	Clause 7.3, A.6.3	Art. 20(2), 21(2)(g)	Art. 5(4), 13(6)	Art. 39(1)(b)
Access control	A.5.15-A.5.18, A.8.5	Art. 21(2)(i)-(j)	Art. 9(4)(c)	Art. 32

What doesn't transfer: NIS2 registration and reporting deadlines, the management-body training duty, DORA's register of information on ICT third-party providers and the specific content of the GDPR record. Plan those as separate tasks. Our guide to information security risk management shows how one documented risk scenario can serve several frameworks at once.

Configure the tool to the process, not the reverse

Over-customisation is a slow way to stall. Teams spend months rebuilding the old spreadsheet inside the new tool, column for column, and recreate the same problems in a more expensive place. Agree the process first: who owns what, how often it's reviewed, what counts as evidence. Then use the platform's standard templates and customise only where your legal obligations or business genuinely differ.

Lever 3: documentation you can maintain

Most GRC documentation is in good shape on the day of the first audit. The problem is the year after.

What decays first: evidence from the Danish public sector

Danish state authorities have had to follow ISO 27001 since 2014, with full implementation expected by early 2016. Yet in the Danish Agency for Digital Government’s measurement, only 16 of 109 authorities reported full implementation in 2018, and 39 of 113 in September 2019. The weakest area was measurement, audit and evaluation, which is exactly the part that keeps an ISMS current after it's built.

In January 2022 the Danish National Audit Office found that none of five critical state authorities met all 20 technical minimum requirements for IT security, and that four of the five had action plans they hadn't followed. And in 2021, the City of Copenhagen's DPO reported that none of the city's administrations had a process ensuring the GDPR record of processing was continuously updated.

None of these organisations lacked policies. What they lacked was a mechanism, with named people and dates, that kept the work moving after the initial push.

The minimum documentation set

Keep the documentation as small as the rules allow, and make sure each item has an owner and a review cycle. Review frequencies below are common practice unless the rule sets them.

Framework	Core documentation	Legal basis	Typical review
GDPR	Record of processing, risk assessments and DPIAs, data processing agreements, breach log	Art. 30, 32, 35, 28, 33(5)	Annually and on significant change
ISO/IEC 27001:2022	Scope, policy, risk assessment and treatment plan, Statement of Applicability, internal audit, management review	Clauses 4.3, 5.2, 6.1.2, 6.1.3, 9.2, 9.3	At planned intervals
NIS2	Management approval of risk measures, training records, incident procedure, supplier assessments	Art. 20, 21, 23	Annually and on significant change
DORA	ICT risk management framework, register of information on ICT third parties, incident classification	Art. 6, 28(3), 17-18	Framework reviewed at least once a year (Art. 6(5))

Four rules that keep documentation alive

One named owner for every document, control, risk and record. A team is not an owner.
A review date set at creation. If nobody knows when a document is due for review, it won't be reviewed.
Version control and a change log. ISO/IEC 27001 clause 7.5.3 requires control of distribution, access, storage, versions and retention. It's good practice everywhere else too.
Evidence stored with the control it proves, not in an email thread or a personal drive.

Run the work through an annual wheel

An annual wheel turns static documents into recurring work with owners and deadlines. A simple version looks like this.

Quarter	Recurring tasks	Owner	Evidence produced
Q1	Review the record of processing, update the supplier list and classification	Process and supplier owners	Updated record, supplier register
Q2	Update risk assessments, run an awareness campaign	Risk owners, compliance lead	Risk register, training completion
Q3	Internal audit, incident and continuity test	Internal audit or ISMS lead, CISO	Audit report, test report
Q4	Management review, approve risk measures, policies and next year’s plan, management training	Management body	Minutes, approvals, training records

See our checklist of recurring GDPR compliance tasks for a fuller list, and our guide to awareness training for the Q2 campaign.

Finally, retire the spreadsheet on a named date. Running both "to be safe" doubles the work and guarantees the two versions drift apart. Our article on Excel versus compliance software covers the trade-offs.

GRC annual wheel in four quarters, each holding task cards with an owner icon and a check mark, while four colleagues place and complete tasks

Example: getting a stalled implementation back on track

Nordvig Forsyning A/S and Line Bech are fictional. We made them up for this article, but the pattern is common.

Nordvig Forsyning is a utility with 180 employees and in NIS2 scope. In January it bought a GRC platform and loaded GDPR, NIS2 and ISO 27001 at once. Line Bech, the compliance manager, assigned most tasks to herself and the rest to the IT team's shared mailbox. By June, 12% of controls had current evidence, the old spreadsheet was still in use and the board had discussed NIS2 twice.

The restart took five decisions.

The management body approved a one-page mandate naming the CFO as sponsor and Line as programme lead, with quarterly reporting.
Scope was cut to the NIS2 measures for three critical systems, using ISO 27001 as the control set.
The 41 controls in scope were assigned to nine named owners in IT, operations and procurement.
Recurring tasks went into the annual wheel, each with an owner, a deadline and the evidence it should produce.
The spreadsheet was retired on 1 September.

Ninety days later, every control had a named owner and 85% had current evidence. In the first quarter of the following year Nordvig added GDPR, reusing its supplier assessments and access-control evidence instead of starting again.

GRC implementation steps: a 12-month roadmap

These ten steps put the three levers in order. They work for a first implementation and for a restart.

Confirm obligations and scope. List the laws and standards that apply, and which entities, systems and processes they cover.
Secure a management mandate and a sponsor. Get the management body to approve the programme, its scope and its reporting cadence.
Baseline your maturity. Place each framework on the maturity scale and agree a year-one target.
Name owners. Build the RACI and assign every control, risk and record to a person, not a team.
Choose the first framework and a pilot area. Pick by legal obligation and keep the pilot narrow.
Build the minimum documentation and control set. Only what the rules require and the business needs, each item with an owner and a review date.
Configure the tool to the process. Use standard templates and customise only where you genuinely differ.
Train, migrate and retire the spreadsheet. Train owners on their tasks, move the data and set a hard retirement date.
Run the first review. An internal audit or review of the pilot, reported to management.
Expand by reusing controls, and review annually. Add the next framework or business unit through the shared control set.

Phase	Timing	Milestones
Foundation	Days 0-30	Mandate approved, obligations mapped, owners named
Pilot	Days 31-60	First framework configured for the pilot area, documentation set under way
Operate	Days 61-90	Spreadsheet retired, first annual-wheel tasks completed, first management report
Expand	Months 4-9	Second framework added through reused controls, more business units onboarded
Review	Months 10-12	Internal audit, management review, plan for year two

Published timelines vary widely. Vendor estimates run from two to four months for a mid-market platform deployment to 12-18 months for a full enterprise rollout, so treat any single figure with care. Our guidance is simpler: aim to have one framework live, with named owners and current evidence, within 90 days.

Twelve-month GRC implementation roadmap with foundation, pilot, operate, expand and review phases and one framework live by day 90

KPIs that show your GRC implementation is working

Measure the programme, not just the project. These indicators are easy to collect from a platform and tell you early when something is slipping.

KPI	What it tells you	Warning sign
Share of controls with a named owner	Ownership is in place	Below 100% after the pilot
Recurring tasks completed on time	The process runs	Falling from one quarter to the next
Overdue risk treatment actions	Risks are actually being reduced	A growing backlog
Evidence freshness	Documentation is maintained	Evidence older than its review interval
Time to answer an auditor’s evidence request	Documentation can be found	Days rather than hours
Management reports delivered on schedule	Governance works	Missed or postponed reports
Management body training completed	NIS2 Art. 20(2), DORA Art. 5(4)	No training record
Owners active in the platform	Adoption	Owners who never log in

Cover of the GRC implementation checklist from .legal

Download the GRC implementation checklist

Eight sections on six pages: obligations and mandate, ownership, scope and first framework, documentation, the first 90 days, the annual wheel, quarterly KPIs and a self-test with warning signs. Use it before you start, after 90 days and at your annual review.

Download the checklist (PDF, 6 pages)

Choosing GRC software that supports implementation

The software can't fix ownership or scope for you, but the wrong tool can make both harder. When implementation is the concern, five capabilities matter most.

Named ownership and role-based access, so every control and record has one responsible person who sees only what they need.
A recurring task engine or annual wheel with reminders and status overview.
Cross-framework control mapping, so one piece of evidence counts everywhere it applies.
Audit trail and version history for every document and decision.
Modularity, so you can start with one framework and add the next without a new project.

For the full evaluation criteria, read our guide to GRC software and our vendor guide to buying compliance software.

How .legal supports a GRC implementation

.legal is a modular GRC platform built for the way this guide recommends working. The Frameworks module maps one task to the controls it supports across GDPR, NIS2, ISO 27001, DORA and the AI Act, so you can start with one framework and reuse the work later. The compliance annual wheel gives every recurring task an owner, a deadline and a status, and Enterprise Risk Management lets you attach risk scenarios to the assets and processes you've already mapped.

Ownership is built in. Every asset, process and supplier has one named responsible person, access is role-based, and colleagues who never log in can still receive and sign off policies. When you're ready to leave the spreadsheet, our migration guide shows how to move your data. The platform is covered by ISAE 3402 and ISAE 3000 assurance reports and hosts data in the EU.

Want to see how a phased implementation would look with your own frameworks? Book a demo and we'll walk you through it.

Still unsure?

Ask Johannes directly, he runs most demos personally. Book him here.

Frequently asked questions about GRC implementation

How do you implement a GRC program?

Start by confirming which laws and standards apply, then get the management body to approve a mandate and appoint a sponsor. Name an owner for every control, risk and record, choose one framework as a pilot, build the minimum documentation set, configure your tool to the agreed process and retire spreadsheets on a fixed date. After the first review, expand by reusing controls for the next framework.

How long does a GRC implementation take?

It depends on scope and size. A realistic target for a mid-sized organisation is one framework live with named owners and current evidence within 90 days, and a second framework within the first year. Full enterprise rollouts across many units and frameworks typically take 12 to 18 months, according to vendor estimates.

Why do GRC implementations fail?

Mostly for organisational reasons: no named owners, no management mandate, a first phase covering too many frameworks, teams working in silos, tools customised to mirror old spreadsheets and documentation with no review date. There is no reliable published failure rate for GRC projects, but research on change management shows that people and process largely decide the outcome.

What is the difference between a GRC framework and a GRC programme?

A framework is the structure of requirements and controls you work against, such as ISO 27001 or NIS2 Article 21. A programme is the standing organisation that makes it work in practice: owners, recurring tasks, reporting and review. You can adopt a framework in a day, but a programme has to be built and maintained.

Who should own GRC in an organisation?

Ownership works on two levels. The management body is accountable and approves risk measures, as NIS2 Article 20 and DORA Article 5 require. Day-to-day responsibility sits with named system, process and control owners in the business, supported by second-line roles such as compliance, the CISO and the DPO.

Is the board responsible for NIS2 compliance?

Yes. Under NIS2 Article 20 the management body must approve the cybersecurity risk-management measures, oversee their implementation and can be held liable for infringements. Members must also follow training. The Danish NIS2 Act, in force since 1 July 2025, carries this responsibility into national law.

What is a GRC maturity model?

A GRC maturity model describes stages of development, typically from ad hoc through fragmented, standardised and integrated to optimised. It isn't a certification. Its value is in agreeing a realistic target with management, for example a standardised programme for one framework in year one and an integrated programme across frameworks in year two.

Should we implement several frameworks at once?

Usually not. Start with the framework you are legally obliged to meet and take it all the way through to the first review. Then add the next one by reusing controls and evidence. Frameworks overlap heavily, but ENISA itself warns that mappings aren't equivalence, so check the gaps each time.

Can you run GRC in spreadsheets?

For one framework and a handful of people it can work for a while. It becomes fragile once several frameworks, owners and audits are involved, because spreadsheets lack a reliable audit trail, version control and reminders. If you move to a platform, set a fixed date to retire the spreadsheet so the two don't drift apart.

What KPIs show that a GRC implementation is working?

Useful indicators include the share of controls with a named owner, recurring tasks completed on time, overdue risk treatment actions, evidence older than its review interval, the time it takes to answer an auditor's evidence request, and whether management reports and management training happen on schedule.

Still unsure?

Ask Johannes directly, he runs most demos personally

Book him here

.legal compliance platform

Keep your GRC implementation moving

Start with one framework and grow from there. .legal gives every control, risk and record a named owner, runs recurring work through an annual wheel and keeps the evidence current after the project team has moved on.