CIA+EFT: The Integrated AI Security Framework UK Boards Should Be Asking About

UK boards are asking a question their technical teams cannot answer cleanly: how secure is our AI? The reason it cannot be answered cleanly is that the question itself is split across two frameworks that were never designed to meet. Traditional security controls protect data and infrastructure; AI governance frameworks address bias, transparency and oversight. Between them sits a seam where regulatory exposure now lives.

CIA+EFT is QL Security’s proprietary integrated approach that extends the classical CIA triad (Confidentiality, Integrity, Availability) with three AI-specific dimensions (Explainability, Fairness, Traceability). It gives boards, CISOs and governance leads one coherent vocabulary for AI security risk and is designed to align with the controls UK organisations already have to evidence under ISO 42001 and the EU AI Act. CIA+EFT is an internal assurance vocabulary; it has not been certified, endorsed or recognised by ISO, EU AI Act supervisory bodies, the ICO or any other regulatory authority.

Treating AI security as either a classical infosec problem or a standalone governance problem leaves a measurable gap. CIA+EFT closes that gap by treating both as one assurance question, owned end to end.

Why the traditional CIA triad falls short for AI systems

The CIA triad is necessary but insufficient for AI. It protects the system; it does not interrogate the model’s behaviour.

Confidentiality, Integrity and Availability are foundational to information security. They work well for what they were built for: protecting data at rest and in transit, ensuring infrastructure behaves predictably and keeping services online. Apply them to a database, a network or an application and the controls map cleanly: encryption, access management, change control, backup, monitoring.

Apply them to a production AI system and most of the model-specific failure modes fall outside the frame. A loan-decision model can be perfectly confidential, with intact training data and 99.9% uptime, and still produce discriminatory outcomes that could engage obligations under the Equality Act 2010. A clinical triage model can pass every classical security control and still make decisions no clinician can justify to a patient. A document-summarisation tool integrated with Microsoft Copilot can be fully patched, fully logged and still drifting quietly over six months until its outputs no longer reflect the source material.

None of these failures are CIA failures. They are model-behaviour failures, and they are the failures regulators, journalists and claimants are now focused on.

Inside most UK organisations the technical security team owns CIA, the data protection officer owns parts of fairness, an emerging AI governance function owns policy and no one owns the seam where a regulator’s question actually lands: can you prove this AI system behaved correctly, fairly and explicably on the date the complaint refers to?

Introducing CIA+EFT: the integrated framework explained

CIA+EFT is one framework that combines the classical CIA triad with three additional dimensions specific to AI systems: Explainability, Fairness and Traceability. It matters because AI systems fail in ways traditional security cannot detect or prevent, such as biased outputs, unexplained decisions or untraceable model drift. UK boards need a single vocabulary that covers both classical and AI-specific risk, and CIA+EFT provides it.

The six dimensions are not ranked. They are assured in parallel, against the same AI system, by named owners with named controls. The framework is deliberately additive rather than replacing CIA, because the classical controls remain necessary; an AI system whose training data is exfiltrated has a confidentiality failure regardless of how explainable its outputs are.

The six dimensions:

Confidentiality, Integrity, Availability: the classical triad, applied to training data, model weights, prompts, inference logs and the surrounding pipeline, with the established controls of access management, tamper detection and resilience.
Explainability: outputs can be justified to the audience that needs the justification, whether that is a regulator, a customer or an internal reviewer.
Fairness: outcomes are equitable across protected and operationally relevant groups, measured and monitored over time.
Traceability: the organisation can reconstruct what the model did, on what inputs, using which version and why, for any decision within a defined retention window.

The value of the integrated framing is operational. A board does not have to choose between a security conversation and a governance conversation. It has one assurance conversation with six dimensions, and gaps surface as missing controls in specific cells of a unified matrix rather than as disputes between functions.

How EFT addresses AI-specific failure modes

The EFT dimensions address failure modes that classical security controls cannot detect, prevent or remediate.

Explainability

Explainability is the ability to justify a model’s output to the audience that needs the justification. The audience matters: the explanation a data scientist needs to debug a model is not the explanation a complaints handler needs to respond to a customer, which is not the explanation a regulator needs to close an investigation.

Failure mode: opaque reasoning. A model produces a high-stakes decision (denial of credit, refusal of a benefit, prioritisation in a clinical queue) and no one in the organisation can articulate why, in terms the affected party would accept. Classical security controls do not address this; the system was secure, it just cannot be defended.

