Acronym glossary

BIA · Business Impact Analysis

Key question: What are the impacts of a disruption?

A method to identify an organisation’s critical processes, activities and resources, the consequences of their disruption and the acceptable recovery delays.

DIMA · Durée d’Interruption Maximale Admissible (maximum admissible interruption duration)

Key question: Beyond what duration does a process disruption become unacceptable?

French term for the total duration beyond which the disruption of a business process causes unacceptable consequences: financial, regulatory, operational, contractual or reputational.

Derived from the BIA, the DIMA expresses a business tolerance. It must not be copied as-is into the RTO: the recovery objective has to be validated against business needs and technical capabilities.

MTPD · Maximum Tolerable Period of Disruption

Key question: What is the absolute maximum time a critical activity can remain disrupted?

The longest period an organisation can accept a critical process, activity or service being unavailable before the consequences become unacceptable, severe or irreversible.

The MTPD is set during the BIA from business, financial, regulatory, contractual, operational and reputational impacts. It is a business tolerance limit, not a technical recovery target.

The RTO must be shorter than the MTPD to leave room for recovery, verification and the return to an acceptable service level. French acronyms sometimes mapped to this notion (DMTP, DMIA or DIMA depending on the edition) are not interchangeable without checking the reference framework.

MBCO · Minimum Business Continuity Objective

Key question: What minimum level of activity must be maintained or restored during a disruption?

The minimum acceptable level of products, services or activities an organisation must be able to maintain or restore during a disruption.

The MBCO expresses a minimum business capacity, such as a transaction volume, a number of cases processed or a priority service scope. It complements the time-based objectives:

• the MTPD sets the limit beyond which disruption becomes unacceptable;
• the RTO gives the target recovery time;
• the RPO caps acceptable data loss;
• the MBCO defines the minimum activity level to reach during or after recovery.

BCP · Business Continuity Plan

Key question: How do we keep critical activities running during a crisis?

A document defining the measures, responsibilities and procedures used to maintain or quickly restore critical activities during a disruption or crisis.

DRP · Disaster Recovery Plan

Key question: How do we restore systems after a disaster?

A document describing the procedures and resources needed to restore systems, applications and data after a major incident. In IT it is often treated together with the ITDRP.

ITDRP · Information Technology Disaster Recovery Plan

Key question: How do we restore IT systems?

Describes the procedures, responsibilities, technical resources and priorities needed to restore information systems after a major incident.

RTO · Recovery Time Objective

Key question: How quickly must we recover?

The maximum acceptable time a system, application or process may remain unavailable after a disruption.

RPO · Recovery Point Objective

Key question: How much data loss is acceptable?

The maximum amount of data it is acceptable to lose, expressed as a duration. For example, a 4-hour RPO means no more than the last 4 hours of data may be lost.

SPOF · Single Point of Failure

Key question: Which single component could take the service down?

A component whose failure alone can interrupt a system, service or activity. Identifying SPOFs makes it possible to add redundancy and reduce availability risks.

CMDB · Configuration Management Database

Key question: Where are information system components and their relationships recorded?

A repository centralising information system components, called Configuration Items (CIs), with their attributes and relationships. It supports asset management, impact analysis and incident and change handling.

iPaaS · Integration Platform as a Service

Key question: How do we connect and orchestrate applications, data and services?

A cloud platform used to connect applications, data, APIs and services, then design, run, monitor and govern their integration flows.

It usually provides connectors, transformation and orchestration mechanisms, plus monitoring and error-handling features.

Sources: IBM — iPaaS

ADR · Architecture Decision Record

Key question: How do we document an architecture decision and its consequences?

A short, versioned document recording a significant decision about a system: its context, the options considered, the chosen decision, its status and its consequences.

An ADR preserves the reasoning behind a choice, avoids reopening the same debate and eases review, evolution or replacement of the decision. It usually contains:

• the context and the problem to solve;
• constraints and decision criteria;
• the options studied and their trade-offs;
• the chosen decision;
• consequences, risks and follow-up actions;
• a status: proposed, accepted, rejected, superseded or deprecated.

An ADR can capture security requirements and trade-offs: threat model, authentication and authorisation, encryption, logging, secrets management, network exposure, dependencies, compliance, resilience and residual risks. It does not replace a risk analysis but keeps its conclusions. Not to be confused with ADR “Application Detection and Response”.

Sources: adr.github.io

KPO · Key Performance Objective

Key question: Which priority outcome are we trying to achieve?

A priority outcome an organisation, team or system aims to achieve. The KPO sets the target and intent; KPIs measure progress towards it.

