Skill

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.


78
Spark score
out of 100
Updated 7 months ago
Version 1.0.0
Models

Add 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

01

Map data lifecycles and analyze data flows.

02

Evaluate legal bases for data processing under GDPR, CCPA, and other frameworks.

03

Assess privacy risks using a defined matrix and classify data sensitivity.

04

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

  1. Data Flow Analysis: Map complete data lifecycles from collection to disposal
  2. Legal Basis Evaluation: Determine lawful grounds for processing under applicable regulations
  3. Risk Assessment Matrix: Quantify privacy risks using likelihood and impact scales
  4. Stakeholder Impact Analysis: Evaluate effects on data subjects and broader community
  5. Mitigation Strategy Development: Design technical and organizational safeguards
  6. 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

  1. Systematic Description: Detailed processing operation documentation
  2. Necessity Assessment: Proportionality and purpose limitation analysis
  3. Risk Identification: Privacy risks to data subject rights and freedoms
  4. Mitigation Measures: Technical and organizational safeguards
  5. DPO Consultation: Data Protection Officer input (where applicable)
  6. 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

  1. Surveys and Questionnaires: Structured feedback collection
  2. Focus Groups: Qualitative impact assessment discussions
  3. Public Consultations: Community-wide input for large-scale processing
  4. Representative Organizations: Advocacy groups and unions
  5. 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

  1. Early Integration: Conduct PIA during system design phase
  2. Cross-functional Teams: Include legal, technical, and business stakeholders
  3. Regular Updates: Maintain living documents that evolve with processing
  4. Executive Support: Ensure leadership commitment to privacy protection
  5. Training Programs: Build organizational PIA competency
  6. 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.