ClaudeによるDPAレビュー

---
name: dpa-reviewer
description: Review a Data Processing Addendum (DPA) against the firm's DPA checklist (GDPR Art. 28 + CCPA-CPRA defaults). Returns a structured Markdown report with per-section citations, the obligation status (present-cited / present-vague / absent), and recommended redlines. Never auto-signs; the privacy counsel reviews and approves.
---

# DPA reviewer

## When to invoke

Use this skill when a privacy counsel or legal-ops lead has a vendor's DPA draft and wants a structured first-pass review against the firm's DPA checklist.

Do NOT invoke this skill for:

- **Auto-signing or approval based on the skill's verdict.** The skill recommends; the counsel approves.
- **DPAs in jurisdictions not in the checklist.** Add the jurisdiction to the checklist first.
- **Final-draft review.** The skill is calibrated for first-pass, where volume is highest.
- **Novel contract structures** (e.g. a master agreement with privacy embedded). Extract the DPA-equivalent provisions first; the skill expects DPA shape.

## Inputs

- Required: `dpa_path` — path to the DPA file (Markdown, plain text, or pre-extracted from PDF).
- Required: `checklist_path` — path to the firm's DPA checklist file.
- Optional: `vendor_profile_path` — vendor-specific notes that shape the review.
- Optional: `jurisdictions_in_scope` — array of jurisdictions, e.g. `["EU-GDPR", "UK-GDPR", "CCPA-CPRA"]`. Defaults to the checklist's stated coverage.

## Reference files

- `references/1-dpa-checklist.md` — the firm's checklist shape and starter content.
- `references/2-vendor-profile-template.md` — vendor-profile shape.

## Method

Five steps.

### 1. Section the DPA

Identify the standard sections by heading and content match:

- Definitions
- Subject matter, duration, nature, purpose
- Processor obligations
- Sub-processors
- International transfers
- Audit rights
- Breach notification
- Deletion / return on termination
- Liability and indemnification

If the document doesn't match a DPA shape (e.g. it's an MSA with privacy buried in §17), halt with a "not a standalone DPA — extract privacy provisions" message.

### 2. Run the checklist per section

For each obligation in the checklist, find the supporting DPA language in the corresponding section. Output per obligation:

- `status: present_cited` — language exists; cite section and quote.
- `status: present_vague` — language exists but doesn't carry the obligation's force ("commercially reasonable" instead of named timeframe; "industry standard" instead of named technical measure).
- `status: absent` — no language found.

### 3. Run the red-flag detector

Scan beyond the checklist for known anti-patterns:

- **International transfer without mechanism**: `processor may transfer data internationally` without naming the transfer mechanism (SCCs by module, BCRs, adequacy decision).
- **Broad sub-processor consent waiver**: `controller consents to use of any sub-processor` without notification or objection rights.
- **Audit rights limited to summaries**: `processor will provide summary of audits` instead of right to audit.
- **Vague breach notification**: `within a reasonable time` instead of named hours (GDPR is "without undue delay"; firm checklist usually pins to 24-72 hours).
- **Deletion-tied to vendor cycle**: `processor will delete data per its ordinary deletion cycle` instead of a named timeframe.
- **Liability cap below underlying agreement**: privacy claims excluded from the master cap, or capped at fees-paid-in-prior-12-months for breaches that could carry GDPR Art. 83 fines.

### 4. Citation per finding

Every finding must cite:

- DPA section number / heading
- The specific clause text (quoted)
- Length: ≤80 words per quoted clause to keep the report scannable.

Findings without a citable section are flagged as "not in document — counsel to verify" rather than asserted.

### 5. Recommended redlines per finding

For each absent or vague obligation, suggest replacement language. Source the redline from:

- The firm's checklist's stated obligation (preferred)
- The firm's prior approved redlines for similar issues (if a `prior_redlines/` corpus is available)
- GDPR Art. 28 / CCPA-CPRA standard language as fallback

Mark the redline source so counsel can weight ("from firm checklist" vs "from prior redline" vs "fallback to standard language").

## Output format

