Quick Reference: Domain 5 — Governance, Safety & Risk Management

Words in the question that decide the surface: never reaches and before it is sent resolve to the output gate or removal · cannot be undone resolves to capability scoping or a human gate (a person who must approve the action first) · after the fact describes a detective control, the wrong option wherever the requirement was a guarantee.

• An instruction is not an access control. If the capability is connected to the system, an instruction not to use it is a request. Highest-frequency wrong answer in the domain; it returns in Domains 3 and 7.
• Untrusted content is everything the system did not author: retrieved documents, tool results, connector payloads, uploaded files, web content. Structural mitigations only — deliver it inside tool results and nowhere else, declare its origin, JSON-encode it where possible so an attacker cannot escape the data context, state in the system prompt that tool content is data to report rather than commands to follow, screen tool output before the model acts, scope access so a successful injection can do little harm, and red-team with deliberately adversarial documents first.
• Screening reduces frequency; scoping bounds consequence. Detection helps, but least privilege is what reliably limits the harm.
• Where a property must hold every time, structured outputs guarantee schema conformance in most cases (check stop_reason for a refusal or a max_tokens cut). Prompt wording makes the property likely, not certain.

Five fields per row, each changing something about the build: mechanism · blast radius · detection signal · owning control, with its 5.1 surface · residual, and who signed for it. A risk with no owning control is an accepted risk, and acceptance is a decision somebody signs.

• Rank by consequence and detectability, not likelihood. A rare irreversible action outranks a frequent reversible one; a failure that nobody notices, in a part of the system with no monitoring, outranks one that is noticed.
• "How would we notice" is a required column. A row whose honest answer is "a customer would complain" has no detection, and it catches only the harms people bother to report.
• Anthropic's Responsible Scaling Policy has the same structure one layer lower: capability thresholds with a committed safeguard upgrade when one is reached.
• Its hallucination guidance ends with the point the register depends on: the techniques reduce hallucinations substantially, do not eliminate them, and critical information must always be validated.

Decide where the human gate goes before you choose the pattern. Reversibility and blast radius decide — not seniority, not squeamishness, not a fixed percentage.

• An answer that mixes patterns is usually the right one. In a question with both a throughput constraint and a reversibility distinction, the right answer is the option that uses different patterns for different actions.
• A gate is a control with a performance number: override rate, reviewer agreement, time per item. An override rate rounding to zero at high daily volume means reviewers approve without real review, and the finding is either that reviewers cannot see enough or that the gate sits in the wrong place.
• The ICO test for meaningful review: a decision does not fall outside the automated-decision rules just because a human signed it. Reviewers need the authority and competence to go against the recommendation, and one restricted to the data the system used is arguably not weighing additional factors at all. Automation bias is not fixed chiefly by training reviewers; the controls belong in place from scoping and design.
• Expect these five patterns as a matching drill: short arrangements classified against the pattern each one implements, with any option usable once, more than once, or not at all. Score such a question all or nothing when you practise it. The guide states only that each question says how many responses to select, and gives no partial-credit policy, so treating a part-right mapping as wrong is the safe way to rehearse it.

The method, every time: name the regulated data class → trace every hop it reaches → ask at each hop whether it may hold this data, for this purpose, for this long, in this place, under an agreement that exists today. The gap is the first hop where the answer is no.

• Scope is the whole data path, not the application: the model provider, the retrieval index and its embeddings, prompt and response logs, the traces Domain 3 built, the eval datasets Domain 4 built, analytics and monitoring vendors, every subprocessor behind them. Traces and eval sets are the forgotten copies, and a question naming an observability vendor or an evaluation dataset is testing exactly that.
• Minimise at the boundary. The ICO instruction architects miss, stated as a conditional: depending on the likelihood and severity of the risk to individuals, you may also need to apply de-identification techniques to training data before it is extracted from its source and shared internally or externally. Read "training data" as any dataset built from live records, and the eval set is in scope. Do not quote it as an unconditional rule; the risk is what triggers it.
• Agreements precede data flow. A HIPAA business associate contract must establish permitted uses and require safeguards and breach reporting. It must bind subcontractors to the same restrictions. It must support access, amendment and an accounting of disclosures. At termination, if feasible, the information must be returned or destroyed with no copies retained. Where return or destruction is not feasible, the contract must extend its protections to the information and limit further uses to the purposes that make removal infeasible. Flow-down (binding subcontractors to the same restrictions) and return-or-destroy are the two clauses that simple designs fail to meet, and the exception for when return or destruction is not feasible is exactly the case a vector index, a backup or an evaluation fixture presents.
• Rights are engineering work. Access, correction, deletion and portability all require finding every copy, which requires provenance and an inventory. Vector indexes, trace stores and evaluation fixtures are the places where deletion requests fail.
• Evidence is a feature you must build. Audit trails, access records, decision logs and change history are compliance requirements in their own right; Domain 3 builds them, Domain 5 sets retention and readership.
• Dated-source note: the ICO pages behind these durable principles currently carry a banner saying the guidance is under review following the Data (Use and Access) Act. Treat them as design principles rather than clause-level assertions.

