AAISM lesson 4: The AI security program

Lesson 4 of 13 · 6 min read · Updated October 16, 2026

An AI security program is the set of people, processes and tools that keeps AI use within the organisation’s risk appetite over time, and it works best as an extension of the security program that already exists rather than a parallel one. Subtopic 1D, with the supporting tasks on awareness training, metrics and security tools, covers how a manager scopes, resources, measures and improves it. Policy states intent; a program makes the intent happen every week.

Components

Most AI security programs are built from the same parts, and each maps to a later lesson.

  • Governance: charter, committee, decision rights and escalation (lesson 2).
  • Inventory and classification: the register of AI assets and data (lesson 3).
  • Risk management: assessment, thresholds and treatment (lesson 6).
  • Control framework: architecture, secure life cycle, data and monitoring controls.
  • Vendor oversight: due diligence and contracts for third-party AI.
  • Incident response and continuity: AI-specific playbooks (lesson 5).
  • Awareness and training: the human layer.
  • Measurement and reporting: evidence for management.

Scope and resourcing come first. A program needs a defined boundary (which AI uses, which business units), an executive sponsor, a budget and named leads. A program with no sponsor stalls the first time it asks a business unit to change anything.

Integrating with what exists

The cheapest, most credible approach is to extend existing processes. The risk register gains AI risks. Change management gains an AI review gate. Procurement adds AI questions to vendor assessment. Incident response gains playbooks for model failures. Identity management covers the service accounts agents use. The security control categories topic gives a vocabulary for deciding which controls are preventive, detective or corrective. A parallel structure creates duplicate forms, conflicting rules and gaps between teams, which is why the integrated model is usually the best answer in a scenario.

Awareness and training

Training should differ by audience. All staff need acceptable use: what may be entered into tools, how to treat outputs, and how to report problems. Developers and data scientists need secure development and data handling for AI. Approvers and executives need enough understanding to make risk decisions. Training is measured by behaviour, such as reported incidents and policy exceptions, as well as by completion rates. Training also does not replace controls: a rule that depends on every employee remembering it is a weak control.

Metrics

A metric earns its place when it supports a decision. Useful AI security measures fall into three groups.

GroupExampleDecision it supports
CoverageShare of AI systems in the inventory with a named owner and a completed assessmentWhere to focus effort
Control effectivenessShare of high-risk systems with output monitoring active; time to revoke access for retired assetsWhether controls work
OutcomesNumber and severity of AI incidents; policy exceptions open past their deadlineWhether risk is falling

Beware vanity numbers such as the count of policies written or of staff trained, which say nothing about risk. Good metrics have a defined owner, a data source, a target tied to appetite, and a reporting audience. Executives need few, trend-based indicators; operational teams need detail.

Tools

Tooling follows need. Typical categories are discovery of AI use, data loss prevention, model and prompt monitoring, vulnerability and configuration scanning, and logging with detection. The manager’s task is to review and select tools against requirements, check that they integrate with existing monitoring, and avoid buying a product to solve a problem that has not been defined. A tool without an owner and a process is shelfware.

A worked example

A 400-person insurer already runs a security program aligned to a common framework. Rather than create an “AI security office”, the security manager adds an AI review step to change management, adds AI risks to the register, includes AI questions in vendor reviews, and drafts two incident playbooks. After a first assessment the program is rated ad hoc: use is discovered but controls are inconsistent. The roadmap moves to defined (standard review for every use), then managed (metrics reported quarterly, thresholds enforced), then optimised (lessons feed back into policy). Maturity models differ in labels, but the idea is the same: climb in steps, prove each one, and tie improvements to risk.

Easy to confuse

  • Program versus project. A program is ongoing; a project ends.
  • Activity metric versus risk metric. Training completions count effort, not exposure.
  • Integrate versus duplicate. Extending existing processes beats building a rival structure.

Key points

  • The program turns policy into repeated practice, with a sponsor, scope and budget.
  • Integration with existing security processes is normally the best approach.
  • Training is tailored by audience and measured by behaviour.
  • Metrics must support decisions and connect to risk appetite.
  • Maturity improves in steps, and tools follow requirements.

Check yourself

Question 1. An organisation with a mature security program is starting to adopt AI. Which approach is MOST appropriate for the security manager?

  • A. Create a separate AI security office with its own processes
  • B. Wait until regulation specifies exactly what to implement
  • C. Extend existing risk, change, vendor and incident processes to cover AI
  • D. Purchase an AI security platform before defining requirements
Show answer

Answer: C

Extending existing processes such as risk registers, change control and vendor review reuses proven governance and avoids gaps between teams. A separate structure duplicates effort, waiting for regulation delays control, and buying tools first lacks defined requirements.

Want more questions like this? Full AAISM practice tests →

Question 2. Which metric BEST shows whether AI risk is being managed effectively?

  • A. Number of AI policies published
  • B. Total hours of AI training delivered
  • C. Number of AI security tools purchased
  • D. Percentage of high-risk AI systems with a completed assessment and active monitoring
Show answer

Answer: D

The share of high-risk systems with active monitoring and a completed assessment ties directly to control coverage and risk. The number of policies, the training hours delivered and the number of tools bought measure activity, not exposure.

Want more questions like this? Full AAISM practice tests →

Question 3. Staff continue pasting confidential data into public tools despite annual training. What should the security manager do NEXT?

  • A. Provide approved alternatives and add preventive controls alongside targeted awareness
  • B. Repeat the same course more often
  • C. Accept the behaviour as inevitable
  • D. Discipline staff without changing any controls
Show answer

Answer: A

Training alone has not changed behaviour, so complementary controls such as approved alternatives and preventive technical measures are needed, along with a look at why staff bypass the rules. Repeating the course, punishing staff or accepting the behaviour do not address the cause.

Want more questions like this? Full AAISM practice tests →

This lesson covers subtopic 1D of Domain 1 (31%); the governance and programme management recap condenses the domain.