Assess. Implement. Assure. The QL Security Methodology

The QL Security methodology is a three-phase approach for moving an AI estate from undefined risk to defensible assurance in a single engagement arc. Assess identifies gaps against ISO 42001 and the EU AI Act. Implement embeds controls and behavioural guardrails into live systems. Assure produces continuous evidence that boards and auditors accept. This is the AI security methodology we use to take a CISO from a position they cannot defend to one they can.

Most organisations approach AI security as a sequence of disconnected tasks: a policy here, a tooling decision there, an audit scramble when a regulator or an enterprise customer asks the hard question. The result is an estate where governance, technical security and audit evidence sit in separate workstreams that never reconcile. Our methodology exists to close that gap. It treats assurance as the operating model the first two phases were built to feed, not a final-stage scramble.

Why CISOs need a defined methodology, not a checklist, for AI security

A checklist tells you what to inspect. A methodology tells you how risk moves through your organisation and what to do at each stage. That distinction matters because AI estates accumulate risk faster than most security teams can codify controls. New models, new integrations and new user behaviours arrive weekly and a static list cannot keep pace with a moving estate.

The AI security methodology we run is built around a single arc with three named phases, each with a fixed output. That structure gives a CISO something a checklist never can: a defensible narrative. When the board asks where AI risk stands, the answer is not a list of half-finished tasks. It is a clear position on the arc, with a gap report behind you, controls embedded in live systems and continuous evidence flowing to the people who need to sign it off.

The three phases connect deliberately. Assess defines the gap, Implement closes it and Assure proves it stays closed. Each phase produces an output the next phase consumes, which is why audit readiness becomes a state the programme maintains rather than a deadline the team races toward. A checklist cannot deliver that, because its items have no dependency on one another; our phases do.

Phase one, Assess: gap analysis against ISO 42001 and the EU AI Act

Assess produces a prioritised gap report mapped to ISO 42001 and the EU AI Act. The phase establishes where your AI estate currently sits against recognised frameworks, what is missing and which gaps carry the most risk. The output is a document a CISO can take to a board, an auditor or an insurer and use as the factual basis for everything that follows.

This is the AI security assessment framework that anchors the whole engagement. We work through the estate systematically: which AI systems exist, who owns them, what data they touch, how they are governed and where control coverage is thin or absent. We map each finding to a specific clause in ISO 42001 and to the relevant obligations under the EU AI Act, so the gap report speaks the language regulators and auditors already use.

Prioritisation is the part that earns its keep. A raw list of gaps tells you everything is broken; a prioritised report tells you what to fix first and why. We rank findings by risk and by the effort required to close them, so Implement starts with a sequenced plan rather than a backlog. That sequencing is what turns an assessment into the first step of a programme rather than a standalone audit that gathers dust.

The deliberate framing here is that Assess is built to feed Implement. We do not produce a gap report and walk away. Every finding is written to be actionable in the next phase, with enough specificity that the controls work can begin without re-discovering the same ground.

Phase two, Implement: embedding controls, guardrails and behaviour verification

Implement embeds technical controls, behavioural guardrails and governance routines into your live systems. The phase takes the prioritised gaps from Assess and closes them in the operational environment, not in a document. The output is an estate where controls are deployed, guardrails are active and behaviour is verified against what those controls are supposed to enforce.

The ISO 42001 implementation methodology we follow treats controls as something that must live inside operational systems to count. We deploy technical controls into the systems that handle AI workloads, set guardrails that constrain what those systems can do and establish the governance routines that keep both maintained as the estate changes.

Behaviour verification is the part many programmes skip. It is not enough to deploy a control; you have to confirm it behaves as designed under real conditions. We verify that guardrails fire when they should, that controls hold when tested and that governance routines produce the records the next phase needs. This work is what makes Assure possible, because you cannot generate credible evidence about controls you have never confirmed are working.

Implement is sequenced from the prioritised gap report, which means the highest-risk gaps close first. By the end of the phase, the estate has left the undefined-risk state Assess documented. It has controls a CISO can point to, guardrails that constrain AI behaviour and a verification record that proves both.

Phase three, Assure: continuous evidence for boards, auditors and regulators

Assure runs continuous monitoring and evidence generation, so audit readiness becomes a state the programme maintains rather than a deadline. Running Assure as an ongoing engagement is exactly what makes this a partner relationship rather than a one-off consultant assessment. The phase produces continuous evidence that AI controls are working as designed and that risks sit within tolerance. The output is an audit trail that withstands scrutiny from regulators, insurers and enterprise procurement teams.

This is what AI assurance for CISOs means in practice. Assurance is the continuous production of evidence, not a one-off certificate. For a CISO reporting to the board, it delivers a defensible position built on documented governance, tested controls, monitored behaviour and an audit trail that holds up when someone asks hard questions. The board gets a clear answer about whether AI risk is under control, backed by evidence rather than assertion.

