Home › Study guides › CCAR-P › Domain 5 › Lesson 5.4

CCAR-P · Domain 5 · 14% of the exam · Lesson 5.4 · 22 min read

Compliance by design: GDPR, HIPAA and FedRAMP on Claude

How an architect turns GDPR, HIPAA and FedRAMP into design constraints for Claude: data maps, BAAs, retention, residency and authorised environments.

Written against objective 5.4 of the official CCAR-P exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

5.4.1 Why a working summary pipeline is not yet a compliant one

Quaymoor Health is a US telehealth provider. After every video visit, Claude drafts a visit summary from the clinician's notes and the transcript; the clinician edits and signs it, and the patient reads it in the app. The pipeline runs on the Claude API, and Quaymoor signed Anthropic's business associate agreement before the first real patient went through it. Then two pieces of news arrive in one week. Quaymoor will start treating patients in the EU next spring, and a US federal health agency has invited it to bid for a contract.

Yusra, Quaymoor's solution architect, is asked a question that sounds legal and is really architectural: "Can the summary pipeline take this on?" The model is not the obstacle. Claude summarises a visit in Lisbon as well as one in Ohio. What changes is where the data may travel, which companies may hold it and for how long, under which contracts, and what evidence Quaymoor must produce afterwards. Every one of those answers lives in the design: which endpoint receives the request, what the prompt contains, what the logs keep and who can read them.

That is why this objective belongs to the architect and not only to counsel. Hollis, Quaymoor's privacy officer, works out what each regulation requires of the company. Yusra decides how the system meets it and how she will prove it. This lesson reads each regulation as a set of design obligations, never as legal advice, and each obligation ends in a control you can point to.

5.4.2 Read each regime as constraints on data flows

Here is the mistake behind most failed compliance reviews: treating the model call as the only place regulated data lives. Follow one visit through Quaymoor's pipeline and count the copies. The transcript sits in the visit store, and parts of it travel in the prompt to the model endpoint. The draft comes back and is saved, then signed. Requests and responses land in logs and traces, and a sample joins the evaluation set used to test prompt changes. Add retrieval later, and chunks and embeddings become copies too. Every regime reaches all of them.

So the architect's first artefact is a data map: every store and flow, with its class of data, location, operator, retention period and readers. Each regime then becomes a set of questions you ask of every row.

Read the right-hand column as work, not law. Five controls recur in all three regimes. Minimise: send only the fields the task needs, redacted before the model. Place: decide where each class of data is processed. Limit retention: at the provider and in every store you run. Log for audit: who sent which data, where and why, without copying the content again. Restrict access: every row names its readers; how you authorise them is a topic of its own.

Applied to Quaymoor's two forgotten rows, those controls become settings. The request log keeps the request ID, the patient's record number, the fields sent, the route and the calling service, never the prompt text. Full prompts, kept only for debugging, sit in a trace store that the on-call group alone can read and that deletes them after seven days. The eval set is rebuilt from synthetic visits, so no real patient enters it.

5.4.3 What Anthropic's commitments cover, and what they leave to you

Hollis starts where every privacy officer starts: "Does Anthropic train on our patients' data, and how long does it keep it?" Answer from Anthropic's own pages (the Trust Center, the Privacy Center and the API docs) as they stand today, because these facts change and distractors misstate them. Where two pages differ in detail, design to the stricter reading; your signed agreements are the final word.

The provider limits its own copy; it cannot limit copies it never sees. A certificate is like a bonded courier's licence: it vouches for the locked van, not for what you packed or the photocopy you left on your desk. In precise terms, a provider's certification attests to the controls on its side of the boundary, and your data map covers the rest.

Two of those arrangements are easy to confuse. ZDR decides whether the provider may store your prompts at all. HIPAA readiness decides whether you may send PHI under a BAA; it allows retention, protected by safeguards such as encryption, access controls and audit logging. For PHI on the Claude API, Anthropic's docs point to HIPAA readiness and say you do not also need ZDR. So Quaymoor's HIPAA-ready organisation fits the visit summaries; ZDR would matter if a contract forbade provider storage outright.

5.4.4 HIPAA: a BAA, eligible features and the minimum necessary

"We signed the BAA, so we're covered" is the sentence Yusra hears most, and it is half true. HIPAA requires a business associate agreement with every vendor that creates, receives, keeps or transmits PHI on Quaymoor's behalf. The BAA with Anthropic covers the model call. The transcription service, the observability vendor and any tool that reads visit data each need their own, or must never see PHI. Data sent to third parties through connectors or external MCP servers is outside Anthropic's BAA. And on Amazon Bedrock and Google Cloud, the Trust Center marks HIPAA as partner-managed: coverage comes from the cloud provider's own terms, not from Anthropic's BAA.