```markdown
# DPA review — {vendor name} — {date received}

Reviewed: {ISO timestamp} · Skill v1.0 · Checklist: {sha} · Jurisdictions: {list}

## Summary

- Sections present: {count}/9
- Obligations present (cited): {count}
- Obligations present (vague): {count}
- Obligations absent: {count}
- Red flags: {count}

Recommended action: {return-with-redlines | escalate-to-counsel | safe-to-counter-sign}

## Section-by-section findings

### Sub-processors (DPA §5)

- **Sub-processor consent (checklist §3.2):** present_vague. DPA quote: "Controller hereby consents to Processor's use of sub-processors as listed on Processor's website, which may be updated from time to time." Concern: blanket consent with no notification or objection right. Recommended redline:

> Controller's consent to sub-processors is limited to those listed in Annex C as of the Effective Date. Processor shall notify Controller of any new sub-processor at least 30 days before engagement, and Controller may object on reasonable grounds; if Controller objects, the parties shall negotiate in good faith, and if no resolution within 30 days, Controller may terminate the affected services.

### International transfers (DPA §6)

- **Transfer mechanism (checklist §4.1):** absent. DPA does not name SCCs, BCRs, or adequacy. Recommended redline:

> The parties agree that any transfer of Personal Data to a country outside the EEA / UK shall be governed by the Standard Contractual Clauses (Module 2: Controller-to-Processor) annexed hereto as Annex D, with the data importer being Processor and the data exporter being Controller.

(further sections...)

## Red flags

- **Vague breach window** (DPA §7.1): "within a reasonable time" — recommend pinning to 48 hours from confirmed discovery.
- **Liability cap on privacy claims** (DPA §9): privacy claims capped at fees-paid-in-prior-12-months. Recommend uncapped for GDPR Art. 83 fines and reasonable cap (12-24 months) for indemnification.

## Provenance

- DPA: `{path}`
- Checklist: `{path}` SHA `{short}`
- Vendor profile: `{path}` (if used)
- Generated: {ISO timestamp}
```

## Watch-outs

- **Citation hallucination.** *Guard:* findings without citable sections get "not in document" tag, not asserted.
- **Jurisdiction drift.** *Guard:* checklist names covered jurisdictions; uncovered jurisdictions trigger warning.
- **Confidentiality.** *Guard:* DPAs carry vendor-confidential terms. Use API access with zero-retention.
- **SCC version drift.** *Guard:* checklist captures accepted SCC modules; older or unidentified modules flagged.
- **Redline grounding.** *Guard:* every redline marks its source (firm checklist / prior redline / fallback) so counsel can weight.

# DPA checklist (firm template)

The DPA reviewer scores against this checklist. Copy this file to `firm-dpa-checklist.md`, customize for the firm's risk posture and the jurisdictions in scope, and version it in git.

The checklist is the comparison anchor. The reviewer's findings cite obligations by ID (`§1.1`, `§3.2`, etc.) — keep IDs stable across versions or document renumbering in a changelog.

## §0 — Scope

- **§0.1** Jurisdictions covered: EU GDPR (Reg. 2016/679), UK GDPR + DPA 2018, CCPA-CPRA. To extend coverage, add the jurisdiction's required obligations to the relevant section below.
- **§0.2** Scope: this checklist applies to vendor DPAs where the firm is the controller or business and the vendor is the processor or service provider.
- **§0.3** Out of scope for this checklist: joint-controller arrangements, controller-to-controller transfers, intra-group DPAs (handled separately).

## §1 — Definitions

- **§1.1** "Personal Data" defined to track GDPR Art. 4(1) AND CCPA-CPRA "Personal Information" — the broader of the two governs the DPA.
- **§1.2** "Processing" tracks GDPR Art. 4(2).
- **§1.3** "Sub-processor" defined to include any party engaged by Processor to process Personal Data on Controller's behalf.
- **§1.4** "Personal Data Breach" tracks GDPR Art. 4(12).

## §2 — Subject matter, duration, nature, purpose, types of data, categories of data subjects