KPI · Key Performance Indicator

Key question: Which measure tracks performance against an objective?

A quantifiable measure used to track the performance of an activity, process or service against a defined objective. A KPI should state its calculation method, source, measurement frequency, target and owner.

Sources: ISO 22400-2

SLO · Service Level Objective

Key question: Which internal reliability or performance target must the service meet?

An internal, measurable target over a given period for a service level indicator, for example 99.9% availability over 30 days. The SLO drives reliability management and is usually stricter than the related SLA.

Sources: Google Cloud — SRE fundamentals

SLA · Service Level Agreement

Key question: Which service level is formally agreed with users or partners?

A formal commitment between a service provider and its users or partners. It defines the expected service level, the measurement period, responsibilities, exclusions and any consequences of non-compliance.

Sources: Google Cloud — SRE fundamentals

DICA · Disponibilité, Intégrité, Confidentialité, Authentification (availability, integrity, confidentiality, authentication)

Key question: Which core criteria protect systems and data?

The French counterpart of the CIA triad. The DIC model defines three core properties; the DICA variant adds authentication. Some frameworks use DICP or DICAN, which add proof, traceability or non-repudiation.

• Availability: systems and data are accessible when needed by authorised people.
• Integrity: data is not modified or altered accidentally or maliciously.
• Confidentiality: only authorised people can access the data.
• Authentication: the identity of users, services or systems is verified; proof and traceability then make it possible to attribute and trace actions.

Sources: Visiativ — DICP · SecuriteInfo.com — DICAN

SCIM · System for Cross-domain Identity Management

Key question: How do we automate the identity lifecycle between an identity provider and applications?

An open standard for identity management. Built on HTTP, REST and JSON, SCIM automates the exchange of identity data and account lifecycle between an identity provider (IdP) and a service provider such as a SaaS application. It is used to:

• provision an account automatically when someone joins;
• update attributes, groups and permissions when their situation changes;
• quickly disable or delete access when they leave;
• synchronise users and groups across systems.

SCIM reduces orphaned accounts, manual operations and access revocation delays. It complements authentication and federation protocols such as SAML or OpenID Connect without replacing them.

Sources: IETF RFC 7644

DLP · Data Loss Prevention

Key question: How do we prevent data leakage or loss?

A set of rules, controls and tools that detect and prevent unauthorised use, exfiltration or sharing of sensitive data.

WORM · Write Once, Read Many

Key question: How do we guarantee data immutability?

Immutable storage: data is written once and cannot be modified or deleted during a defined retention period. It protects backups, logs and records subject to retention requirements.

ADR · Application Detection and Response

Key question: How do we detect and handle application incidents?

An approach and tooling used to identify abnormal behaviour or incidents affecting applications, then analyse and respond to them.

Not to be confused with ADR “Architecture Decision Record”.

IoC · Indicator of Compromise

Key question: Which clues reveal a potential or confirmed compromise?

An observable artefact that may signal a potential or confirmed compromise of a system, account or network: a malicious file hash, an IP address or domain linked to malicious activity, a suspicious file or a characteristic log entry.

IoCs are used to detect, hunt and analyse malicious activity. They must be read in context: a single indicator is not always proof of compromise.

SoD · Separation (or Segregation) of Duties

Key question: How do we split sensitive responsibilities?

An internal control principle that splits responsibilities across several people so that nobody can perform every step of a sensitive operation alone, for example initiating, approving and executing a transaction.

AppSec · Application Security

Key question: How do we build security into the whole application lifecycle?

A holistic approach that embeds security throughout an application’s lifecycle (design, development, testing, deployment and operations) rather than treating it as a one-off check at the end. It combines complementary practices:

• SCA: inventories third-party components and dependencies and looks up their known vulnerabilities;
• SAST: analyses code or artefacts without running the application;
• DAST: tests a running application from the outside;
• IAST: observes the application’s internal behaviour during execution and tests;
• code review, threat modelling and penetration testing: complementary human, contextual analysis.

No single technique covers every risk: combining them covers dependencies, source code, the deployed application and its runtime behaviour.

SCA · Software Composition Analysis

Key question: Which vulnerabilities affect third-party components and dependencies?

A method to inventory the libraries, packages and third-party components of an application, then identify their known vulnerabilities, outdated versions and potential licence risks. SCA can feed an SBOM and plug into CI/CD pipelines or runtime analysis.

SAST · Static Application Security Testing

Key question: Which flaws can be found in code without running it?

