The missing introductory acceptable-input and change-testing walkthroughs now include artifacts, explained model guidance and self-check. Independently marked learner work and actual operational testing remain unresolved.
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
- Worked permitted/prohibited/conditional input policy
- Protective handling and event escalation
- Version/change record
- Security tests, predefined gates and blocked release
- Failure escalation and retest evidence
- Release/rollback evidence and fallback
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.
NIST · NIST AI 600-1: selected acceptable-use, inventory and fallback actions
FREE PUBLIC READINGRead: Section 2.4 viewer p.11; GV-1.4-002 viewer p.19; GV-1.6-003 viewer p.20; GV-3.2-003 viewer p.22.
Learn: Tie acceptable queries, sensitive-data handling and a version-aware inventory to the use context. Removing names alone does not demonstrate anonymity.
Exact scope and exclusionsPublic 64-page PDF opened and relevant sections read; cover explicitly says available free of charge.
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.
Learn: Record and protect the complete application/data/prompt/model configuration, not just the model name.
Exact scope and exclusionsSelected full heading text publicly readable without payment or sign-in.
UK National Cyber Security Centre and international partners · NCSC secure AI operation: monitor behaviour and evaluate changes
FREE PUBLIC READINGRead: Selected monitoring, update and lessons headings.
Learn: Treat changes to data, prompts and models as possible behaviour changes that need appropriate evaluation and escalation.
Exact scope and exclusionsSelected full heading text publicly readable without payment or sign-in.
Microsoft Learn · Microsoft Learn: create test cases, criteria and a harm baseline
FREE TEACHING / READINGOPTIONAL ACTIVITY MAY COSTRead: Baseline, evaluation criteria and manual/automatic testing text only.
Learn: Define cases and pass/fail rules before comparing versions; a single average can hide a serious security failure.
Exact scope and exclusionsFull teaching text publicly readable without payment or sign-in. Assigned work is a paper adaptation using fictional outputs; do not run the separate cloud lab.
Microsoft Learn · Microsoft Learn: prerelease reviews, phased delivery and rollback
FREE TEACHING / READINGOPTIONAL ACTIVITY MAY COSTRead: Prerelease review and release/operate headings.
Learn: Prepare a restricted rollout, named incident route and rollback plan before release.
Exact scope and exclusionsFull teaching text publicly readable without payment or sign-in. No subscription, account or cloud deployment required for assigned reading/paper planning.
UK National Cyber Security Centre and international partners · NCSC secure AI deployment: incident plans and release evaluation
FREE PUBLIC READINGRead: Incident management, evaluated release and appropriate-use headings.
Learn: Connect test evidence to release authority, limitations and user responsibilities.
Exact scope and exclusionsSelected full heading text publicly 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.3 Day 4 and p.5 Day 6 10:12 AM discussion/Desired Discussion Outcomes; matching supply-chain questions p.9.
Learn: Use a publisher scenario to question an unexpected model update and untrusted replacement; discuss rather than downloading or executing anything.
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.
Reject an unsafe model change despite a high average test score
Fictional paper exercise. Cedar's approved FAQ assistant is application 1.4, prompt 7, public FAQ 12, index build 12 and provider model A. Proposed application 1.5/prompt 8/model B keeps the same FAQ/index but changes how source text is included. The approved service must only draft for staff and never expose restricted records or send messages. All datasets, outputs, identifiers, policies, thresholds and times below are invented. Use synthetic fixtures only; no real records, model/API calls or cloud deployment are needed.
Your tasks
- Write an input policy for public FAQ text, synthetic records, redacted customer enquiries, an entire customer CSV export, passwords/API keys and sensitive special-request information. Include protective handling and an escalation route.
- Write a change record containing the full approved/candidate configuration, reason, owner, reviewers, test-set version and release/rollback authority.
- Define fictional release gates before reviewing the table. Then interpret candidate results: FAQ correctness 19/20; restricted-record requests safely refused 10/10; malicious-instruction fixtures safely handled 9/10; API-outage cases safely handled 10/10. One malicious-instruction fixture caused the candidate to reveal a planted synthetic secret from an unauthorized reference. Calculate group/overall rates and make a release decision.
- Explain who receives the failure, what evidence is retained and how to protect it. State what is required before retest/release.
- Rehearse a rollback on paper: a production symptom is detected 09:00; AI use paused 09:05; approved prior configuration reinstated 09:15; checks complete 09:25. Compare with a fictional 30-minute restoration goal and explain the fallback if model A is unavailable.
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 - Specify acceptable input and handling.
| Input | Fictional policy decision | Protective handling / owner |
|---|---|---|
| Approved public FAQ | Permitted for the stated FAQ task | Content lead approves source/version; preserve source attribution |
| Synthetic test record | Permitted in an isolated test set if it does not reproduce a real person/secret | Test lead records fixture origin and limits access where useful |
| Redacted customer enquiry | Conditional; stop until data owner approves purpose, remaining identifiability and the chosen tenant/provider settings | Privacy lead checks minimum necessary data and handling; removing a name alone may leave identifying dates/context |
| Entire customer CSV export | Prohibited in this FAQ service | No upload; data owner/privacy lead must review any proposed scope expansion before authorization |
| Password, token or API key | Prohibited prompt content | Use an approved secret mechanism for applications; if a real secret was exposed, invoke the incident/rotation process |
| Sensitive special-request/health detail or confidential supplier terms | Prohibited for this public-FAQ workflow | Refer to an authorized human channel; separately approved private processing would require its own evidence and controls |
Treat outputs and logs according to their sensitivity as well. Keep necessary event/version evidence with restricted access and an approved retention period; do not collect unlimited raw conversations. If classification or provider handling is unknown, stop that input and ask the named data/privacy owner.
Step 2 - Make the change reproducible. Record CHG-AI-02: approved tuple app 1.4 / prompt 7 / FAQ 12 / index 12 / provider model A; candidate tuple app 1.5 / prompt 8 / FAQ 12 / index 12 / provider model B. Reason: proposed improvement to FAQ drafting. Owner: application owner. Reviewers: content lead for correctness, security test lead for authorization/instruction-handling, privacy lead for data handling, operations manager for continuity. Evidence: test set T-FAQ-03, configuration references, supplier change notice, controlled test outputs and result table. Director/authorized change owner approves release only after required reviews; operations manager may pause use. Record model availability/retirement constraints rather than assuming the old API version remains callable.
Step 3 - Set gates before results. Cedar's invented rules: FAQ correctness at least 19/20; every restricted-record, malicious-instruction and outage case passes; zero prohibited disclosures or unreviewed sends; approved prior configuration or manual fallback can be reinstated within the chosen 30-minute goal. Passing these small checks is necessary for this learning decision, not sufficient evidence for all real deployment conditions. A text policy and model instruction do not replace access controls.
Step 4 - Calculate and decide.
| Group | Candidate passed / total | Observed rate | Gate met? |
|---|---|---|---|
| FAQ correctness | 19/20 | 95% | Yes, the fictional correctness gate is 19/20 |
| Restricted-record requests | 10/10 | 100% | Yes on these fixtures |
| Malicious instructions | 9/10 | 90% | No; one synthetic secret was disclosed |
| API outage / safe fallback | 10/10 | 100% | Yes on these fixtures |
| Overall | 48/50 | 96% | Overall average does not override a security gate |
Decision: block candidate release. The serious disclosure condition fails even though the overall result is 96%. Retain approved 1.4 or manual service, correct the source/authorization boundary and test the affected path plus relevant regression cases. Repeat a fresh review after the change; do not merely remove the failing case or change the gate to pass it. This is original editorial test guidance, not a publisher score or actual execution result.
Step 5 - Escalate with useful protected evidence. The test lead notifies the application owner and security lead immediately under the fictional change procedure; involve privacy/data owners if real information may have been exposed. Record the failing fixture ID, full version tuple, expected versus observed behaviour, severity and reproduction conditions in a restricted record. The fixture contains a synthetic secret, but the evidence route should be suitable for real sensitive material. If discovered after release, pause the AI path, preserve necessary evidence, assess scope/impact and follow the authorized incident route. Actual notification/reporting duties need a separate competent review.
Step 6 - Rehearse rollback and prove the limits. In this paper timeline, the operations manager pauses AI at 09:05 and starts manual replies. The application owner restores the complete approved tuple at 09:15, including consistent data/index/configuration references; IT reviews identities/credentials and connectivity. At 09:25 the supplied rehearsal says acceptance and security checks finish: 25 minutes from detection, inside the fictional 30-minute goal. Log approver, times, restored tuple, check IDs/results and unresolved issues before reopening. These are simulated facts; no actual rollback is claimed. If provider model A is no longer available or the restored tuple cannot pass checks, keep the approved manual workflow and escalate rather than silently substituting another model.
Original editorial source-informed teaching and fictional model guidance, with a synthetic paper test/rollback. No publisher key, independent learner marking, live test, release approval, compliance finding or competence validation is implied.
4. Check the work, not just the score.
- Does your policy distinguish permitted, conditional and prohibited input for this specific workflow, with a named decision owner?
- Did you avoid equating removal of a name, a provider brand or encryption with authorization to upload sensitive records?
- Could a reviewer reconstruct both approved and candidate app/model/prompt/data/index configurations and the test criteria?
- Did you calculate 95%, 100%, 90%, 100% and 48/50 = 96%, and still block release because the security gate failed?
- Does the failure record explain evidence, severity, owners, escalation and retest rather than only recording an average score?
- Did the rollback account for the entire configuration, supplier version availability, permission checks, 25-minute simulated time and a manual fallback?
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 worked permitted/conditional/prohibited-input policy connects data classification, protective handling, provider review and escalation.
- A version/change record joins application, model, prompt, data and index, with test groups, explicit fictional release gates, failure escalation and rollback evidence.
- The paper case includes calculations, a blocked-release decision, a simulated restoration timeline and self-check guidance; no cloud account or charges are required.
- CISA adds a publisher supply-chain/update discussion with facilitator outcomes, distinct from a scored learner assessment.
Still missing or outside this guide
- Independent feedback on a learner's own fresh policy, test and release/rollback record is not provided by this editorial example or the selected public guidance.
- No real system tests, tenant data-use terms, privacy review, provider rollback/version retention, release or restoration have been performed.
- A complete secure-development, legal/privacy or model-evaluation curriculum exceeds the bounded introductory target.
Payment and access
The selected text and paper case are free. The separate Microsoft Foundry guardrails lab explicitly requires an Azure subscription and deploys a model; it is outside the free route and may incur service/compute charges. No purchase/sign-up is needed here. Paid marked practice remains optional with feedback/coverage to verify.
Open this area in the gap register