The continuous part is the point. Because Assess produced the framework mapping and Implement produced verified controls, Assure has everything it needs to generate evidence on an ongoing basis. Monitoring runs against the controls Implement deployed; evidence is produced against the frameworks Assess mapped. Nothing has to be reconstructed under deadline pressure, because the first two phases were built to feed this one.

How the three phases connect: why assurance is designed in, not bolted on

Assurance is designed in from phase one because Assess maps to the same frameworks Assure reports against and Implement verifies the same controls Assure monitors. The three phases share a common spine, which is why evidence flows continuously rather than being assembled at the end. This shared spine is the structural difference between a methodology and a sequence of separate projects, and it is the single feature that most changes a CISO’s position.

Consider what happens when assurance is bolted on instead. A team runs an assessment, implements some controls and then, months later, tries to assemble audit evidence. The assessment used one framework, the controls were chosen against another and the evidence has to be reverse-engineered to fit whatever the auditor asks for. The workstreams never reconcile, and the CISO is left defending a position the underlying work does not actually support. Each handover loses fidelity, and the cost of recovering it lands precisely when the regulator or the enterprise customer is already waiting.

Our arc avoids that by aligning the three phases on the same frameworks and the same controls from the start. Assess maps to ISO 42001 and the EU AI Act; Implement deploys against those mappings; Assure reports against them. Because every artefact is produced in the form the next stage and the eventual auditor expect, the board-level narrative is backed by evidence that was designed to support it rather than retrofitted to it. That is what makes readiness a property of the programme itself, not a heroic effort layered on top of it.

What a typical engagement arc looks like across the three phases

A typical engagement moves through Assess, Implement and Assure as a single arc with handovers built in. Assess opens the engagement and produces the prioritised gap report. Implement consumes that report and embeds controls into live systems. Assure takes over once controls are verified and runs continuously from there.

The arc is designed so each phase hands the next exactly what it needs. Assess hands Implement a sequenced, prioritised plan. Implement hands Assure a set of verified controls and a behaviour-verification record. Assure produces continuous evidence that feeds straight into board reporting and audit response. The CISO experiences this as one programme with a clear trajectory rather than three procurements stitched together.

The value of running all three in a single arc is that nothing is lost between phases. There is no re-scoping, no re-discovery or reconciliation of mismatched workstreams. The AI governance programme approach we use keeps the same framework mappings and the same controls visible from the first day of Assess to the continuous operation of Assure.

Key questions on the Assess, Implement, Assure methodology

How long does each phase of the methodology typically take? Duration depends on the size and complexity of the AI estate. Assess is scoped to the number of AI systems in use and the depth of framework mapping required. Implement scales with the number and severity of gaps the assessment surfaces. Assure is continuous by design, so it has no end date; it becomes the operating state the programme maintains. We size each phase against your estate during the methodology walkthrough.

Can we start at Implement if we already have an assessment from another provider? In principle yes, but Implement depends on the prioritised gap mapping that Assess produces. If an existing assessment maps cleanly to ISO 42001 and the EU AI Act and prioritises gaps by risk, it can feed Implement directly. If it does not, we run a focused Assess to produce the mapping Implement needs, because Implement cannot embed controls reliably against gaps that were never mapped to a recognised framework.

How does Assure integrate with our existing SOC and GRC tooling? Assure is built to produce evidence against the frameworks Assess mapped and the controls Implement deployed, and that evidence is designed to feed the tooling you already run. Where you have a SOC and GRC stack, Assure supplies the continuous monitoring outputs and evidence records those systems consume, so audit readiness is maintained inside your existing operating model rather than alongside it.

What makes this methodology auditor-ready by design? Auditor readiness comes from the shared spine across the three phases. Because Assess maps to the same frameworks Assure reports against, and Implement verifies the same controls Assure monitors, the evidence an auditor asks for already exists in the form they expect. Nothing has to be reconstructed, which is what makes readiness a maintained state rather than a deadline.

Who in the organisation owns each phase? The CISO owns the arc, but each phase touches different teams. Assess engages system and data owners to establish the current state. Implement works with the engineering and operations teams who run the live systems controls are embedded into. Assure works with the governance, risk and audit functions who consume the continuous evidence. The methodology keeps these teams aligned on the same framework mappings throughout.

Does the methodology cover only generative AI or the whole AI estate? The methodology applies to the whole AI estate. Assess inventories every AI system in scope, not only generative models, and maps each against ISO 42001 and the EU AI Act. Implement and Assure then cover the controls and evidence for that full estate, so the board-level position reflects all AI risk rather than a single category of it.

What happens after Assure is running? Assure is the steady operating state, so what happens after it begins is continuous: monitoring runs, evidence is produced and the audit trail stays current as the estate changes. When the estate shifts materially, with new systems or new regulatory obligations, the arc loops back through a focused Assess to map the change, so the programme stays aligned to recognised frameworks over time.

Ready to see how this works against your own estate? Book a methodology walkthrough with our team to see how Assess, Implement, Assure maps to your current AI estate.