Analysis of source code, bytecode or artefacts without running the application. SAST detects issues such as injections, insecure data flows or validation errors early, usually during development or in CI/CD.

DAST · Dynamic Application Security Testing

Key question: Which flaws appear when the application is running?

Analysis of a running application by sending requests and simulating attacks from the outside, without access to the source code. DAST reveals vulnerabilities tied to real behaviour, configuration or interactions between components.

IAST · Interactive Application Security Testing

Key question: Which vulnerabilities appear while the application runs and is tested?

A method that analyses a web application while it runs to identify vulnerabilities from its internal behaviour and from the interactions generated by manual or automated tests.

IAST combines in-application instrumentation with observation of requests, data flows and the code actually executed. It provides contextual results: the vulnerability location, the execution path involved and the data concerned.

SSRF · Server-Side Request Forgery

Key question: How do we stop a server from issuing unauthorised network requests?

A web vulnerability that lets an attacker trick a vulnerable server into sending unauthorised network requests to internal or external systems.

It can expose internal services that are normally unreachable from the Internet or bypass some network controls.

Sources: OWASP — SSRF

CVE · Common Vulnerabilities and Exposures

Key question: Which unique identifier designates a publicly listed vulnerability?

A unique reference (for example CVE-2021-44228) assigned to a known security flaw so it can be cited and tracked consistently across tools and organisations.

Sources: CVE.org

CVSS · Common Vulnerability Scoring System

Key question: What is the theoretical technical severity of a vulnerability (0 to 10)?

A 0–10 score computed by the vendor or the NVD from technical criteria: exploitability, potential impact, complexity and attack vector. It rates the theoretical severity of a vulnerability, regardless of whether it is actually exploited.

Sources: FIRST — CVSS

EPSS · Exploit Prediction Scoring System

Key question: How likely is a vulnerability to be exploited in the next 30 days?

A statistical estimate published by FIRST, from 0 to 100%, of the probability that a vulnerability will be exploited in the next 30 days. It complements CVSS: a CVE can have a high CVSS but a low EPSS if it is not exploited in practice.

Sources: FIRST — EPSS

KEV · Known Exploited Vulnerabilities

Key question: Which vulnerabilities are confirmed to be actively exploited in the wild?

A catalogue maintained by CISA (US agency) of CVEs with confirmed active exploitation, to be handled as top priority. Each entry carries a remediation due date binding on US federal agencies; while not binding elsewhere, it is the closest external reference to a recognised standard for auditors and cyber insurers.

Sources: CISA — KEV catalog

DPA · Data Processing Agreement

Key question: How do we contractually frame personal data processing carried out by a processor?

A contract or set of clauses governing the processing of personal data by a processor on behalf of a controller. Under the GDPR it specifies in particular:

• the subject matter, duration, nature and purposes of the processing;
• the categories of personal data and data subjects;
• the controller’s documented instructions;
• confidentiality obligations and security measures;
• the conditions for engaging sub-processors;
• assistance with data subject rights, incidents and impact assessments;
• return or deletion of data at the end of the service;
• audit rights and evidence of compliance.

The DPA mainly formalises the GDPR Article 28 obligations between controller and processor. It must not be confused with the DPIA.

Sources: GDPR — Regulation (EU) 2016/679

DPIA · Data Protection Impact Assessment

Key question: How do we assess and reduce the high risks a processing poses to people’s rights and freedoms?

A structured process to identify, assess and reduce the risks that personal data processing poses to the rights and freedoms of data subjects. It usually describes:

• the planned processing, its purposes and legal basis;
• its necessity and proportionality;
• the risks to data subjects;
• the technical and organisational measures planned to reduce those risks;
• residual risks and the decision to accept them or take further action.

Required by GDPR Article 35 when processing is likely to result in a high risk. If a high risk remains despite the planned measures, the supervisory authority must be consulted before processing starts. Not to be confused with the DPA, which is a contractual agreement.

Sources: GDPR — Regulation (EU) 2016/679

DORA · Digital Operational Resilience Act

Key question: Which European framework governs digital operational resilience?

EU regulation on digital operational resilience. It governs information and communication technology risk management in the financial sector, including the insurance undertakings in scope.

Sources: Regulation (EU) 2022/2554

PRA · Prudential Regulation Authority

Key question: Which authority supervises the UK financial sector?

The UK prudential regulator, part of the Bank of England. It carries out the prudential supervision of banks, insurers and other financial institutions in scope.

Not to be confused with the French PRA, Plan de Reprise d’Activité, the equivalent of a DRP.

Sources: Bank of England — PRA