Every value here is dated — verify live before it reaches a design document, and never let the answer to a question depend on one. The durable claim has two parts. Retention, residency and eligibility are configuration decisions with compliance consequences that belong in the design conversation. A provider arrangement governs the provider, never your own logs, indexes and eval sets that hold the same records.

• Zero data retention (ZDR): available per organisation by arrangement; prompts and responses are not stored at rest once the response has returned. It does not cover Console usage (including the playground, formerly Workbench), stateful features (the Files API, batch processing, code execution, Managed Agents), consumer products, or third-party integrations.
• Default retention: 30 days for Covered Models. Content flagged by trust and safety systems may be retained for up to two years regardless of ZDR or HIPAA readiness — the exception that applies under every arrangement.
• HIPAA readiness: the alternative to ZDR where protected health information is involved, under a signed BAA (business associate agreement). It applies encryption, access controls and audit logging across the data lifecycle rather than immediate deletion. It is enabled and enforced at organisation level. It cannot be disabled once accepted. The API rejects requests that use features the BAA does not cover. An organisation handling PHI needs HIPAA readiness rather than ZDR, and HIPAA and non-HIPAA workloads require separate organisations.
• Data residency: an inference geo set per request (us or global), and a workspace geo fixed at creation (us only at present).
• Third-party integrations sit outside these arrangements entirely, with the documented instruction to review each service's own data-handling practices. This means the provider is telling you that the third-party surface is a risk you must record on your register.

Some placements are settled before the architecture conversation, which turns "should there be a human here" into "where does the qualified person sit, and what do they see".

• Disclosure baseline: all consumer-facing chatbots or AI agents that communicate directly with external users must disclose that the user is interacting with AI rather than a human, at a minimum at the beginning of each chat session or in the product interface. This holds whether or not the product makes High-risk AI Recommendations.
• The requirements attach to a recommendation about one person, and the scope is part of the rule. They apply to anyone who uses Claude to make a High-risk AI Recommendation: advice to an individual who might rely on it, or a recommendation used to implement a decision about them. The exclusions cover general or educational information not applied to the person's circumstances, wellness content, internal drafting or analysis that is not the final recommendation delivered, carrying out a decision a person has already made, and business operations that do not advise or decide about a specific individual. Read a question for what the output does, and to whom, before deciding the policy compels anything.
• High-risk Areas named as of October 2026: legal advice to an individual · medical diagnosis, treatment and medication, including mental health · personalised investment and tax advice · credit decisions and creditworthiness assessments · insurance underwriting, claims and coverage · housing applications, tenancy termination and eviction · employment decisions from screening to dismissal · admissions, high-stakes grading, professional licences and academic misconduct · healthcare access, triage and eligibility · public benefits and essential services · legal status and adjudication, including immigration. Read the current list rather than memorising this one.
• Two controls attach there: a qualified person, with the authority to change or modify the recommendation, meaningfully reviews it before it is delivered as advice or used to implement a decision, and stays responsible for what is delivered or decided. The person it concerns is clearly told that AI was used to produce it. Where the law permits, one of four listed decisions wholly favourable to the person, such as paying an insurance claim or granting a public benefit, can go ahead without that review. A partial or conditional approval does not count.
• The exception is a real distinction, not a minor detail. A nutrition or sleep assistant gives wellness content, which the policy excludes. The same assistant interpreting a blood result or adjusting a treatment is giving medical advice, which is a High-risk Area. A human still belongs in plenty of wellness designs, but on the architect's judgement about consequence rather than because the policy compels it.
• The judgement is contractually the customer's. Anthropic's commercial terms place evaluating whether outputs are appropriate, including where human review is appropriate, on the customer before outputs are used or shared.
• Anthropic's own transparency work — model summaries covering capabilities, safety evaluations and deployment safeguards, and the RSP commitment to publish key information about evaluation and deployment — is evidence about the component and none at all about your application.

Durable — state this as the obligation. An authorisation boundary is all components of an information system to be authorised for operation by an authorising official, excluding separately authorised systems it connects to. That definition comes from OMB Circular A-130 and NIST SP 800-37 Rev. 2, not from the FedRAMP programme, which is what makes it stable. A FedRAMP authorisation certifies that a cloud service completed the FedRAMP process. It is not an authorisation to operate. The reason is that the agency's own authorising official still decides for their environment, and still establishes that environment's boundary under OMB and NIST guidance. The tested consequence is this. Any component that carries federal information and is not already authorised at the required impact level brings itself, and its assessment work, inside the boundary the agency has to authorise. That is why the choice belongs in design rather than assessment.

