6.1
Governance and Accountability
- Senior management must formally approve the AI security policy, this standard, and the exception-handling decision process.
- A CAISO must be appointed, or an equivalent function must be clearly assigned in a documented decision.
- All significant AI systems must have an assigned business owner, technical owner, security contact, data owner, and legal / compliance contact.
6.2
Inventory and Classification
- The organisation must maintain an AI systems register.
- At minimum it must include: purpose, owner, model type, vendor, version, data categories, integrations, environment, criticality, and legal basis.
- Not only data, but also model weights, system prompts, retrieval corpora, vector databases, experimental artefacts, security rules, and logs must be classified as protected information assets.
- High-sensitivity AI components must be subject to stricter access, export, copying, and sharing restrictions.
6.3
Risk Assessment
- Before development, procurement, or major change, an AI security risk assessment must be performed.
- Where AI uses personal data or may create high risk for individuals' rights and freedoms, the need for a DPIA must be evaluated.
- Where AI may have significant impact on individuals, groups, or society, an AI System Impact Assessment (AI ISA) must be performed.
- Risk assessment must evaluate at least the following threats: prompt injection, jailbreaking, data leakage, supply-chain compromise, model theft, training-data poisoning, compromise of RAG sources, unauthorised tool invocation, hallucination impact, and privilege escalation.
6.4
Identity, Access, and Secrets
- Least privilege must be enforced.
- MFA must be required for administrative access.
- Separate administrative accounts must be used.
- API keys, model-service secrets, storage credentials, and vector database credentials must be managed in a centralised secrets vault.
- Direct access to production model weights, prompts, and raw logs must be limited to documented need-to-know cases.
6.5
Data and Model Security
- Training, validation, and inference data must have documented provenance, lawful basis of use, quality level, and retention period.
- Data minimisation, separation, and—where appropriate—pseudonymisation or anonymisation must be applied.
- Model versions, prompt templates, retrieval datasets, and evaluation results must be versioned and traceable.
6.6
Development, Testing, and Deployment
- The AI development lifecycle must be integrated into a secure development process: code review, dependency scanning, vulnerability management, supply-chain checking, and change approval.
- Development, test, pre-production, and production environments must be separated.
- Direct deployment into production without an approved change process is prohibited.
- Before production deployment there must be a security gate, evidence of functional and security testing, and a rollback plan.
- Critical or sensitive solutions must undergo targeted AI red teaming or adversarial testing.
6.7
Operations and Inference Controls
- Production AI systems must implement access restrictions, rate limiting, abuse detection, and—where required—content filtering.
- RAG architectures must define permitted sources, source trust levels, and source update/removal procedures.
- If AI generates conclusions, recommendations, or content, the organisation must define human review and escalation criteria.
6.8
Logging, Monitoring, and Traceability
- At minimum, logs must capture: user or system identity, model version, prompt template version, data source, exceptions, errors, security events, and change history.
- Full logging of sensitive content is allowed only where lawful, necessary, and proportionate; otherwise only metadata or redacted values should be logged.
- AI logs must be integrated into the broader SIEM / SOC monitoring capability.
6.9
Incident Management
- AI incidents must be classified as a distinct incident category, for example: model compromise, prompt compromise, AI-enabled data leakage, unauthorised tool use.
- The CAISO, CISO, and DPO escalation chain must be defined in advance.
- After a significant AI incident, a post-incident review must be performed and controls must be updated.
6.10
Supply Chain and Third Parties
- Before procuring or integrating a third-party AI model, API, or library, a security and compliance review must be performed.
- Contracts must address: data location, subprocessors, security incident notification, vulnerability management, model-change notices, and exit planning.
- For open-source models and datasets, the organisation must assess licence risk, provenance, community trustworthiness, and vulnerability history.
6.11
Training and AI Literacy
- Executives, developers, analysts, researchers, administrators, and end users must receive role-based AI security and AI literacy training.
- The training programme must cover at least: lawful AI use, protection of sensitive information, prompt injection and social engineering scenarios, model limitations, and escalation procedures.
6.12
Audit and Evidence
- The organisation must periodically assess conformity with this standard and retain audit evidence: registries, risk assessments, test reports, training records, exception decisions, and incident summaries.
- Exceptions are allowed only through a documented decision with risk owner, validity period, and compensating controls.