On the Claude API, the BAA takes effect through a HIPAA-ready organisation, and three of its properties shape the design. It is enforced per organisation and cannot be switched off once enabled, so work that needs other features runs in a separate organisation with no PHI. The API blocks most features the BAA does not cover with a 400 error, among them the Batch API, the Files API and code execution, so the pipeline makes real-time Messages API calls. And PHI must never appear in a JSON schema for structured outputs, because Anthropic caches schemas apart from message content, without the same protections.

Then there is the minimum necessary standard: a use or disclosure of PHI should be limited to what its purpose needs. A summary needs the reason for the visit, the clinical findings, the medications and the follow-up plan. It does not need the patient's name, birth date, address or insurance number. So Quaymoor removes them before the call and puts the name back afterwards, in its own code. Look at the loop, which only ever reads the listed fields, and at the mapping returned beside the request, which never leaves Quaymoor's store.

SUMMARY_FIELDS = ("reason_for_visit", "clinician_notes", "medications", "follow_up")

def build_request(visit: dict) -> tuple[dict, dict]:
    safe, mapping = {}, {}
    for field in SUMMARY_FIELDS:                     # name, birth date, address, insurer ID never leave
        safe[field], found = redact(visit[field])    # masks names, phones, record numbers in free text
        mapping.update(found)                        # {"[PATIENT]": "Ana Ruiz", ...} stays in your store
    request = {
        "model": MODEL,
        "max_tokens": 2000,
        "system": SUMMARY_PROMPT,
        "messages": [{"role": "user", "content": render(safe)}],
    }                                                # sent with the HIPAA-ready organisation's key
    return request, mapping                          # your code restores the name in the reply

Redaction shrinks what leaves; it does not make the rest anonymous. The clinical text can still point to one patient, so Quaymoor treats it as PHI and the call still runs under the BAA: minimisation and the BAA are separate controls, and you need both.

5.4.5 GDPR: purpose, rights, processors and transfers

For EU patients, Quaymoor is the controller: it decides why and how the data is processed. On the Claude API, Anthropic is a processor acting on Quaymoor's instructions. Hollis names the lawful basis for each purpose; health data is a special category that needs an additional legal condition, and choosing it is her call. Yusra's job is to make that purpose enforceable, and each obligation lands on a part of the design.

• Purpose limitation. Transcripts collected to draft summaries are not automatically free for eval sets or prompt tuning. Tag records with their purpose, and build test sets from synthetic or de-identified visits unless Hollis approves the reuse.
• Minimisation. The same redaction step that serves HIPAA serves GDPR.
• Access and erasure. A patient's request for a copy or for deletion must cover every row of the data map. That works only if every derived copy (summary, log entry, eval case, embedding) carries the patient's identifier, and logs hold identifiers rather than content.
• Processor agreements. Anthropic's Data Processing Addendum (DPA), with Standard Contractual Clauses (the EU's model contract terms for transfers), is part of its Commercial Terms. Every other processor on the map needs its own agreement.
• Records of processing. The data map, kept current with each release, becomes the core of Quaymoor's record of processing activities.

The design decision is residency. On the Claude API, inference runs in any available geography by default, or only in the US with inference_geo: "us", and stored data rests in the US; the docs list no EU-only option today. GDPR does not forbid processing outside the EU. It requires a lawful transfer mechanism, such as the clauses in Anthropic's addendum. EU-only processing becomes a hard requirement when a contract or Quaymoor's own policy demands it, and then the route changes.

Quaymoor's EU partner clinics write EU-only processing into their contracts. So Yusra routes EU visits to an EU endpoint on the cloud partner that already hosts Quaymoor's EU stack, tests the summary prompt on the models offered there, and records the costs. Those visits are still health data that Quaymoor handles as PHI, so Hollis also confirms the provider's HIPAA terms for that route.

5.4.6 FedRAMP: build inside an authorised boundary

The federal bid raises a tempting question: "Our processing is already US-only, so we're fine for a federal agency, right?" No. FedRAMP is the US government's programme for assessing and authorising the cloud services agencies use, at impact levels such as Moderate and High. It is not a region setting. It asks whether a specific environment, inside a defined boundary, has had its controls assessed and authorised. The agency then grants an authority to operate (ATO) for the system it uses.

