The Core Point
In the first five articles in this series, I examined AI governance as a board-level issue, consequence-led risk tiering, security as a commercial enabler, operational resilience and the operating model needed beneath policy.
This sixth instalment considers assurance.
The series was originally planned as six articles. It has expanded to seven because assurance warrants separate treatment: designing governance and demonstrating that it is operating effectively are related, but distinct, disciplines.
The precise assurance approach will depend on the use case, sector, applicable obligations and organisational operating model. The practices described here are a practical governance model rather than a single statutory template.
An organisation may have:
an AI policy
an inventory of use cases
a risk-tiering method
documented approvals
defined controls
governance committees
management reporting
These establish that governance has been designed.
They do not, by themselves, demonstrate that it is operating effectively.
The practical question is:
How does the organisation know that AI governance is working as intended?
Assurance should establish whether material AI use is visible, accountability is clear, controls are operating, changes are being reassessed and weaknesses are identified before they result in unacceptable outcomes.
The objective is not to produce more documentation.
It is to provide credible evidence that governance can be relied upon.
Governance Design Is Only the Starting Point
A well-designed governance framework may specify:
which use cases must be registered
how risk is classified
who approves higher-risk uses
which controls apply
when human oversight is required
how suppliers are assessed
what evidence must be retained
which changes trigger reassessment
That design matters.
However, assurance needs to look beyond what the framework says should happen.
It should test what is happening in practice.
For example:
Are teams registering AI use cases consistently?
Are classifications supported by the actual consequences of failure?
Are approval conditions being implemented?
Are controls operating at the required frequency?
Is human oversight capable of influencing outcomes?
Are incidents and near misses being recognised?
Are material changes triggering reassessment?
Can management produce reliable evidence?
A governance model may look coherent on paper while operating unevenly across business units, platforms and jurisdictions.
Assurance identifies that gap.
Start with the AI Inventory
Assurance cannot be reliable if the organisation does not know where AI is being used.
The inventory is therefore a sensible starting point.
Testing should consider whether it captures AI introduced through:
internally developed applications
third-party software
cloud platforms
embedded product features
supplier services
data and analytics teams
business-led experimentation
automated agents and workflows
existing tools that have subsequently added AI capability
A centrally maintained register may still be incomplete if discovery depends entirely on voluntary declaration.
Assurance should therefore compare the register with other sources, such as:
procurement and supplier records
software and cloud inventories
architecture reviews
privacy assessments
development repositories
expense and subscription data
software-discovery and usage telemetry where lawful, proportionate and appropriate
interviews with business and technology teams
The purpose is not to prove that every minor experiment has been captured immediately.
It is to determine whether material use is likely to be visible and whether the discovery process is proportionate to the risk.
Useful questions include:
Are the most consequential uses recorded?
Are accountable owners named?
Is the information current?
Are retired or abandoned uses closed?
Are embedded supplier capabilities included?
Is the inventory linked to relevant risk, privacy, supplier and resilience records?
An incomplete inventory can weaken the assurance activities that follow.
Test Whether Risk Classification Remains Valid
An initial risk tier is a point-in-time judgement.
It may become unreliable as the use case changes.
A system originally approved as a low-risk drafting tool may later:
process confidential information
become customer-facing
influence a material decision
connect to other systems
gain authority to take actions
support an important or critical service
use a different model or provider
Assurance should test whether classification decisions:
use the approved criteria
consider the potential consequence, not merely the technology
are supported by sufficient information
receive appropriate challenge
remain valid after material change
trigger the expected control requirements
A useful sample should include more than high-risk cases.
It should also include use cases classified as low or moderate risk, because understatement of risk may be more difficult to detect than an obvious high-risk designation.
The assurance question is not simply:
Was a tier assigned?
It is:
Was the tier reasonable, consistently applied and kept under review?
Assess Control Design and Operating Effectiveness
Assurance should distinguish between two questions.
Is the Control Suitably Designed?
A well-designed control should have:
a clear purpose
a defined owner
an appropriate trigger or frequency
a practical method of operation
evidence requirements
escalation criteria
a relationship to the risk it is intended to address
Is the Control Operating Effectively?
A control may be well designed but inconsistently performed.
Testing might determine whether:
required reviews took place
evidence was retained
exceptions were recorded
thresholds triggered action
remediation was completed
control failures were escalated
responsible people understood their obligations
Both aspects matter.
A control that operates consistently but does not address the relevant risk may provide misplaced confidence.
A suitable control that is not performed provides little protection.
Test the Conditions Attached to Approval
Higher-risk AI use cases may be approved subject to conditions.
These could include:
use of specified data only
mandatory human review
restricted system permissions
additional testing
defined performance thresholds
enhanced monitoring
customer disclosure
contractual safeguards
fallback arrangements
periodic reassessment
Assurance should establish whether these conditions were translated into operational requirements.
A documented approval is not sufficient where:
the product team did not receive the conditions
the technical configuration does not enforce them
monitoring was never implemented
ownership changed without handover
the provider or model changed
temporary restrictions became permanent by default
Conditions should be visible, owned and traceable to evidence.
Where they are not, the approval process may provide an appearance of governance without influencing the operation of the system.
Examine Whether Human Oversight Is Effective
Human oversight is frequently described as a key AI control.
Its effectiveness should not be assumed.
Assurance should consider:
whether the reviewer has sufficient information
whether the reviewer understands the system’s limitations
whether review volumes are manageable
whether sufficient time is available
whether the person has authority to disagree
whether overrides are possible and recorded
whether patterns of automatic acceptance are monitored
whether escalation routes are used
whether accountability for the decision remains clear
whether the reviewer understands their responsibility within the process
Evidence may include:
review and override records
sampled decisions
observation of the process
interviews with reviewers
training records
workload and capacity information
escalation and exception data
A nominal approval step may not be an effective control if reviewers routinely accept outputs without meaningful assessment.
The assurance conclusion should therefore address the quality of the oversight, not merely its presence.
Verify Monitoring and Detection
AI governance needs to operate after deployment.
Assurance should determine whether monitoring covers the risks relevant to the use case.
Depending on the system, this may include:
output quality
error rates
bias or differential outcomes
inappropriate content
unauthorised access
unusual agent behaviour
use outside approved conditions
changes in data or model performance
supplier incidents
service availability
customer complaints
manual overrides
unexpected downstream actions
The measures should relate to the potential consequence.
Generic platform availability may be insufficient where the principal risk is unreliable output or inappropriate automated action.
Testing should consider:
whether indicators have defined owners
whether thresholds are documented
whether alerts are reviewed
whether data is reliable
whether adverse trends trigger investigation
whether monitoring continues after ownership or supplier changes
whether management can reconstruct what happened
Monitoring is useful only if it can lead to a decision or action.
Test Change Management and Reassessment
AI capabilities can change without a conventional software release.
Changes may arise from:
a new model version
revised prompts or system instructions
different retrieval sources
updated training or reference data
altered thresholds
expanded user groups
new integrations
increased permissions
changed supplier terms
modifications made by the provider
use of the system for a new purpose
Assurance should test whether the organisation has defined which changes are material and whether those changes trigger appropriate review.
Questions include:
Can the organisation identify when a provider changes a model?
Are material changes assessed before implementation where possible?
Does a new use of an existing tool require reassessment?
Are control requirements updated?
Are affected owners and reviewers notified?
Is previous approval still valid?
A governance process that assesses the use case once and then leaves it unchanged is unlikely to remain reliable.
Use Incidents, Exceptions and Near Misses as Evidence
Incidents provide direct evidence about how the control environment behaves under pressure.
Assurance should consider:
whether AI-related incidents are identifiable within existing processes
whether staff know when and how to report them
whether incidents are classified consistently
whether affected decisions or records can be reconstructed
whether root causes are identified
whether lessons lead to changes in controls
whether similar use cases are reviewed
whether material matters reach the appropriate governance forum
Near misses are also valuable.
They may show that:
a control operated successfully
a failure was detected by chance
monitoring thresholds were insufficient
human intervention prevented harm
a supplier issue exposed a wider dependency
the same weakness exists elsewhere
Exceptions should receive similar scrutiny.
Assurance should determine whether they have:
a documented rationale
an accountable owner
approval by the appropriate authority
compensating controls
an expiry date
a remediation plan
periodic review
A temporary exception without effective tracking can become an unmanaged permanent arrangement.
Confirm That Evidence Is Reliable
Evidence is central to assurance, but its existence does not automatically make it reliable.
Evidence should be:
relevant to the control
attributable to the responsible person or system
sufficiently complete
retained for an appropriate period
protected against inappropriate alteration
reproducible where necessary
understandable to an independent reviewer
Screenshots, emails and meeting notes may sometimes be appropriate.
However, they are often weaker than structured records produced through the normal workflow.
More reliable evidence may include:
system-generated logs
recorded approvals
assessment histories
version records
control results
exception registers
monitoring data
incident records
remediation tracking
governance decisions
Automation can improve consistency, but it should not remove the need for accountable judgement.
A system may record that an approval occurred.
Assurance may still need to establish whether the approver had sufficient information and appropriate authority.
Use Proportionate Sources of Assurance
Organisations use different assurance models, but a practical approach may draw on several sources.
This may align with a Three Lines model, but the precise allocation of responsibilities should reflect the organisation’s governance structure and operating model.
Management Assurance
Business and technology owners confirm that:
use cases remain within approved conditions
controls have operated
issues have been reported
evidence is complete
reassessment triggers have been considered
This provides regular operational confirmation but is not independent.
Control-Function Oversight
Security, Risk, Compliance, Privacy or other relevant functions may:
review higher-risk use cases
test selected controls
challenge management attestations
assess trends and exceptions
monitor remediation
report material weaknesses
The precise responsibilities should reflect the organisation’s operating model and the independence required.
Independent Assurance
Internal Audit or another appropriately independent assurance provider may assess whether:
the governance framework is suitably designed
management and oversight arrangements are effective
reporting is reliable
material risks are being addressed
previous findings have been remediated
Independent assurance should be risk-based and performed in accordance with the provider’s mandate.
Not every use case needs separate audit coverage.
The organisation needs sufficient assurance to support confidence in the overall control environment and its most consequential uses.
Avoid Relying Solely on Attestation
Management attestation can be useful.
For example, an accountable owner may periodically confirm that:
the use case remains accurately recorded
its purpose has not materially changed
approval conditions remain in place
incidents and exceptions have been reported
required controls have operated
But attestation should not be the only evidence.
People may confirm compliance without:
checking the underlying records
understanding all changes
recognising that a control has weakened
knowing that a supplier has altered the service
identifying unmanaged use by their teams
A proportionate assurance programme should combine attestation with:
data analysis
control testing
record inspection
interviews
system evidence
observation
targeted thematic reviews
Attestation provides accountability.
Testing provides corroboration.
Measure What Matters
Activity measures can be useful but should not be confused with assurance.
For example:
number of registered use cases
number of assessments completed
number of people trained
number of governance meetings held
These indicate that activity occurred.
They do not establish whether governance is effective.
More useful indicators may include:
material AI use cases missing from the inventory
higher-risk cases without a named accountable owner
controls that failed or were not performed
approvals with unimplemented conditions
overdue reassessments
material changes not reported
unresolved high-risk findings
exceptions beyond their expiry date
incidents and near misses by consequence
repeated control failures
time taken to complete remediation
use cases operating outside approved conditions
unreliable or incomplete evidence
The purpose of reporting is not to produce a larger dashboard.
It is to show whether the organisation’s material AI exposure is understood and controlled.
What the Board Needs to See
Boards do not need detailed test scripts or every individual finding.
They need a clear view of whether the governance model can be relied upon.
Useful reporting may include:
the scope and coverage of assurance activity
significant gaps in the AI inventory
material control weaknesses
high-risk use cases outside approved conditions
overdue remediation
significant incidents and near misses
repeated or systemic findings
areas where evidence is insufficient
management’s response
any residual exposure requiring executive or board attention
Board reporting should distinguish between:
isolated operational issues
weaknesses affecting several use cases
deficiencies in the governance model itself
matters that may place customers, employees or important services at risk
The central board questions are straightforward:
Are material AI uses visible?
Are accountabilities clear?
Are controls operating effectively?
Are changes, incidents and exceptions being managed?
Is the evidence sufficiently reliable?
Are significant weaknesses being corrected?
The CISO’s Role in Assurance
The CISO may have several roles in AI governance assurance.
The security function may:
own testing of security controls
provide evidence from monitoring and incident processes
challenge weak architecture or access controls
contribute to thematic reviews
report security-related findings
track remediation within its remit
support client, regulatory and board assurance
The CISO and security function may provide management assurance over controls they own or operate, but they cannot provide independent assurance over those same controls.
Where independence is required, testing should be performed or overseen by an appropriately separate function.
The CISO should also ensure that security assurance does not become the entire AI assurance programme.
AI governance may require evidence covering:
privacy
legal and regulatory compliance
model performance
customer or employee outcomes
data quality
resilience
supplier management
business accountability
Security is an important component.
It is not the whole picture.
Common Assurance Weaknesses
Several patterns can reduce confidence in AI governance.
Assurance Tests Documentation Only
The review confirms that policies and assessments exist but does not examine whether controls are operating.
The Inventory Is Assumed to Be Complete
Testing begins with the central register without considering undeclared or embedded AI use.
Only High-Risk Classifications Are Reviewed
The assurance programme does not test whether apparently lower-risk cases have been understated.
Human Oversight Is Treated as a Binary Control
The review confirms that a person is involved but does not assess whether the intervention is meaningful.
Monitoring Is Generic
Availability and technical errors are measured, but the organisation does not monitor the outcomes that matter.
Change Is Not Reassessed
The original approval remains in place despite material changes to the model, data, provider or use.
Exceptions Are Poorly Controlled
Temporary departures from the standard lack expiry dates, compensating controls or remediation.
Assurance Lacks Independence
A function relies solely on its own confirmation that its controls are working.
Findings Do Not Lead to Improvement
Issues are recorded, but remediation is not tracked or lessons are not applied to similar use cases.
These weaknesses can create the appearance of assurance without providing reliable confidence.
A Practical Assurance Cycle
A proportionate AI governance assurance cycle might include:
Confirm the scope and material AI inventory.
Select use cases using consequence, change and incident information.
Review classification and accountable ownership.
Assess whether required controls are suitably designed.
Test whether selected controls operated effectively.
Verify approval conditions and exceptions.
Examine monitoring, incidents and near misses.
Test whether material changes triggered reassessment.
Evaluate the reliability of supporting evidence.
Report findings, ownership and remediation dates.
Track corrective action to completion.
Use the results to improve standards, processes and risk criteria.
The frequency and depth should reflect the organisation’s exposure.
A high-impact automated decision system may require more frequent and detailed assurance than a controlled internal drafting tool.
From Governance Design to Confidence
Policies, standards, assessments and approvals establish the governance model.
Assurance determines whether it can be relied upon.
It tests whether:
material AI use is visible
risk classification remains valid
accountabilities are clear
controls operate effectively
human oversight is meaningful
monitoring can detect problems
changes trigger reassessment
incidents and exceptions lead to action
evidence supports the organisation’s claims
The purpose is not to demonstrate perfection.
It is to provide a defensible view of where governance is working, where it is not and what management is doing about the gaps.
That is how governance design becomes operational confidence.
What evidence does your organisation rely on to demonstrate that its AI governance is working in practice?
Part 7 will examine the modern CISO’s role in AI governance: where security should lead, where it should enable and where accountability should remain with the appropriate business owner.
Personal commentary. Views are the author’s own.