GRC in 2026: from policy management to control operations

2026 is the year of operational proof

Cybersecurity governance, risk, and compliance has spent years organising obligations, policies, questionnaires, and audit evidence. That work remains necessary, but it is no longer enough. A policy can be approved while the control it describes is missing. A control can be implemented while nobody checks whether it still works. A green dashboard can coexist with an attack path that the organisation has never tested.

The useful question in 2026 is therefore not only whether a requirement has been mapped. It is whether the organisation can show who owns the control, how it operates, what evidence it produces, what happens when it fails, and whether the remaining risk is acceptable. Compliance is an input to that decision. Operational security is the outcome that gives the evidence meaning.

One control can serve several obligations

A weak GRC model creates a separate checklist for every regulation, framework, customer questionnaire, and internal standard. Teams then collect similar evidence several times, describe the same control in different language, and struggle to tell which version reflects reality.

A stronger model starts with the organisation's control objectives. Requirements from DORA, NIS2, the Cyber Resilience Act, ISO/IEC 27001, NIST CSF, customer contracts, and internal risk decisions can be mapped to that control layer. The mapping preserves traceability, but operation remains centred on one control, one accountable owner, one defined frequency, and one body of evidence.

This does not mean that different obligations are interchangeable. Their scope, legal effect, reporting rules, assurance expectations, and competent authorities differ. The point is to reuse the security mechanism and its evidence where the facts genuinely overlap, while preserving the distinctions that matter.

Evidence must be designed into the operation

Evidence should be an output of the control, not a reconstruction performed just before an assessment. An access review should produce the reviewed population, decisions, approvals, unresolved exceptions, and completion record. A backup control should produce job status, protected scope, failure handling, restore results, and action ownership. An incident control should preserve decisions, timelines, evidence, communications, and lessons learned.

For each important control, define the claim being made, the expected evidence, the source system, the owner, the retention period, and the escalation path when evidence is missing or contradictory. Automation can reduce collection effort, but it cannot repair an unclear control objective or an unowned exception.

Evidence quality also has limits. A configuration screenshot can show a setting at one moment. It may not show that the setting covered every relevant asset or operated throughout the period. Good GRC records both what the evidence supports and what it does not.

Current regulation reinforces the operational shift

The direction is visible across European cybersecurity obligations. DORA connects ICT risk management with incident handling, resilience testing, third-party risk, and management accountability. ENISA's technical guidance for parts of the NIS2 ecosystem includes practical implementation advice, examples of evidence, and mappings of security requirements.

The Cyber Resilience Act adds a near-term operational test for manufacturers. From 11 September 2026, the reporting obligations for actively exploited vulnerabilities and severe incidents affecting products with digital elements begin to apply, with early-warning and notification timelines that cannot be met by policy text alone. The AI Act also entered a new enforcement phase on 2 August 2026, alongside transparency requirements for certain AI systems and generated or altered content.

Applicability still needs careful legal and jurisdictional analysis. The management lesson is broader: inventories, ownership, detection, escalation, evidence, supplier coordination, and tested reporting procedures must work together before an incident or regulatory deadline arrives.

AI changes the work, not the accountability

AI can help classify obligations, compare control language, summarise evidence, draft questions, and identify inconsistencies. Used carefully, it can remove repetitive work and help a small team examine more material. It can also produce confident errors, overlook scope conditions, expose sensitive records, or turn uncertain evidence into a polished but unsupported conclusion.

The right operating model treats AI output as an analysis aid. Source traceability, access control, data handling, review thresholds, validation, and named human approval remain necessary. Risk acceptance, materiality judgments, legal interpretation, and assurance conclusions should not be silently delegated to a model.

The same principle applies to AI systems governed by the organisation. The GRC record should connect each material use case to an owner, purpose, data, model or provider, permissions, controls, monitoring, incidents, and change decisions. An AI inventory without these relationships is only a list.

Threat and incident data belong in GRC

A risk register becomes stale when it is separated from the security operation. Threat intelligence should influence scenarios, exposure priorities, supplier questions, and detection coverage. Incidents and near misses should challenge risk assumptions. Vulnerability and attack-path findings should identify which control claim was contradicted and which business service was exposed.

This is the practical connection between GRC and offensive or defensive security. Technical activity produces evidence about how controls behave. Governance gives that evidence context, ownership, materiality, and a decision path. Neither side should operate as a reporting annex to the other.

Not every threat report deserves a new risk entry, and not every technical finding is material. The organisation needs criteria for relevance, impact, confidence, escalation, and acceptance. That is how intelligence becomes a decision input rather than a news feed.

A credible operating model is simple to describe

For every material control, the organisation should be able to state the objective, scope, owner, design, implementation state, operating frequency, evidence, health measure, open exceptions, dependencies, and last independent challenge. These are separate facts. Combining them into one status hides the exact point of failure.

Management cadence matters as much as the register. Control owners need a schedule. Exceptions need expiry dates and treatment decisions. Material changes need impact assessment. Incidents need to feed improvement. Leaders need a small set of indicators that expose coverage, overdue work, repeated failures, unsupported claims, and residual risk.

Independent assurance should remain a distinct activity. A team that designs or operates a control can test its work and support remediation, but an assurance conclusion needs objective criteria, sufficient evidence, transparent limitations, and managed conflicts.

The next 90 days

Start with one critical service or regulatory objective, not the entire control library. Identify the obligations that apply, select the controls that make the objective true, and separate design, implementation, operation, evidence, and effectiveness. Assign owners and agree what failure looks like.

Then test the evidence chain. Can the organisation retrieve a complete and trustworthy record without a manual rescue exercise? Do incidents, changes, threat information, and technical findings reach the control owner? Can management see the exceptions that alter the risk decision?

The result should not be another maturity score. It should be a short, owned improvement backlog and a control system that is easier to operate next month than it was last month. That is the standard GRC should meet in 2026.