What You Need to Know
An obligation becomes an architecture constraint when it changes what you build. Regulated data is data that a law or contract restricts, such as personal data or protected health information. A hop is any place that regulated data reaches, when it is sent there or stored there. A trust boundary is the edge of the systems that are trusted with regulated data.
This lesson uses one made-up example throughout: a health insurer. Its assistant answers "is my claim paid" from claim records. These records hold names, addresses and diagnoses. For any system, name the regulated data class and trace every hop that this data reaches. At each hop, ask one question. May this hop 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 insurer, one diagnosis 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 it is easy to omit them from a drawing of the application.
The ICO, the UK data protection regulator, addresses this failure. It says to record every movement and storage of personal data, keep clear audit trails, and delete intermediate files once they are no longer needed. If you stop your assessment at the application boundary, you do not assess the copies outside it, such as the traces and evaluation sets.
Minimise at the Boundary
Send only the fields the task needs. Redact, tokenise or pseudonymise regulated data before it crosses a trust boundary. Tokenising and pseudonymising replace a real value with a substitute. Keep the re-identification key inside the boundary. Once data crosses the boundary, the recipient holds the data. The insurer's assistant needs a claim's status, so the customer's diagnosis stays inside the boundary.
The ICO adds a step that architects miss, and the ICO makes this step conditional. Depending on the likelihood and severity of the risk to individuals, you may also need to apply de-identification techniques to training data. This step 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 insurer's evaluation set of real customer chats.
Agreements Precede the Data Flow
A vendor that receives regulated data needs a contract that restricts its use. The obligation is to have this contract before the data moves. Otherwise a party that no contract restricts holds the regulated data. The insurer's trace vendor signs before the first trace is sent.
HIPAA is the US law that protects health information. A business associate is a vendor that handles it for an organisation that the law covers, such as an insurer. 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, and extend the contract's protections to whatever cannot be returned or destroyed
Naive architectures fail the last two. Flow-down, the rule that binds subcontractors, reaches every vendor in the path, including the ones your vendor chose, such as the insurer's analytics subprocessors. Return-or-destroy reaches the evaluation set nobody listed. Saying that return or destruction is not feasible does not end the obligation: 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. Decide them before launch, for every copy and the primary store. Where inference runs and where data is stored are configuration decisions with compliance consequences. State the requirement in terms that will not go out of date, then verify which regional options are available now.
Data-subject rights, the rights of people over their own personal data, need engineering work. Access, correction, deletion and portability all require you to find every copy. Finding every copy needs provenance and an inventory. Deletion requests miss copies in vector indexes, trace stores and evaluation fixtures. At the insurer, a customer's erased address can remain in an embedding or a trace. A provider's retention or residency arrangement governs that provider. It does not govern what your own copies do.
FedRAMP and the Authorisation Boundary
FedRAMP is the US government programme that assesses cloud services for federal agencies. An authorising official is the agency official who approves a system. An authorisation boundary is all components of an information system to be authorised for operation by an authorising official. It excludes separately authorised systems that the information system connects to. That definition comes from OMB Circular A-130 and NIST SP 800-37, not from FedRAMP. Because of this origin, the definition is unlikely to change. So the part that is unlikely to change is the agency's boundary, not FedRAMP's own rules.
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 current question is which services that carry federal information are already authorised at the required impact level. The impact level rates the harm that a breach would cause. Any service that is not already authorised at that level brings itself, and its assessment burden, inside the boundary that the agency must authorise. That is why the choice of services belongs in design. An insurer that handles claims for a federal agency would ask this question about each vendor.
In the exam
Questions 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 question about an over-broad data flow, the right answer nearly always reduces the data that crosses the boundary. At the insurer, that answer sends fewer fields to the trace vendor. The ICO condition is the risk, so a question that establishes a serious risk has already answered that condition.
Sort the Options by What Still Crosses
When a question describes too much data crossing a boundary, sort the options by what still crosses afterwards. Only one option changes that number. Usually it is the option that reads as the most work.
In 2026, the programme restated its own rule for what a FedRAMP provider must have assessed. The rule's labels changed at the same time. Treat that mechanism and its vocabulary as quick-reference material, never as the thing that a question depends on.
Exam Traps
Adding a privacy notice, encryption, shorter retention, access limits or consent while the same fields keep crossing
Each is a real control aimed at a different problem, so each looks convincing. None reduces what the recipient receives. Send only the fields the task needs, and pseudonymise them before they cross, keeping the key inside.
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, so they belong inside the assessment.
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.
Treating a supplier's FedRAMP authorisation, pending or granted, as the agency's own authorisation to operate
FedRAMP certifies that a service completed the process; it is not an authorisation to operate. The agency's authorising official still decides. Choose a service already authorised at the required impact level, or keep the component inside the boundary the official will authorise.
Practice Scenario
A workplace 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 describe the deletion process 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 right answer in this objective nearly always reduces what crosses, and forcing the order stops the automatic choice of a notice and encryption.
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.
- Describe the deletion process: 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 shows the real 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