Glossary

The compliance terms that matter, in plain English.

74 definitions across data protection, security and resilience, risk and governance, and AI regulation. No jargon, no legal advice.

Data protection & privacy

Adequacy decision: A formal determination by the European Commission (or, for the UK, the government) that a non-EEA country, territory or sector ensures a level of data protection essentially equivalent to the GDPR. Where one exists, personal data can flow to that destination freely without additional safeguards such as standard contractual clauses. Adequacy decisions are periodically reviewed and can be challenged or revoked, so reliance on them carries some ongoing uncertainty.
Breach notification: The GDPR obligation to report a personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals. Where the breach is likely to result in a high risk, affected individuals must also be told without undue delay. All breaches must be documented internally even when no report is required, so the regulator can verify the assessment. See the GDPR guide.
Consent: A lawful basis requiring a freely given, specific, informed and unambiguous indication of the individual's wishes, given by a clear affirmative action such as ticking an unticked box. Consent must be as easy to withdraw as to give, cannot be bundled into terms and conditions, and silence or pre-ticked boxes do not count. Because it can be withdrawn at any time, organisations should avoid relying on consent where another basis fits better. See the GDPR guide.
Data (Use and Access) Act 2025 (DUAA): The Data (Use and Access) Act 2025 is the UK statute, given Royal Assent on 19 June 2025, that reforms the UK GDPR, the Data Protection Act 2018 and PECR rather than replacing them. It introduces a list of recognised legitimate interests that need no balancing test, a revised automated decision-making regime (Articles 22A to 22D), a 'stop the clock' rule for data subject access requests, changes to cookies and direct marketing under PECR, a reformed regulator (the Information Commission), and a new duty on controllers to facilitate and handle data protection complaints (Data Protection Act 2018 section 164A). Its provisions commence in phases: SI 2026/82 brings several into force from 5 February 2026, with the section 164A complaints duty applying from 19 June 2026. See the GDPR guide.
Data controller: The organisation or person that determines the purposes and means of processing personal data, in other words who decides why and how the data is used. The controller carries primary accountability for compliance, including choosing a lawful basis, honouring individual rights and responding to breaches. Two or more parties that jointly decide purposes and means are joint controllers and must agree how they split responsibilities. See the GDPR guide.
Data minimisation: A core GDPR principle requiring that personal data collected and processed be adequate, relevant and limited to what is necessary for the stated purpose. In practice it means not gathering data on a just-in-case basis and not retaining more fields than the task requires. It reduces both compliance risk and breach exposure, since data you do not hold cannot be lost or misused. See the GDPR guide.
Data processor: A third party that processes personal data on behalf of, and on the documented instructions of, a controller, such as a cloud host or payroll provider. A processor must not use the data for its own purposes and is bound by a written contract under GDPR Article 28 setting out security and confidentiality duties. Processors have their own direct obligations and can be fined, but the controller remains accountable for choosing a processor that offers sufficient guarantees. See the GDPR guide.
Data Protection Impact Assessment (DPIA): A structured assessment, required by GDPR Article 35, of the risks a processing activity poses to individuals and the measures taken to mitigate them. It is mandatory where processing is likely to result in a high risk, for example large-scale profiling, systematic monitoring of public areas or large-scale use of special category data. If a high risk remains after mitigation, the organisation must consult its supervisory authority before going ahead. See the GDPR guide.
Data Protection Officer (DPO): An independent expert role required under GDPR Article 37 for public authorities and for organisations whose core activities involve large-scale systematic monitoring or large-scale processing of special category data. The DPO advises on compliance, monitors it, trains staff and acts as a contact point for individuals and the supervisory authority. They must report to the highest management level, be free from conflicts of interest, and cannot be penalised for performing the role. See the GDPR guide.
Data Subject Access Request (DSAR): A request by an individual to obtain a copy of the personal data an organisation holds about them, together with supplementary information such as the purposes, recipients and retention periods. Under GDPR it must usually be answered within one month, free of charge, with limited grounds to extend, refuse or charge for manifestly unfounded or excessive requests. Handling DSARs correctly is a common compliance pressure point because deadlines are tight and exemptions, such as third-party data, must be applied carefully. See the GDPR guide.
Data subject rights: The set of rights GDPR gives individuals over their personal data: access, rectification, erasure (the right to be forgotten), restriction of processing, data portability, objection, and rights relating to automated decision-making and profiling. Most rights are not absolute and are subject to conditions and exemptions, and requests generally must be handled within a month. Organisations need processes to recognise, verify and action these requests across all the systems where data lives. See the GDPR guide.
General Data Protection Regulation (GDPR): The EU regulation (Regulation 2016/679) that governs how organisations collect, use, store and share personal data about individuals in the EU and EEA. It sets out core principles, a set of individual rights, accountability obligations and a lawful-basis requirement for all processing. It matters because non-compliance can attract fines of up to 20 million euros or 4 percent of global annual turnover, whichever is higher, and it applies extraterritorially to organisations outside the EU that target or monitor people in it. See the GDPR guide.
International data transfer: The transfer of personal data to a country outside the EEA (or, under UK rules, outside the UK), including remote access and use of overseas cloud or support providers. Such restricted transfers are only lawful if covered by an adequacy decision, an appropriate safeguard such as standard contractual clauses or binding corporate rules, or a specific derogation. Following the Schrems II ruling, organisations must also assess the laws and practices of the destination and add supplementary measures where needed. See the GDPR guide.
Lawful basis: The legal justification an organisation must have to process personal data; GDPR Article 6 sets out six and at least one must apply: consent, contract, legal obligation, vital interests, public task, or legitimate interests. The basis should be identified and documented before processing begins, and it shapes which individual rights apply. Choosing the right basis matters because you generally cannot swap to another one later to justify the same processing. See the GDPR guide.
Legitimate interest: A lawful basis allowing processing that is necessary for the legitimate interests of the controller or a third party, provided those interests are not overridden by the individual's rights, interests or reasonable expectations. Relying on it requires a documented three-part legitimate interests assessment (LIA) weighing purpose, necessity and balance. It is the most flexible basis but also the most accountability-heavy, and individuals retain the right to object. See the GDPR guide.
Personal data: Any information relating to an identified or identifiable living individual, such as a name, email address, location data, an online identifier or factors specific to that person. Data is personal even if identification requires combining it with other information that is reasonably likely to be available. The concept is deliberately broad because it defines the scope of what data protection law protects. See the GDPR guide.
Personal data breach: A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. It covers far more than hacking, including lost laptops, misdirected emails, ransomware and unavailability of data. Identifying that an incident is a personal data breach is the trigger for assessing risk to individuals and deciding whether notification obligations apply. See the GDPR guide.
Privacy and Electronic Communications Regulations (PECR): UK rules, derived from the EU ePrivacy Directive, that govern electronic marketing, cookies and similar tracking technologies, and the security and confidentiality of electronic communications. PECR sits alongside the UK GDPR and often sets a stricter standard, for example requiring consent before placing non-essential cookies or sending most marketing emails and texts. It is enforced by the ICO and applies even where no personal data is involved, such as cookies set on a device.
Privacy notice: The transparency information an organisation must give individuals about how it uses their personal data, covering who the controller is, the purposes and lawful bases, recipients, retention, international transfers and the individual's rights. GDPR Articles 13 and 14 specify what must be included depending on whether the data is collected directly from the person or from another source. It must be concise, clear and accessible, and is sometimes also called a privacy policy or fair processing notice. See the GDPR guide.
Purpose limitation: A core GDPR principle that personal data must be collected for specified, explicit and legitimate purposes and not further processed in a way incompatible with those purposes. New uses generally need to be compatible with the original purpose, or require a fresh lawful basis and notice to the individual. It prevents function creep, where data quietly gets reused for things people never agreed to or expected. See the GDPR guide.
Records of Processing Activities (RoPA): A documented inventory, required by GDPR Article 30, of the personal data processing an organisation carries out, covering purposes, categories of data and individuals, recipients, transfers, retention periods and security measures. Controllers and processors must keep one, with a narrow exemption for some smaller organisations, and provide it to the regulator on request. It is a foundational accountability record that also underpins DPIAs, breach assessments and responses to individual rights requests. See the GDPR guide.
Special category data: A subset of personal data that is more sensitive and carries extra protection: data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for identification, and data concerning health, sex life or sexual orientation. Processing it is prohibited unless one of the specific conditions in GDPR Article 9 applies, in addition to having a normal lawful basis. Criminal offence data is treated under a separate, similarly strict regime. See the GDPR guide.
Standard Contractual Clauses (SCCs): Pre-approved model contract terms that provide a lawful safeguard for transferring personal data to countries without an adequacy decision. The EU adopted modernised SCCs in 2021, and the UK uses its own International Data Transfer Agreement (IDTA) or an addendum to the EU clauses. Using SCCs generally also requires a transfer risk assessment to confirm the data will be adequately protected in practice in the destination country.
UK GDPR: The version of the GDPR that the UK retained in domestic law after leaving the EU, sitting alongside the Data Protection Act 2018. It mirrors the EU GDPR closely but is enforced by the Information Commissioner's Office (ICO) and can diverge over time, for example through the Data (Use and Access) Act 2025. Organisations operating in both the UK and the EU often need to satisfy both regimes and may need a representative in each. See the GDPR guide.