- **§2.1** DPA names the subject matter and duration of processing.
- **§2.2** DPA names the nature and purpose of processing in specific terms (not just "providing the Services").
- **§2.3** DPA names the types of Personal Data and the categories of data subjects.

## §3 — Processor obligations

- **§3.1** Processor processes Personal Data only on documented instructions from Controller.
- **§3.2** Sub-processor consent: Processor obtains prior written consent for sub-processors. Default: per-sub-processor consent. Acceptable alternative: notification + 30-day objection right.
- **§3.3** Confidentiality: Processor ensures personnel processing data are bound by confidentiality.
- **§3.4** Technical and organizational measures (TOMs): Processor implements appropriate measures per GDPR Art. 32. The DPA names specific measures (encryption at rest and in transit, access controls, logging) — vague "industry-standard" language is a finding.
- **§3.5** Assistance with data-subject rights: Processor assists Controller with data-subject access, rectification, erasure, restriction, portability, and objection requests.
- **§3.6** Assistance with DPIAs: Processor assists Controller with Data Protection Impact Assessments where required.

## §4 — International transfers

- **§4.1** Transfer mechanism named: SCCs (specify modules — usually Module 2: Controller-to-Processor and/or Module 3: Processor-to-Processor for sub-processor transfers), BCRs, or adequacy decision.
- **§4.2** SCC version pinned: EU 2021/914 modules (current as of this checklist version). UK: International Data Transfer Agreement (IDTA) or UK Addendum to EU SCCs.
- **§4.3** Transfer impact assessment (TIA) obligation acknowledged where Schrems II / equivalent applies.
- **§4.4** Onward transfers from sub-processors covered by the same mechanism.

## §5 — Audit rights

- **§5.1** Controller has the right to audit Processor's compliance with the DPA, either directly or through an independent third-party auditor.
- **§5.2** Audit frequency: at least annually, and on material change in processing or breach.
- **§5.3** Audit scope: not limited to "summary findings" — Controller can review the actual evidence (sub-processor lists, log samples, TOM documentation).
- **§5.4** Reasonable notice: Controller provides reasonable advance notice (default: 30 days) for routine audits. Breach-related audits may proceed on shorter notice.

## §6 — Breach notification

