The Core Point
In the first six articles in this series, I examined AI governance as a board-level issue, consequence-led risk tiering, security as a commercial enabler, operational resilience, the operating model beneath policy and the assurance needed to establish whether governance is working.
This seventh and final instalment considers the CISO’s role within that wider model.
AI can introduce new risks and amplify existing security, privacy, resilience, third-party and governance risks. It is therefore understandable that organisations often look to the CISO for leadership.
But the CISO should not become the default owner of every AI system, use case, control or business outcome.
The role is more precise:
lead where the principal requirement concerns security
enable the wider governance and assurance model
challenge unclear ownership and ineffective controls
provide management assurance within Security’s remit
support independent assurance without claiming independence over controls Security owns
help keep accountability with the owner of the relevant business outcome
The CISO has a significant but bounded role in AI governance.
Why the CISO Is Drawn into AI Governance
AI cuts across many areas already within, or adjacent to, the CISO’s remit:
information protection
identity and access management
secure development
cloud and third-party risk
application and model security
incident response
operational resilience
control monitoring
client and regulatory assurance
board-level risk reporting
Security teams are also accustomed to working across organisational boundaries.
They understand that technical design, supplier decisions, data, user behaviour and business processes can combine to create material risk.
This makes the CISO well placed to help establish and operate the governance model.
It does not make the CISO accountable for every use of AI.
Accountability Should Follow the Outcome
The accountable business owner should remain responsible for:
why the AI capability is being used
the outcome it is intended to support
the process being automated or augmented
the effect on customers, employees and third parties
the continued suitability of the use case
ensuring that residual risk is accepted by the appropriate delegated authority
The CISO may own security standards and controls.
The Chief Data Officer may own data standards.
Legal may advise on applicable law and contractual obligations.
Privacy specialists may advise on data-protection requirements.
Compliance may advise on regulatory obligations and monitor adherence within its remit.
Risk may provide methodology, aggregation and challenge.
Internal Audit may provide independent assurance in accordance with its mandate.
None of these roles removes accountability from the business owner responsible for the relevant service, decision or outcome.
A practical test is:
If the AI capability produces an unacceptable outcome, which executive is accountable for the affected business process?
If accountability defaults to the CISO solely because the system uses AI, the allocation of responsibilities should be reconsidered.
Where the CISO May Need to Lead
The precise allocation of responsibilities will depend on the organisation’s structure, sector and existing control model.
The areas below are those in which the CISO or security function would normally be expected to lead or make a material contribution.
Security Architecture
AI capabilities should be incorporated into established architecture and security-review processes.
The security function should help determine:
how the service connects to organisational systems
what information it can access
which identities and permissions it uses
whether outputs can trigger actions
how activity is logged
how the capability can be restricted or disabled
which controls are required before deployment
This becomes particularly important where AI agents can access data, change records, initiate transactions or communicate externally.
The greater the system’s authority, the stronger the control expectations should be.
AI-Specific and AI-Amplified Security Risks
AI introduces some new attack techniques and can amplify familiar software, data and supply-chain risks.
Relevant concerns may include:
prompt injection
sensitive-data leakage
insecure model or API integration
malicious input or content manipulation
unauthorised tool use
excessive agent permissions
poisoning of training data or retrieval sources
model extraction or reconstruction
weaknesses in third-party components
manipulation of models, prompts or supporting data
The assessment should also consider output-integrity risks, including unreliable or fabricated content being accepted by users or passed into downstream processes.
The CISO should ensure these risks are considered in threat modelling, secure design, testing and monitoring.
This does not require a separate security framework for every AI system.
It requires established practices to be extended where AI changes the threat or control environment.
Identity and Access
AI applications and agents that access organisational systems should use identifiable and controlled workload identities, with permissions limited to those required for their intended function.
The security function should challenge:
shared or poorly controlled service accounts
excessive access to corporate information
broad agent permissions
weak segregation between development and production
inadequate approval for sensitive actions
an inability to attribute actions to a user, service or agent
An AI-enabled process should not receive wider access simply because automation makes the workflow more convenient.
Information Protection
The CISO should help define how information-classification requirements apply to AI services.
This may include determining:
which information may be entered into approved services
whether prompts and outputs are retained
whether organisational data may be used to improve the provider’s service
where processing and storage occur
how confidential or regulated information is protected
whether sensitive information can be retrieved by unintended users
The control should follow the information and its use, not merely the label attached to the technology.
Security Monitoring and Incident Response
AI-related incidents should be connected to established security and operational processes.
The organisation should be able to identify and respond to events such as:
unauthorised disclosure of information
compromised credentials or workload identities
manipulated system behaviour
excessive or unintended actions
malicious use of an approved AI capability
supplier-side security incidents
failures in logging or monitoring
The CISO should help ensure that escalation routes, containment actions and evidence requirements are defined before a material incident occurs.
Third-Party Security
Many organisations will consume AI through cloud platforms, software products, embedded features and external model providers.
The CISO should lead or support proportionate security due diligence covering:
data use and retention
access controls
encryption
logging
vulnerability management
incident notification
subcontractors
material model or service changes
resilience and exit arrangements
contractual security obligations
The assessment should reflect the importance and potential consequence of the use case.
A drafting assistant and a system influencing material decisions should not receive identical scrutiny.
Where the CISO Should Enable
Some areas require strong security involvement without making the CISO the sole owner.
Governance Design
The CISO can help translate high-level policy into:
practical standards
risk-tiering criteria
approval thresholds
control requirements
escalation routes
evidence expectations
reassessment triggers
Security teams often have useful experience converting broad principles into repeatable controls.
That capability should support the wider governance model rather than dominate it.
Use-Case Discovery
The CISO can help identify where AI enters the organisation through:
procurement
software development
cloud services
supplier onboarding
architecture review
data platforms
business-led experimentation
existing products adding AI features
Security should not, however, be expected to discover every use case independently.
Business functions, Procurement, Technology, Data and Product teams all need defined responsibilities for identifying and registering AI use.
Risk Tiering
Security should contribute to classification, particularly where the use case involves:
sensitive information
autonomous action
external exposure
privileged access
important or critical services
material third-party dependency
significant cyber threats
The overall tier should consider the full potential consequence, not only the security exposure.
A use case may be high risk because of its effect on customers, employees, financial decisions or regulatory obligations even where its technical security risk is moderate.
Training and Awareness
The CISO can support practical guidance on:
approved and unapproved tools
safe handling of information
verification of outputs
malicious prompts and content
account security
escalation of suspected incidents
risks associated with autonomous actions
Training should be tailored to the user’s role.
Developers, procurement teams, executives and occasional users do not need the same level of detail.
Operational Resilience
The CISO should work with Technology, Operations and accountable business owners to assess:
critical model and provider dependencies
service concentration
relevant failure modes
continuity arrangements
fallback processes
recovery priorities
incident coordination
The CISO can challenge weak assumptions, particularly where the proposed fallback is an untested return to manual processing.
The accountable service owner should remain responsible for ensuring the business outcome can continue within the organisation’s tolerance.
Governance Assurance
As discussed in Part 6, assurance should test whether governance is operating in practice rather than merely documented.
The CISO and security function may contribute by:
testing security controls
providing monitoring and incident evidence
identifying weaknesses in architecture or access
supporting thematic reviews
reporting security-related findings
tracking remediation within Security’s remit
supporting client, regulatory and board assurance
This is management assurance, not independent assurance, where Security owns or operates the controls being tested.
Where independence is required, assurance should be performed or overseen by an appropriately separate function.
Security is an important source of assurance.
It is not the entire assurance model.
Where the CISO Should Challenge
An effective CISO should be prepared to challenge decisions where the control environment is unclear or disproportionate to the potential consequence.
Examples include:
no accountable business owner
unclear authority to accept residual risk
a higher-risk use proceeding without adequate assessment
sensitive information being used in an unapproved service
autonomous actions without appropriate restrictions
human oversight that is unlikely to operate effectively
untested fallback arrangements
insufficient monitoring or evidence
inadequate supplier commitments
material changes that have not triggered reassessment
use cases operating outside approved conditions
assurance based solely on management attestation
Challenge does not mean stopping every proposal.
It means ensuring that material decisions are explicit, evidence-based and made by the appropriate authority.
Where the CISO Should Step Back
The CISO should avoid assuming ownership for matters that properly belong elsewhere.
Business Purpose and Outcomes
The accountable business owner should determine whether the use case is necessary, valuable and aligned with the organisation’s objectives.
Security can assess and advise on risk.
It should not decide the business case or own the resulting business outcome.
Legal, Regulatory and Privacy Matters
Legal should advise on the interpretation of applicable law and contractual obligations.
Compliance should advise on relevant regulatory requirements and monitor adherence within its remit.
The organisation, as controller or processor, remains accountable for applicable data-protection requirements. Privacy specialists and the Data Protection Officer should provide advice on matters including the need for a DPIA, appropriate safeguards and the implications of the proposed processing.
Security should support the design and operation of relevant technical and organisational measures.
It should not become the organisation’s default legal, regulatory or privacy authority for AI.
Fairness and Affected-Party Outcomes
Security may contribute to governance and evidence, but it should not own the organisation’s position on fairness, discrimination, employment decisions or customer outcomes.
These matters require input from the accountable business owner and relevant functions such as Legal, Compliance, Privacy, Data, HR and Product.
Model Suitability and Performance
The CISO should not be expected to validate whether a model is statistically appropriate for a business decision unless that capability genuinely sits within the security function.
Model owners, Data Science, Product and relevant business specialists should remain responsible for:
fitness for purpose
model performance
validation
outcome quality
ongoing monitoring
Business Risk Acceptance
The CISO can advise on security risk and recommend treatment.
Residual business risk should be accepted by the authority defined in the organisation’s risk framework.
Security should not accept risk on behalf of the owner of the business outcome.
Independent Assurance
The CISO should not claim independent assurance over controls owned or operated by the security function.
Security may test and report on its own controls as part of management assurance.
Independent assurance requires sufficient organisational separation and should be performed in accordance with the relevant assurance mandate.
A Practical Division of Responsibilities
A workable model might distinguish responsibilities as follows.
Accountable Business Owner
Owns the purpose, intended outcome, continuing use and business risk.
Technology or Product Owner
Owns implementation, operation, change and technical performance.
Data or Model Owner
Owns data quality, model suitability, validation and performance where applicable.
CISO and Security Function
Owns or oversees the security standards, threat assessment, architecture controls, monitoring and incident-response responsibilities allocated to the function.
Privacy, Legal and Compliance
Provides advice and challenge within their respective legal, privacy and regulatory remits.
Enterprise Risk
Provides risk methodology, aggregation, escalation and oversight.
Internal Audit or Independent Assurance
May provide independent assurance on whether governance and controls are appropriately designed and operating effectively, in accordance with its mandate and assurance plan.
The precise titles will vary.
The important point is that contribution, oversight, management assurance and independent assurance are not treated as the same thing.
What the Board Needs from the CISO
Part 6 considered the broader assurance information a board needs to understand whether AI governance can be relied upon.
The CISO’s contribution should focus on material security exposure and the effectiveness of controls within Security’s remit.
Useful reporting may include:
material security dependencies arising from AI
higher-risk use cases with unresolved security gaps
significant supplier or concentration risks
incidents and material near misses
use cases with excessive access or autonomous authority
deficiencies in monitoring, logging or response
overdue security remediation
areas where accountability remains unclear
management-assurance results for relevant security controls
matters requiring independent review or executive decision
The CISO should distinguish between:
risks owned by Security
risks on which Security provides advice
risks owned by another business function
management assurance provided by Security
matters requiring independent assurance
matters requiring executive or board decision
That distinction improves accountability and prevents the CISO report from becoming a general register of every AI concern.
The Skills the CISO Needs
The modern CISO does not need to become a data scientist or model auditor.
The role does require enough understanding to ask useful questions about:
how the model or service is used
what data it relies on
what systems it can access
what actions it can take
how outputs are checked
how behaviour may change
how failures are detected
how decisions can be reconstructed
how suppliers manage security and change
how the service can be restricted or stopped
what evidence demonstrates that security controls are operating
The CISO also needs to translate technical concerns into business consequences.
Executives and boards are generally less concerned with the mechanics of a prompt-injection attack than with what it could enable:
disclosure of confidential information
unauthorised transactions
manipulation of customer communications
disruption of an important or critical service
unreliable decisions
regulatory or contractual exposure
That translation is central to the role.
Common Failure Patterns
Several problems arise when the CISO’s role is poorly defined.
Security Owns Everything
AI is treated as a technology issue and accountability shifts to the CISO.
Business ownership weakens and governance becomes disconnected from the outcome.
Security Is Involved Too Late
AI is treated solely as innovation or data strategy.
Security is consulted after important design, supplier or access decisions have already been made.
Every Use Case Receives the Same Security Review
Low-risk uses create unnecessary workload while higher-risk cases compete for attention.
The process becomes slow and teams may work around it.
Security Risk Becomes the Entire Assessment
The organisation considers confidentiality, integrity and availability but overlooks customer, employee, legal, operational or ethical consequences.
Security Is Expected to Accept Business Risk
The CISO recommends a treatment decision and is then expected to approve the residual exposure on behalf of the business owner.
This weakens accountability.
Management Assurance Is Presented as Independent
Security tests controls that it owns and presents the result as independent assurance.
This may provide useful management information, but it does not provide organisational independence.
The Board Receives Detail Without Context
Reporting describes models, vulnerabilities and controls but does not explain the potential effect on material outcomes.
The board cannot readily determine whether further action is required.
A Practical CISO Agenda
A CISO establishing or improving AI governance should consider the following priorities:
Identify where AI changes the organisation’s security and dependency profile.
Define the security questions required in use-case screening.
Establish proportionate security controls by risk tier.
Clarify when formal security review is required.
Integrate AI into architecture, supplier, incident and resilience processes.
Ensure privileged access and autonomous actions receive appropriate scrutiny.
Define monitoring, logging and evidence requirements.
Confirm that AI-related security incidents can be contained and investigated.
Provide management assurance over Security’s controls and support independent assurance where required.
Challenge unclear ownership and unsupported risk acceptance.
Provide the board with consequence-led reporting on material exposure.
This should not require an entirely separate governance structure where existing processes can be adapted effectively.
The objective is to incorporate AI into the organisation’s control environment while adding new measures where the technology materially changes the risk.
Lead, Enable and Challenge
The CISO has a significant but bounded role in AI governance.
Security should lead where the principal requirement concerns security architecture, threat management, information protection, monitoring, incident response or technical assurance.
It should enable the wider operating model through proportionate standards, risk assessment, supplier governance, resilience planning and evidence.
It should contribute management assurance over the controls within its remit and support independent assurance without claiming independence over its own work.
It should challenge unclear ownership, ineffective controls and assumptions that are not supported by testing.
It should also recognise where accountability properly belongs with the business owner, Legal, Privacy, Data, Product or another control function.
An effective CISO does not need to own every AI risk.
The role is to help the organisation understand its exposure, apply proportionate controls, produce credible evidence and place accountability with the people responsible for the relevant decisions and outcomes.
That is where the CISO adds most value: leading where Security is accountable, enabling the wider governance model and challenging where ownership or control is unclear.
Where do you believe the CISO’s responsibility for AI governance should begin and where should it end?
Personal commentary. Views are the author’s own.