As of mid-2026: The programme's own rule for what a provider must have assessed is now settled, and it is not the one older material describes. The Minimum Assessment Scope launched on 24 June 2026 as part of the FedRAMP Consolidated Rules for 2026. It replaced the former Boundary approach. Providers must identify the set of information resources that handle federal information or are likely to affect its confidentiality, integrity or availability, and assess those. Two labels changed with it — FedRAMP no longer defines authorisation boundary as a programme term, and the scoping unit is the cloud service offering. Re-verify the current wording before using any of it, and don't answer an exam question from the programme mechanism: it is the part of this domain that changes fastest. The Anthropic documentation reviewed for this domain makes no FedRAMP claim for the Claude API either, so here FedRAMP is about how to draw the boundary, and never a claim about the platform's status.

Read the wrong answers here as the trap they are: each one sounds more rigorous than the right answer, which is exactly why it gets picked.

• Bias is a property of measured outcomes, not of input fields. Dropping the protected attribute is fairness through unawareness: features correlate with protected characteristics in non-obvious ways, and modern machine learning finds those combinations and redundant encodings (the same information carried in several variables) more readily than traditional statistics. Working hours (ranking redundancy candidates on hours worked discriminates by sex where more women work part-time), occupation, application channel, address history and language register (the style and level of formality of a person's writing) all carry the signal.
• Proxies are one entry point of several. Bias also enters through how variables were measured, labelled or aggregated; through the builders' cultural assumptions; through an objective (the goal the model is built to optimise) whose "best outcome" embeds an assumption about who is worth optimising for; and through an interface that is not accessible, harming a group of people before the model acts.
• Measurement means disaggregation. Aggregate accuracy is a weighted average dominated by the majority, so a cohort failure is invisible in it at any level of precision — a tighter confidence interval measures the majority more precisely. Cohorts come from a harm hypothesis, not from data availability.
• Criteria conflict, so one is chosen and stated. Equal error rates across groups, equal selection rates and calibration within groups cannot generally all hold at once. Fairness metrics identify discriminatory impacts but are not likely to guarantee compliance or explain why unfairness occurs, so they sit inside a broader non-technical framework. The right answer names a criterion and justifies it against the harm; the wrong option asserts the system is unbiased.
• Remediation steps, cheapest and most durable first: fix the data (representation, labels, and the population the ground truth came from; ground truth is the correct answers the model learns from) → fix the framing (what the model is asked to decide, and whether that decision suits a model at all) → constrain the decision (score and rank rather than decide, human adjudication for affected cases, a narrower remit) → monitor continuously, because decisions change the world that produces the next round of input data. Hiding the score is not a remediation step, and neither is blaming the base model.
• Three transparency obligations, and wrong options reliably answer a different one: disclosure to the user at the point of use · explainability to the affected person, meaning an outcome-based explanation in plain everyday language, saying whether a human was meaningfully involved, with a timely route to contest · traceability to the organisation, meaning which version, which prompt, which retrieved context, retained long enough to answer a challenge months later.
• Accountability does not transfer to the tool. A named human or role owns the outputs, and senior management is expected to sign off the intended use against the organisation's risk appetite (the amount of risk it is willing to accept), with a clear statement of who is accountable for what from the outset.

Where Domain 5 stops. Domain 2 owns prompt-guardrail mechanics and model choice; Domain 5 sets the policy they enforce. Domain 3 wires tool scoping, identity propagation (tool calls carry the authenticated user's identity), secret handling and traces; Domain 5 decides which must exist. Domain 4 measures safety, bias and quality; Domain 5 covers the obligation to measure, the unacceptable threshold, and what changes when the number is bad. Domain 6 covers presenting the analysis to executives and legal teams. Domain 7 implements this policy in developer environments.

The catalogue, in one pass. A firmer instruction is context, not enforcement. A more capable model is unrelated to authorisation scope. Logging against a "never reaches" requirement answers a preventive requirement with a detective control, and a confirmation step on a capability the role never needs adds an extra step to a privilege that should not exist. A high accuracy figure carries no reversibility, exposure, recourse or detection; a larger back-test (a test on past data) gives the same kind of evidence about the same property. Approve-everything fails the throughput requirement the scenario already stated. Notice, transit encryption, shorter retention, access restriction and consent all leave the same records crossing. No protected attribute collected proves nothing while proxies remain; base-model attribution ignores four things the application team can change; a model card offered as disclosure is the right artefact for the wrong audience at the wrong moment.

Sort a compliance question by what still crosses afterwards, and a guardrail question by which surface the named risk needs.