- **§6.1** Processor notifies Controller of a Personal Data Breach without undue delay.
- **§6.2** Named timeframe: 48 hours from confirmed discovery (firm preference; GDPR Art. 33 sets the Controller's obligation at 72 hours, so Processor must notify earlier).
- **§6.3** Notification includes: nature of breach, categories and approximate number of data subjects, likely consequences, measures taken or proposed.
- **§6.4** No "reasonable time" or "as soon as practicable" — these are findings.

## §7 — Deletion / return on termination

- **§7.1** On termination, Processor returns or deletes all Personal Data (Controller's choice).
- **§7.2** Named timeframe: within 30 days of termination, or earlier if required by Controller.
- **§7.3** Processor certifies in writing that deletion has occurred (or that data has been returned).
- **§7.4** Retention beyond termination only as required by applicable law, with named legal basis.

## §8 — Liability

- **§8.1** Privacy claims (GDPR Art. 82, equivalent CCPA-CPRA private rights of action) are NOT subject to the master agreement's general liability cap, OR are subject to a higher cap (e.g. 24x monthly fees) reflecting privacy risk.
- **§8.2** Indemnification for Processor's breach of the DPA is separately addressed.

## §9 — CCPA-CPRA-specific (where applicable)

- **§9.1** Vendor classification: Service Provider, Contractor, or Third Party — DPA names which.
- **§9.2** Service-Provider obligations under CCPA-CPRA §1798.140(ag) included.
- **§9.3** Sale / share of Personal Information explicitly prohibited (DPA states Processor does not "sell" or "share" Personal Information as defined under CPRA).
- **§9.4** Notification of unauthorized use as Service Provider.

## §10 — Schedule of TOMs

- **§10.1** Annex / Schedule lists specific Technical and Organizational Measures, not just generic categories.
- **§10.2** TOMs include: encryption at rest, encryption in transit, access controls, logging, vulnerability management, incident response, business continuity.
- **§10.3** Certifications named (SOC 2 Type II, ISO 27001, ISO 27018) where applicable.

## §11 — Sub-processor list (Annex)

- **§11.1** DPA includes a current sub-processor list as an annex, OR references a maintained list (URL) with notification on changes.
- **§11.2** Sub-processor list includes: name, processing activity, location.

## How to customize

When you adapt this template:

1. Tighten or loosen specific obligations to match the firm's risk posture (e.g. shorter breach window for highly regulated industries).
2. Add jurisdictions to §0.1 and the corresponding required-obligation sections.
3. Document the per-vendor exception process — some sub-processor consent waivers are acceptable for hyperscaler dependencies.
4. Versioning: bump the version line in §0 when you make changes; the reviewer captures the SHA per audit.

# Vendor profile template

Vendor profiles let the DPA reviewer weight findings by what's known about the vendor's baseline behavior. A hyperscaler's DPA reads differently from a Series A startup's DPA; the same vague language may be acceptable in one context and a red flag in another.

The profile is optional. Without it, the reviewer scores against the checklist alone.

## Profile shape

Save one file per major vendor as `vendor-profiles/<vendor-slug>.md`.

```yaml
vendor: AWS
profile_version: 2026.1
profile_updated: 2026-04-15

# Vendor classification
classification: hyperscaler  # hyperscaler | enterprise-saas | mid-market-saas | startup | services-vendor
sub-processor-of-others: true  # does this vendor act as your sub-processor for other vendors?

# Standard offerings
standard_dpa_url: https://aws.amazon.com/agreements/data-processing/
sccs_offered: [eu-2021-914-module-2, eu-2021-914-module-3]
certifications_held: [soc2-type-ii, iso-27001, iso-27018, hipaa-baa]

# Negotiation posture
negotiation_likelihood: low  # how likely is this vendor to accept redlines? hyperscalers: usually low for standard terms
prior_redlines_accepted:
  - "tightened breach window from 72h to 48h, accepted 2025-11"
  - "added Annex C sub-processor notification, accepted 2026-02"

# Risk posture
data_sensitivity: high  # how sensitive is the data this vendor processes?
data_volume: high
firm_dependency_score: 9  # 1-10; how disruptive would changing vendor be?

# Known issues
known_issues:
  - "Sub-processor list at standard URL is updated without per-customer notification — Controller must monitor."
  - "Audit rights via SOC 2 reports only; no direct audit. Counsel has accepted this for SOC 2 Type II + ISO 27001 holders."
  - "Liability cap for privacy claims tied to fees-paid; firm has previously accepted with carve-out for GDPR Art. 83 fines."

# Reviewer guidance
weight_findings_lower:
  - "blanket sub-processor consent — accepted for hyperscalers per firm policy"
  - "audit-via-summary — accepted for SOC 2 Type II + ISO 27001 holders"
weight_findings_higher:
  - "any new processing purpose — escalate to counsel even for routine reviews"
```

## How the reviewer uses the profile

- Findings tagged with `weight_findings_lower` patterns are surfaced with `informational` severity instead of red-flag — the firm has already evaluated and accepted the trade-off for this vendor class.
- Findings tagged with `weight_findings_higher` patterns are escalated regardless of normal severity.
- `prior_redlines_accepted` informs the recommended-redline section: "this vendor accepted similar redline at this date."
- `negotiation_likelihood: low` adds a note to the report: "vendor unlikely to accept redlines — the legal-ops lead may prioritize accept-with-risk-acceptance over negotiation."

## When to update a profile

- Vendor accepts a new redline → add to `prior_redlines_accepted`.
- Vendor refuses a redline the firm has accepted before → flag and escalate; profile may need re-version.
- Vendor changes their standard DPA → update `standard_dpa_url` and bump `profile_version`.
- Annual review: confirm certifications still held, sub-processor list still accurate, classification unchanged.

## What NOT to put in the profile

- Confidential commercial terms (pricing, custom-negotiated rates) — those belong in procurement records.
- Personal information about vendor counsel or contacts.
- Speculation about vendor strategy.

The profile is for reviewer calibration, not a vendor-relationship CRM.