AAISM lesson 13: Scenarios across domains

Scenario questions are built from three parts: who the reader is, where the situation sits in the AI life cycle, and what the qualifier asks for. Reading in that order usually removes two options at once. The AAISM outline has three domains (31%, 31% and 38%) and 22 supporting tasks that cut across them, so a single scenario often touches more than one area, and the method below works whichever domain it lands in. The question format itself is covered on the exam format page.

A three-step reading method

1. Role. The reader is normally the security manager or leader who advises and is accountable, not the engineer who configures. Options that describe hands-on tuning are usually wrong unless the role says otherwise.
2. Stage. Is the system an idea, in build, in production, being retired, or in an incident? The right action depends on the stage. Before deployment, assess and design; in an incident, contain; with unknown usage, inventory.
3. Qualifier. FIRST means the earliest sensible step, often to establish facts or ownership. BEST means the most complete fit to the situation. MOST means the strongest among several valid options.

Underneath sits a ladder that repeats in this course: know what exists, decide who owns it, assess the risk, set thresholds, apply controls, monitor, and respond.

Scenario 1: unsanctioned use discovered (Domain 1)

A 400-person insurer finds from proxy logs that three departments upload customer documents to a public chatbot. The role is the security manager, the stage is “in use, unmanaged”, and the qualifier is FIRST. The ladder says to establish what exists: identify the tools, the data involved and the business purpose. A ban, a policy rewrite or training all come after, and each is easier to get right once the picture is known. The follow-ups, in order, are classifying the data involved, offering a sanctioned alternative, updating acceptable use guidance and awareness training, and considering whether notification duties arise.

Scenario 2: a vendor model changes (Domain 2)

The same insurer relies on a hosted model to draft claim letters. The provider updates it, and drafts begin to include unsupported statements about coverage. Role: security manager. Stage: production, with a vendor involved. The immediate step is to contain by reverting to the previous version if possible or by adding human review while the issue is assessed; then the incident process and the vendor contract (change notice, incident notification) apply, and the risk is reassessed. Longer-term, the contract gains a notice and pinning clause and the team adds a fixed evaluation set. The distractors, such as replacing the vendor immediately, skip the assessment step.

Scenario 3: a new agent proposal (Domain 3)

A business unit wants an agent that reads emails and updates the policy system. Role: security manager advising on design. Stage: pre-build. The best answer is architectural: give the agent its own identity and minimal permissions, treat email content as untrusted, route calls through the gateway with logging, and require approval for changes to policy records, all decided in a design review and an impact assessment before build. Testing it later does not fix a design that grants too much agency.

Situation to first action

The table gives a starting point only; the facts of a scenario can move the answer. Cross-checks are worth a few seconds: does the action fit the role, the stage and the qualifier, and does it address the cause rather than a symptom?

Key points

• Read role, then stage, then qualifier.
• FIRST often means establish facts, ownership or scope.
• Distractors typically act too early, too narrowly or at the wrong stage.
• The security manager advises on and owns outcomes; engineers configure.
• Supporting tasks cut across domains, so one scenario can use several lessons.

Check yourself

This closing lesson reaches across all three AAISM domains (31%, 31% and 38%); the whole-course recap is on the cheat sheet.