GRC Engineering: what the trend means for CISOs

GRC Engineering means applying software engineering methods to governance, risk and compliance: automating repetitive tasks, expressing some controls as code, collecting evidence automatically and monitoring compliance continuously. Born in a community of US practitioners, the term spread in 2025, carried by the SANS Institute and then by compliance software vendors. It is still almost unknown in continental Europe. Here is where it comes from, what it covers, and what a CISO can take from it, even without developers.

Traditional GRC works in cycles: fill in a questionnaire, gather evidence before the audit, produce a report, then start again the following year. GRC Engineering starts from a simple observation: much of this work is repetitive, manual and out of step with the actual state of systems. So it proposes treating GRC the way development teams treat their software, with automation, tests and measurement.

Definitions vary from one author to another, but three ideas come up everywhere:

• Automate whatever can be automated: evidence collection, reminders, consolidation, indicator calculation.
• Test rather than declare: compliance status is derived from what systems show, not only from what people say.
• Monitor continuously rather than once a year, to detect a gap when it appears.

GRC Engineering, GRC Ops: a word on terms

In this series we use "GRC Engineering" for the movement and its tools, and GRC Ops for the way an organisation runs GRC continuously, with or without code.

A practitioners' manifesto

The reference text is the GRC Engineering Manifesto, published on grc.engineering by nine practitioners including Ayoub Fandi, Justin Pagano, Charles Nwatu and Terra Cooke. Following the format of the Agile Manifesto, it contrasts pairs of values: it prefers early automation to manual processes, "GRC as code" to tool-specific constructs, measurable risk outcomes to checkbox compliance, deep continuous assurance to shallow periodic monitoring, and open, practitioner-built solutions to closed paradigms. It adds principles: build GRC into systems from the design stage, treat GRC as a product, and base controls on a current understanding of threats.

A community, then SANS

A community has formed around the manifesto: Ayoub Fandi's newsletter The GRC Engineer, a collective blog, and the GRC Engineering Club, a paid community offering cloud labs, training and local chapters in dozens of cities. The SANS Institute, a widely followed cybersecurity training organisation, devoted a webcast to the topic in June 2025, focused on policy as code, then in August 2025 a blog post by AJ Yawn presenting GRC Engineering as using software development, automation and cloud technologies to streamline GRC processes.

A signal from US authorities

On the government side, the US federal cloud authorisation programme launched FedRAMP 20x in March 2025. Its first phase tested automatically validated security indicators that can show a provider's posture in near real time, instead of static annual assessments. It is the most visible application of GRC Engineering ideas by a regulator.

The term covers several practices of varying difficulty. The table below summarises them.

Several technical building blocks are mature. The Open Policy Agent rule language, widely used for policy as code, became a graduated Cloud Native Computing Foundation project in February 2021, the foundation's highest maturity level. In June 2021 NIST released OSCAL 1.0, a set of open formats (XML, JSON, YAML) for describing frameworks, security plans and assessment results in a machine-readable way. And continuous security monitoring has been covered by a NIST guide since 2011.

Note that not all of the movement's advocates put code at the centre. Ayoub Fandi, co-author of the manifesto, sums up his position as "not policy-as-code, policy from code": derive compliance status from the data systems produce, rather than writing policies as code. He presents programming as an asset, not a prerequisite.

Take a requirement found in almost every framework: multi-factor authentication for administrator accounts. In traditional GRC it sits on a spreadsheet line, and someone answers "compliant" once a year with a screenshot. In GRC Engineering it follows a very different path.

1. The rule: the requirement is translated into a verifiable condition ("no account in the administrators group without a second factor").
2. The test: a script queries the directory every day and compares the result with the rule.
3. The evidence: each run produces a dated, stored result that the auditor can consult without asking for screenshots.
4. The dashboard: the result feeds an indicator; a gap opens an action assigned to an owner, and the next test confirms the fix.

This circuit is powerful for repetitive technical controls. It says nothing, however, about whether the rule itself is relevant: it is the risk assessment that determines which accounts to protect and to what level.

Most European CISOs, particularly in hospitals, local authorities and mid-sized companies, have no engineer dedicated to compliance automation. GRC Engineering is still a source of very practical ideas.

1. Write controls, not just requirements

Every important requirement should have an associated control: who performs it, how often, with what expected evidence. This is the most useful step, and it requires no code.

2. Link frameworks together

ISO 27001, NIS 2, DORA, GDPR and your security policy overlap widely. One control linked to several requirements avoids answering the same question five times.

3. Automate first what needs no expertise

Reminders, consolidating answers, calculating compliance rates, generating reports: a GRC platform does this without development, and it is often where most time is lost.

4. Ask for evidence at the source

Instead of a screenshot, ask for the dated export produced by the tool itself. Operations teams often know how to generate it, and some of their tools (directory, patch management, backup) already produce regular reports.

5. Measure outcomes, not activity

"95% of questionnaires returned" measures activity. "Average time to fix critical gaps" measures an outcome. European texts point the same way: Implementing Regulation 2024/2690 requires organisations to determine which measures to monitor, how and when, and DORA requires continuous monitoring of ICT systems.

6. Start small with operations

If your technical teams can write scripts, choose two or three technical controls with them that are easy to automate. What matters most is not the tool but collaboration between GRC and operations, which the manifesto calls a "shared-fate partnership".

• A model born in the cloud. The movement comes from US technology companies, often fully cloud-hosted and subject to attestations such as SOC 2. A hospital information system or a local authority, with older on-premises applications, does not offer the same access points for automation.
• Not everything can be coded. The quality of a risk assessment, staff awareness, crisis management or the relevance of a contract cannot be checked by a script.
• An automated control needs maintenance. A script that no longer runs, or tests the wrong thing, gives false assurance. It needs an owner and a review, like any control.
• Automating a checkbox is still a checkbox. The manifesto itself warns against compliance for show: checking a poorly chosen rule a thousand times reduces no risk.
• Often promotional figures. Much of the literature is published by vendors or trainers; the gains claimed are rarely measured independently.
• Audits remain. ISO 27001 and DORA still require internal audits and management review. GRC Engineering makes them easier; it does not remove them.

GRC Engineering describes a discipline and a profile: the GRC practitioner who can automate. Our GRC Ops guide draws a definition from it for the whole organisation: GRC run continuously, with shared data, evidence collected as you go and steering by indicators, whether automation comes from code or from a platform. To go further, read our articles on continuous compliance, which covers moving from the annual audit to permanent control, on compliance management (method, roles, indicators) and on AI applied to GRC, the logical next step after automation.

To automate reminders, consolidation and indicators without writing code, see our compliance campaigns module.