The authorisation belongs to the environment, not to the model. Anthropic's Trust Center marks FedRAMP High for three routes today: Claude for Government, Claude on Amazon Bedrock in AWS GovCloud, and Claude on Google Vertex AI in Google Assured Workloads. For the two partner routes it notes that the authorisation applies to the hosting environment, because Claude models are not standalone cloud services. The Claude API and Claude Enterprise are not in scope. Anthropic's public-sector FAQ adds that buying through a cloud marketplace changes nothing: Claude Platform on AWS is not FedRAMP authorised either.

The three routes serve different users. Claude for Government is Claude itself, the app people chat and code in, run inside an authorised government environment. A service that calls Claude from its own code takes one of the two partner routes.

For Quaymoor this means a separate deployment, not a setting. Agency visit data goes to Claude on Bedrock in AWS GovCloud, chosen because Quaymoor's federal environment will run on AWS. The federal deployment gets its own logs, traces and eval set inside the boundary, and nothing flows back to the commercial stack. The agency's authority to operate will cover Quaymoor's whole service, not just the model route, so Quaymoor documents its own controls and inherits the rest from the authorised environment beneath it. Before designing around any model or feature, Yusra confirms that the authorised environment offers it and has it in scope.

5.4.7 The exam traps

Every trap here puts the control in the wrong place: in a prompt, in someone else's certificate, or around one copy of the data.

• ✗ "Our provider is SOC 2 and ISO certified and signs a BAA, so our solution is compliant." ✓ Certificates cover the provider's side of the boundary. Your prompts, logs, eval sets, other vendors and access rules are yours to control and to evidence.
• ✗ Telling the model not to repeat names or other identifiers. ✓ Remove identifiers in code before the call. Once PHI is in the prompt it has already left your boundary; an instruction only shapes the output.
• ✗ Governing only the model call. ✓ Apply retention, erasure, residency and access rules to every derived copy. Encryption protects logs, traces and eval sets but neither limits nor erases them.
• ✗ Treating US-only inference, or any region setting, as FedRAMP. ✓ FedRAMP authorises an environment. Use an authorised route and keep the federal workload inside its boundary.
• ✗ Treating ZDR as the answer for PHI on the Claude API, or using a feature the BAA excludes. ✓ Send PHI through a HIPAA-ready organisation on eligible features. ZDR answers a different question, about provider storage.
• ✗ Assuming GDPR always means EU hosting, or that contract clauses satisfy an EU-only term. ✓ Let the requirement decide. A lawful transfer mechanism can be enough; an EU-only contract term needs an EU endpoint.

5.4.8 Put it together: map one workload across three regimes

You now have the method. Map every copy, read each regime as questions about those copies, take the provider's commitments for exactly what they cover, and answer the rest with your own controls. Quaymoor ends up with one summary feature and three deployments. To make it stick, build the minimisation gate, watch it catch a leak, and write the decision record Hollis will sign.

Compliance is one part of governing a Claude solution. Ethical considerations (5.5) ask what no regulation fully answers: whether the summaries serve every patient equally well, and whether patients know Claude drafted them. In Domain 6, the decision record you just wrote becomes the artefact for communicating trade-offs (6.2) and for documenting the architecture for the teams who will run it (6.4).

Key takeaways

• ✓ A regulation becomes design constraints on where data flows, who holds it, how long it is kept and what evidence exists, and the architect turns each constraint into a control.
• ✓ Map every copy of regulated data, including prompts, logs, traces, eval sets and indexes, because every regime applies to all of them.
• ✓ Anthropic's commitments cover only its own copy: no training on commercial data by default, at most 30 days of retention by default, ZDR by agreement, HIPAA readiness under a BAA, and audited certifications.
• ✓ HIPAA needs a BAA with every vendor that handles PHI and only the minimum necessary PHI per use; on the Claude API that is a HIPAA-ready organisation that blocks most ineligible features.
• ✓ GDPR needs a purpose, minimisation, rights that reach every copy, processor agreements and lawful transfers; EU-only processing today means an EU endpoint on a cloud partner.
• ✓ FedRAMP authorises environments, not models or regions, so a federal workload runs as a separate deployment on an authorised route such as Claude on Bedrock in AWS GovCloud.

Check your understanding

4 questions written for this lesson, then one from the CCAR-P question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• API and data retention
• Data residency
• Claude in Amazon Bedrock
• Anthropic Trust Center
• How long do you store my organization's data?
• Public sector FAQs
• The CCAR-P exam guide, summarised