GRC Ops: operational, continuous GRC

GRC Ops (or operational GRC) is a way of running governance, risk and compliance as a continuous activity: controls are monitored all year round, data is shared between risk, compliance and third-party management, evidence is collected as work happens, repetitive tasks are automated and steering relies on up-to-date indicators. It contrasts with campaign-based GRC, where everything happens in the weeks before the annual audit. The term is recent and not defined by any standard; its ideas, however, are proven, and NIS 2, DORA and ISO 27001 make them increasingly necessary.

GRC (governance, risk and compliance) brings together three activities every CISO knows: setting the rules (security policy, frameworks, roles), analysing and treating risk, and checking that requirements are met, internally and at suppliers. In many organisations these activities follow a calendar: a risk assessment every three years, a compliance campaign every year, a certification audit, then a long period during which the spreadsheets stop moving.

GRC Ops changes that rhythm. We define it as follows: GRC run continuously, in which every control has an owner, a frequency and expected evidence, risk, compliance and third-party management share the same data, and gaps trigger actions tracked until closure, measured by up-to-date indicators. The "Ops" suffix echoes DevOps and DevSecOps: it points to an activity built into day-to-day operations rather than a one-off project.

The five components of operational GRC

• Continuously monitored controls: each security measure is checked at a frequency suited to its risk, not only in audit years.
• A single source of data: one framework of requirements, one inventory of assets and third parties, one risk scale, shared by every team.
• Evidence collected as you go: evidence is produced when the control is performed, dated and linked to the requirement, instead of being hunted down in a rush.
• Automation of repetitive tasks: reminders, consolidation, indicator calculation and reports happen without manual copying.
• Steering by indicators: management follows a few measures that show whether controls hold, not a pile of documents.

GRC Ops, GRCOps, continuous GRC: a new term

To be clear: "GRC Ops" is not a standard, not a method published by a security agency and not a term owned by any standards body. As of September 2026 it is rarely used, in Europe or elsewhere. What does exist is a US movement called GRC Engineering, continuous control monitoring practices that are more than a decade old, and European texts that require organisations to check that their measures remain effective over time. GRC Ops brings these ideas together under a simple name that works for teams without developers. That is the meaning we give it in this series.

GRC Ops does not start from scratch. It builds on three movements that have each proven their worth.

Continuous control monitoring

As early as September 2011, the US standards institute NIST published SP 800-137 on Information Security Continuous Monitoring. The idea: give ongoing visibility into assets, threats and vulnerabilities, and make sure on an ongoing basis that controls remain aligned with the organisation's risk tolerance. In the audit world, the same idea is known as continuous control monitoring.

DevSecOps

Development teams have learned to build security into their delivery pipelines: automatic tests on every change, dependency analysis, blocking rules. The principle, often summed up as "shifting security left", is to deal with a problem when it appears rather than after the fact. GRC Ops applies the same reflex to compliance requirements.

GRC Engineering

Over the past few years, and more visibly since 2025, a community of US practitioners has argued that GRC should borrow the methods of software engineering. Their manifesto, published on grc.engineering by nine authors, values "automate early and often" over manual processes, and deep continuous assurance over shallow periodic monitoring. In August 2025, an article on the SANS Institute blog by AJ Yawn described GRC Engineering as using software development, automation and cloud technologies to streamline GRC processes. On the government side, the US FedRAMP 20x programme, announced in March 2025, is testing automatically validated security indicators to replace part of the static annual assessments. We cover the movement, its tools and its limits in our article GRC Engineering: what the trend means for CISOs.

GRC Ops is its operational version, designed for a European context: it keeps the goal (continuous, measurable, evidence-based GRC) without requiring every control to be written as code.

No text uses the words "GRC Ops". But every text that matters to a European CISO requires organisations to check that measures work over time, not just that they exist on paper.

NIS 2: assessing the effectiveness of measures