Control examples: documented model cards, output-level explanation methods appropriate to model type, role-specific explanation interfaces and an escalation route for cases where the standard explanation is insufficient.

Fairness

Fairness is the property that outcomes are equitable across groups, where the relevant groups are defined by law (such as protected characteristics under the Equality Act 2010), by contract or by operational risk.

Failure mode: embedded bias. A model trained on historical data reproduces the biases of that data, often without anyone in the organisation noticing until an external party does. Classical integrity controls confirm the training data was not tampered with; they do not interrogate whether the untampered data encodes discriminatory patterns.

Control examples: pre-deployment bias assessment, defined fairness metrics with thresholds, ongoing monitoring against those metrics in production and a documented remediation path when thresholds are breached.

Traceability

Traceability is the audit dimension: the ability to reconstruct, after the fact, what a model did and why. It is the dimension that fails first in most UK organisations, and the reason is structural rather than technical.

Classical IT environments evolved alongside decades of audit expectation. Versioned source control, change tickets, database transaction logs and access logs exist because auditors asked for them year after year. AI systems are newer, and the equivalent evidence infrastructure has rarely been built in from the start.

A model that has been retrained four times over twelve months, served from a container that has been redeployed weekly, against inputs that have drifted in distribution and downstream of upstream data pipelines that have themselves changed, can become unreconstructible within months of going live.

The failure mode is silent. The service is up. The accuracy metric on the current dashboard looks acceptable. Six months later a regulator asks about a specific decision made on a specific date for a specific customer, and the organisation cannot say which model version produced it, on what inputs, with what configuration, against which fairness thresholds. Classical availability controls kept the service running; they did not preserve the evidence trail.

Control examples sit across three layers. At the model layer: versioned model registries with immutable lineage from training data through to deployed artefact. At the inference layer: capture of inputs, outputs, model version and configuration sufficient to reproduce any individual decision, retained for a period defined by regulatory exposure rather than by storage cost. At the monitoring layer: drift detection on input distributions, output distributions and performance metrics, with alerting thresholds and a documented response path when drift is material.

Retrofitting traceability is the hardest of the three EFT dimensions, because evidence that was not captured at the time cannot be reconstructed later. Organisations that delay this work are, in practical terms, accepting that any regulator request landing before the gap is closed will be answered with apology rather than evidence.

Mapping CIA+EFT onto ISO 42001 and the EU AI Act

CIA+EFT is not a replacement for ISO 42001 or the EU AI Act; it is an internal assurance vocabulary designed to make both easier to evidence. It is not a certified or recognised compliance methodology.

The mapping at a glance:

Confidentiality, Integrity, Availability map to ISO 42001’s inherited information security clauses and to the EU AI Act’s cybersecurity and robustness requirements for high-risk systems.
Explainability maps to ISO 42001’s transparency and information-provision controls and to the EU AI Act’s transparency and human oversight obligations.
Fairness maps to ISO 42001’s impact assessment and data governance controls and to the EU AI Act’s data governance and risk management requirements.
Traceability maps to ISO 42001’s lifecycle documentation, oversight and continual improvement controls and to the EU AI Act’s record-keeping and technical documentation obligations.

The EU AI Act has extraterritorial reach under Article 2, which sets out a provider and deployer nexus test. UK organisations may fall in scope where they place AI systems on the EU market, or where they act as providers or deployers within the scope tests in Article 2(1). The precise application to UK organisations is subject to ongoing interpretive guidance and depends on the facts of each case; UK readers should take independent legal advice on their own position.

For UK organisations the practical benefit is consolidation. One CIA+EFT control matrix, populated per AI system, is designed to help generate the evidence organisations need to demonstrate readiness for ISO 42001 certification, EU AI Act conformity assessment where applicable, internal assurance aligned with UK GDPR obligations and sector-specific obligations such as those in the FCA/PRA Model Risk Management Principles for Banks (May 2023) or the NHS Digital Technology Assessment Criteria (subject to current version). CIA+EFT does not constitute a UK GDPR compliance methodology recognised by the ICO.

The alternative (maintaining one control set for security, another for AI governance, another for data protection, another for sector compliance) is the situation most UK organisations are in today, and it is the situation CIA+EFT is designed to replace.

Three questions UK boards should be asking right now

A board does not need to learn the framework in detail. It needs three questions that surface whether the framework, or something equivalent, is actually in place.

First: which AI systems are in scope, and what is their risk classification?

