Conduct Privacy Impact Assessments
Conducts Privacy Impact Assessments: GDPR Article 35 DPIA criteria, risk scoring matrices, lawful basis evaluation, and stakeholder consultation.
Maintainer of this project? Claim this page to edit the listing.
1.0.0Add to Favorites
Why it matters
Ensure compliance with global privacy regulations by conducting comprehensive Privacy Impact Assessments (PIAs). This skill systematically analyzes data flows, identifies risks, and develops mitigation strategies.
Outcomes
What it gets done
Map data lifecycles and analyze data flows.
Evaluate legal bases for data processing under GDPR, CCPA, and other frameworks.
Assess privacy risks using a defined matrix and classify data sensitivity.
Develop technical and organizational safeguards for data protection.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/vb-privacy-impact-assessment | bash Overview
Privacy Impact Assessment Expert
Guides conducting Privacy Impact Assessments - GDPR Article 35 DPIA requirements, quantified risk scoring, lawful basis evaluation, technical privacy controls assessment, and stakeholder consultation documentation. Reach for this when a new system or data processing activity triggers elevated privacy risk requiring a structured PIA/DPIA.
What it does
This skill conducts systematic Privacy Impact Assessments (PIAs) aligned with GDPR, CCPA, PIPEDA, and other privacy frameworks. The core framework covers six components: data flow analysis (mapping the full lifecycle from collection to disposal), legal basis evaluation, a quantified risk assessment matrix, stakeholder impact analysis, mitigation strategy development, and compliance gap analysis. PIA triggering criteria flag when an assessment is required - high-risk automated decision-making or profiling, large-scale special-category data processing, systematic public monitoring, novel technologies, third-country transfers, or processing affecting vulnerable populations.
Risk scoring multiplies a 1-5 likelihood scale (from "very unlikely" under 10% to "very likely" over 80%) by a 1-5 impact scale (from minimal inconvenience to catastrophic widespread harm) to produce a risk level. Data is classified into five sensitivity tiers from Public through Special Category (genetic data, political opinions, sexual orientation), each with a numeric sensitivity level.
Risk Level = Likelihood x Impact
Likelihood: 1 (Very Unlikely <10%) to 5 (Very Likely >80%)
Impact: 1 (Minimal) to 5 (Catastrophic)
GDPR-specific assessment follows Article 35 DPIA requirements - systematic processing description, necessity/proportionality assessment, risk identification against data subject rights, mitigation measures, DPO consultation, and data subject consultation. A lawful-basis evaluation function maps GDPR Article 6 bases (consent, contract, legal obligation, legitimate interests) to their specific requirements, revocability, and typical use cases. Technical privacy controls are assessed against a structured checklist covering data minimization, anonymization techniques (k-anonymity, differential privacy, pseudonymization), access controls, and encryption at rest/in transit. Documentation follows an executive-summary template capturing risk rating, key findings, processing overview, legal basis, retention, and third-party sharing. Stakeholder consultation covers methods (surveys, focus groups, public consultations, advocacy group input) with a structured record format capturing participant counts, key concerns raised, and how feedback was incorporated into the final design. Ongoing monitoring defines a review cadence (annual, change-triggered, post-incident, regulatory-update-triggered, technology-change-triggered) and KPIs tracking PIA completion rate, review timeliness, risk reduction, compliance gaps, and stakeholder satisfaction. Best practices emphasize early integration during system design, cross-functional teams, living documentation, executive support, and embedded tooling, while flagging pitfalls like late-stage PIAs, underestimated impact severity, incomplete processing inventories, and treating PIA as a one-time exercise.
When to use - and when NOT to
Use this skill when a new system, feature, or data processing activity triggers privacy risk - conducting a structured PIA/DPIA, scoring privacy risks, evaluating lawful basis for processing, assessing technical privacy controls, or documenting stakeholder consultation for compliance.
It is not the right fit for processing activities with no elevated privacy risk (routine, low-sensitivity data handling already covered by existing assessments), or for general security risk assessment unrelated to personal data processing, which needs a broader security framework rather than a privacy-specific PIA.
Inputs and outputs
Input: the system or processing activity's data flows, the personal data categories involved, and the applicable regulatory framework (GDPR, CCPA, etc.). Output: a completed PIA/DPIA with data flow mapping, a scored risk assessment, lawful basis determination, a technical controls checklist, an executive summary document, stakeholder consultation records, and an ongoing review schedule with tracked KPIs.
Integrations
References GDPR Article 6/35 as the primary regulatory anchor, with technical control implementation covering encryption standards (AES-256, TLS 1.3) and anonymization techniques, designed to integrate into development workflows for early-stage privacy-by-design assessment.
Who it's for
Privacy, legal, and compliance teams conducting Privacy Impact Assessments for new systems or data processing activities - particularly those needing GDPR Article 35-compliant DPIAs, quantified risk scoring, and documented stakeholder consultation.
Source README
Core PIA Framework
Essential Assessment Components
- Data Flow Analysis: Map complete data lifecycles from collection to disposal
- Legal Basis Evaluation: Determine lawful grounds for processing under applicable regulations
- Risk Assessment Matrix: Quantify privacy risks using likelihood and impact scales
- Stakeholder Impact Analysis: Evaluate effects on data subjects and broader community
- Mitigation Strategy Development: Design technical and organizational safeguards
- Compliance Gap Analysis: Identify regulatory non-compliance areas
PIA Triggering Criteria
- High-risk processing activities (automated decision-making, profiling)
- Large-scale processing of special category data
- Systematic monitoring of public areas
- New technologies with unknown privacy implications
- Data transfers to third countries
- Processing affecting vulnerable populations
Risk Assessment Methodology
Data Sensitivity Classification
Data Categories:
Public:
sensitivity_level: 1
examples: ["published content", "public profiles"]
Internal:
sensitivity_level: 2
examples: ["employee directories", "business communications"]
Confidential:
sensitivity_level: 3
examples: ["customer data", "financial records"]
Restricted:
sensitivity_level: 4
examples: ["health records", "biometric data"]
Special_Category:
sensitivity_level: 5
examples: ["genetic data", "political opinions", "sexual orientation"]
GDPR-Specific Assessment Criteria
Article 35 DPIA Requirements
- Systematic Description: Detailed processing operation documentation
- Necessity Assessment: Proportionality and purpose limitation analysis
- Risk Identification: Privacy risks to data subject rights and freedoms
- Mitigation Measures: Technical and organizational safeguards
- DPO Consultation: Data Protection Officer input (where applicable)
- Data Subject Consultation: Individual perspectives on processing impact
Processing Lawfulness Evaluation
def assess_lawful_basis(processing_context):
"""
Evaluate GDPR Article 6 lawful basis for processing
"""
lawful_bases = {
'consent': {
'requirements': ['freely_given', 'specific', 'informed', 'unambiguous'],
'revocability': True,
'suitable_for': ['marketing', 'non_essential_services']
},
'contract': {
'requirements': ['processing_necessary', 'contract_performance'],
'revocability': False,
'suitable_for': ['service_delivery', 'payment_processing']
},
'legal_obligation': {
'requirements': ['eu_law_requirement', 'member_state_law'],
'revocability': False,
'suitable_for': ['tax_reporting', 'regulatory_compliance']
},
'legitimate_interests': {
'requirements': ['balancing_test', 'impact_assessment'],
'revocability': True,
'suitable_for': ['fraud_prevention', 'direct_marketing']
}
}
return evaluate_basis_suitability(processing_context, lawful_bases)
Technical Privacy Controls Assessment
Privacy-by-Design Implementation
// Example: Privacy control validation checklist
const privacyControls = {
dataMinimization: {
implemented: false,
controls: [
'purpose_limitation',
'data_field_necessity_review',
'retention_period_enforcement'
]
},
anonymization: {
implemented: false,
techniques: [
'k_anonymity',
'differential_privacy',
'pseudonymization'
]
},
accessControls: {
implemented: false,
mechanisms: [
'role_based_access',
'attribute_based_access',
'least_privilege_principle'
]
},
encryptionAtRest: {
implemented: false,
standards: ['AES_256', 'field_level_encryption']
},
encryptionInTransit: {
implemented: false,
protocols: ['TLS_1.3', 'end_to_end_encryption']
}
};
PIA Documentation Template
Executive Summary Structure
### Key Findings
- **Highest Risk**: [Primary privacy concern]
- **Data Subjects Affected**: [Number and categories]
- **Regulatory Compliance**: [GDPR/CCPA/Other status]
- **Recommended Actions**: [Critical mitigation measures]
### Processing Overview
- **Personal Data Types**: [Categories processed]
- **Processing Purposes**: [Specific purposes]
- **Legal Basis**: [Article 6/9 basis]
- **Data Retention**: [Retention periods]
- **Third Party Sharing**: [Recipients and safeguards]
Stakeholder Consultation Framework
Data Subject Consultation Methods
- Surveys and Questionnaires: Structured feedback collection
- Focus Groups: Qualitative impact assessment discussions
- Public Consultations: Community-wide input for large-scale processing
- Representative Organizations: Advocacy groups and unions
- Privacy Advocacy Groups: External privacy expertise
Consultation Documentation
Consultation_Record:
stakeholder_type: "data_subjects"
method: "online_survey"
participants: 150
key_concerns:
- "data_retention_period"
- "third_party_sharing"
- "consent_withdrawal_process"
responses_incorporated:
- "reduced_retention_from_7_to_3_years"
- "enhanced_privacy_notice_clarity"
- "simplified_opt_out_mechanism"
Ongoing Monitoring and Review
PIA Maintenance Schedule
- Annual Review: Comprehensive assessment update
- Triggered Review: Significant processing changes
- Incident Review: Post-breach impact reassessment
- Regulatory Update: New privacy law compliance check
- Technology Change: New system or vendor integration
Key Performance Indicators
pia_metrics = {
'completion_rate': 'PIAs completed / PIAs required',
'review_timeliness': 'Reviews completed on schedule',
'risk_reduction': 'High risks mitigated to medium/low',
'compliance_gaps': 'Outstanding regulatory compliance issues',
'stakeholder_satisfaction': 'Data subject consultation feedback scores'
}
Best Practices and Recommendations
Critical Success Factors
- Early Integration: Conduct PIA during system design phase
- Cross-functional Teams: Include legal, technical, and business stakeholders
- Regular Updates: Maintain living documents that evolve with processing
- Executive Support: Ensure leadership commitment to privacy protection
- Training Programs: Build organizational PIA competency
- Tool Integration: Embed PIA workflows into development processes
Common Pitfalls to Avoid
- Conducting PIAs too late in project lifecycle
- Underestimating data subject impact severity
- Failing to identify all data processing activities
- Inadequate consultation with affected stakeholders
- Treating PIA as one-time compliance exercise
- Insufficient technical control implementation
- Poor documentation and audit trail maintenance
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.