Security & resilience

Business continuity: Business continuity is an organisation's capability to keep delivering critical products and services at acceptable levels during and after a disruptive event, supported by a documented business continuity plan. Planning usually starts with a business impact analysis to identify critical activities and their tolerable downtime, then defines workarounds, alternate sites and recovery procedures. It matters for compliance because resilience regimes such as DORA and operational resilience rules expect tested, maintained continuity arrangements rather than plans that exist only on paper.
Critical ICT third-party provider (CTPP): A critical ICT third-party provider (CTPP) is an ICT service provider that the European Supervisory Authorities designate as systemically important to the EU financial sector, typically large cloud or core technology vendors many firms depend on. Once designated, a CTPP comes under a direct EU oversight framework led by a Lead Overseer, which can examine it, issue recommendations and request information. The regime exists to address concentration risk, so that the failure of one widely used provider does not threaten financial stability. See the DORA guide.
Digital operational resilience: Digital operational resilience is an organisation's ability to build, assure and review the integrity and reliability of its ICT systems so it can keep delivering critical services through disruptions, including cyberattacks and technology failures. It is the central concept of DORA, which treats resilience as an outcome achieved through ICT risk management, incident handling, resilience testing and third-party oversight working together. The goal is not just preventing incidents but absorbing, adapting to and recovering from them with minimal harm to customers and markets. See the DORA guide.
Digital Operational Resilience Act (DORA): DORA is an EU regulation (Regulation (EU) 2022/2554) that sets uniform rules for how financial entities manage information and communication technology (ICT) risk so they can withstand, respond to and recover from ICT disruptions. It applies from 17 January 2025 and covers banks, insurers, investment firms, crypto-asset providers and many other regulated firms, plus the critical ICT providers that serve them. Its requirements span ICT risk management, incident reporting, resilience testing, third-party risk and information sharing, making it a single consolidated rulebook for operational resilience in EU finance. See the DORA guide.
Essential and important entities: Essential and important entities are the two categories of organisation that fall within the scope of the NIS2 Directive, based on their sector, size and criticality. Essential entities operate in highly critical sectors such as energy, transport, banking, health and digital infrastructure, while important entities cover other sectors NIS2 designates, including areas like postal services, waste management and certain manufacturing. Both must meet the same cybersecurity risk-management and reporting duties, but essential entities face stricter, proactive supervision whereas important entities are generally supervised reactively after an incident. See the NIS2 guide.
ICT risk management: ICT risk management is the structured process of identifying, assessing, mitigating and monitoring risks to an organisation's information and communication technology systems, data and services. It typically covers governance, asset and dependency mapping, protection and prevention controls, detection, response and recovery, and continuous learning. Under DORA it is a formal, board-owned framework that financial entities must document, maintain and review, and it underpins almost every other operational-resilience obligation. See the DORA guide.
ICT third-party risk: ICT third-party risk is the exposure an organisation takes on when it relies on external providers such as cloud, software, data or managed-service vendors to deliver or support its technology. Managing it means assessing providers before contracting, securing the right contractual safeguards, monitoring performance and concentration, and planning for exit or substitution. DORA gives this its own detailed chapter, requiring financial entities to keep oversight of all ICT service providers and to address dependency and concentration risk across their supply chain. See the DORA guide.
Incident response: Incident response is the organised approach to detecting, containing, investigating, eradicating and recovering from a security or operational incident, then capturing lessons learned. A defined incident response plan assigns roles, escalation paths and communication steps so the organisation reacts consistently under pressure rather than improvising. It matters for compliance because frameworks such as DORA, NIS2 and GDPR impose specific handling, recording and regulator or data-subject notification duties once an incident occurs.
ISO/IEC 27001: ISO/IEC 27001 is the leading international standard for an information security management system (ISMS), a risk-based framework for managing the confidentiality, integrity and availability of information. It requires an organisation to assess its risks, select and document controls (drawing on the Annex A control set detailed in ISO/IEC 27002) and continually improve the system. Organisations can be independently certified against it, which is often used to demonstrate sound security governance to customers, partners and regulators.
NIS2 Directive: NIS2 (Directive (EU) 2022/2555) is the EU's updated cybersecurity law for network and information systems, replacing the original 2016 NIS Directive with a wider scope and tougher requirements. It obliges in-scope organisations to take risk-management measures, report significant incidents and ensure senior management accountability for cybersecurity. Because it is a directive, it takes effect through each member state's national transposition, so the precise rules and supervisory authority vary by country. See the NIS2 guide.
Operational resilience: Operational resilience is an organisation's broader ability to prevent, adapt to, respond to, recover from and learn from operational disruptions to its important business services, whether the cause is technology, people, processes or third parties. In UK financial services it is a specific regulatory regime from the PRA and FCA requiring firms to identify important business services, set impact tolerances and remain within them through severe but plausible scenarios. It is wider than cybersecurity and overlaps with, but is distinct from, DORA's more ICT-focused digital operational resilience.
Recovery point objective (RPO): The recovery point objective (RPO) is the maximum amount of data, measured as a period of time, that an organisation can afford to lose in a disruption, which in practice sets how recent the last usable backup must be. A one-hour RPO, for example, means backups or replication must capture data at least every hour so that no more than an hour's work is lost. RPO and RTO are usually defined together for each critical service to size backup frequency and recovery architecture appropriately.
Recovery time objective (RTO): The recovery time objective (RTO) is the maximum acceptable length of time a system, application or business process can be unavailable after a disruption before the impact becomes unacceptable. It sets the target by which services must be restored and drives decisions about backup, failover and disaster-recovery design and spend. Defining realistic RTOs for critical services is a standard part of business continuity and ICT resilience planning, and they are commonly tested to confirm they can actually be met.
Register of information: The register of information is a structured inventory that financial entities must maintain under DORA listing all their contractual arrangements with ICT third-party service providers. It records details such as the services received, the providers and any subcontractors, which functions they support and whether those functions are critical or important. Firms must keep it current and submit it to competent authorities, which use the aggregated data to map dependencies and concentration risk across the financial system. See the DORA guide.
SOC 2: SOC 2 is an attestation report, defined by the AICPA, in which an independent auditor evaluates how a service organisation's controls meet one or more Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. A Type I report assesses control design at a point in time, while a Type II report tests operating effectiveness over a period, usually several months. It is widely requested by customers performing vendor due diligence, particularly for cloud and SaaS providers, as evidence that controls over their data are in place and working.
Threat intelligence sharing: Threat intelligence sharing is the voluntary or organised exchange of information about cyber threats, indicators of compromise, attack techniques and mitigations between organisations, often through industry groups or ISACs. The aim is to help peers detect and defend against attacks earlier by learning from incidents others have already faced. DORA explicitly encourages financial entities to exchange cyber threat information within trusted communities, and effective sharing usually depends on agreed protocols, trust and data-protection safeguards.
Threat-led penetration testing (TLPT): Threat-led penetration testing (TLPT) is an advanced, intelligence-driven security test that simulates the tactics, techniques and procedures of real adversaries against an organisation's live production systems. Under DORA, designated financial entities must carry out TLPT at least every three years, conducted by qualified testers and aligned with the European TIBER-EU framework. It goes well beyond routine vulnerability scanning by testing people, processes and technology together to reveal how the organisation would fare against a genuine targeted attack. See the DORA guide.
Vulnerability management: Vulnerability management is the ongoing process of discovering, assessing, prioritising, remediating and verifying weaknesses in software, systems and configurations before attackers can exploit them. It combines scanning, risk-based prioritisation (often using severity ratings such as CVSS), patching or mitigation, and tracking to closure. It is a baseline expectation in security frameworks like ISO 27001 and SOC 2 and a core protective measure under DORA and NIS2 risk-management requirements.

