PIA-TEMPLATE
Authorized use only. Offensive reference for systems you own or are explicitly permitted to test. You are responsible for staying within the law.
A practical template and guide for conducting Privacy Impact Assessments (PIAs) and Data Protection Impact Assessments (DPIAs) as required by GDPR Article 35 and other privacy regulations.
WHEN IS A PIA/DPIA REQUIRED#
Mandatory under GDPR when processing is likely to result in HIGH RISK: - Systematic and extensive profiling with significant effects - Large-scale processing of special categories / criminal data - Systematic monitoring of publicly accessible areas (CCTV) - New technologies with potential high risk - Automated decision-making with legal or significant effects - Large-scale processing of children's data - Data matching or combining datasets - Invisible processing (data subject unaware) - Tracking location or behavior Recommended even when not mandatory: - New systems processing personal data - Changes to existing processing activities - New third-party data sharing arrangements - Cross-border data transfers - Biometric or genetic data processing
PIA PROCESS OVERVIEW#
Step 1: Identify the Need for a PIA Step 2: Describe the Processing Step 3: Map Data Flows Step 4: Assess Necessity and Proportionality Step 5: Identify and Assess Privacy Risks Step 6: Identify Measures to Mitigate Risks Step 7: Consult Stakeholders Step 8: Document and Sign Off Step 9: Integrate Outcomes Step 10: Review and Update =====================================================================
TEMPLATE BEGINS HERE#
SECTION 1: PROJECT OVERVIEW#
Project Name: _______________________________________________ Project Lead: _______________________________________________ DPO Contact: _______________________________________________ Date of Assessment: _______________________________________________ Version: _______________________________________________ Status: [ ] Draft [ ] Under Review [ ] Approved 1.1 Project Description Describe the project, system, or processing activity: ________________________________________________________________ ________________________________________________________________ 1.2 Purpose of Processing What is the purpose and expected outcome? ________________________________________________________________ 1.3 Legal Basis for Processing [ ] Consent (Art. 6(1)(a)) [ ] Contract performance (Art. 6(1)(b)) [ ] Legal obligation (Art. 6(1)(c)) [ ] Vital interests (Art. 6(1)(d)) [ ] Public interest (Art. 6(1)(e)) [ ] Legitimate interests (Art. 6(1)(f)) Justification: __________________________________________________ 1.4 Special Category Data (Art. 9) [ ] Racial or ethnic origin [ ] Political opinions [ ] Religious or philosophical beliefs [ ] Trade union membership [ ] Genetic data [ ] Biometric data for identification [ ] Health data [ ] Sex life or sexual orientation [ ] None of the above If yes, additional legal basis under Art. 9(2): __________________
SECTION 2: DATA INVENTORY#
2.1 Categories of Data Subjects [ ] Employees [ ] Customers/Clients [ ] Job applicants [ ] Website visitors [ ] Contractors [ ] Children (under 16/13) [ ] Patients [ ] Students [ ] Other: _______________ 2.2 Categories of Personal Data Data Element | Source | Sensitive? | Retention Period ____________________|________________|____________|_________________ Name | | | Email | | | Phone | | | Address | | | Date of birth | | | Financial data | | | Health data | | | Location data | | | IP address | | | Cookies/tracking | | | Biometric data | | | ____________________|________________|____________|_________________ 2.3 Volume of Data Estimated number of data subjects: ______________________________ Estimated volume of records: ____________________________________ Geographic scope: _______________________________________________
SECTION 3: DATA FLOW MAPPING#
3.1 Data Collection
How is data collected?
[ ] Directly from data subject (forms, interviews)
[ ] From third parties (specify): ________________________________
[ ] Automated collection (cookies, sensors, logs)
[ ] Public sources
[ ] Other: ______________________________________________________
3.2 Data Flow Diagram
Document the flow: Collection -> Processing -> Storage -> Sharing -> Deletion
Collection Point(s): __________________________________________
Processing System(s): __________________________________________
Storage Location(s): __________________________________________
Third Party Recipients: __________________________________________
Cross-border Transfers: __________________________________________
3.3 Data Sharing
Recipient | Purpose | Legal Basis | Safeguards
_________________|_________________|_____________|_______________
| | |
| | |
| | |
3.4 Cross-Border Transfers
Country/Region: ________________________________________________
Transfer mechanism:
[ ] Adequacy decision [ ] Standard Contractual Clauses
[ ] Binding Corporate Rules [ ] Explicit consent
[ ] Other: ______________________________________________________
Transfer Impact Assessment completed? [ ] Yes [ ] No
SECTION 4: NECESSITY AND PROPORTIONALITY#
4.1 Is the processing necessary for the stated purpose? [ ] Yes [ ] Partially [ ] No Justification: __________________________________________________ 4.2 Could the purpose be achieved with less data? [ ] Yes (explain what can be reduced): ___________________________ [ ] No (justify): _______________________________________________ 4.3 Could the purpose be achieved without personal data? [ ] Yes (consider anonymization/aggregation) [ ] No (justify): _______________________________________________ 4.4 Data Minimization Assessment For each data element, confirm it is: [ ] Adequate - sufficient for the purpose [ ] Relevant - has a rational link to the purpose [ ] Limited - not excessive for the purpose 4.5 Retention Assessment Is a retention schedule defined? [ ] Yes [ ] No Is automatic deletion implemented? [ ] Yes [ ] No Retention period justified? [ ] Yes [ ] No
SECTION 5: RISK IDENTIFICATION AND ASSESSMENT#
5.1 Risk Categories to Consider
CONFIDENTIALITY RISKS:
- Unauthorized access to personal data
- Data breach / data leak
- Insider threat
- Inadequate access controls
- Third-party / supply chain risk
INTEGRITY RISKS:
- Unauthorized modification of data
- Inaccurate data leading to wrong decisions
- Lack of audit trail
AVAILABILITY RISKS:
- Data loss without backup
- System downtime affecting data subject rights
- Ransomware / destructive attacks
COMPLIANCE RISKS:
- Failure to meet data subject rights requests
- Inadequate consent mechanisms
- Non-compliant cross-border transfers
- Insufficient legal basis
RIGHTS AND FREEDOMS RISKS:
- Discrimination based on profiling
- Financial loss to data subjects
- Reputational damage to data subjects
- Loss of confidentiality (medical, legal)
- Physical safety risks
- Social disadvantage
5.2 Risk Assessment Matrix
Risk Description | Likelihood | Impact | Risk Level
| (1-4) | (1-4) | (L x I)
_____________________|______________|______________|____________
| | |
| | |
| | |
Likelihood Scale:
1 = Remote (unlikely to occur)
2 = Possible (could occur)
3 = Probable (likely to occur)
4 = Almost certain (expected to occur)
Impact Scale:
1 = Negligible (minor inconvenience)
2 = Limited (significant inconvenience)
3 = Significant (serious consequences)
4 = Maximum (irreversible consequences)
Risk Level:
1-4 = Low (accept)
5-8 = Medium (mitigate)
9-12 = High (mitigate urgently)
13-16 = Very High (avoid or redesign)
SECTION 6: RISK MITIGATION MEASURES#
6.1 Technical Safeguards
[ ] Encryption at rest (algorithm: __________)
[ ] Encryption in transit (TLS 1.2+)
[ ] Access controls (RBAC/ABAC)
[ ] Multi-factor authentication
[ ] Data masking / pseudonymization
[ ] Anonymization techniques
[ ] Automated data deletion
[ ] Intrusion detection / prevention
[ ] Logging and monitoring
[ ] Backup and disaster recovery
[ ] Network segmentation
[ ] Vulnerability scanning
[ ] Penetration testing schedule
[ ] Other: ______________________________________________________
6.2 Organizational Safeguards
[ ] Data protection policies in place
[ ] Staff training and awareness
[ ] Data processing agreements with third parties
[ ] Incident response procedures
[ ] Data subject rights procedures
[ ] Regular audits
[ ] Privacy by design principles applied
[ ] Clean desk / clear screen policy
[ ] Confidentiality agreements
[ ] Other: ______________________________________________________
6.3 Residual Risk Assessment
Risk Description | Mitigation Applied | Residual Risk Level
_____________________|____________________|____________________
| |
| |
| |
Residual risk acceptable? [ ] Yes [ ] No
If No: escalate to DPO / consult supervisory authority (Art. 36)
SECTION 7: STAKEHOLDER CONSULTATION#
7.1 Internal Stakeholders Consulted Name/Role | Date | Input/Feedback _____________________|____________|_________________________ DPO | | IT Security | | Legal | | Project Owner | | HR (if employee data)| | _____________________|____________|_________________________ 7.2 Data Subject Consultation Were data subjects or their representatives consulted? [ ] Yes [ ] No If no, justify: _________________________________________________ Method of consultation: _________________________________________ Summary of feedback: ____________________________________________ 7.3 Supervisory Authority Consultation (Art. 36) Is prior consultation with DPA required? [ ] Yes [ ] No (Required when residual risk remains high after mitigation) If yes, date consulted: _________________________________________ Authority response: _____________________________________________
SECTION 8: DOCUMENTATION AND APPROVAL#
8.1 Assessment Outcome
[ ] Processing may proceed as planned
[ ] Processing may proceed with identified mitigations
[ ] Processing requires redesign
[ ] Processing should not proceed (risk too high)
[ ] Prior consultation with supervisory authority required
8.2 Action Items
Action | Owner | Deadline | Status
______________________|_____________|_____________|____________
| | |
| | |
| | |
8.3 Approval Sign-Off
Project Lead: _________________ Date: _________ Signature: ___
DPO: _________________ Date: _________ Signature: ___
CISO: _________________ Date: _________ Signature: ___
Senior Management:_________________ Date: _________ Signature: ___
SECTION 9: REVIEW SCHEDULE#
Next review date: _______________________________________________
Review triggers:
[ ] Annual review
[ ] Significant change to processing
[ ] Change in legal/regulatory requirements
[ ] Data breach or security incident
[ ] New technology introduced
[ ] Complaint from data subject
[ ] Audit finding
Review history:
Date | Reviewer | Changes Made | Version
_____________|_____________|___________________|_________
| | |
| | |
PRACTICAL TIPS#
1. Start the PIA early in project planning, not as an afterthought 2. Involve the DPO from the beginning 3. Use data flow diagrams - visual mapping catches issues text misses 4. Be honest about risks - understating them defeats the purpose 5. Document everything - the process matters as much as the outcome 6. Consider both current and future uses of the data 7. Review PIAs when processing changes, not just on schedule 8. Keep language clear - the PIA should be understandable to non-experts 9. Use risk scenarios (what if...?) to identify hidden risks 10. Integrate PIA findings into project management and system design
REFERENCES#
- GDPR Articles 35-36 (DPIA and Prior Consultation) - WP29 Guidelines on DPIAs (wp248rev.01) - ICO DPIA Guidance and Template - CNIL PIA Tool (open source) - NIST Privacy Framework - ISO 29134:2017 (Privacy Impact Assessment Guidelines)