How to Write an AI Security Policy for Your Organisation

Most organisations that have adopted AI in meaningful ways do not yet have an AI security policy. What they typically have is a patchwork of references in existing policies: the acceptable use policy mentions AI tools, the data classification policy touches on training data, and the vendor management policy covers AI-powered SaaS platforms in passing. That is not the same as a policy that addresses AI security as a distinct discipline with its own requirements and controls.

An AI security policy does not need to be long. It needs to be accurate, specific, and connected to real programme activities rather than aspirational statements. This article covers what one should contain and how to approach writing it in a way that will hold up under audit.

Start with scope: what systems does this policy govern?

The policy needs to define what counts as an AI system for the purposes of the document. That definition should cover AI systems the organisation builds or fine-tunes itself, AI capabilities embedded in vendor-supplied platforms, AI APIs consumed by internal applications, and AI tools used by staff for productivity purposes. Without a clear scope definition, staff and auditors will disagree about whether the policy applies to a given system.

The scope section should also reference the AI inventory. The policy commits the organisation to maintaining an inventory of AI systems in scope, and the inventory is the mechanism by which the policy is applied. If the organisation does not yet have a mature AI inventory process, the policy can specify that one will be established and set a timeline. What the policy should not do is describe governance of systems that cannot be identified.

Define the security requirements that apply to AI systems

This is the substantive core of the policy. Security requirements for AI systems overlap with but are not identical to requirements for conventional software. The policy should address:

• Pre-deployment security assessment requirements, including adversarial testing appropriate to the system's risk level
• Controls over training data, including provenance, access controls, and retention
• Prompt injection and input validation controls for systems that accept user-supplied input
• Output monitoring and logging requirements
• Access controls for model inference endpoints
• Requirements for systems that use retrieval-augmented generation or other external data sources
• Incident response obligations when an AI system produces an adverse or unexpected output

The NIST AI Risk Management Framework and ISO 42001 both provide useful structure for thinking through AI security requirements. You do not need to implement either framework in full to write a functional policy, but referencing them gives the policy a recognised basis and simplifies future alignment exercises.

Address third-party and vendor-supplied AI

A significant proportion of organisational AI use comes from third-party platforms. The policy needs to address how the organisation evaluates and manages AI supplied by vendors. This includes requiring vendors to disclose when their products include AI capabilities, extending security assessment requirements to vendor AI components, and specifying what contractual provisions must be in place before AI-powered vendor services are adopted.

Vendor-supplied AI introduces risks that are not fully in the organisation's control: the model may be updated without notice, the vendor's data handling practices may not align with the organisation's requirements, and the vendor may use customer inputs to improve the model unless this is contractually prohibited. The policy should specify minimum acceptable terms for vendor AI and assign responsibility for verifying compliance.

Assign accountability and link to existing governance structures

An AI security policy that does not assign clear accountability will not be implemented consistently. The policy should name the function responsible for maintaining the AI inventory, the function responsible for conducting or commissioning AI security assessments, and the escalation path when an AI system does not meet policy requirements.

The policy should also specify how it relates to existing governance documents. AI security sits within the broader information security management system, and the AI security policy should not duplicate or contradict the ISMS. Where the ISMS refers to software security testing, the AI security policy extends that to address AI-specific requirements. Clarity about these relationships makes the policy easier to maintain and reduces the risk of conflicts emerging as either document is updated.

We help organisations develop AI security policies that are proportionate to their AI use, aligned with ISO 42001 and the NIST AI RMF, and grounded in practical security programme activities. Get in touch at info@cyberlinx.com.au to discuss what a policy review or development engagement would look like for your organisation.