Article 21 of the NIS 2 Directive lists, among the minimum risk management measures, policies and procedures to assess the effectiveness of cybersecurity risk management measures (point f). Article 20 requires management bodies to approve these measures and oversee their implementation. Implementing Regulation 2024/2690, which details these measures for certain categories of digital entities (cloud, data centre and managed service providers, among others), goes further: it requires regular review of compliance with security policies, a compliance reporting system to management and monitoring "at planned intervals" (point 2.2), plus a procedure setting out which measures to monitor, how, when and by whom (point 7).

In France, the transposition law had still not been adopted at the time of writing: the bill that transposes it is still awaiting debate in the National Assembly. The national agency ANSSI is already supporting the entities concerned. See our article From NIS to NIS 2 for details.

DORA: continuous monitoring and a yearly review

For financial entities, the DORA Regulation, applicable since 17 January 2025, is explicit. Article 9 requires them to continuously monitor and control the security and functioning of ICT systems and tools. Article 6 requires the ICT risk management framework to be documented, reviewed at least once a year and after major incidents, continuously improved based on lessons learned, and regularly subject to internal audit. Article 5 places ultimate responsibility for this risk on the management body.

ISO 27001: clause 9 and continual improvement

ISO/IEC 27001:2022 devotes clause 9 to performance evaluation: monitoring, measurement, analysis and evaluation (9.1), internal audit (9.2) and management review (9.3). Clause 10 requires continual improvement of the ISMS and handling of nonconformities. An ISMS that only comes to life for the surveillance audit meets these clauses in form, rarely in substance.

The difference does not lie in the frameworks, which stay the same, but in how they are kept alive. The table below compares the two approaches on the points that matter day to day.

GRC Ops comes down to a loop: a control is performed, it produces evidence, the evidence may reveal a gap, the gap becomes an action, and progress feeds an indicator. Then the next control starts, without waiting for next year's audit.

1. Controls rather than questionnaires

A requirement ("privileged accounts are reviewed") is not enough: you need a control that states who checks it, how, how often and with what expected result. A quarterly control that is actually performed is worth more than a "compliant" answer given once a year.

2. A single source of data

The same requirement often serves several texts: access management appears in ISO 27001, NIS 2, DORA and your security policy. By linking these frameworks, one control answers several obligations, and a measure decided in a risk assessment goes straight into the compliance action plan. It is also what lets you compare a subsidiary, a site or a supplier against the same grid.

3. Evidence as you go

Evidence is not a document produced for the auditor; it is the normal trace of the work. An export of an access review, the record of a restore test, the report of a crisis exercise: each piece of evidence is dated, linked to the requirement it covers and kept with its history.

4. Automate what repeats

Chasing contributors, consolidating answers from twenty sites, recalculating a compliance rate, producing the quarterly report: these tasks require no expertise yet consume a large part of GRC teams' time. Automating them frees time for analysis. Automation does not decide for you: it prepares, people validate.

5. Steer by indicators

A good indicator shows whether measures hold: share of controls up to date, age of gaps, time to fix. It lets management, which NIS 2 and DORA make responsible for cybersecurity, follow the situation without reading a hundred-page report.

How to move from the annual audit to permanent control in practice, and which controls to automate first, is the subject of our article on continuous compliance.

The examples below are typical situations, built from each sector's obligations, to show what operational GRC looks like day to day.

The CISO of a public hospital