Risk & governance

Attestation: A formal sign-off in which a named person confirms that a control, policy or statement is in place and accurate, usually at set intervals. Attestations create accountability by tying a specific individual to a specific assertion at a specific date. They are widely used for confirming policy acknowledgement, control ownership and the ongoing operation of key controls.
Audit trail: A chronological, tamper-evident record of who did what and when, capturing the sequence of actions, approvals and changes affecting a process or system. It lets an organisation reconstruct events after the fact and prove that required steps were followed. A reliable audit trail is essential evidence for internal audit, external auditors and regulatory investigations.
Compliance programme: The overall framework of policies, procedures, controls, training, monitoring and governance through which an organisation meets its legal and regulatory obligations. A mature programme assigns clear ownership, operates on a continuous cycle of assessment and improvement, and is championed from the top. Regulators frequently look to the design and effectiveness of a compliance programme when judging whether an organisation took reasonable steps to comply.
Control: A safeguard, policy, procedure or technical measure put in place to reduce a risk or to meet a legal or regulatory obligation. Controls can be preventive (stopping something happening), detective (spotting it when it does) or corrective (fixing it afterwards). The effectiveness of controls is what brings inherent risk down to residual risk.
Control testing: The process of checking that a control is both designed properly and operating effectively over a period, rather than merely existing on paper. Testing methods range from inspecting documents and re-performing a process to sampling transactions and observing the control in action. Regular testing produces the evidence that internal audit, external auditors and regulators rely on to confirm controls actually work.
Evidence: The documents, records, screenshots, logs and other artefacts that demonstrate a control is operating or an obligation has been met. Evidence is what turns a claim of compliance into something an auditor or regulator can verify independently. Collecting and retaining it systematically is central to audits, certifications and regulatory examinations.
Gap analysis: A structured comparison between what is currently in place and what a standard, regulation or obligation requires, in order to identify where the organisation falls short. The output is a list of gaps, often prioritised by severity, that feeds a remediation plan. Gap analysis is a common first step when adopting a new framework or preparing for a regulatory deadline.
Governance, Risk and Compliance (GRC): An integrated approach that aligns an organisation's governance (how decisions are made and oversight is exercised), risk management (identifying and treating threats to objectives), and compliance (meeting legal, regulatory and internal-policy requirements). Treating these as one connected discipline avoids duplicated effort and conflicting controls across functions. GRC is often supported by dedicated software that gives leadership a single, consistent view of obligations, risks, controls and evidence.
Horizon scanning: The systematic monitoring of laws, regulations, regulator guidance and wider developments to spot changes that may affect the organisation before they take effect. It gives compliance and risk teams lead time to assess impact and prepare, rather than reacting once a rule is already in force. Effective horizon scanning feeds directly into regulatory change management and forward planning.
Inherent risk: The level of risk that exists before any controls or mitigating actions are taken into account, in other words the raw or gross exposure. It reflects how serious a threat would be in its natural state. Assessing inherent risk first helps an organisation decide how much control effort a given risk justifies.
Materiality: A threshold for deciding whether an issue, error or risk is significant enough to warrant attention, disclosure or reporting. Something is material if it could reasonably influence the decisions or judgement of a relevant audience, such as regulators, auditors or stakeholders. Setting materiality helps an organisation focus effort on what genuinely matters rather than treating every item as equally urgent.
Policy management: The lifecycle of creating, approving, publishing, communicating and periodically reviewing an organisation's internal policies and procedures. It includes version control, tracking who has read and acknowledged each policy, and ensuring policies stay current as requirements change. Strong policy management gives staff clear, up-to-date rules to follow and provides evidence that those rules were properly approved and circulated.
Register: A maintained list that records items of a particular kind together with their key attributes, so they can be tracked, owned and reviewed over time. Common examples in governance include the risk register, the records of processing activities, and registers of policies, controls or incidents. Keeping an accurate register is a basic discipline that underpins oversight and provides a ready record for audits and regulators.
Regulatory change management: The disciplined process of identifying changes in laws and regulations, assessing how they affect the organisation, and implementing the necessary updates to policies, controls and processes. It turns a detected change into tracked, accountable actions with owners and deadlines. Done well, it ensures the organisation stays compliant as the regulatory landscape shifts and can evidence that it responded in time.
Regulatory obligation: A specific requirement imposed on an organisation by a law, regulation or regulator that it must satisfy, such as notifying a breach within a set time or keeping particular records. Obligations are the concrete building blocks that a compliance programme is organised around. Mapping each obligation to the controls and evidence that satisfy it is how an organisation demonstrates compliance.
Residual risk: The level of risk that remains after existing controls and mitigations have been applied. It represents the exposure the organisation is actually carrying day to day. Comparing residual risk against the organisation's risk appetite shows whether a risk has been treated adequately or needs further action.
Risk appetite: The amount and type of risk an organisation is willing to accept in pursuit of its objectives, usually set and approved by the board or senior leadership. It provides a benchmark against which individual risks and decisions can be judged as acceptable or not. A clearly stated appetite, sometimes broken down into more granular risk tolerances, keeps risk-taking consistent across the organisation.
Risk assessment: The process of identifying risks, analysing their likelihood and potential impact, and evaluating them against the organisation's risk appetite to decide how they should be treated. It is the structured judgement step that turns raw threats into prioritised, actionable decisions. Risk assessments underpin the risk register and are often a direct regulatory requirement for higher-risk activities.
Risk register: A structured record of the risks an organisation has identified, each typically described with an owner, likelihood and impact ratings, existing controls, and a treatment plan. It is the central tool for tracking risks from identification through to mitigation and review. A well-maintained register lets management prioritise effort and demonstrate to auditors and regulators that risks are being actively managed.
Three lines of defence: A governance model that separates responsibility for managing risk into three layers: the first line (operational management who own and manage risks day to day), the second line (risk and compliance functions that set policy and oversee the first line), and the third line (internal audit, which provides independent assurance). Keeping these roles distinct avoids conflicts of interest and gives the board confidence that risks are being managed and independently checked. The model was updated by the Institute of Internal Auditors in 2020 into a more flexible three lines model, but the original term remains in common use.

