Claude Certification Guide CCAR-P

Curriculum › Governance, Safety & Risk Management · 14% of the exam

Regulatory compliance: GDPR, HIPAA, FedRAMP

What you’ll be able to do

  • Explain what GDPR, HIPAA and FedRAMP each govern and the architectural requirements that follow from each
  • Map every place regulated data flows in a Claude system (prompts, logs, vector stores, caches, eval sets, tools, MCP servers) and apply minimization and retention to each
  • Determine which agreements and authorizations (data processing agreements, business associate agreements, FedRAMP authorizations) must cover which components before regulated data flows
  • Design access control, audit logging and erasure paths that compliance teams can verify

What you need to know

This lesson covers architectural implications, not legal advice. Whether a deployment meets a regulation is for your legal and compliance teams to decide; the architect builds a system whose data flows they can assess.

The core idea: compliance follows the data

A model call is one hop in a longer path. Regulated data in a Claude system typically touches the client, an API gateway, prompt assembly, the model endpoint, conversation storage, application logs, tracing and observability tools, vector indexes and the documents behind them, caches, evaluation datasets built from production traffic, tool backends and MCP servers, and any third-party services those tools call. Every one of those is in scope. The common failure isn't the model endpoint. It's the debug log, the analytics SDK or the community MCP server that quietly receives the same data with no agreement covering it.

Start every regulated design with a data-flow inventory: each component, what data classes it receives, where it runs (region), who operates it, which agreement covers it, and how long it keeps data.

GDPR: personal data of people in the EU

The EU General Data Protection Regulation governs the processing of personal data about individuals in the EU, with broad territorial reach. Its principles turn directly into architecture:

  • Lawful basis and purpose limitation. Process data only for defined purposes. Reusing support transcripts to build an unrelated product feature or an eval set needs its own justification.
  • Data minimization. Send the model only the fields the task needs. Redact or pseudonymize identifiers before prompt assembly where the task allows it, and retrieve narrowly rather than dumping whole records into context.
  • Storage limitation. Set retention periods for transcripts, logs and derived data, and enforce them automatically.
  • Data subject rights. Access, rectification and erasure requests have to reach every copy: primary stores, vector indexes (delete or re-embed the affected chunks), conversation history, caches, backups according to policy, and eval datasets. If you can't find a person's data in your index, you can't erase it, so keep metadata that links chunks back to their source records.
  • Processors and transfers. Vendors that process personal data on your behalf need a data processing agreement, and transfers outside the EU/EEA need a recognized transfer mechanism. Know which region each component processes in, and who its subprocessors are.
  • Automated decisions. GDPR restricts decisions based solely on automated processing that have legal or similarly significant effects on a person, and requires safeguards such as the ability to get human intervention and to contest the decision. For credit, hiring or benefits use cases, design a meaningful human review step (5.3) and an explanation path (5.5).
  • DPIAs. High-risk processing calls for a data protection impact assessment. Your data-flow inventory and risk register (5.2) are its raw material.

HIPAA: protected health information in the US

HIPAA governs protected health information (PHI) handled by covered entities (health plans, most healthcare providers, clearinghouses) and by their business associates, the vendors that create, receive, maintain or transmit PHI for them. Architectural implications:

  • Business associate agreements. A BAA must be in place with each vendor in the PHI path before PHI flows to it. Confirm exactly which services, endpoints and features the agreement covers. Don't assume every feature or product a vendor offers is in scope.
  • Minimum necessary. Limit PHI in prompts and retrieval to what the task requires. Where the task doesn't need identity, de-identify using a recognized method rather than an ad hoc redaction.
  • Security Rule safeguards. Role-based access control, unique user identification, audit controls that record who accessed which PHI, integrity protections, and encryption in transit and at rest.
  • Keep PHI out of uncovered components. Error trackers, prompt-observability tools, analytics, developer laptops and test fixtures are the usual leaks.

FedRAMP: cloud services for US federal agencies

FedRAMP is the US government program that standardizes security assessment, authorization and continuous monitoring of cloud services used by federal agencies. It's built on NIST security controls, with impact levels (Low, Moderate, High) set by the sensitivity of the data. Architectural implications:

  • Authorization is scoped to a defined system boundary and impact level. It applies to a specific service offering, not to a vendor's whole catalog, and may be limited to particular environments or regions. Verify the current status of each specific service against the official FedRAMP sources and the agency's own requirements.
  • Every component handling federal data must sit inside an appropriately authorized boundary. That includes the model endpoint, vector store, logging, CI/CD and any tool or MCP server. Agencies then grant their own authority to operate for the overall system.
  • Continuous monitoring. Expect vulnerability management, audit logging, incident reporting and change control. Treat model version changes, new tools and new data sources as changes that go through that process.

