Notifications
Clear all
Topic starter
22/06/2026 10:21 am
TL;DR: ISO/IEC 42001 gives organisations a structured way to govern AI risk, but implementation still breaks down where teams lack visibility into data access, lineage, and audit evidence, according to Cyera and Deloitte. The standard only works operationally when data control is enforced at the layer where AI systems actually consume and move information.
NHIMG editorial — based on content published by Cyera: ISO/IEC 42001 for AI Governance: What Security Teams Need (and How DSPM Maps to It)
By the numbers:
- 69% said it would take over a year to fully implement a governance strategy.
- 63% of surveyed organizations lacked AI governance policies to manage AI or prevent the proliferation of shadow AI.
Questions worth separating out
Q: How should security teams govern AI systems that access sensitive data?
A: Security teams should govern AI systems as data consumers with explicit ownership, scoped access, and continuous monitoring.
Q: Why do AI governance programmes fail without data visibility?
A: They fail because AI risk usually emerges from the data path, not from the model alone.
Q: What breaks when AI tools are approved once and never rechecked?
A: The original approval no longer reflects the real risk.
Practitioner guidance
- Inventory every AI system that touches sensitive data Build a current register of copilots, embedded AI features, unapproved tools, and workflow automations that can read or write regulated data.
- Enforce data-layer controls before the model layer Apply classification, access restriction, and policy enforcement where the data resides, not only inside the application that consumes it.
- Establish continuous monitoring for AI-data interactions Track which systems access sensitive data, how often they do it, and whether usage changes after approval.
What's in the full article
Cyera's full research covers the operational detail this post intentionally leaves for the source:
- A walkthrough of how DSPM supports AI governance mapping across data stores, SaaS apps, and internal tools
- Examples of the specific control points used to enforce policy at the data layer rather than only in the application
- Implementation guidance for continuous monitoring, audit trail generation, and evidence collection in AI workflows
- The source's fuller discussion of common failure patterns such as shadow AI, stale approvals, and manual compliance evidence
👉 Read Cyera's analysis of ISO/IEC 42001 and DSPM for AI governance →
ISO/IEC 42001 and DSPM: what security teams must govern now?
Explore further
22/06/2026 11:13 am
ISO/IEC 42001 only becomes meaningful when governance is tied to data control. The standard gives organisations a management framework, but the article shows that framework alone does not produce enforceable security. AI governance breaks when teams cannot see what data is being consumed, where it flows, or whether access is still justified. Practitioners should treat data visibility as the control plane that makes AI governance auditable.
A few things that frame the scale:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
A question worth separating out:
Q: Who is accountable for ISO/IEC 42001 evidence and AI access control?
A: Accountability belongs to the organisation that owns the AI system, not the tool itself. The programme needs named owners for data sources, access rules, monitoring, and audit evidence so responsibility does not disappear into shared workflows. In practice, this is a joint responsibility across security, data governance, and identity teams.
👉 Read our full editorial: ISO/IEC 42001 exposes the AI governance gap in data control