They are responsible for the security of the health information system, the requirements linked to health data hosting, the expectations of national funding programmes and, soon, NIS 2. Working almost alone, they cannot run a full campaign for each framework. With GRC Ops, they link these texts in a common framework, track about twenty priority controls (offline backups tested, privileged accounts reviewed, patches on exposed equipment, maintenance providers' access) and have the evidence filled in by the teams doing the work. When management or the regional health authority asks where the hospital stands, the indicator is already up to date.

A local authority

A group of municipalities has to keep the security accreditation of its online services up to date, oversee many service providers and prepare for NIS 2. Its departments are scattered and security is nobody's main job. GRC Ops lets it assign each control to a named owner in each department, send automatic reminders and follow critical suppliers with the same grid as internal services. Accreditation stops being a file redone every three years and becomes continuous monitoring of residual risk.

A mid-sized industrial company

A mid-sized company with several sites and subsidiaries receives security questionnaires from its large customers, is aiming for ISO 27001 certification and may fall within the scope of NIS 2. Instead of answering case by case, it runs a compliance campaign across its sites from a single framework, tracks gaps site by site and reuses the same evidence for the certification audit and for its customers. Management follows a quarterly dashboard, comparable from one site to the next.

There is no need to transform everything at once. Organisations that make this shift start small, measure, then widen the scope.

1. List your obligations

List what actually applies to you: NIS 2, DORA, GDPR, sector rules, ISO 27001, your customers' contractual requirements, your security policy. Bring them together in a common framework and link overlapping requirements.

2. Pick about ten priority controls

Start from your major risks, taken from your latest risk assessment or your risk matrix. Keep the controls that cover the most risks and requirements at once: backups, access management, patching, multi-factor authentication, critical suppliers.

3. Give each control an owner, a frequency and evidence

This is the step that makes the difference. "Quarterly review of privileged accounts by the system administrator, evidence: dated export of the approved list" is a control. "Access is under control" is not.

4. Tool the cycle

A shared spreadsheet may be enough to test ten controls. Beyond that you need a GRC platform that links frameworks, controls, evidence, action plans and indicators, and sends reminders for you. Teams with developers can also automate some technical controls with scripts, GRC Engineering style.

5. Treat gaps as actions

Each gap becomes an action with an owner and a deadline, or a risk explicitly accepted by the person entitled to do so. A gap with no follow-up is worthless.

6. Measure, report, expand

After a quarter, present the first indicators to management, adjust frequencies, then add new controls and new scopes. Method, roles and the steering committee are covered in our article on compliance management.

A few well-chosen indicators are enough. They should measure whether measures hold, not how many documents were produced.

These indicators only make sense over time: a trend matters more than a single value. They also feed the yearly review required by DORA and the ISO 27001 management review.

• "Everything can be automated." No. A technical setting can be checked automatically; the relevance of a policy, the quality of a risk assessment or the decision to accept a risk remain human.
• "A tool is enough." A tool without well-defined controls only automates disorder. Method first, tool second.
• "Continuous replaces audit." No: internal audits and certification audits are still required by ISO 27001 and DORA. GRC Ops makes them easier, because the evidence is already there.
• "More controls is better." A poorly chosen control costs time without reducing risk. The choice starts from the risk assessment.
• "AI will do the work." It can speed up reading evidence or drafting, provided every proposal is validated by a person. We look at what it brings and its limits in our article AI and GRC.

Phinasoft is a French GRC software platform built for cybersecurity. It covers the steering side of the GRC Ops loop: frameworks, assessments, evidence, action plans and indicators. Its five modules share the same data: a measure decided in a risk assessment appears in the action plan, and a requirement from your security policy can be used to assess a subsidiary as well as a supplier.

• A common framework: a catalogue of more than twenty frameworks (ISO 27001/2, NIS 2, DORA, GDPR, IGI 1300…) and your own policy, versioned and linked in the policies editor, with the evidence expected for each requirement.
• Campaigns tracked over time: compliance campaigns collect compliance levels, justifications and evidence, with progress tracking and reminders, and show how a scope evolves from one campaign to the next.
• Suppliers in the same loop: the supplier assessment portal applies the same requirements to your providers.
• Actions and indicators without copying: consolidated action plans that each owner updates directly, reminder notifications, automatically calculated indicators and custom dashboards.
• AI prepares, you validate: the built-in AI analyses your documents, maps evidence to the right requirements and proposes a first assessment; every proposal goes through explicit validation.

To see how this cycle applies to your own frameworks, book a demo.