Integrating AI governance into an existing security and privacy framework means extending your current controls, roles, and risk processes to cover the unique characteristics of AI systems — without rebuilding everything from scratch. Most organisations already have a working foundation in ISO 27001 or GDPR compliance, and AI governance builds on that foundation rather than replacing it. If you want to talk through how this applies to your specific situation, feel free to get in touch with us and we will be happy to help. The sections below walk through the most common questions organisations ask when they start this integration.
What gaps appear when AI governance meets existing security and privacy controls?
The most significant gaps appear where AI systems behave in ways that traditional security and privacy controls were never designed to address. Existing frameworks protect data at rest, in transit, and in use — but AI introduces dynamic model behaviour, training data dependencies, and outputs that can cause harm without any security breach occurring. These gaps are structural, not cosmetic.
Specifically, organisations tend to discover three categories of gaps when they first map AI systems against their existing controls:
- Model transparency gaps: Security controls assume deterministic system behaviour. AI models produce probabilistic outputs, and most organisations have no mechanism to audit why a model produced a specific decision or recommendation.
- Data lineage gaps: GDPR controls track personal data flows, but AI governance also requires tracking how training data was collected, labelled, and used — including whether it introduced bias or violated consent at the point of collection, not just at the point of processing.
- Risk ownership gaps: Security and privacy risks are typically owned by defined roles. AI risks — such as model drift, hallucination, or discriminatory output — often fall between existing ownership boundaries, creating accountability vacuums.
Recognising these gaps early prevents organisations from assuming that passing an ISO 27001 audit means their AI systems are governed. It does not. The two frameworks address different threat surfaces, and the intersection between them requires deliberate design.
How does AI governance overlap with ISO 27001 and GDPR?
AI governance overlaps with ISO 27001 and GDPR in meaningful ways, particularly around risk management, data protection, access control, and supplier oversight. ISO 42001 — the international standard for AI management systems — was deliberately designed to be compatible with ISO 27001’s structure, so organisations already certified under 27001 can map a significant portion of their existing controls directly across.
Where ISO 27001 controls carry over to AI governance
ISO 27001 controls covering asset management, access control, incident response, and supplier relationships all apply to AI systems. An AI model is an information asset. The infrastructure it runs on requires access controls. Incidents involving AI outputs — such as a model producing harmful or incorrect decisions — require a structured response process. Third-party AI providers fall under supplier management obligations. None of this requires new control categories; it requires extending existing ones to cover AI-specific scenarios.
Where GDPR obligations extend into AI governance
GDPR already imposes obligations relevant to AI: lawful basis for processing, data minimisation, purpose limitation, and rights of data subjects. AI governance adds specificity to these obligations. Automated decision-making under Article 22 requires organisations to be able to explain decisions made by AI systems that significantly affect individuals. Data protection impact assessments (DPIAs) must be extended to cover not just data flows but model behaviour and output risk. The EU AI Act, which applies in 2026, reinforces and formalises many of these requirements for high-risk AI systems.
What roles and responsibilities does AI governance add to a security team?
AI governance adds three primary responsibilities to a security team’s existing mandate: AI risk assessment, model lifecycle oversight, and AI-specific incident classification. These do not necessarily require new headcount — but they do require existing roles to develop new competencies or be supported by specialists who have them.
In practice, the most important role addition is an AI risk owner — someone accountable for the ongoing risk posture of each AI system in use. This is distinct from the system owner in IT terms. The AI risk owner monitors model performance, flags drift or degraded accuracy, and ensures that risk assessments are updated when the model is retrained or its use case changes.
Security teams also need to extend their third-party risk processes to assess AI vendors and foundation model providers. Evaluating an AI supplier requires different criteria than evaluating a cloud infrastructure provider — questions about training data provenance, model update policies, and explainability capabilities are not covered by standard vendor questionnaires.
Finally, incident response teams need a classification category for AI-related incidents. A model producing systematically biased outputs, or a generative AI tool leaking confidential information through its context window, are incidents that require response — but they do not fit neatly into existing breach or vulnerability categories. Defining these classifications in advance avoids confusion when an incident occurs.
How do you map AI risks to an existing risk register?
Mapping AI risks to an existing risk register works best by treating each AI system as a risk subject and then assessing it across four dimensions: data risk, model risk, output risk, and compliance risk. These dimensions align with the categories most risk registers already use, which makes integration straightforward without requiring a separate AI risk register.
Start by inventorying every AI system in use — including third-party tools, embedded AI features in SaaS platforms, and internally developed models. For each system, assess:
- Data risk: What personal or sensitive data does the system process? Is the training data documented and compliant with applicable data protection obligations?
- Model risk: How is the model maintained? Who is responsible for detecting and responding to model drift or degraded performance?
- Output risk: What decisions or actions does the model’s output influence? What is the potential harm if the output is incorrect, biased, or manipulated?
- Compliance risk: Does the system qualify as high-risk under the EU AI Act? Does it perform automated decision-making subject to GDPR Article 22?
Each of these assessments produces a risk entry that can sit alongside existing information security and privacy risks in your register. The risk owner, likelihood, impact, and treatment columns remain the same. What changes is the nature of the threats being assessed — which is exactly what a risk register is designed to accommodate.
Which AI governance controls can reuse existing security and privacy evidence?
A substantial portion of AI governance controls can reuse existing security and privacy evidence, particularly in the areas of access management, data classification, incident response, and supplier due diligence. Organisations that have already invested in ISO 27001 certification or GDPR compliance documentation do not need to start from zero — they need to extend and annotate what already exists.
Specific examples of evidence reuse include:
- Access control logs already collected for ISO 27001 can serve as evidence that access to AI models and training data is restricted to authorised personnel.
- Data processing records maintained under GDPR Article 30 can be extended to include AI-specific processing activities, training data sources, and automated decision-making processes.
- Supplier assessment documentation used for third-party risk management can be adapted to cover AI vendors, with additional criteria for model governance and explainability.
- Incident response procedures can be updated to include AI-specific incident types without replacing the underlying process.
- Business continuity and change management records apply directly to AI model updates, retraining events, and deployment changes.
The controls that genuinely require new evidence are those specific to AI: algorithmic impact assessments, model cards, bias testing results, and human oversight mechanisms. These have no direct equivalent in security or privacy frameworks — but they represent a minority of the total control set, not the majority.
When should AI governance be managed as a continuous system rather than a project?
AI governance should be managed as a continuous system from the moment an organisation deploys AI in a context that affects people, processes, or regulated data — which, for most organisations, is immediately. Project-based governance creates a dangerous illusion of completeness: the project closes, the documentation is filed, and the AI system continues to evolve without oversight. Continuous governance prevents that drift.
The case for continuous governance rests on three characteristics unique to AI systems. First, AI models change over time — through retraining, fine-tuning, or simply because the data they process shifts in distribution. A risk assessment completed at deployment may be outdated within months. Second, the regulatory environment for AI is actively evolving. The EU AI Act introduced new obligations in 2026, and organisations that treat compliance as a one-time project will find themselves repeatedly out of step. Third, AI incidents are often slow-moving and cumulative — biased outputs, gradual accuracy degradation, or subtle data leakage do not trigger alarms the way a security breach does. Only continuous monitoring catches them.
This is the principle behind how we approach governance at Moatt. Our governance services are built as subscription-based, always-active systems rather than periodic engagements — because governance that switches off between audits is not governance. It is documentation. For organisations subject to NIS2, ISO 27001, ISO 42001, GDPR, or the EU AI Act, the difference between a project and a system is the difference between periodic compliance and genuine operational readiness.
If your organisation is ready to move from project-based AI governance to a continuous model, contact us and we can help you map out exactly what that looks like for your existing framework.
Frequently Asked Questions
How long does it typically take to integrate AI governance into an existing ISO 27001 or GDPR framework?
The timeline depends heavily on the number of AI systems in use and the maturity of your existing controls, but most organisations can complete an initial integration in 3–6 months. This typically involves inventorying AI systems, mapping gaps, extending the risk register, and updating key documentation such as DPIAs and supplier assessments. The ongoing maintenance — monitoring, reassessment, and regulatory updates — is then managed continuously rather than as a separate project.
What's the best way to get started if we have no formal AI governance in place yet?
The most practical starting point is an AI system inventory: catalogue every AI tool in use across the organisation, including third-party SaaS platforms with embedded AI features. From there, apply the four-dimension risk assessment (data, model, output, and compliance risk) to each system to identify your highest-priority gaps. This gives you a defensible, evidence-based starting point without requiring a full framework overhaul before you can begin.
Do we need to achieve ISO 42001 certification, or is aligning with it informally sufficient?
Formal ISO 42001 certification is not mandatory unless required by a regulator, client contract, or sector-specific obligation — but aligning with its structure is valuable regardless. The standard provides a proven control set and maps cleanly onto ISO 27001, making it a practical reference even for organisations that pursue alignment without certification. If your organisation is subject to the EU AI Act's high-risk system requirements, however, formal certification may become increasingly expected as a demonstration of compliance.
How do we handle AI governance for third-party AI tools we don't control, like foundation model APIs?
Third-party AI tools should be treated as a subset of your existing supplier risk management process, extended with AI-specific due diligence criteria. Key questions to add to vendor assessments include how training data is sourced and documented, what the provider's model update and deprecation policy is, whether the model's outputs are explainable, and how the provider handles data submitted via the API. Where a provider cannot answer these questions satisfactorily, that gap should be recorded as a risk entry and mitigated through contractual controls or usage restrictions.
What's the most common mistake organisations make when first implementing AI governance?
The most common mistake is scoping AI governance only around internally developed models and overlooking the far larger footprint of third-party and embedded AI tools already in use across the business. Many organisations discover mid-implementation that their exposure is primarily through SaaS platforms, productivity tools, and API-connected services — not bespoke models. Starting the process with a thorough AI system inventory, including shadow AI usage, prevents this blind spot from undermining the entire governance effort.
How should we handle AI governance when our AI systems are retrained or significantly updated?
Model retraining and significant updates should be treated as change management events that trigger a reassessment of the relevant risk register entries, not just a technical deployment process. At minimum, the AI risk owner should review whether the update changes the system's output risk, data processing scope, or compliance classification — particularly in relation to GDPR Article 22 and EU AI Act risk tiers. Change management records from your existing ISO 27001 controls can be extended to capture this review without creating a parallel process.
How does the EU AI Act interact with existing GDPR obligations for organisations already compliant with GDPR?
The EU AI Act and GDPR are complementary but address different risks: GDPR governs the processing of personal data, while the AI Act governs the development and deployment of AI systems based on their risk level and use case. For organisations already GDPR-compliant, the most immediate practical overlap is in high-risk AI systems subject to both Article 22 automated decision-making requirements and the AI Act's conformity assessment obligations. Existing DPIAs should be reviewed and extended to cover AI Act requirements, and documentation of human oversight mechanisms will serve as evidence under both frameworks.