Most UK organisations do not have a complete inventory of AI systems in use. Embedded AI in third-party tools, shadow AI used by individual employees and AI features added to existing software through vendor updates all expand the estate without formal recognition. Without an inventory, no framework applies, because there is nothing for it to apply to. The board’s question forces the inventory.

Second: how is each CIA+EFT dimension assured in production, with named controls and named owners?

This is the question that exposes the seam. A confident answer names a specific control, a specific owner and specific evidence for each dimension on each in-scope system. A vague answer (“the security team handles security and the governance team handles governance”) is the gap.

Third: who owns the evidence when a regulator, customer or auditor asks for it?

Evidence ownership is the dimension organisations most often defer until the request arrives. By that point the conversation about which team owns which artefact is happening under time pressure, with a regulator waiting. The board’s question forces the ownership to be assigned in advance.

What an integrated AI security programme looks like in practice

An integrated programme has four characteristics that distinguish it from the fragmented approach most UK organisations currently operate.

One: one AI system inventory with risk classification. Every AI system, whether built in-house, procured or embedded in third-party tools, appears in one inventory with a documented risk classification driven by the use case, not the technology.

Two: a control matrix covering all six CIA+EFT dimensions. Each system is assessed against each dimension. Gaps are visible as empty cells with named remediation owners and target dates.

Three: named ownership across the seam. For each dimension on each system, one person owns the control and one person owns the evidence. The CISO does not own fairness alone; the DPO does not own traceability alone; the AI governance lead does not own explainability alone.

Four: evidence produced as a by-product of operation. Inference logs, fairness metrics, explanation records, model version histories and access logs are generated continuously, retained according to a defined policy and retrievable on demand. Evidence assembled retrospectively for an audit is evidence that is incomplete.

Reaching this state from a typical fragmented starting position is not a short project. It begins with a gap analysis against CIA+EFT, prioritises the highest-risk systems and sequences remediation against board-approved risk appetite.

Key questions on adopting an integrated AI security framework

Is CIA+EFT a replacement for NIST AI RMF or a complement to it?

CIA+EFT is complementary. NIST AI RMF is a risk management framework defining functions (govern, map, measure, manage) widely used as a process backbone. CIA+EFT is an assurance vocabulary that names the dimensions along which AI systems must be controlled and evidenced. Organisations using NIST AI RMF can adopt CIA+EFT as the language in which their measure and manage outputs are expressed, without replacing the surrounding process.

How long does it take to implement a CIA+EFT assessment across an existing AI estate?

For a focused estate with a workable starting inventory, an initial CIA+EFT assessment is typically a matter of weeks rather than months. Organisations without a current AI inventory should expect the inventory phase to take longer than the assessment itself, because shadow AI and embedded AI in third-party tools have to be surfaced before they can be assessed. Actual scope and duration are confirmed per engagement.

Which CIA+EFT dimension typically fails first in UK organisations?

Traceability. Classical security controls give organisations some coverage of CIA, and the visibility of bias risk has pushed many to begin work on Fairness. Traceability fails first because it requires evidence infrastructure (versioned model registries, immutable logging, retention policies) that often does not exist at all for AI systems. The first regulator request for reconstruction is usually the moment the gap becomes visible.

Can CIA+EFT be applied retrospectively to AI systems already in production?

Yes, with caveats. Most dimensions can be assessed and remediated against systems already in production, including adding fairness monitoring, improving explanation interfaces and tightening access controls. Traceability is the dimension with the strongest retrospective limit: evidence that was not captured at the time cannot be reconstructed later. Retrospective adoption typically draws a line, assures forward from that point and accepts a documented gap behind it.

Where to start

If you are responsible for AI security, governance or risk in a UK organisation and the three board questions in this post do not yet have confident answers, the next step is a gap analysis against CIA+EFT to see exactly where the seam sits in your environment.

Book a 30-minute AI Security Gap Analysis call with our team. We will walk through how CIA+EFT maps against your current AI estate. You will leave with a view of where the most material gaps are likely to be and what a sequenced remediation programme would look like for your risk profile.

Related services: AI Governance and ISO 42001 readiness and AI Risk Assessment for UK organisations.

For more, see our CIA+EFT Framework FAQ and the related glossary entries for CIA Triad, AI Explainability, AI Fairness, AI Traceability and AI Governance.

This post is provided for general information only and does not constitute legal, regulatory or compliance advice. Organisations should seek independent legal counsel regarding their specific obligations under the EU AI Act, UK GDPR, the Equality Act 2010, ISO 42001 and any sector-specific regulatory regime.