Controls that serve all three

  • Data classification at ingestion, so routing, redaction and retention rules can key off it.
  • Identity-scoped access. Tools and retrieval run with the end user's authority, so the model can't surface records the user isn't allowed to see (5.1).
  • Audit logging designed for compliance. Record who did what, to which record, and when. Weigh this against minimization: log identifiers and metadata by default, and keep full prompt and response capture in a restricted, retention-limited store, only where it's justified.
  • Environment separation. Regulated workloads get their own deployment path, keys and logging, so a debug setting in a shared environment can't leak them.

Key concept

Compliance is a property of the whole data flow: inventory every component that touches regulated data, minimize what reaches each one, verify that the right agreement or authorization covers each, and make access, audit and erasure work everywhere data lands.

Questions often frame compliance as a model choice or a single vendor checkbox. Prefer answers that find the uncovered hop (logs, tools, indexes, eval sets), minimize data before it reaches the model, or verify the scope of an agreement or authorization. Be wary of any option that asserts a product "is compliant" as if that settled the question.

Practice scenario

ScenarioA hospital network is piloting a discharge-summary assistant. The team has confirmed with legal that the model endpoint they use is covered by a BAA. The app also sends full prompts and completions to a third-party LLM-observability SaaS for debugging, uses a community MCP server to fetch drug-interaction data by passing it the patient's full medication list and demographics, and copies interesting production transcripts into the eval repository in the team's general-purpose source control.
Work it through, then open this

Three hops carry PHI outside the covered path. First, the observability SaaS receives full PHI. Either bring it under a BAA or stop sending content to it, logging metadata and redacted traces instead. Second, the MCP server gets demographics it doesn’t need. Send only the medication list in a de-identified form, and either run the server inside the covered environment or put its operator under an agreement. Third, the eval transcripts are PHI copied into an uncovered system. De-identify them with a recognized method before they leave the regulated environment, or keep the eval set inside it with access controls and retention. Then document the data-flow inventory so compliance can verify it, and add a control (for example, egress restrictions from the regulated environment) so a new integration can’t recreate the leak.

Build exercise — Build a regulated data-flow inventory

Advanced · 50 min

What you’ll learn

  • Tracing regulated data through every component of a Claude system
  • Matching each component to the agreement or authorization that must cover it
  • Designing an erasure path that reaches derived stores

  1. Draw the data flow for one Claude feature, from user input to downstream action, including logs, traces, caches, vector stores, eval sets, tools and MCP servers. For each node, record the data classes it receives, its region, its operator, its retention, and the agreement or authorization that covers it.

    • Why: Compliance gaps live in the nodes nobody drew. The inventory is also what your privacy or security team needs for a DPIA or an authorization package.
    • You should see: At least one node receiving regulated data with no confirmed agreement, or with retention longer than its purpose requires.

  2. Apply minimization at prompt assembly: list which fields each task actually needs, and specify redaction, pseudonymization or de-identification for the rest (illustrative: a pre-assembly filter keyed on data classification).

    • Why: Data that never reaches a component can’t leak from it or need erasing from it.
    • You should see: A measurable reduction in the regulated fields reaching the model and the logs.

  3. Walk an erasure request for one individual through every node, including how you’d find and remove their chunks in the vector index and their transcripts in eval data.

    • Why: Erasure that stops at the primary database leaves copies in derived stores.
    • You should see: A documented path for every node, plus any node where you’d need to add source-record metadata to make erasure possible.

Exam traps

Assuming a system is compliant because the model provider is, or because one component is covered

Compliance is assessed for the whole system and its data flows. One covered hop says nothing about the logging, tools or indexes around it.

Covering the model endpoint but sending regulated data to logging, analytics, tracing or third-party tool services outside the agreement

These are the most common leaks. Every component that receives regulated data needs coverage, or needs to stop receiving that data.

Honoring a GDPR erasure request in the primary database but not in vector indexes, transcripts, caches or eval datasets

Derived stores hold copies. Keep source-record metadata so you can find and remove them.

Sending whole records to the model when the task needs a few fields

Minimization (GDPR) and minimum necessary (HIPAA) both point the same way: assemble the prompt from only the fields the task requires.

Fully automating a decision with legal or similarly significant effects on individuals without the safeguards GDPR expects

Design for meaningful human intervention, an explanation and a way to contest the decision, and involve privacy counsel early.

Treating a FedRAMP authorization as covering every service, region and feature a vendor offers

Authorizations are scoped to a defined boundary and impact level. Verify each specific service you use.

Logging full prompts and responses indefinitely by default for debugging

That turns your logs into an unmanaged regulated data store. Log metadata by default and keep content capture restricted and retention-limited.

Sources

Quick check

A US clinic network's legal team has confirmed a business associate agreement covering the Claude model endpoint the team uses. The engineering plan also sends full request and response payloads to a third-party tracing service, and uses a public MCP server to normalize medication names. What is the most important architectural change before PHI flows?