Director Brief: Is your board getting evidence that its AI is secure?

When management tells the board an AI system is secure, what is that assurance based on? Too often it is a yes and a slide. Boards should expect evidence, not yes or no answers, and a new international standard gives them a better basis for asking for it.

There are two separate risks here and they often get blurred. The first is software built with AI tools. Teams are now vibe coding, generating applications largely by prompting an AI tool with little human review of the code, and pushing them out faster than testing and policy can keep up. Too often the customer becomes the tester, and sometimes the victim, of poor development processes. The second is the security of AI systems themselves: the models, training data and interfaces an organisation builds, buys or supplies to others, which can be attacked in ways traditional IT controls were not designed for. Many organisations now carry both, sometimes in the same product.

This is a risk for the public who use these systems, for the company, and for the board. None of it creates a new legal duty. AI oversight sits within directors' existing duties of care and diligence, and that includes AI the organisation relies on from its supply chain.

The first risk is largely a matter of secure development and testing practice. The second is where ISO/IEC 27090:2026, Cybersecurity: Artificial intelligence (AI): Addressing security threats and compromises to AI systems, comes in. It is guidance rather than a certifiable standard. It helps organisations understand, detect and mitigate AI-specific threats throughout the system lifecycle, since attacks on AI systems can occur during training and development as well as in operation. It applies to organisations developing or using any type of AI, not just generative AI, including those building AI solutions for others, and it addresses threats such as:

• Data and model poisoning
• Model theft or extraction
• Evasion and inference attacks
• Prompt injection and sensitive outputs
• Training-data leakage
• AI supply-chain compromise

Company policies don't always keep pace with technology change or the demands of frequent releases into production. The standard can help teams identify AI-specific security requirements before AI system changes go live. It complements ISO/IEC 27001 and 27002 rather than replacing them, adding AI-specific guidance to established information security practice where those standards are already in place.

It also sits alongside ISO/IEC 38507, which extends the governance framework in ISO/IEC 38500 to the use of AI, and ISO/IEC 42001, the AI management system standard. Between them, boards now have a governance frame, a management system and the security detail.

Questions to put to management

These are our questions, not requirements of the standard. Directors do not need to read every report listed. Ask for the board-level findings each one supports: what was tested, what remains exposed, the consequences, who owns remediation and when it is due. The detailed material should be available if the board wants to look closer.

1. How have we identified and assessed AI-specific security risks?

Evidence to request:

• AI risk register
• AI threat assessments
• AI system inventories
• Risk treatment plans

What you are looking for: Evidence that management has considered threats such as data poisoning, model extraction, prompt injection and model manipulation, not just traditional cyber risks.

2. Have we independently tested our AI systems, including those we buy, against AI-specific attacks?

Evidence to request:

• Red-team or adversarial testing results, including prompt injection testing
• Independent security assessment outcomes
• Supplier security evidence for AI products and services, and what we have verified ourselves
• Controls against model theft or extraction, where we own proprietary models

What you are looking for: Testing of AI-specific attack scenarios, not only traditional cybersecurity testing, and a clear view of what remains unresolved. For AI we buy, supplier claims should be backed by evidence the organisation has checked, with its limits understood.

3. How do we monitor AI systems after deployment and detect compromised behaviour?

Evidence to request:

• AI monitoring dashboards
• Drift detection reports
• Incident logs
• Escalation procedures

What you are looking for: Evidence that management can identify when an AI system begins behaving unexpectedly due to attack, corrupted data or model degradation. ISO/IEC 27090 emphasises security throughout the AI lifecycle, including operation and retraining.

4. Which of our systems were built or changed using AI coding tools, and what review did that code get before release?

Evidence to request:

• A record of where AI coding tools are used in development
• Code review and security testing records for those releases
• Release approvals

What you are looking for: Confirmation that AI-written code goes through the same secure development gates as any other code, not a faster lane because it was quicker to produce.

5. Who accepted the residual AI security risk, and what did they see when they did?

Evidence to request:

• Risk acceptance records with a named owner
• The assessment the decision relied on
• Board or committee papers and minutes where it was reported

What you are looking for: A named person, a dated decision and the evidence it was based on. If the board cannot trace a decision back to evidence, it will struggle to show it exercised care and diligence.

The board-level killer question

“Please show us the last independent assessment of our AI security posture and identify the top three AI security vulnerabilities that remain unresolved.”

Having evidence is not the same as being secure. The test is whether management understands what the evidence shows, has assigned responsibility, and is addressing material risks within agreed timeframes. If the answer is just a yes, that is the conversation the board needs to have.

References

International Organization for Standardization. (2026). ISO/IEC 27090:2026 - Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. In ISO. International Organization for Standardization.
https://www.iso.org/standard/27090

About the authors

Murray Wills

Murray Wills is a Director and GM of consulting at Liverton Security, a Director of Maxsys Limited, and Wellington Chapter Director for Digital Directors ANZ. He is a member of the New Zealand ISO/IEC standards committees for IT Governance and IT Service Management.

Email: murray.wills@livertonsecurity.com

Sam Banerjee

Sam Banerjee is a PhD researcher at UTS on AI governance and director accountability, founder of AI Decoded, and NSW Chapter Director with Digital Directors ANZ. Questions 4 and 5 draw on his research on director accountability.

Email: sam@aidecoded.io

Digital Directors ANZ is a peer network for company directors building digital governance capability on boards.