Privacy Assessment

---
name: privacy-assessment
description: Run an evidence-backed privacy assessment for a product, feature, system, vendor, or changed data use using DataGrail Smart Assessments' nine-section DPIA structure. Use to screen whether a PIA or DPIA may be indicated, research public context, identify privacy risks to individuals, recommend controls, or update an existing assessment. Do not use for final legal advice, contract redlining, incident response, data mapping, or automated approval.
---

# Privacy Assessment

Produce a transparent first-pass assessment from the evidence available. Organize it in the same nine-section sequence as DataGrail Smart Assessments so the result can be reviewed or transferred without remapping. Help the user make a better-informed decision without inventing organizational facts or presenting a draft as final legal advice.

## Choose the mode

- **Screen:** decide whether a fuller assessment appears required, recommended, not indicated, or unresolved.
- **Assess:** create a new assessment for a project, product, feature, system, vendor, or data use.
- **Update:** revise an existing assessment after a material change and show what changed.

If the request is ambiguous, infer the narrowest useful mode and state the assumption. Do not turn a screening request into a full assessment unless the user asks.

## Read the relevant guidance

- Read [references/assessment-method.md](references/assessment-method.md) for every assessment.
- Read [references/smart-assessment-structure.md](references/smart-assessment-structure.md) before intake, research, or drafting.
- Read [references/risk-model.md](references/risk-model.md) before scoring or prioritizing risk.
- Read [references/dpia-screening.md](references/dpia-screening.md) when the user asks about a PIA/DPIA or the facts suggest potentially high-risk processing.
- Read [references/output-contract.md](references/output-contract.md) before producing the final report or structured handoff.

## Two-layer workflow

### Layer 1: Claude evidence and analysis

1. Identify the decision, assessment object, stage, jurisdictions, stakeholders, and supplied sources.
2. Build an evidence ledger separating documented facts, stakeholder assertions, public research, assumptions, and unknowns.
3. Ask one consolidated set of questions only for missing internal facts that could materially change the outcome. Continue with explicit limitations if the user cannot answer.
4. If research tools are available and public context would materially help, research authoritative legal, regulatory, technical, or vendor sources. Public research may enrich the assessment; it cannot prove internal implementation, contracts, approvals, or actual system behavior.
5. Analyze and draft the assessment in this exact order:
   1. General Information
   2. Need for DPIA
   3. Consultation Process
   4. Data Processing Context
   5. Benefits of Processing
   6. Lawfulness & Fairness
   7. Privacy Rights & Expectations
   8. Protective Measures
   9. Special Topics
6. Identify risks to individuals from problematic data actions. Score inherent risk before controls and residual risk after verified or proposed controls.
7. Connect every recommended control to a specific risk, owner, implementation evidence, deadline or condition, and review trigger.

### Layer 2: Smart Assessments handoff

8. Preserve the nine section names and order in the report and machine-readable handoff.
9. Treat Smart Assessments as the authoritative workflow and system of record for assignments, approvals, versions, and final disposition. If a Smart Assessments export or existing assessment is supplied, update it instead of creating a competing record.
10. End with a decision and handoff block covering recommendation, conditions, open questions, owners, approvals, and reassessment triggers. For updates, include a change log and identify decisions requiring re-approval.

## Hard rules

- Never invent data flows, legal bases, contracts, controls, approvals, system behavior, or evidence.
- Never use public research to fill an internal-fact gap. Label it as public context and cite it separately.
- Cite supplied evidence by filename, section, page, URL, or quoted answer when available.
- Keep facts, assertions, assumptions, and unknowns visibly separate.
- Focus risk analysis on potential effects on individuals. Organizational, regulatory, financial, and reputational impacts may be secondary consequences.
- Distinguish privacy risk from security risk. A secure system can still create privacy harm through intended processing.
- Avoid false precision. Explain scores in plain language and expose uncertainty.
- Do not make a final legal determination or approve processing. Escalate unresolved high residual risk, contested facts, novel processing, or regulator-consultation questions to qualified privacy or legal reviewers.
- When current law matters, verify against authoritative regulator or statutory sources if tools permit. Otherwise identify the legal point as requiring verification.
- Minimize personal data in the assessment. Recommend redaction or summarization when raw personal data is unnecessary.
- Do not send, upload, file, approve, or share an assessment without explicit authorization.

## Completion standard

The result is complete only when all nine sections are present or explicitly marked not applicable, and it states the decision, evidence quality, unresolved questions, risks, controls, residual risk, accountable owners, human approval needs, and reassessment triggers. A polished report with hidden gaps is not complete.