AI GRC Glossary: All Definitions
AI GRC, cybersecurity and artificial intelligence terms, explained simply. A lexicon to speak the same language across governance, risk and compliance.
AI GRC (Governance, Risk, Compliance through AI)
AI GRC refers to the use of artificial intelligence to speed up governance, risk management and regulatory compliance processes. In an AI GRC platform like Vailor, the AI (LLM, RAG) reads your documents and prefills assessments from cited excerpts, then your experts validate each proposal.
Cyber GRC (Cybersecurity GRC)
Cyber GRC is the application of Governance, Risk, and Compliance principles specifically to the cybersecurity domain. It encompasses cyber risk management, compliance with security standards (ISO 27001, ANSSI, NIS2), and IT security governance.
Governance
Governance refers to all the processes, rules, and practices by which an organization is directed and controlled. In GRC, governance includes policy definition, risk oversight, and regulatory compliance assurance.
Compliance
Compliance refers to adherence to laws, regulations, standards, and internal policies applicable to an organization. In cybersecurity, this includes GDPR, NIS2, ISO 27001, and other security framework compliance.
Risk Assessment
Risk assessment is the process of identifying, evaluating, and prioritizing risks to which an organization is exposed. In cybersecurity, it includes threat identification, vulnerability assessment, and evaluation of potential impact on information assets.
EBIOS RM (Expression des Besoins et Identification des Objectifs de Sécurité - Risk Manager)
EBIOS RM is the reference risk assessment method published by ANSSI (the French National Cybersecurity Agency). It structures the analysis into 5 workshops: scope and security baseline, risk sources, strategic scenarios, operational scenarios, and risk treatment.
Business value
In EBIOS RM, a business value is a component that matters to the organisation in carrying out its mission: a service, a support function, a project stage, a piece of information or know-how. It is identified in workshop 1, together with its owner, and then linked to feared events (loss of availability, integrity or confidentiality) whose severity is assessed. Business values are not technical items: they rely on supporting assets. Choosing them well shapes the rest of the analysis, because they define what you actually want to protect.
Supporting asset
A supporting asset is a component of the information system on which one or more business values rely. In EBIOS RM, it can be digital (server, application, network, cloud service), physical (premises, equipment) or organisational (team, service provider, process). Supporting assets are listed in workshop 1 and become the targets of the attack paths described in the operational scenarios of workshop 4. Most security measures apply to them. An up-to-date inventory of supporting assets, linked to business values, tells you which activity is exposed when a technical component is vulnerable.
Risk source and target objective (RS/TO)
A risk source is a person, group or organisation that could harm the organisation: a state, a cybercriminal, an activist, a competitor, a malicious employee. The target objective is what it is trying to achieve: financial gain, espionage, sabotage, reputational damage. In EBIOS RM workshop 2, you form RS/TO pairs, assess them mainly on the motivation and resources of the source, and keep the most relevant ones. These pairs feed the strategic scenarios of workshop 3. This step steers the analysis towards threats that are plausible in your context rather than a generic list.
Strategic scenario
A strategic scenario describes, at a high level, the path a risk source can take to reach its objective. It is built in EBIOS RM workshop 3 from the selected risk source and target objective pairs. It can go through the ecosystem: a supplier, a service provider, a partner or a customer used as an entry point. Workshop 3 therefore maps stakeholders and their threat level, then assesses the severity of each scenario against the feared events. It is also where first measures on the ecosystem are decided, before attack paths are detailed in operational scenarios.
Operational scenario
An operational scenario details the technical attack path behind a strategic scenario: which supporting assets are targeted and through which elementary actions the attacker progresses. The EBIOS RM guide suggests chaining them in four phases: know, enter, find, exploit. These scenarios are built in workshop 4, often using knowledge bases such as MITRE ATT&CK. Their likelihood is then assessed and, combined with the severity of the related strategic scenario, gives the risk level. The level of detail depends on what is at stake: an operational scenario is a decision tool, not an exhaustive catalogue of attack techniques.
Residual risk
Residual risk is the risk that remains after treatment measures have been applied. No measure brings a risk down to zero, so it has to be estimated, documented and formally accepted by management or by the risk owner. In EBIOS RM, workshop 5 assesses residual risks once the treatment strategy is defined and presents them in a final risk map. In the French public sector, this acceptance is part of the security accreditation process (homologation). Residual risk must be reviewed over time, because the threat, the scope and the effectiveness of measures all change.
Risk treatment plan (action plan)
The risk treatment plan brings together the decision made for each risk: reduce it, share it, avoid it or accept it. It turns into an action plan: concrete measures, an owner, a deadline, a cost and a priority. In EBIOS RM, it takes the form of the continuous security improvement plan (PACS) drawn up in workshop 5. A good plan links each measure to the risks it covers, which helps justify budgets and track how risk goes down. In Vailor, the risk register is linked to the measures of the action plan, with effort in person-days, cost and a priority from P1 to P4.
ISMS (Information Security Management System)
An ISMS is the set of policies, processes, roles and tools through which an organisation manages information security over time. The ISO/IEC 27001 standard sets its requirements: scope definition, risk assessment and treatment, selection of security controls, statement of applicability, internal audits, management review and continual improvement. An ISMS can be certified by an accredited body. Its value goes beyond certification: it gives a stable framework to decide, measure and correct. Risk assessment is what drives it, since it justifies the controls you select.
Information security policy (PSSI)
The information security policy (PSSI in French) is the reference document that sets an organisation's information security objectives, principles and rules. Approved by management, it covers for example access management, information classification, endpoint security, backups, incident management and everyone's responsibilities. It is then broken down into procedures and operational requirements. A security policy is only worth something if its application is checked: its rules must be translated into measurable controls. In Vailor, the client's security policy can be uploaded as a source document for assessments; it is not tracked as a compliance framework.
Security control
A security control is a technical, organisational or physical measure meant to reduce a risk or meet a requirement: multi-factor authentication, access rights review, tested backups, staff awareness. Each framework (NIS2, DORA, NIST CSF, internal security policy) words its own requirements, but many overlap. Hence the value of a unified control framework, which describes each control once and links it to every requirement it covers. That is the principle of the Vailor Control Framework (VCF): one control maintained once, linked to every framework that asks for it.
Compliance evidence
Compliance evidence is a verifiable item that shows a control is actually in place and working: a configuration extract, a scan report, access review minutes, a training certificate, a signed contract. Auditors and regulators rely on evidence, not statements. Good evidence is dated, attached to a specific control, kept with its history and renewed at the right frequency. When several frameworks ask for the same thing, collecting the same evidence several times is costly. In Vailor, evidence is collected once and reused for every relevant framework, through the control it is attached to.
Continuous compliance
Continuous compliance means checking the state of controls regularly, or even automatically, rather than once a year as an audit approaches. It relies on indicators linked to controls, evidence renewed at a defined frequency and, where possible, technical checks connected directly to systems. The compliance as code approach goes further by expressing some requirements as rules that tools can verify. The goal is to detect a gap when it appears, not months later. It requires a stable control framework and a clearly named owner for each control.
NIS2 (EU cybersecurity directive)
NIS2 is Directive (EU) 2022/2555, which raises the common level of cybersecurity across the European Union and replaces the 2016 NIS directive. It widens the scope considerably: essential and important entities in 18 sectors, including energy, health, transport, digital infrastructure and part of manufacturing. Its article 21 requires risk management measures, among them risk analysis, incident handling, business continuity and supply chain security. Article 23 governs the notification of significant incidents. Management bodies must approve these measures and are accountable for them.
DORA (Digital Operational Resilience Act)
DORA is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, applicable since 17 January 2025. It covers banks, insurers, investment firms, payment service providers and many other financial entities. It is built on five pillars: ICT risk management, incident management and reporting, digital operational resilience testing, ICT third-party risk management, and threat information sharing. It also creates a European oversight framework for critical ICT third-party providers. As a regulation, it applies directly, without national transposition.
Third-party risk management (TPRM)
Third-party risk management (TPRM) means identifying, assessing and monitoring the risks brought in by suppliers, service providers and partners that access your data or systems. It covers the whole relationship lifecycle: listing and tiering third parties by criticality, pre-contract assessment, security clauses, ongoing monitoring and exit. NIS2 and DORA make it an explicit requirement. In Vailor, the third-party register linked to the organisation and its assets is available; AI-analysed questionnaires, the contract side and real-time scoring are planned.
Supply chain cyber risk
Supply chain cyber risk covers threats that reach an organisation through its supply chain: a compromised software vendor, a managed service provider whose access is hijacked, an unavailable cloud provider, a vulnerable open source component. Attackers go for the weakest link to reach their real target. Article 21 of the NIS2 directive explicitly lists supply chain security among the required risk management measures. In EBIOS RM, workshop 3 addresses it by mapping the ecosystem and critical stakeholders. The answer lies in third-party risk management and contractual requirements monitored over time.
Security assurance plan (PAS)
The security assurance plan (Plan d'Assurance Sécurité, or PAS, in French practice) is the contractual document in which a service provider describes the security measures it commits to apply to the service: organisation, access management, backups, incident management, audit conditions, reversibility. It is usually annexed to the contract and answers the security requirements set by the client. The ANSSI guide on managing outsourcing risks recommends its use. For the client, the PAS is the reference for checking the provider over time. It is an integral part of third-party risk management.
DORA register of information
The register of information is a DORA requirement (article 28): each financial entity must keep up to date, at entity level as well as at sub-consolidated and consolidated levels, the list of all its contractual arrangements for ICT services provided by third-party providers. It records in particular the provider, the services involved, the functions they support and their criticality. Its format is set by European implementing technical standards. Competent authorities collect it, among other things to identify the critical ICT providers placed under European oversight. It is the foundation of the ICT third-party risk management that DORA requires.
AI-Native
An AI-native architecture means software was designed from the start with artificial intelligence at the core of how it works, rather than added on top of an existing tool. In an AI-native GRC platform like Vailor, the AI works at the heart of the assessment workflow, and every proposal remains subject to an expert's validation.
LLM (Large Language Model)
An LLM (Large Language Model) is a type of artificial intelligence trained on vast text corpora to understand and generate natural language. LLMs like GPT, Claude, or Mistral are used in AI GRC platforms to automate document analysis and content generation.
RAG (Retrieval-Augmented Generation)
RAG is an AI technique that combines information retrieval with text generation. In AI GRC, RAG allows AI to base its responses on the organization's specific documents and data, rather than on general knowledge.
Agentic AI
Agentic AI refers to artificial intelligence systems that can chain several steps to complete a task: plan, call tools, check a result, then try again if needed. Unlike a conversational assistant that answers a question, an agent acts with a degree of autonomy. In GRC, that autonomy has to stay bounded: a risk or compliance decision commits the organisation and must be justifiable to an auditor or a regulator. That is why Vailor's principle is that the AI proposes and your experts decide, with every decision traced.
Digital Sovereignty
Digital sovereignty refers to an organization's or state's ability to control its data and IT systems. In AI GRC, this implies hosting in France/EU, using auditable AI models, and independence from non-European providers.
Multi-tenant
A multi-tenant architecture lets a single software instance serve several customers (tenants) while isolating each one's data. It is the common SaaS model. The most demanding organisations sometimes prefer a dedicated instance or a deployment in their own infrastructure.
Explore AI GRC with Vailor
Our resources on governance, risk and compliance assisted by artificial intelligence.
By role, and to go further
Pages to discover
Recommended articles
ANSSI-labelled EBIOS RM software: the 2026 overview
The EBIOS Risk Manager tools labelled by ANSSI as of 9 October 2026, what the label guarantees, what it does not, and how to check it.
Supply Chain Cyber Risk: How to Manage Your Suppliers
Supply chain cyber risk: what NIS2, DORA and EBIOS RM require, how to map your critical third parties, and what to ask your suppliers before and after signing.
Cyber Risk Assessment: Methodology and Key Steps
How to run a cyber risk assessment: key definitions, steps, scales and matrix, choosing EBIOS RM, ISO 27005 or a flash assessment, and keeping it current.
EBIOS RM vs ISO 27005: Which One Fits Your Project?
EBIOS RM vs ISO 27005: one is the ANSSI risk method, the other a risk management standard. Key differences, when each fits and how to combine them.
An EBIOS RM Case Study: All Five Workshops on One Example
A complete fictional case showing how the five EBIOS RM workshops chain together, what each one produces, and where the work actually stalls.
Complete Guide to AI GRC in 2026
AI GRC explained: definition, real benefits, implementation and good practices for equipping governance, risk and compliance with AI.
How to Choose Your Cyber AI GRC Platform?
The criteria for choosing a cyber AI GRC platform: architecture, sovereignty, GRC expertise, pilot and exit terms. The complete buying guide.
AI-Accelerated EBIOS RM: Practical Guide
How to use artificial intelligence to speed up your EBIOS RM analyses, workshop by workshop, without giving up the rigour of the method.
Top 10 Essential Features of an AI GRC Platform
The 10 features to demand from an AI GRC platform, and how to check them. A checklist to evaluate the solutions on the market.
AI GRC ROI: A Worked Example and Key Metrics
How to calculate the ROI of an AI GRC platform: method, a worked example built on explicit assumptions, and the indicators to track over time.
AI GRC and NIS2: Complete Compliance Guide
How to use an AI GRC platform to reach and maintain NIS2 compliance: scope, requirements, penalties, incident reporting and long-term steering.
Switch to AI GRC with Vailor
You have the vocabulary. Now see how Vailor applies it to your risk assessments and your compliance.