Introductory worked teaching and guided self-check now address every named teaching element and artifact. Independent marking and a real restoration exercise remain separate unresolved needs.
Original editorial teaching and fictional application, informed by the linked primary passages. Compare your reasoning with the model; this is not independently marked learner work, an official examination key or a replacement for the selected course.
What this guide contributes.
Primary route: ISC2 CC. These are selected related scope positions, not a claim that the guide teaches the entire objective/application/statement. Full scope and remaining depth are in the coverage register.
See this guide’s exact scope links and remaining depth
What the source review checked
- Recovery/dependency walkthrough for models/configuration/data
- Checked asset/dependency/recovery-owner table
- Fallback/restore explanation
- Drift/KRI decision and all required metric fields
- Response to AI-enabled impersonation
Assigned public passages and original model guidance were checked. No learner work, paid course or full licensed standard was assessed; the remaining-needs section controls any closure claim.
1. Read with a purpose.
UK National Cyber Security Centre and international partners · NCSC secure AI development: assets, versions and a known-good state
FREE PUBLIC READINGRead: Identify, track and protect your assets; Document your data, models and prompts; supply-chain failover sentence.
Learn: Restoring the application requires more than a model name: inventory data, prompts, software, configurations and protected evidence.
Exact scope and exclusionsSelected full heading text publicly readable without payment or sign-in.
NIST · NIST AI 600-1: selected acceptable-use, inventory and fallback actions
FREE PUBLIC READINGRead: GV-6.2-001, viewer p.25; GV-6.2-003 and GV-6.2-006, viewer p.26.
Learn: Name third-party dependencies, incident owners and tested fallback choices, including manual processing.
Exact scope and exclusionsPublic 64-page PDF opened and relevant sections read; cover explicitly says available free of charge.
NIST · NIST AI RMF Playbook: production monitoring and drift investigation
FREE PUBLIC READINGRead: MEASURE 2.4 About and Suggested Actions.
Learn: Compare deployment observations with a baseline, investigate causes, and define responsible human responses.
Exact scope and exclusionsSelected HTML text was publicly readable without payment or sign-in.
NIST · NIST AI RMF Playbook: recovery, bypass and redeployment decisions
FREE PUBLIC READINGRead: MANAGE 2.3 and 2.4 selected passages.
Learn: Preplan how to bypass or suspend an unreliable component and what evidence is needed for return.
Exact scope and exclusionsSelected HTML text was publicly readable without payment or sign-in.
FBI Internet Crime Complaint Center · FBI IC3: AI voice/video impersonation and independent contact verification
FREE PUBLIC READINGRead: Voice/video impersonation headings and independent-contact verification bullet only.
Learn: A believable voice or video is insufficient authority for a sensitive request.
Exact scope and exclusionsAssigned public HTML text readable without payment or sign-in.
CISA National Cyber Exercise Program / JCDC · CISA JCDC AI Cyber Tabletop Exercise: scenario and facilitator outcomes
FREE PUBLIC READINGRead: p.7 Day 21 questions/Desired Discussion Outcome and the matching continuity question on p.10.
Learn: Add a publisher-facilitated continuity decision discussion after an AI incident; do not mistake its outcome statement for marking.
Exact scope and exclusionsExact public PDF fetched by ordinary HTTP with browser User-Agent: HTTP 200, 342286 bytes, 10 pages. All pages read in memory. Web reader separately returned 403; access may vary.
2. Try the fictional case.
Keep booking work running when an AI supplier fails and quality changes
Fictional paper exercise. Cedar now uses a customer-built drafting application calling a provider-hosted model API. Humans continue to manage the separate booking system. A model outage begins at 09:00. Fictional business goals are to resume accepting bookings within 30 minutes and restore a validated assistant within 4 hours. The booking-record recovery point objective is 15 minutes; public FAQ changes have a separate 24-hour recovery-point target. Later, a weekly quality sample worsens and a caller sounding like the director requests an urgent bank-account change. All targets, samples and times are invented choices. No live service, records or voice-generation tool is required.
Your tasks
- Build an asset/dependency table naming who owns restoration, what evidence/artifact is retained, and how to work without it. Distinguish items Cedar can back up from a hosted model it cannot copy.
- Explain a safe fallback and ordered return to service. Use the supplied paper events: manual intake available at 09:20; approved assistant validated at 12:00. Compare elapsed times with the stated goals.
- Define a KRI: materially wrong answers per 100 human-reviewed replies per week. Baseline is 2 of 100; current week is 9 of 100. Fictional escalation trigger is greater than 5%; a prohibited-data disclosure triggers immediate suspension at any rate. Calculate and decide.
- Explain at least three plausible causes of the change and what evidence could distinguish them. Do not label it poisoning solely because the rate changed.
- Respond to the urgent director-voice request. State who verifies it, what channel is used, what action is held and when the security team is involved.
3. Compare your reasoning.
Decide and write your explanation first. Where a table is wider than your screen, focus it and use the arrow keys, or scroll it sideways.
Open explained model guidance
Step 1 - Separate business continuity from AI restoration. Continue accepting bookings with the existing booking system and approved manual templates; queue draft requests and prohibit automated messages. A backup is a retained copy; recovery also requires people, permissions, dependencies and a successful validation. A provider-hosted model is not assumed downloadable or reproducible by the customer.
Step 2 - Complete the dependency record.
| Dependency/asset | Restore or coordination owner | Retained evidence and recovery check | Fallback/limit |
|---|---|---|---|
| Booking records | Operations data owner and IT backup owner | Protected record snapshots at most 15 minutes apart; reconcile sequence numbers after restore | Protected numbered manual intake, then reconcile; snapshot frequency alone does not prove RPO |
| Application v1.4, prompt v7, configuration | Application owner | Approved release archive, change record, integrity evidence and configuration; validate access and behaviour | Manual FAQ replies; review credentials separately and do not blindly restore revoked secrets |
| Public FAQ v12 and retrieval index | Content lead | Approved daily FAQ copy plus index recipe/versions; check recent amendments and retrieval | Static approved FAQ; rebuild/validate index rather than assuming an old index matches new text |
| Provider-hosted model/API version | Supplier service owner, coordinated by Cedar application owner | Availability/version notice and tested endpoint/behaviour; verify earlier version is still offered | Remain manual if the required model cannot be restored; customer's backup does not recreate provider weights |
| Identity, network access and useful logs | IT platform owner and security lead | Approved access/network configuration and restricted event records; test permitted and denied requests | Keep AI disconnected until controls are restored; protect sensitive logs |
| Staff and escalation contacts | Operations manager | Current approved instructions and reachable duty owners | Train another staff member to run manual intake |
Step 3 - Walk through recovery. At 09:00 the operations manager suspends AI drafting and starts the response record; IT preserves necessary event/version evidence and checks whether the booking system is also affected. At 09:20 staff can accept bookings manually: 20 minutes, within the fictional 30-minute continuity target. The application owner restores the approved application/prompt/configuration, the content lead checks FAQ/index consistency, and IT checks identities, endpoint and logging. At 12:00 the supplied paper exercise says acceptance/security checks pass and the operations manager authorizes return: 3 hours after 09:00, within the 4-hour assistant goal. These are simulated times, not an executed restore or an SLA guarantee. Booking RPO 15 minutes and FAQ RPO 24 hours refer to different data; test and reconcile each separately.
Step 4 - Make the KRI actionable. Name: material-answer-error rate. Formula: materially wrong replies / reviewed replies x 100. Baseline: 2/100 = 2%. Current: 9/100 = 9%; increase = 7 percentage points. Direction: higher is worse. Fictional threshold: greater than 5% in a weekly sample, with any prohibited disclosure causing immediate suspension. Owner: content lead measures; operations manager decides; security/privacy leads receive relevant escalations. At 9%, record a breach and revert to the manual/verified-template workflow until reviewed. Preserve sample-selection method and version metadata. This sample rate does not establish the population rate, representativeness, or a cause of the change.
Step 5 - Investigate before classifying. Compare input mix with the baseline: a seasonal increase in unfamiliar questions may mean the context changed. Check whether supplier model, prompt, application, FAQ or index versions changed. Check labels and the review process for measurement error, and review access/integrity events for evidence of tampering. Data/concept/model drift is a possible explanation; poisoning needs evidence of adversarial interference. Re-test relevant cases against the approved configuration, warn users about limitations and require an authorized return decision. Document owner, cause, action and follow-up date.
Step 6 - Handle the voice inject. A familiar-sounding caller is a claim of identity, not approval. The staff member holds the bank-detail change and ends the incoming interaction; the finance owner contacts the director through a number already verified in the internal directory, not the supplied callback number. The ordinary dual-approval process remains in force. Report the suspicious request to the security coordinator with proportionate time/channel/request evidence and preserve it under the incident process. Do not send data or make a payment merely to test the caller. Verification failure remains an incident to investigate, even if the voice sounds convincing.
Original editorial source-informed paper exercise with invented targets/results. It offers self-comparison, not independently marked learning, statistical drift validation, actual continuity/backup testing, an official exam key or proof of competence.
4. Check the work, not just the score.
- Did your table include people, data, configurations, prompts, index and provider dependency rather than only a model backup?
- Did you explain why a hosted API may require supplier coordination/manual fallback, and why provider recovery cannot be assumed?
- Did you distinguish 20-minute continuity, 3-hour assistant restoration, 15-minute booking RPO and 24-hour FAQ RPO?
- Does the KRI have the same denominator and review method, 2% baseline, 9% current, 7-percentage-point change, direction, trigger, owner and response?
- Did you retain multiple explanations for degraded quality and reserve attack claims for evidence?
- Would the impersonation response still work if voice, video, spelling and caller ID all looked convincing?
These checks help you revise an explanation. They do not certify mastery or predict an examination result. Ask a qualified reviewer to assess a fresh case when independent feedback is needed.
5. Keep the limits in view.
Free coverage added
- A dependency/recovery-owner table covers application, prompt/configuration, reference data, index, hosted model, identity/network and business records, with distinct recovery goals.
- A worked KRI calculation has a baseline, denominator, direction, fictional threshold, owner and response, while distinguishing observed degradation from an attack finding.
- A synthetic voice-impersonation inject practices trusted-channel verification, payment/change authority and escalation.
- A paper fallback/restore walkthrough and CISA continuity discussion provide guided practice without an account or cloud charges.
Still missing or outside this guide
- The learner's own fresh dependency table, recovery explanation and KRI decision still need independent review if marked practice is desired.
- No actual backup restore, provider failover, model-version availability, statistical drift diagnosis or operational recovery time has been tested by this paper case.
- A qualified organization must define real business-impact priorities, recovery targets, reporting duties and supplier arrangements.
Payment and access
Selected reading and the complete paper case are free. A hosted model/API/Sentinel or other cloud lab can incur service/compute charges and is not needed. Paid marked support remains optional and unverified; do not buy a course merely because its catalogue says AI or continuity.
Open this area in the gap register