AI & emerging regulation

AI governance: AI governance is the framework of policies, roles, processes and controls an organisation uses to direct and oversee the responsible development, procurement, deployment and monitoring of AI throughout its lifecycle. It typically includes an AI inventory, risk classification, model and use-case approval gates, accountability and oversight roles, documentation, testing and monitoring, and incident handling, and it is often aligned to standards such as ISO/IEC 42001 or frameworks like the NIST AI Risk Management Framework. It matters in GRC because it is the operating model that turns external requirements, including the EU AI Act and data protection law, into repeatable internal controls and auditable evidence rather than ad hoc decisions.
AI literacy: AI literacy is the set of skills, knowledge and understanding that lets people who develop, deploy or are affected by AI make informed decisions about it and appreciate its opportunities, risks and possible harms. The EU AI Act places a direct obligation on providers and deployers to take measures ensuring a sufficient level of AI literacy among their staff and others operating AI systems on their behalf, taking account of those people's roles, context and the affected groups. It is one of the Act's earliest-applying obligations and is not limited to high-risk systems. For GRC teams this means training, role-appropriate guidance and evidence of those measures are a baseline compliance requirement, not an optional good practice. See the EU AI Act guide.
Algorithmic transparency: Algorithmic transparency is the practice of being open about when and how algorithmic or AI systems are used, what data and logic drive them, and what effects they have, so that affected people, regulators and oversight bodies can understand and scrutinise them. It spans concrete obligations, such as informing people they are interacting with an AI system, labelling AI-generated or manipulated content, and providing meaningful information about the logic of automated decisions, as well as broader accountability practices like public reporting. In the UK, mechanisms such as the Algorithmic Transparency Recording Standard apply to public-sector use. It matters because transparency is a precondition for contestability, redress and trust, and several specific transparency duties are directly enforceable under the AI Act and data protection law.
Automated decision-making (ADM): Automated decision-making is the making of a decision by technological means without meaningful human involvement, and it carries specific legal weight under data protection law as well as the AI Act. Under the GDPR and the UK GDPR, individuals have a right not to be subject to a decision based solely on automated processing, including profiling, that produces legal or similarly significant effects, subject to limited exceptions and with safeguards such as a right to human intervention, to express a point of view and to contest the decision. It matters in GRC because solely automated significant decisions trigger heightened transparency, lawful-basis and safeguard duties, and many high-impact uses overlap with high-risk classification under the AI Act. See the GDPR guide.
CE marking for AI: CE marking for AI is the conformity mark that a provider affixes to a high-risk AI system under the EU AI Act to indicate that it conforms with the Act's requirements and, where relevant, other applicable EU harmonisation legislation. It is applied only after the system has passed the required conformity assessment and the provider has drawn up the EU declaration of conformity, and for systems without a physical form the mark may appear digitally. It matters in GRC because the CE marking is the visible signal of market access in the EU: without it, a high-risk system cannot lawfully be placed on the market, and an unjustified or missing mark exposes the provider to enforcement. See the EU AI Act guide.
Conformity assessment: Conformity assessment is the process of verifying and demonstrating that a high-risk AI system meets the EU AI Act's applicable requirements before it is placed on the market or put into service. Depending on the system, it is carried out either through an internal self-assessment by the provider or, for certain cases such as some biometric systems, through a third-party notified body. A successful assessment underpins the EU declaration of conformity and the affixing of the CE marking, and it must be repeated when the system is substantially modified. It matters in GRC because it is the formal gateway that converts the Act's technical and documentation requirements into a defensible, auditable record of compliance. See the EU AI Act guide.
EU AI Act: The EU AI Act (Regulation (EU) 2024/1689) is the first comprehensive horizontal law regulating artificial intelligence, applying a risk-based approach that sorts AI systems into unacceptable, high, limited and minimal risk tiers with proportionate obligations for each. It applies extraterritorially to providers and deployers whose AI systems are placed on the EU market or whose outputs are used in the EU, regardless of where they are established. Obligations phase in over time, with prohibited practices and AI literacy duties applying first and most high-risk system requirements following later. It matters for GRC because non-compliance carries fines of up to 35 million euros or 7 percent of global annual turnover, whichever is higher. See the EU AI Act guide.
Fundamental rights impact assessment (FRIA): A fundamental rights impact assessment is an assessment, required of certain deployers of high-risk AI systems under the EU AI Act, that examines the potential impact on people's fundamental rights before the system is put into use. It typically covers the intended purpose and context of use, the categories of people and groups likely to be affected, the specific risks of harm to them, the human oversight measures in place, and the steps to take if those risks materialise. The duty falls on deployers such as public bodies and certain private operators providing public services, and it sits alongside, and can build on, a data protection impact assessment. It matters in GRC because it shifts part of the accountability burden onto deployers and creates a documented, rights-focused record that regulators can request. See the EU AI Act guide.
General-purpose AI (GPAI) model: A general-purpose AI model is an AI model, typically a large foundation or generative model, that displays significant generality and can competently perform a wide range of distinct tasks and be integrated into many downstream systems. The EU AI Act sets a dedicated tier of obligations for GPAI model providers, including technical documentation, information for downstream developers, a policy to respect EU copyright law, and a public summary of training content. Models judged to carry systemic risk, broadly the most capable, face additional duties such as model evaluation, adversarial testing, incident reporting and cybersecurity measures. This matters because the obligations attach at the model layer and flow down the AI value chain to everyone building on top of these models. See the EU AI Act guide.
High-risk AI system: Under the EU AI Act, a high-risk AI system is one that poses a significant risk to health, safety or fundamental rights, identified either because it is a safety component of a regulated product or because it falls within listed use cases such as biometric identification, critical infrastructure, education, employment, access to essential services, law enforcement, migration and the administration of justice. Providers of high-risk systems must meet requirements covering risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness and cybersecurity before market entry. Deployers also carry duties, including monitoring use and, in some cases, conducting impact assessments. Correctly classifying a system as high-risk is the pivotal compliance decision because it triggers the heaviest obligations in the regime. See the EU AI Act guide.
Model risk: Model risk is the risk of adverse outcomes arising from decisions based on models that are incorrect, misused or applied outside their intended scope, including errors in design, data, assumptions or implementation. The concept originates in financial services model risk management, notably US supervisory guidance such as SR 11-7, which calls for sound development, independent validation and ongoing monitoring across the model lifecycle, and it now extends naturally to AI and machine-learning models. For GRC teams it matters because AI systems concentrate model risk in ways that can be opaque, drift over time and scale harm quickly, so validation, monitoring and clear ownership are essential controls.
Prohibited AI practice: Prohibited AI practices are the uses of AI that the EU AI Act bans outright because they are deemed to pose an unacceptable risk, including subliminal or manipulative techniques that cause harm, exploitation of vulnerabilities, certain social scoring, untargeted scraping of facial images to build recognition databases, emotion inference in workplaces and schools, and most real-time remote biometric identification in public spaces by law enforcement. These prohibitions were among the first provisions of the Act to take effect. They matter in GRC because they are not a matter of mitigation or documentation: a banned practice cannot be made compliant, so organisations must screen AI uses against the list and discontinue or never deploy anything that falls within it. See the EU AI Act guide.

RegSpace

Turn these terms into a working compliance programme.

RegSpace monitors the regulators behind every one of these, scores your policies for gaps, and keeps the registers current.

Book a demo