What You Need to Know
An obligation becomes an architecture constraint when it changes what you build. Regulated data is data a law or contract restricts, such as personal data or protected health information. A hop is any place it reaches, sent or stored. A trust boundary is the edge of the systems trusted with it.
Take a courier firm whose assistant answers "where is my parcel" from delivery records holding names, addresses and phone numbers. For any system, name the regulated data class and trace every hop it reaches. At each hop, ask 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
Draw the data's path, not the application:
- the request to the model provider
- the retrieval index and its embeddings
- prompt and response logs
- the observability traces Domain 3 built
- the evaluation datasets Domain 4 built
- analytics and monitoring vendors, and the subprocessors behind them
At the courier firm, one address can reach the prompt, the log and a vendor's trace. Traces and evaluation sets are the most commonly forgotten copies. Domains 3 and 4 built them deliberately, yet they are easy to leave off a drawing of the application.
The ICO targets this failure: record every movement and storage of personal data, keep clear audit trails, and delete intermediate files once they are no longer needed. Stopping at the application boundary assesses the least interesting part of the system.
Minimise at the Boundary
Send only the fields the task needs. Redact, tokenise or pseudonymise regulated data before it crosses a trust boundary, and keep the re-identification key inside it. Once data crosses, the recipient holds it. The courier firm's assistant needs a parcel's status, so the customer's phone number stays behind.
The ICO adds a step architects miss, and makes it conditional. Depending on the likelihood and severity of the risk to individuals, you may also need to apply de-identification techniques to training data. That comes before the data is extracted from its source and shared internally or externally. Read "training data" as any dataset built from live records, such as the courier firm's evaluation set of real customer chats.
Agreements Precede the Data Flow
The obligation is to have this contract before the data moves. Otherwise regulated data sits with a party under no contractual restriction. The courier firm's trace vendor signs before the first trace is sent.
A HIPAA business associate contract has to:
- establish the permitted uses of protected health information
- require safeguards and breach reporting
- bind any subcontractor to the same restrictions
- at termination, return or destroy every copy where that is feasible, extending the contract's protections to whatever cannot be returned or destroyed
The last two break naive architectures. Flow-down reaches every vendor in the path, including the ones your vendor chose, such as the courier firm's analytics subprocessors. Return-or-destroy reaches the evaluation set nobody listed. The infeasibility route is no escape: it binds you to keep protecting what you could not remove.
Purpose, Retention, Residency, and the Rights That Follow the Copies
Purpose and retention are design inputs, decided before launch for every copy and the primary store. Where inference runs and where data rests are configuration decisions with compliance consequences. State the requirement durably, then verify the current regional options live.
Data-subject rights are engineering work. Access, correction, deletion and portability all require finding every copy, which needs provenance and an inventory. Vector indexes, trace stores and evaluation fixtures are where deletion requests miss copies. A courier firm customer's erased address can survive in an embedding or a trace. A provider's retention or residency arrangement governs that provider, not what your own copies do.
FedRAMP and the Authorisation Boundary
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, not from FedRAMP, which makes it durable. So the durable half of FedRAMP sits with the agency, not the programme.
A FedRAMP authorisation certifies that a cloud service completed the FedRAMP process. It is not an authorisation to operate: the agency's authorising official still makes that decision for their environment.
The live question is which services carrying federal information are already authorised at the required impact level. Anything that is not brings itself, and its assessment burden, inside the boundary the agency must authorise. That is why the choice belongs in design. A courier firm carrying federal information would ask it of each vendor.
In the exam
Items here do not test statute. They test whether you turn an obligation into a design constraint, and how far you think it reaches. In a stem about an over-broad flow, the keyed answer nearly always reduces what crosses: fewer courier fields reaching the trace vendor. The ICO condition is the risk, so an item that establishes a serious one has already answered it.
Sort the Options by What Still Crosses
When a stem describes too much data crossing a boundary, sort the options by what still crosses afterwards. Only one changes that number, usually the one that reads as the most work.
The programme's own rule for what a FedRAMP provider must have assessed was restated in 2026, and its labels moved with it. Treat that mechanism and its vocabulary as quick-reference material, never as the thing an item turns on.
Exam Traps
Adding a privacy notice, transit encryption, or a shorter retention window while the same fields keep crossing
Each is a genuine control aimed at a different problem, which is what makes them convincing. None of them reduces what the recipient receives, so the minimisation finding survives all three untouched.
Drawing the assessment around the user-facing application while logs, traces, retrieval indexes and evaluation sets sit outside it
Those are copies of the same regulated data, created on purpose by Domains 3 and 4. Retention limits, deletion requests and processor agreements all reach them, and a stem that mentions an observability vendor or an evaluation dataset is testing precisely this.
Putting the processor agreement in place at the vendor's next contract renewal
The obligation attaches before the disclosure, not after the pilot. Regulated data would flow to a party under no contractual restriction, with no subcontractor flow-down and no return-or-destroy obligation covering the copies it makes.
Restricting the destination system to a few named people, or collecting consent, for an over-broad flow
Fewer readers, identical exposure: the data still left and the recipient still holds it. A lawful basis licenses processing that is necessary; it cannot make an unnecessary flow necessary, and the necessity test asks whether a less intrusive route to the same purpose exists.
Practice Scenario
An occupational-health provider is building an assistant that answers employer queries using employee health assessments. The proposed design streams retrieved assessment excerpts to a third-party observability vendor for trace capture, and keeps an evaluation dataset built from real assessments, indefinitely, in a shared analytics account. The provider may not disclose health data to a vendor without a contract in place, or keep it longer than it needs it for. What should the architect require?
Build Exercise
Trace the Compliance Path for One Regulated System
What you'll learn
- How to enumerate every hop a regulated data class reaches, including the ones built for observability and evaluation
- How to test each hop against purpose, retention, location and the agreement that covers it today
- How to locate the first gap and understand what inherits it downstream
- How to prefer remedies that reduce what crosses over remedies that leave the flow intact
- How to write the deletion story and find the copy you could not currently reach
- Name the regulated data class your system touches and write the exhaustive list of hops it reaches, including prompt and response logs, observability traces, the retrieval index and its embeddings, evaluation datasets, and every analytics or monitoring vendor
Why: Scope drawn around the application is the single most common finding, and the forgotten hops are always the ones another domain built.
You should see: A numbered hop list where at least three entries are internal artefacts rather than external systems.
- At each hop record four things: the purpose that justifies it holding this data, the retention period, the location, and the agreement that covers it today
Why: These are the four questions an assessment asks, and writing them per hop turns a vague worry into a specific finding.
You should see: A four-column table with one row per hop and no cell left as to be confirmed.
- Mark the first hop where any of those four is missing, and note what inherits the same gap downstream
Why: The first gap is the finding, and everything downstream of it carries the same defect whether or not it has its own paperwork.
You should see: One marked hop and a downstream list, usually longer than the team expected.
- For each gap, choose a remedy that reduces what crosses before considering any remedy that leaves the flow intact
Why: The keyed answer in this objective nearly always reduces what crosses, and forcing the order stops the notice-and-encryption reflex.
You should see: A remedy per gap, with the fewer-fields, de-identification and synthetic-data options considered first and the rest recorded as supplementary.
- Write the deletion story: given an erasure request, list every copy you would have to find, and name the one you currently could not
Why: Data-subject rights are engineering work, and the copy you cannot reach is the honest state of your provenance and inventory.
You should see: A copy list with a reachability verdict per entry, and at least one entry marked as unreachable today.
Sources
- How should we assess security and data minimisation in AI? — Information Commissioner's Office
- Business associate contracts (45 CFR 164.504) — Electronic Code of Federal Regulations
- NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations — US National Institute of Standards and Technology
- OMB Circular A-130: Managing Information as a Strategic Resource — US Office of Management and Budget
- API and data retention — Anthropic
- Data residency — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 5 — Anthropic