Privacy impact assessment

Purpose

Convert a processing proposal into an evidence-based privacy impact assessment. The assessment traces personal-data fields from collection to deletion, tests necessity and proportionality, records safeguards and residual risk, and identifies unresolved decisions before the activity is treated as ready.

Scope

Cover the processing register, data-flow diagram, product or process description, data inventory, purpose and legal-basis register, vendor list, retention schedule, security-control matrix, risk methodology, and incident or rights-request procedures. Include profiling and automated decision logic when present. Excluded: legal conclusions for a jurisdiction not identified in the supplied policy, penetration testing, and implementation of controls.

Data basis

• Processing register with activity_id, purpose, controller, processor, system, data_subject, geography, and status.
• Data inventory with field_name, category, sensitivity, source, recipient, volume, and transfer destination.
• Flow or architecture documents showing collection, storage, access, sharing, deletion, and subprocessors.
• Policy and control documents covering legal basis, retention, access, encryption, incident response, rights handling, and risk scoring.

Result

Produce a PIA report and risk register. Each processing activity has a flow summary, necessity and proportionality assessment, control evidence, inherent and residual risk, owner, mitigation, due date, and source citations.

Quality criteria

• Every personal-data field has a purpose, source, recipient, storage location, retention rule, and deletion event or open point.
• Sensitive categories, vulnerable populations, profiling, and cross-border transfers are explicitly tested.
• Risk scores use the supplied likelihood-impact matrix and never hide missing evidence.
• Controls are linked to a policy section, system statement, or control record.
• Every material conclusion cites a source document, section, page, or table row.

Instructions

Separate stated facts, policy requirements, assumptions, and recommendations. Do not infer a legal basis from a purpose label. Test data minimization at field level and purpose limitation at flow level. Treat a processor, recipient, transfer, or retention period missing from the map as an evidence gap. Apply the supplied risk matrix exactly; if no matrix exists, report qualitative likelihood and impact without inventing a numeric threshold. Preserve activity_id and field_name in every risk row.

Adapt before use

• Add the company privacy policy, risk matrix, retention schedule, and control catalogue to the scope.
• Map processing-register, data-inventory, architecture, vendor, and incident fields to the named columns.
• Define the review roles, escalation labels, and evidence standard for residual high risk.
• Specify the jurisdictions and transfer terminology that the assessment must use.