Why do existing security and privacy controls not fully cover ISO 42001?

Where generic security and privacy controls stop short

Most existing controls are designed to protect systems, data, and processes in a stable environment. That works well for access control, logging, encryption, and privacy reviews, but ISO 42001 asks for something broader: a management system that treats AI as a changing capability with its own governance, accountability, and performance risks over time.

In practice, this is why a control set can be technically strong yet still miss ISO 42001 expectations. It may prove that the organisation secures infrastructure and documents decisions, but not that it continually governs how the AI is trained, changed, monitored, and accepted for use.

What ISO 42001 adds that other control sets usually miss

ISO/IEC 42001:2023 requires an AI management system standard mindset, so the control objective is not only to secure the environment around the model. It is to govern the AI system itself, including policy, accountability, risk treatment, lifecycle oversight, and evidence that the organisation can explain how the system is run and changed.

That matters because AI systems can degrade without a single obvious incident. Bias can emerge from data and feedback loops, explainability can be limited even when the system is working, and model or workflow drift can make earlier approvals stale. Existing security controls may detect unauthorised change, but they rarely tell you whether the AI is still behaving within its intended operating envelope.

NIST SP 800-53 Rev 5 Security and Privacy Controls helps with access, audit, integrity, and configuration discipline, and GDPR strengthens privacy governance, especially where personal data is involved. But neither framework by itself fully covers the AI-specific questions ISO 42001 raises about model governance, lifecycle change, and the ongoing validation of AI behaviour.

Why the gap becomes visible in real operations

The mismatch usually shows up when teams try to rely on controls that were built for static IT assets. A privacy review may assess the training dataset once, a security review may approve deployment once, and an audit trail may record the decision. ISO 42001 expects those controls to be part of a living governance loop that tracks change, reassesses risk, and revisits assumptions as the AI system evolves.

For organisations that want a practical bridge, existing security and privacy controls still matter. They supply the evidence base for access control, change control, logging, retention, and privacy-by-design. But ISO 42001 adds the expectation that those controls be connected to AI-specific governance artefacts, including impact assessment, human oversight, performance monitoring, and review of changes that alter model behaviour or use.

NIST Privacy Framework and NIST Cybersecurity Framework 2.0 are useful complements because they structure privacy and cybersecurity risk management. The gap is that ISO 42001 turns those capabilities into an AI management problem, where behaviour, accountability, and lifecycle oversight are part of the control objective, not just adjacent concerns.

Risk and Threat Considerations

When organisations assume generic controls are enough, the main risk is governance blind spot: the AI can remain technically secure while becoming operationally unreliable, unfair, or misaligned with the approved use case. That creates exposure not only from misuse or drift, but also from weak accountability when the system’s outputs change after deployment.

Failure mechanism: Controls designed for static systems may not force periodic AI review, so performance drift, bias emergence, or changes in intended use can persist after the original approval point.

Impact: The organisation may keep passing security checks while losing control over AI quality, trustworthiness, and compliance with its own governance obligations.

Practitioner Guidance

What to verify: Check whether your current control set includes explicit triggers for AI model review, retraining review, performance monitoring, and approval of material behavioural change. If it only covers infrastructure and data protection, it is incomplete for ISO 42001.

Decision rule: If a control only proves the system was approved once, treat it as baseline governance, not as evidence of ongoing AI management. Require evidence of lifecycle monitoring before accepting ISO 42001 coverage.

What good looks like: The organisation can show who owns the AI system, how changes are approved, how bias or drift is measured, and how security, privacy, and operational reviews are re-run when the model or its context changes.

Practitioner takeaway: ISO 42001 is not “security plus privacy” with an AI label, it is governance over a changing AI system, so the key test is whether your controls still work after the model, data, or use case changes.

Related resources from NHI Mgmt Group

• How does ISO/IEC 42001 fit with existing IAM and security controls?
• How should security teams govern non-human identities for ISO 27001?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?