[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AEGASQC7AMJMP3CBTPMZY3":3,"skill-same:01M6AEGASQC7AMJMP3CBTPMZY3":86},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M6AEGASQC7AMJMP3CBTPMZY3","biometric-dpia",null,"Guides DPIA for biometric processing systems including facial recognition, fingerprint, voice, iris, and gait analysis. Covers Art. 9 special category requirements, Art. 35(3)(b) mandatory DPIA triggers for large-scale biometric processing, and EDPB Guidelines 3\u002F2019 on video surveillance. Keywords: biometric, facial recognition, fingerprint, DPIA, Art. 9, special category, EDPB Guidelines 3\u002F2019.","mukul975\u002FPrivacy-Data-Protection-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADNKWX1HF4Q5DKEXT5M774",336,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fbiometric-dpia\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[27,28,29,30,31],"dpia","biometric dpia","assessment","guidelines","privacy","2026-11-10 10:12:30",false,"---\nname: biometric-dpia\ndescription: >-\n  Guides DPIA for biometric processing systems including facial recognition,\n  fingerprint, voice, iris, and gait analysis. Covers Art. 9 special category\n  requirements, Art. 35(3)(b) mandatory DPIA triggers for large-scale biometric\n  processing, and EDPB Guidelines 3\u002F2019 on video surveillance. Keywords:\n  biometric, facial recognition, fingerprint, DPIA, Art. 9, special category,\n  EDPB Guidelines 3\u002F2019.\nlicense: Apache-2.0\nmetadata:\n  author: mukul975\n  version: \"1.0\"\n  domain: privacy\n  subdomain: privacy-impact-assessment\n  tags: \"biometric, facial-recognition, fingerprint, dpia, art-9, special-category\"\n---\n\n# Assessing Biometric Processing Privacy\n\n## Overview\n\nBiometric data is classified as a special category of personal data under GDPR Art. 9(1) when processed for the purpose of uniquely identifying a natural person. Processing biometric data on a large scale triggers a mandatory DPIA under Art. 35(3)(b). This skill provides a comprehensive DPIA methodology for biometric systems including facial recognition, fingerprint identification, voice recognition, iris scanning, vein pattern analysis, and behavioural biometrics (gait, typing patterns, signature dynamics).\n\n## Legal Framework for Biometric Data\n\n### GDPR Definition — Art. 4(14)\n\n\"'Biometric data' means personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data.\"\n\n### Art. 9(1) — Prohibition on Processing Special Categories\n\nProcessing of biometric data for the purpose of uniquely identifying a natural person is prohibited unless one of the Art. 9(2) exemptions applies.\n\n**Critical distinction**: Art. 9 only applies when biometric data is processed \"for the purpose of uniquely identifying\" a person. A photograph used for illustration purposes is not Art. 9 data; the same photograph processed through facial recognition software to identify the person is Art. 9 data.\n\n### Art. 9(2) Exemptions Applicable to Biometric Processing\n\n| Exemption | Reference | Application to Biometrics |\n|-----------|-----------|--------------------------|\n| Explicit consent | Art. 9(2)(a) | Employee consent often not freely given due to power imbalance (WP29 Opinion 2\u002F2017). Consumer biometric consent must meet Art. 7 standards. |\n| Employment, social security, social protection law | Art. 9(2)(b) | Member State law may authorise biometric processing in the employment context (e.g., biometric access control for high-security areas). |\n| Vital interests | Art. 9(2)(c) | Limited to emergency situations where biometric identification is needed to protect someone's life. |\n| Substantial public interest | Art. 9(2)(g) | Member State law basis required. May apply to law enforcement biometrics where authorised by specific legislation. |\n| Health or social care | Art. 9(2)(h) | Biometric patient identification in healthcare settings. |\n| Public health | Art. 9(2)(i) | Biometric contact tracing during health emergencies (subject to proportionality). |\n| Archiving, scientific research, statistics | Art. 9(2)(j) | Biometric research (e.g., medical imaging analysis) with Art. 89(1) safeguards. |\n\n### Art. 35(3)(b) — Mandatory DPIA Trigger\n\nProcessing on a large scale of special categories of data referred to in Art. 9(1), including biometric data processed for unique identification, requires a DPIA. \"Large scale\" factors per WP248rev.01:\n- Number of data subjects (in absolute terms or as a proportion of the relevant population)\n- Volume of data and\u002For range of data items\n- Duration or permanence of the processing\n- Geographic scope\n\n### EDPB Guidelines 3\u002F2019 on Video Surveillance\n\nKey provisions relevant to facial recognition CCTV:\n- Facial recognition in public spaces generally constitutes systematic monitoring of publicly accessible areas (Art. 35(3)(c)) in addition to large-scale biometric processing (Art. 35(3)(b)).\n- Facial recognition for access control is less intrusive than identification in public spaces but still requires DPIA.\n- Purpose limitation: biometric templates created for access control must not be repurposed for attendance monitoring or performance management.\n- Storage limitation: biometric templates should be stored on a device controlled by the data subject (e.g., access card) rather than a central database where possible.\n\n## Biometric System Types and Risk Assessment\n\n### Verification (1:1 Matching)\n\nOne-to-one comparison of a live biometric sample against a stored template for the claimed identity. Used for access control, device unlock, payment authentication.\n\n| Risk Factor | Assessment |\n|-------------|-----------|\n| Data subjects | Defined, enrolled individuals |\n| Volume of data | Limited to enrolled population |\n| Proportionality | Generally more proportionate than identification |\n| Storage recommendation | Template stored on user's device or card (decentralised) |\n| Art. 35(3)(b) trigger | Depends on scale of enrolled population |\n\n### Identification (1:N Matching)\n\nOne-to-many comparison of a live biometric sample against a database of templates to determine identity. Used for law enforcement, border control, surveillance.\n\n| Risk Factor | Assessment |\n|-------------|-----------|\n| Data subjects | Potentially unlimited (all persons in the capture area) |\n| Volume of data | Can be very large (entire population databases) |\n| Proportionality | Highly intrusive; requires strong justification |\n| Storage recommendation | Centralised database is typically required for 1:N matching |\n| Art. 35(3)(b) trigger | Almost always triggered |\n\n### Categorisation\n\nClassification of individuals into groups based on biometric characteristics (age, gender, ethnicity, emotion) without uniquely identifying them. Used for analytics, targeted advertising, audience measurement.\n\n| Risk Factor | Assessment |\n|-------------|-----------|\n| Art. 9 applicability | May not fall under Art. 9 if not used for unique identification, but still high risk |\n| AI Act classification | Emotion recognition in workplace\u002Feducation prohibited (Art. 5(1)(f)) |\n| Discrimination risk | Categorisation by race, ethnicity, or emotion raises equality law concerns |\n\n## DPIA Content for Biometric Systems\n\n### Systematic Description\n\nFor biometric systems, the Art. 35(7)(a) systematic description must include:\n\n| Element | Required Detail |\n|---------|----------------|\n| Biometric modality | Facial, fingerprint, iris, voice, vein, gait, or multi-modal |\n| Processing mode | Verification (1:1) or identification (1:N) or categorisation |\n| Capture environment | Controlled (sensor\u002Fscanner) or uncontrolled (CCTV, ambient camera) |\n| Template storage | Centralised database, decentralised (user device\u002Fcard), or encrypted enclave |\n| Template format | Proprietary template, ISO 19794 standard, or raw biometric data |\n| Matching algorithm | Vendor algorithm (specify), open-source algorithm, or custom development |\n| Accuracy metrics | False Acceptance Rate (FAR), False Rejection Rate (FRR), Equal Error Rate (EER) |\n| Liveness detection | Anti-spoofing measures (presentation attack detection) |\n| Fallback mechanism | Alternative identification method when biometric fails |\n| Retention period | Template retention, raw biometric data retention, audit log retention |\n\n### Necessity and Proportionality for Biometric Processing\n\nThe proportionality assessment for biometric systems must be rigorous because biometric data:\n- Is permanent (unlike passwords, biometric characteristics cannot be changed if compromised)\n- Is uniquely identifying (biometric data is inherently linked to the individual)\n- Creates heightened risk of function creep (biometric templates can be repurposed)\n- Has disproportionate impact if breached (biometric data cannot be reissued)\n\n| Proportionality Question | Assessment Standard |\n|--------------------------|-------------------|\n| Is biometric processing necessary, or can a non-biometric alternative achieve the same purpose? | Badge\u002Fcard access, PIN, password, or multi-factor authentication without biometrics |\n| Is the biometric modality the least intrusive option? | Fingerprint is generally less intrusive than facial recognition; on-device verification less intrusive than centralised identification |\n| Is the scale of biometric processing proportionate? | Processing all persons in an area (identification) is less proportionate than processing enrolled volunteers (verification) |\n| Is the retention of biometric data minimised? | On-card template storage preferred over centralised database; raw biometric images should not be retained after template extraction |\n\n## Risk Register for Biometric DPIA\n\n### Common Biometric Processing Risks\n\n| Risk ID | Risk | Likelihood | Severity | Typical Level |\n|---------|------|-----------|----------|--------------|\n| BIO-R1 | Biometric data breach — templates or raw data exposed to unauthorised parties | Possible | Maximum | Very High |\n| BIO-R2 | Function creep — biometric data collected for access control repurposed for surveillance or attendance monitoring | Likely | Significant | High |\n| BIO-R3 | Discriminatory accuracy — facial recognition performs worse on certain demographic groups (skin colour, age, gender) | Likely | Significant | High |\n| BIO-R4 | False rejection denying legitimate access — disabled individuals, elderly, or those with skin conditions experience higher rejection rates | Possible | Significant | High |\n| BIO-R5 | Spoofing or presentation attacks — fraudulent biometric samples (photos, masks, artificial fingerprints) bypass security | Possible | Significant | High |\n| BIO-R6 | Chilling effect — knowledge of biometric surveillance alters behaviour in public or workplace spaces | Likely | Limited | High |\n| BIO-R7 | Irreversibility — unlike passwords, compromised biometric data cannot be changed or reissued | Almost certain | Maximum | Very High |\n| BIO-R8 | Third-party capture — biometric data of non-enrolled individuals incidentally captured by the system | Likely | Limited | High |\n\n## Mitigation Measures for Biometric Processing\n\n| Measure | Type | Risk Addressed |\n|---------|------|---------------|\n| On-device or on-card template storage (no centralised database) | Technical (DPbD) | BIO-R1, BIO-R7 |\n| Template protection: cancellable biometrics or biometric encryption (BioHashing, fuzzy vault) | Technical | BIO-R1, BIO-R7 |\n| Liveness detection \u002F presentation attack detection (ISO 30107 compliance) | Technical | BIO-R5 |\n| Purpose limitation enforcement through technical access controls | Technical + Organisational | BIO-R2 |\n| Demographic accuracy testing across skin colour, age, gender groups (NIST FRVT benchmarks) | Technical | BIO-R3 |\n| Non-biometric fallback mechanism (PIN, card, helpdesk override) | Organisational | BIO-R4 |\n| Signage and transparency notices in capture areas | Organisational (Transparency) | BIO-R6, BIO-R8 |\n| Automatic deletion of raw biometric images after template extraction | Technical (Data minimisation) | BIO-R1 |\n| Regular penetration testing of biometric system | Technical (Security) | BIO-R5 |\n\n## Enforcement Precedents\n\n- **CNIL vs Clearview AI (2022)**: EUR 20 million fine for mass collection of facial images from internet for biometric identification database without consent, transparency, or DPIA.\n- **ICO vs Clearview AI (2022)**: GBP 7.5 million fine for same biometric processing; enforcement notice ordering deletion of UK residents' biometric data.\n- **Swedish DPA vs Skelleftea Municipality (2019)**: SEK 200,000 fine for school using facial recognition for student attendance tracking. Consent relied upon was not freely given due to power imbalance. Less intrusive alternatives were available.\n- **ICO vs Serco Leisure (2022)**: Enforcement notice for requiring employees to use facial recognition for time and attendance at leisure centres. No DPIA conducted; no less intrusive alternative offered.\n- **CNIL vs Clearview AI (2023)**: EUR 5.2 million additional penalty for non-compliance with the 2022 order, demonstrating the consequences of continued biometric processing in violation of enforcement.\n- **French Conseil d'Etat vs Presto (2020)**: Upheld CNIL enforcement against biometric time-and-attendance system for employees; found that fingerprint scanning for attendance was disproportionate when badge systems were available.\n- **Italian Garante vs P&G (Gillette) (2022)**: Enforcement action against automated age estimation system using facial analysis in retail stores without DPIA and without valid consent.\n","# Assessing Biometric Processing Privacy\n\n## Overview\n\nBiometric data is classified as a special category of personal data under GDPR Art. 9(1) when processed for the purpose of uniquely identifying a natural person. Processing biometric data on a large scale triggers a mandatory DPIA under Art. 35(3)(b). This skill provides a comprehensive DPIA methodology for biometric systems including facial recognition, fingerprint identification, voice recognition, iris scanning, vein pattern analysis, and behavioural biometrics (gait, typing patterns, signature dynamics).\n\n## Legal Framework for Biometric Data\n\n### GDPR Definition — Art. 4(14)\n\n\"'Biometric data' means personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data.\"\n\n### Art. 9(1) — Prohibition on Processing Special Categories\n\nProcessing of biometric data for the purpose of uniquely identifying a natural person is prohibited unless one of the Art. 9(2) exemptions applies.\n\n**Critical distinction**: Art. 9 only applies when biometric data is processed \"for the purpose of uniquely identifying\" a person. A photograph used for illustration purposes is not Art. 9 data; the same photograph processed through facial recognition software to identify the person is Art. 9 data.\n\n### Art. 9(2) Exemptions Applicable to Biometric Processing\n\n| Exemption | Reference | Application to Biometrics |\n|-----------|-----------|--------------------------|\n| Explicit consent | Art. 9(2)(a) | Employee consent often not freely given due to power imbalance (WP29 Opinion 2\u002F2017). Consumer biometric consent must meet Art. 7 standards. |\n| Employment, social security, social protection law | Art. 9(2)(b) | Member State law may authorise biometric processing in the employment context (e.g., biometric access control for high-security areas). |\n| Vital interests | Art. 9(2)(c) | Limited to emergency situations where biometric identification is needed to protect someone's life. |\n| Substantial public interest | Art. 9(2)(g) | Member State law basis required. May apply to law enforcement biometrics where authorised by specific legislation. |\n| Health or social care | Art. 9(2)(h) | Biometric patient identification in healthcare settings. |\n| Public health | Art. 9(2)(i) | Biometric contact tracing during health emergencies (subject to proportionality). |\n| Archiving, scientific research, statistics | Art. 9(2)(j) | Biometric research (e.g., medical imaging analysis) with Art. 89(1) safeguards. |\n\n### Art. 35(3)(b) — Mandatory DPIA Trigger\n\nProcessing on a large scale of special categories of data referred to in Art. 9(1), including biometric data processed for unique identification, requires a DPIA. \"Large scale\" factors per WP248rev.01:\n- Number of data subjects (in absolute terms or as a proportion of the relevant population)\n- Volume of data and\u002For range of data items\n- Duration or permanence of the processing\n- Geographic scope\n\n### EDPB Guidelines 3\u002F2019 on Video Surveillance\n\nKey provisions relevant to facial recognition CCTV:\n- Facial recognition in public spaces generally constitutes systematic monitoring of publicly accessible areas (Art. 35(3)(c)) in addition to large-scale biometric processing (Art. 35(3)(b)).\n- Facial recognition for access control is less intrusive than identification in public spaces but still requires DPIA.\n- Purpose limitation: biometric templates created for access control must not be repurposed for attendance monitoring or performance management.\n- Storage limitation: biometric templates should be stored on a device controlled by the data subject (e.g., access card) rather than a central database where possible.\n\n## Biometric System Types and Risk Assessment\n\n### Verification (1:1 Matching)\n\nOne-to-one comparison of a live biometric sample against a stored template for the claimed identity. Used for access control, device unlock, payment authentication.\n\n| Risk Factor | Assessment |\n|-------------|-----------|\n| Data subjects | Defined, enrolled individuals |\n| Volume of data | Limited to enrolled population |\n| Proportionality | Generally more proportionate than identification |\n| Storage recommendation | Template stored on user's device or card (decentralised) |\n| Art. 35(3)(b) trigger | Depends on scale of enrolled population |\n\n### Identification (1:N Matching)\n\nOne-to-many comparison of a live biometric sample against a database of templates to determine identity. Used for law enforcement, border control, surveillance.\n\n| Risk Factor | Assessment |\n|-------------|-----------|\n| Data subjects | Potentially unlimited (all persons in the capture area) |\n| Volume of data | Can be very large (entire population databases) |\n| Proportionality | Highly intrusive; requires strong justification |\n| Storage recommendation | Centralised database is typically required for 1:N matching |\n| Art. 35(3)(b) trigger | Almost always triggered |\n\n### Categorisation\n\nClassification of individuals into groups based on biometric characteristics (age, gender, ethnicity, emotion) without uniquely identifying them. Used for analytics, targeted advertising, audience measurement.\n\n| Risk Factor | Assessment |\n|-------------|-----------|\n| Art. 9 applicability | May not fall under Art. 9 if not used for unique identification, but still high risk |\n| AI Act classification | Emotion recognition in workplace\u002Feducation prohibited (Art. 5(1)(f)) |\n| Discrimination risk | Categorisation by race, ethnicity, or emotion raises equality law concerns |\n\n## DPIA Content for Biometric Systems\n\n### Systematic Description\n\nFor biometric systems, the Art. 35(7)(a) systematic description must include:\n\n| Element | Required Detail |\n|---------|----------------|\n| Biometric modality | Facial, fingerprint, iris, voice, vein, gait, or multi-modal |\n| Processing mode | Verification (1:1) or identification (1:N) or categorisation |\n| Capture environment | Controlled (sensor\u002Fscanner) or uncontrolled (CCTV, ambient camera) |\n| Template storage | Centralised database, decentralised (user device\u002Fcard), or encrypted enclave |\n| Template format | Proprietary template, ISO 19794 standard, or raw biometric data |\n| Matching algorithm | Vendor algorithm (specify), open-source algorithm, or custom development |\n| Accuracy metrics | False Acceptance Rate (FAR), False Rejection Rate (FRR), Equal Error Rate (EER) |\n| Liveness detection | Anti-spoofing measures (presentation attack detection) |\n| Fallback mechanism | Alternative identification method when biometric fails |\n| Retention period | Template retention, raw biometric data retention, audit log retention |\n\n### Necessity and Proportionality for Biometric Processing\n\nThe proportionality assessment for biometric systems must be rigorous because biometric data:\n- Is permanent (unlike passwords, biometric characteristics cannot be changed if compromised)\n- Is uniquely identifying (biometric data is inherently linked to the individual)\n- Creates heightened risk of function creep (biometric templates can be repurposed)\n- Has disproportionate impact if breached (biometric data cannot be reissued)\n\n| Proportionality Question | Assessment Standard |\n|--------------------------|-------------------|\n| Is biometric processing necessary, or can a non-biometric alternative achieve the same purpose? | Badge\u002Fcard access, PIN, password, or multi-factor authentication without biometrics |\n| Is the biometric modality the least intrusive option? | Fingerprint is generally less intrusive than facial recognition; on-device verification less intrusive than centralised identification |\n| Is the scale of biometric processing proportionate? | Processing all persons in an area (identification) is less proportionate than processing enrolled volunteers (verification) |\n| Is the retention of biometric data minimised? | On-card template storage preferred over centralised database; raw biometric images should not be retained after template extraction |\n\n## Risk Register for Biometric DPIA\n\n### Common Biometric Processing Risks\n\n| Risk ID | Risk | Likelihood | Severity | Typical Level |\n|---------|------|-----------|----------|--------------|\n| BIO-R1 | Biometric data breach — templates or raw data exposed to unauthorised parties | Possible | Maximum | Very High |\n| BIO-R2 | Function creep — biometric data collected for access control repurposed for surveillance or attendance monitoring | Likely | Significant | High |\n| BIO-R3 | Discriminatory accuracy — facial recognition performs worse on certain demographic groups (skin colour, age, gender) | Likely | Significant | High |\n| BIO-R4 | False rejection denying legitimate access — disabled individuals, elderly, or those with skin conditions experience higher rejection rates | Possible | Significant | High |\n| BIO-R5 | Spoofing or presentation attacks — fraudulent biometric samples (photos, masks, artificial fingerprints) bypass security | Possible | Significant | High |\n| BIO-R6 | Chilling effect — knowledge of biometric surveillance alters behaviour in public or workplace spaces | Likely | Limited | High |\n| BIO-R7 | Irreversibility — unlike passwords, compromised biometric data cannot be changed or reissued | Almost certain | Maximum | Very High |\n| BIO-R8 | Third-party capture — biometric data of non-enrolled individuals incidentally captured by the system | Likely | Limited | High |\n\n## Mitigation Measures for Biometric Processing\n\n| Measure | Type | Risk Addressed |\n|---------|------|---------------|\n| On-device or on-card template storage (no centralised database) | Technical (DPbD) | BIO-R1, BIO-R7 |\n| Template protection: cancellable biometrics or biometric encryption (BioHashing, fuzzy vault) | Technical | BIO-R1, BIO-R7 |\n| Liveness detection \u002F presentation attack detection (ISO 30107 compliance) | Technical | BIO-R5 |\n| Purpose limitation enforcement through technical access controls | Technical + Organisational | BIO-R2 |\n| Demographic accuracy testing across skin colour, age, gender groups (NIST FRVT benchmarks) | Technical | BIO-R3 |\n| Non-biometric fallback mechanism (PIN, card, helpdesk override) | Organisational | BIO-R4 |\n| Signage and transparency notices in capture areas | Organisational (Transparency) | BIO-R6, BIO-R8 |\n| Automatic deletion of raw biometric images after template extraction | Technical (Data minimisation) | BIO-R1 |\n| Regular penetration testing of biometric system | Technical (Security) | BIO-R5 |\n\n## Enforcement Precedents\n\n- **CNIL vs Clearview AI (2022)**: EUR 20 million fine for mass collection of facial images from internet for biometric identification database without consent, transparency, or DPIA.\n- **ICO vs Clearview AI (2022)**: GBP 7.5 million fine for same biometric processing; enforcement notice ordering deletion of UK residents' biometric data.\n- **Swedish DPA vs Skelleftea Municipality (2019)**: SEK 200,000 fine for school using facial recognition for student attendance tracking. Consent relied upon was not freely given due to power imbalance. Less intrusive alternatives were available.\n- **ICO vs Serco Leisure (2022)**: Enforcement notice for requiring employees to use facial recognition for time and attendance at leisure centres. No DPIA conducted; no less intrusive alternative offered.\n- **CNIL vs Clearview AI (2023)**: EUR 5.2 million additional penalty for non-compliance with the 2022 order, demonstrating the consequences of continued biometric processing in violation of enforcement.\n- **French Conseil d'Etat vs Presto (2020)**: Upheld CNIL enforcement against biometric time-and-attendance system for employees; found that fingerprint scanning for attendance was disproportionate when badge systems were available.\n- **Italian Garante vs P&G (Gillette) (2022)**: Enforcement action against automated age estimation system using facial analysis in retail stores without DPIA and without valid consent.\n",{"name":5,"license":15,"metadata":37,"description":7},{"tags":38,"author":9,"domain":31,"version":39,"subdomain":40},"biometric, facial-recognition, fingerprint, dpia, art-9, special-category","1.0","privacy-impact-assessment","main","9b2ef9eae161c00a17241d42a388571321b33e9f","plugins\u002Fprivacy-skills-complete\u002Fskills\u002Fbiometric-dpia",67,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-03-17 04:06:52",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill biometric-dpia",{"tool":56,"command":57},"bunx","bunx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill biometric-dpia",{"tool":59,"command":60},"pnpm","pnpm dlx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill biometric-dpia","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fbiometric-dpia\u002FSKILL.md",true,[64,70,76,80],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"assets\u002Ftemplate.md","ASSET","资产文件",7593,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fbiometric-dpia\u002Fassets\u002Ftemplate.md",{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fstandards.md","REFERENCE","参考文档",6514,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fbiometric-dpia\u002Freferences\u002Fstandards.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fworkflows.md",5835,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fbiometric-dpia\u002Freferences\u002Fworkflows.md",{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"scripts\u002Fprocess.py","SCRIPT","脚本",14337,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fbiometric-dpia\u002Fscripts\u002Fprocess.py",[87,114,131,144,160,173],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":104,"publishedAt":32},"01M6AG6K8R3XW10ENWH2FH18RH","workplace-email-privacy","Implements email and internet monitoring compliance in the workplace per Barbulescu v Romania (ECHR Grand Chamber), EDPB guidance, and national labour law. Covers acceptable use policies, legitimate expectation of privacy, proportionality testing, and content vs metadata monitoring. Keywords: email monitoring, Barbulescu, workplace privacy, internet monitoring, acceptable use policy, ECHR, proportionality.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fworkplace-email-privacy\u002FSKILL.md",[93,96,99],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通",{"categoryNo":97,"categoryName":98,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[105,106,31,107,108,109,110,111,112,113],"email","workplace email privacy","compliance","content","data","policy","testing","monitoring","metadata",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":124,"publishedAt":32},"01M6AG6FRCBJY7D061BJZMNV49","whistleblower-data","Implements data protection compliance for whistleblowing systems under EU Directive 2019\u002F1937 and GDPR. Covers anonymous reporting channels, identity protection for whistleblowers and accused persons, retention limits, access restrictions, and retaliation prevention. Addresses national transpositions and DPA guidance. Keywords: whistleblower, Directive 2019\u002F1937, anonymous reporting, identity protection, retaliation, retention, reporting channel.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fwhistleblower-data\u002FSKILL.md",[120,123],{"categoryNo":121,"categoryName":122,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000033","数据分析师",{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},[109,125,126,127,107,128,129,31,130],"whistleblower data","identity","reporting","data protection","gdpr","prevention",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":138,"publishedAt":32},"01M6AG6CJP0PW3X65HC7VP9SR9","vendor-termination-data","Vendor termination data return and deletion procedures per GDPR Article 28(3)(g). Covers data extraction formats, deletion certification requirements, transition planning, residual data handling, and post-termination verification.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fvendor-termination-data\u002FSKILL.md",[137],{"categoryNo":121,"categoryName":122,"taxonomyType":102,"taxonomyTypeDesc":103},[109,139,140,141,142,129,31,143],"vendor termination data","planning","verification","extraction","certification",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":151,"publishedAt":32},"01M6AG69E277DXZB2NF6KV17ZA","vendor-risk-scoring","Vendor privacy risk tiering methodology for processor management. Covers scoring factors including data volume, sensitivity, transfer locations, certifications, breach history, and control maturity with weighted risk calculation and tier assignment.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fvendor-risk-scoring\u002FSKILL.md",[150],{"categoryNo":121,"categoryName":122,"taxonomyType":102,"taxonomyTypeDesc":103},[152,153,154,155,156,29,157,158,31,109,159],"vendor risk scoring","risk","risk scoring","methodology","risk-scoring","transfer","certifications","processor",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":167,"publishedAt":32},"01M6AG6655ABFKT2BBWHCP4PAT","vendor-privacy-due-diligence","Pre-contract vendor privacy due diligence per GDPR Article 28(1). Covers risk questionnaires, technical controls assessment, certification review, data flow analysis, and documented sufficiency decisions for processor engagement.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fvendor-privacy-due-diligence\u002FSKILL.md",[166],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},[31,168,129,169,29,170,171,109,159,153,143,172],"vendor privacy due diligence","review","onboarding","flow","analysis",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":186,"publishedAt":32},"01M6AG62C3VD8SYNGH4N7RHZTE","vendor-privacy-audit","On-site and remote vendor audit procedures per GDPR Article 28(3)(h). Covers audit planning, evidence collection methodologies, finding classification, remediation tracking, and audit report generation for processor compliance verification.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fvendor-privacy-audit\u002FSKILL.md",[179,182,185],{"categoryNo":180,"categoryName":181,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":183,"categoryName":184,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},[187,188,31,189,141,190,107,129,191,159,192,193,194,140],"vendor privacy audit","audit","report","audit report","remediation","collection","remediation-tracking","classification"]