Claude Certified Engineers logoCCE

CCAR-P · Study Guide

← Domain 5: Governance, Safety & Risk Management

5.4 · Lesson 4 of 5

Ensure compliance with regulations (e.g., GDPR, HIPAA, FedRAMP)

What You Need to Know

Regulatory compliance for Claude systems is a mapping problem: data classes, regions, and deployment context determine which regime applies — for example GDPR, HIPAA-oriented health controls, or FedRAMP-oriented federal baselines. Architects minimize sensitive data in prompts, retrieval, logs, and traces; protect what must remain; and document control ownership with evidence. Informal “we are careful” is not compliance.

Common failure: logging full prompt payloads with patient or personal identifiers for debugging. That choice must be challenged against the named regime. Retention, access, cross-border transfer, and subprocessors (including model providers) belong in the design, not only in a legal memo after launch.

Compliance design moves

  • Determine applicable regime from data class and context
  • Map flows including logs, traces, caches, and eval stores
  • Minimize and redact sensitive fields before model and storage
  • Assign owners and evidence for each material control
  • Prefer documented boundaries over unrestricted tools and public dumps

Decision rules

  • Map data handling to the named regime — not generic slogans.
  • Minimize and protect sensitive data in prompts, logs, and traces.
  • Document control ownership and evidence.
  • Treat debug logging of identifiers as a compliance decision.
  • FedRAMP-oriented (and similar) work needs boundaries and evidence, not vibes.

Why slogans fail

“Follow industry best practices” without naming GDPR retention, HIPAA-oriented PHI handling, or FedRAMP-oriented control evidence does not answer the stem. Exam items reward architects who connect the scenario’s data and deployment to concrete obligations and design controls.

Review checklist

  • Which regime applies, and why?
  • Where does sensitive data appear in the Claude path?
  • Are prompts/logs/traces minimized and access-controlled?
  • Who owns each control, and where is the evidence?
  • Would an auditor accept “we are careful” here? (No.)

Prefer answers that name the regime, the data class, and a concrete control (minimize, redact, encrypt, dual control, documented evidence). Ignore distractors about fonts, color, or unrelated infrastructure.

Exam application

PHI in logs → HIPAA-oriented handling first. Federal deployments → documented controls and boundaries. GDPR-flavored stems → lawful basis, minimization, and data-subject constraints as design inputs. Distractors: ignore logs, public unrestricted tools, skip auth.

Exam traps

  • Generic “follow best practices”

    Exam items name GDPR, HIPAA, FedRAMP (or similar). Map to the regime — slogans without mapping are weak.

  • Logging full sensitive payloads “for debug”

    Prompts, tool args, and traces often contain regulated data. Redact, minimize, and control access.

  • Informal carefulness without evidence

    FedRAMP-oriented and similar regimes expect documented controls and evidence, not vibes.

  • Ignoring region and data-class fit

    Wrong regime assumptions (EU personal data vs US PHI vs federal boundaries) break design choices.

Practice scenario

A US health system wants a Claude care-routing assistant. Engineering proposes logging full prompt payloads including patient identifiers for debugging. What concern should the architect raise first?

Choose one answer

Build exercise

Map HIPAA-oriented controls for a care-routing Claude assistant

40 minutes

What you'll learn

  • Name applicable regimes from data and context
  • Map sensitive flows including logs and eval stores
  • Minimize, protect, and assign control owners
  • Assemble evidence instead of informal carefulness

  1. Step 1

    Name the regime from data and deployment context

    Identify data classes (PHI, personal data, CUI), regions, customers, and hosting. Select GDPR, HIPAA-oriented, FedRAMP-oriented, or other obligations that actually apply.

    Why: Compliance starts with applicability. Wrong regime → wrong controls.

    You should see: One-pager: data classes, regions, regimes in scope, out-of-scope rationale.

  2. Step 2

    Map data flows through the Claude system

    Diagram intake → retrieval → model → tools → logs/traces → eval stores. Mark where sensitive data appears and who can access it.

    Why: You cannot protect what you have not mapped. Logging and eval stores are common blind spots.

    You should see: Flow diagram with sensitivity labels on each store and hop.

  3. Step 3

    Minimize, protect, and assign control owners

    Strip unnecessary identifiers before prompts; redact logs; encrypt; restrict access; set retention. Assign an owner and evidence artifact per control.

    Why: Architects design for minimization and evidence — not maximal logging by default.

    You should see: Control matrix: requirement → control → owner → evidence location.

  4. Step 4

    Reject informal claims; produce evidence packs

    For audit-oriented deployments, package policies, diagrams, access reviews, and incident paths. Refuse “we are careful” as a compliance answer.

    Why: Named regimes expect evidence-backed controls.

    You should see: Checklist of artifacts an auditor would request for this workload.

Sources