[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AFNRPBEX5D8PM6TCZMTK7N":3,"skill-same:01M6AFNRPBEX5D8PM6TCZMTK7N":95},{"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":23,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6AFNRPBEX5D8PM6TCZMTK7N","dsar-intake-system",null,"Builds a multi-channel DSAR intake system supporting web form, email, phone, and in-person requests with identity verification tiers, automated routing logic, SLA tracking, and response generation. Activate for DSAR intake, rights request portal, multi-channel intake, SLA tracking, request management queries.","mukul975\u002FPrivacy-Data-Protection-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADNKWX1HF4Q5DKEXT5M774",337,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdsar-intake-system\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37],"intake","dsar intake system","dsar","web","identity","routing","verification","email","privacy","data","sla","sla-tracking","data-subject-rights","identity-verification","2026-11-10 10:12:30",false,"---\nname: dsar-intake-system\ndescription: >-\n  Builds a multi-channel DSAR intake system supporting web form, email, phone,\n  and in-person requests with identity verification tiers, automated routing\n  logic, SLA tracking, and response generation. Activate for DSAR intake,\n  rights request portal, multi-channel intake, SLA tracking, request management queries.\nlicense: Apache-2.0\nmetadata:\n  author: mukul975\n  version: \"1.0\"\n  domain: privacy\n  subdomain: data-subject-rights\n  tags: \"dsar-intake, multi-channel, identity-verification, sla-tracking, request-management\"\n---\n\n# Building a Universal DSAR Intake System\n\n## Overview\n\nA universal DSAR intake system centralises the receipt, verification, routing, and tracking of all data subject rights requests across multiple channels. This skill provides the architectural design, identity verification framework, routing logic, SLA management, and response generation capabilities needed to operate a compliant and efficient rights request management programme.\n\n## System Architecture\n\n### Multi-Channel Intake\n\nThe intake system must accept requests from all channels through which data subjects may contact the organisation:\n\n| Channel | Intake Method | Processing |\n|---------|--------------|------------|\n| Web form | Dedicated privacy rights portal at meridiananalytics.co.uk\u002Fprivacy\u002Frights | Automated capture, structured data, immediate acknowledgement |\n| Email | dsar@meridiananalytics.co.uk (dedicated monitored inbox) | Semi-automated: email parser extracts key fields, manual triage |\n| Telephone | Privacy hotline: +44 20 7946 0958 (staffed Mon-Fri 09:00-17:00 GMT) | Agent-assisted: agent completes intake form during call |\n| Postal mail | Data Protection Office, 47 Canary Wharf Tower, London E14 5AB | Manual: scanned, digitised, entered into system within 2 business days |\n| In-person | Reception desk at registered office | Agent-assisted: staff member completes intake form |\n| Social media | Direct messages on official channels | Redirect to formal channel; do not process rights requests via social media |\n\n### Central Request Register\n\nAll requests from all channels feed into a single central register with the following record structure:\n\n| Field | Description |\n|-------|-------------|\n| Reference | Auto-generated: [TYPE]-YYYY-NNNN (e.g., DSAR-2026-0142) |\n| Receipt date | UTC timestamp of initial receipt |\n| Channel | Source channel |\n| Request type | Access (Art. 15), Erasure (Art. 17), Portability (Art. 20), Restriction (Art. 18), Rectification (Art. 16), Object (Art. 21), Marketing opt-out (Art. 21(2)), Automated decision (Art. 22), CCPA know, CCPA delete, CCPA opt-out |\n| Data subject name | As provided by requester |\n| Data subject identifiers | Email, account number, other identifiers provided |\n| Verification status | Pending \u002F Verified \u002F Failed |\n| Verification tier | Low \u002F Medium \u002F High |\n| Assignee | Privacy team member responsible |\n| Priority | Standard \u002F Complex \u002F Urgent |\n| Status | Received \u002F Acknowledged \u002F Verifying \u002F Processing \u002F QA Review \u002F Delivered \u002F Closed |\n| Deadline | Calculated response deadline |\n| Extension | Whether extension has been applied |\n| Notes | Free text for processing notes |\n\n## Identity Verification Framework\n\n### Tiered Verification\n\n| Tier | When Applied | Requirements | Clock Behaviour |\n|------|-------------|--------------|-----------------|\n| **Tier 1 — Low Risk** | Request from authenticated account (logged-in portal, verified email) | Confirm account ownership via existing authentication | Clock starts immediately |\n| **Tier 2 — Medium Risk** | Request from known email address (matches records) but not authenticated | Provide 2 of: date of birth, account number, postal code, last 4 digits of payment method | Clock starts on verification |\n| **Tier 3 — High Risk** | Request from unknown channel, or request on behalf of another person | Government-issued photo ID + one additional identifier. Third-party requests: signed authorisation from data subject + ID for both | Clock starts on verification |\n\n### Verification Workflow\n\n```\n[Request Received]\n         │\n         ▼\n[Determine Verification Tier]\n   │\n   ├── Authenticated channel? ──► Tier 1 (auto-verified)\n   ├── Known identifier matches? ──► Tier 2 (request 2 data points)\n   └── Unknown channel \u002F third party? ──► Tier 3 (request ID + authorisation)\n         │\n         ▼\n[Verification Request Sent (within 3 business days)]\n         │\n         ▼\n[Verification Response Received?]\n   ├── Yes ──► [Data Points Match?]\n   │             ├── Yes ──► Mark Verified, start clock\n   │             └── No ──► Request additional info (one retry)\n   │                          ├── Second attempt matches ──► Verified\n   │                          └── Second attempt fails ──► Close as Unverified\n   │\n   └── No response (30 days) ──► Close as Abandoned\n```\n\n## Routing Logic\n\n### Automated Request Classification\n\nUpon intake, the system classifies and routes requests based on:\n\n1. **Request type** (extracted from web form selection or email keywords):\n   - Access\u002FDSAR → DSAR team\n   - Erasure\u002FDeletion → Erasure team\n   - Portability\u002FExport → Portability team\n   - Marketing opt-out → Marketing Operations (immediate processing)\n   - CCPA requests → US Privacy team\n   - Regulatory complaint → DPO + Legal\n\n2. **Complexity assessment**:\n   - Standard: single request type, single jurisdiction, \u003C 5 data systems\n   - Complex: multiple request types, cross-border, > 5 data systems, or involving exemptions\n   - Urgent: regulatory enquiry, legal deadline, or data subject facing imminent harm\n\n3. **Jurisdiction detection**:\n   - UK\u002FEU data subject → GDPR workflow (30-day deadline)\n   - California resident → CCPA workflow (45-day deadline)\n   - Other US state → Applicable state privacy law workflow\n   - Other jurisdiction → Assess applicable law, default to GDPR standard\n\n### Routing Matrix\n\n| Request Type | Assignee | Priority | SLA |\n|-------------|----------|----------|-----|\n| DSAR (Art. 15) — Standard | Privacy Analyst | Standard | 30 days |\n| DSAR (Art. 15) — Complex | Senior Privacy Analyst | Complex | 30 days (extendable to 90) |\n| Erasure (Art. 17) | Privacy Analyst | Standard | 30 days |\n| Portability (Art. 20) | Data Engineer + Privacy Analyst | Standard | 30 days |\n| Rectification (Art. 16) | Privacy Analyst | Standard | 30 days |\n| Restriction (Art. 18) | Senior Privacy Analyst | Standard | 30 days + 72h implementation |\n| Object (Art. 21) | DPO | Complex | 30 days + immediate cessation |\n| Marketing opt-out (Art. 21(2)) | Marketing Operations | Urgent | 24 hours |\n| Automated decision (Art. 22) | DPO + Technical Lead | Complex | 30 days |\n| CCPA Know | Privacy Analyst | Standard | 45 days |\n| CCPA Delete | Privacy Analyst | Standard | 45 days |\n| CCPA Opt-Out | Marketing Operations | Urgent | 15 business days |\n| Regulatory complaint | DPO + General Counsel | Urgent | Per DPA deadline |\n\n## SLA Tracking\n\n### Dashboard Metrics\n\n| Metric | Target | Measurement |\n|--------|--------|-------------|\n| Acknowledgement within 3 business days | 100% | (Acknowledged requests \u002F Total requests) within 3 business days |\n| Response within statutory deadline | 100% | (On-time responses \u002F Total responses) |\n| Average response time | \u003C 20 calendar days | Sum of response days \u002F Number of completed requests |\n| Verification completion rate | > 95% | (Verified requests \u002F Total requests requiring verification) |\n| Extension rate | \u003C 15% | (Extended requests \u002F Total requests) |\n| First-contact resolution (marketing opt-out) | 100% within 24h | (Resolved within 24h \u002F Total marketing opt-outs) |\n\n### Escalation Rules\n\n| Condition | Escalation |\n|-----------|-----------|\n| 20 days elapsed, response not delivered | Alert to assignee and team lead |\n| 25 days elapsed, response not delivered | Alert to DPO |\n| 28 days elapsed, response not delivered | Alert to DPO + General Counsel (emergency priority) |\n| Extension notification not sent by day 28 | Alert to DPO (compliance risk) |\n| Verification pending > 14 days | Alert to assignee (follow up with data subject) |\n\n## Response Generation\n\n### Automated Response Components\n\nThe system generates responses by assembling modular components:\n\n1. **Cover letter**: Standard header, addressee, reference number, opening paragraph.\n2. **Right-specific content**: Template paragraph for each right type.\n3. **Data compilation**: System-generated data extract (for access requests).\n4. **Supplementary information**: Art. 15(1)(a)-(h) information block (for access requests).\n5. **Redaction log**: Automatically generated from redaction flags (for access requests with exemptions).\n6. **Third-party notification log**: Recipients notified under Art. 19 (for erasure\u002Frectification\u002Frestriction).\n7. **Rights information**: Standard block listing the data subject's other rights and complaint mechanisms.\n8. **Sign-off**: DPO name and contact details.\n\n### Quality Assurance Checklist\n\nBefore any response is sent, the QA reviewer verifies:\n\n- [ ] Response addresses all elements of the relevant GDPR article\n- [ ] Data extract is complete (all identified systems queried)\n- [ ] Redactions are legally justified and documented\n- [ ] Response deadline has been met (or extension properly communicated)\n- [ ] Response is in clear, plain language per Art. 12\n- [ ] Delivery method is secure (encryption, secure portal, or registered post)\n- [ ] DPO sign-off obtained\n","# Building a Universal DSAR Intake System\n\n## Overview\n\nA universal DSAR intake system centralises the receipt, verification, routing, and tracking of all data subject rights requests across multiple channels. This skill provides the architectural design, identity verification framework, routing logic, SLA management, and response generation capabilities needed to operate a compliant and efficient rights request management programme.\n\n## System Architecture\n\n### Multi-Channel Intake\n\nThe intake system must accept requests from all channels through which data subjects may contact the organisation:\n\n| Channel | Intake Method | Processing |\n|---------|--------------|------------|\n| Web form | Dedicated privacy rights portal at meridiananalytics.co.uk\u002Fprivacy\u002Frights | Automated capture, structured data, immediate acknowledgement |\n| Email | dsar@meridiananalytics.co.uk (dedicated monitored inbox) | Semi-automated: email parser extracts key fields, manual triage |\n| Telephone | Privacy hotline: +44 20 7946 0958 (staffed Mon-Fri 09:00-17:00 GMT) | Agent-assisted: agent completes intake form during call |\n| Postal mail | Data Protection Office, 47 Canary Wharf Tower, London E14 5AB | Manual: scanned, digitised, entered into system within 2 business days |\n| In-person | Reception desk at registered office | Agent-assisted: staff member completes intake form |\n| Social media | Direct messages on official channels | Redirect to formal channel; do not process rights requests via social media |\n\n### Central Request Register\n\nAll requests from all channels feed into a single central register with the following record structure:\n\n| Field | Description |\n|-------|-------------|\n| Reference | Auto-generated: [TYPE]-YYYY-NNNN (e.g., DSAR-2026-0142) |\n| Receipt date | UTC timestamp of initial receipt |\n| Channel | Source channel |\n| Request type | Access (Art. 15), Erasure (Art. 17), Portability (Art. 20), Restriction (Art. 18), Rectification (Art. 16), Object (Art. 21), Marketing opt-out (Art. 21(2)), Automated decision (Art. 22), CCPA know, CCPA delete, CCPA opt-out |\n| Data subject name | As provided by requester |\n| Data subject identifiers | Email, account number, other identifiers provided |\n| Verification status | Pending \u002F Verified \u002F Failed |\n| Verification tier | Low \u002F Medium \u002F High |\n| Assignee | Privacy team member responsible |\n| Priority | Standard \u002F Complex \u002F Urgent |\n| Status | Received \u002F Acknowledged \u002F Verifying \u002F Processing \u002F QA Review \u002F Delivered \u002F Closed |\n| Deadline | Calculated response deadline |\n| Extension | Whether extension has been applied |\n| Notes | Free text for processing notes |\n\n## Identity Verification Framework\n\n### Tiered Verification\n\n| Tier | When Applied | Requirements | Clock Behaviour |\n|------|-------------|--------------|-----------------|\n| **Tier 1 — Low Risk** | Request from authenticated account (logged-in portal, verified email) | Confirm account ownership via existing authentication | Clock starts immediately |\n| **Tier 2 — Medium Risk** | Request from known email address (matches records) but not authenticated | Provide 2 of: date of birth, account number, postal code, last 4 digits of payment method | Clock starts on verification |\n| **Tier 3 — High Risk** | Request from unknown channel, or request on behalf of another person | Government-issued photo ID + one additional identifier. Third-party requests: signed authorisation from data subject + ID for both | Clock starts on verification |\n\n### Verification Workflow\n\n```\n[Request Received]\n         │\n         ▼\n[Determine Verification Tier]\n   │\n   ├── Authenticated channel? ──► Tier 1 (auto-verified)\n   ├── Known identifier matches? ──► Tier 2 (request 2 data points)\n   └── Unknown channel \u002F third party? ──► Tier 3 (request ID + authorisation)\n         │\n         ▼\n[Verification Request Sent (within 3 business days)]\n         │\n         ▼\n[Verification Response Received?]\n   ├── Yes ──► [Data Points Match?]\n   │             ├── Yes ──► Mark Verified, start clock\n   │             └── No ──► Request additional info (one retry)\n   │                          ├── Second attempt matches ──► Verified\n   │                          └── Second attempt fails ──► Close as Unverified\n   │\n   └── No response (30 days) ──► Close as Abandoned\n```\n\n## Routing Logic\n\n### Automated Request Classification\n\nUpon intake, the system classifies and routes requests based on:\n\n1. **Request type** (extracted from web form selection or email keywords):\n   - Access\u002FDSAR → DSAR team\n   - Erasure\u002FDeletion → Erasure team\n   - Portability\u002FExport → Portability team\n   - Marketing opt-out → Marketing Operations (immediate processing)\n   - CCPA requests → US Privacy team\n   - Regulatory complaint → DPO + Legal\n\n2. **Complexity assessment**:\n   - Standard: single request type, single jurisdiction, \u003C 5 data systems\n   - Complex: multiple request types, cross-border, > 5 data systems, or involving exemptions\n   - Urgent: regulatory enquiry, legal deadline, or data subject facing imminent harm\n\n3. **Jurisdiction detection**:\n   - UK\u002FEU data subject → GDPR workflow (30-day deadline)\n   - California resident → CCPA workflow (45-day deadline)\n   - Other US state → Applicable state privacy law workflow\n   - Other jurisdiction → Assess applicable law, default to GDPR standard\n\n### Routing Matrix\n\n| Request Type | Assignee | Priority | SLA |\n|-------------|----------|----------|-----|\n| DSAR (Art. 15) — Standard | Privacy Analyst | Standard | 30 days |\n| DSAR (Art. 15) — Complex | Senior Privacy Analyst | Complex | 30 days (extendable to 90) |\n| Erasure (Art. 17) | Privacy Analyst | Standard | 30 days |\n| Portability (Art. 20) | Data Engineer + Privacy Analyst | Standard | 30 days |\n| Rectification (Art. 16) | Privacy Analyst | Standard | 30 days |\n| Restriction (Art. 18) | Senior Privacy Analyst | Standard | 30 days + 72h implementation |\n| Object (Art. 21) | DPO | Complex | 30 days + immediate cessation |\n| Marketing opt-out (Art. 21(2)) | Marketing Operations | Urgent | 24 hours |\n| Automated decision (Art. 22) | DPO + Technical Lead | Complex | 30 days |\n| CCPA Know | Privacy Analyst | Standard | 45 days |\n| CCPA Delete | Privacy Analyst | Standard | 45 days |\n| CCPA Opt-Out | Marketing Operations | Urgent | 15 business days |\n| Regulatory complaint | DPO + General Counsel | Urgent | Per DPA deadline |\n\n## SLA Tracking\n\n### Dashboard Metrics\n\n| Metric | Target | Measurement |\n|--------|--------|-------------|\n| Acknowledgement within 3 business days | 100% | (Acknowledged requests \u002F Total requests) within 3 business days |\n| Response within statutory deadline | 100% | (On-time responses \u002F Total responses) |\n| Average response time | \u003C 20 calendar days | Sum of response days \u002F Number of completed requests |\n| Verification completion rate | > 95% | (Verified requests \u002F Total requests requiring verification) |\n| Extension rate | \u003C 15% | (Extended requests \u002F Total requests) |\n| First-contact resolution (marketing opt-out) | 100% within 24h | (Resolved within 24h \u002F Total marketing opt-outs) |\n\n### Escalation Rules\n\n| Condition | Escalation |\n|-----------|-----------|\n| 20 days elapsed, response not delivered | Alert to assignee and team lead |\n| 25 days elapsed, response not delivered | Alert to DPO |\n| 28 days elapsed, response not delivered | Alert to DPO + General Counsel (emergency priority) |\n| Extension notification not sent by day 28 | Alert to DPO (compliance risk) |\n| Verification pending > 14 days | Alert to assignee (follow up with data subject) |\n\n## Response Generation\n\n### Automated Response Components\n\nThe system generates responses by assembling modular components:\n\n1. **Cover letter**: Standard header, addressee, reference number, opening paragraph.\n2. **Right-specific content**: Template paragraph for each right type.\n3. **Data compilation**: System-generated data extract (for access requests).\n4. **Supplementary information**: Art. 15(1)(a)-(h) information block (for access requests).\n5. **Redaction log**: Automatically generated from redaction flags (for access requests with exemptions).\n6. **Third-party notification log**: Recipients notified under Art. 19 (for erasure\u002Frectification\u002Frestriction).\n7. **Rights information**: Standard block listing the data subject's other rights and complaint mechanisms.\n8. **Sign-off**: DPO name and contact details.\n\n### Quality Assurance Checklist\n\nBefore any response is sent, the QA reviewer verifies:\n\n- [ ] Response addresses all elements of the relevant GDPR article\n- [ ] Data extract is complete (all identified systems queried)\n- [ ] Redactions are legally justified and documented\n- [ ] Response deadline has been met (or extension properly communicated)\n- [ ] Response is in clear, plain language per Art. 12\n- [ ] Delivery method is secure (encryption, secure portal, or registered post)\n- [ ] DPO sign-off obtained\n",{"name":5,"license":15,"metadata":43,"description":7},{"tags":44,"author":9,"domain":32,"version":45,"subdomain":36},"dsar-intake, multi-channel, identity-verification, sla-tracking, request-management","1.0","main","9b2ef9eae161c00a17241d42a388571321b33e9f","skills\u002Fprivacy\u002Fdsar-intake-system",68,"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":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill dsar-intake-system",{"tool":61,"command":62},"bunx","bunx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill dsar-intake-system",{"tool":64,"command":65},"pnpm","pnpm dlx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill dsar-intake-system","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdsar-intake-system\u002FSKILL.md",true,[69,75,81,85,89],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"assets\u002Ftemplate.md","ASSET","资产文件",4462,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdsar-intake-system\u002Fassets\u002Ftemplate.md",{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fmonitoring-patterns.md","REFERENCE","参考文档",10593,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Finfrastructure\u002Fobservability-design\u002Freferences\u002Fmonitoring-patterns.md",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fstandards.md",2483,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdsar-intake-system\u002Freferences\u002Fstandards.md",{"path":86,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fworkflows.md",4944,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdsar-intake-system\u002Freferences\u002Fworkflows.md",{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"scripts\u002Fprocess.py","SCRIPT","脚本",11448,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdsar-intake-system\u002Fscripts\u002Fprocess.py",[96,121,135,147,164,177],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":113,"publishedAt":38},"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",[102,107,110],{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",{"categoryNo":108,"categoryName":109,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务",[31,114,32,115,116,33,117,118,119,120],"workplace email privacy","compliance","content","policy","testing","monitoring","metadata",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":129,"publishedAt":38},"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",[127,128],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},[33,130,28,131,115,132,133,32,134],"whistleblower data","reporting","data protection","gdpr","prevention",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":142,"publishedAt":38},"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",[141],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[33,143,144,30,145,133,32,146],"vendor termination data","planning","extraction","certification",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":154,"publishedAt":38},"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",[153],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[155,156,157,158,159,160,161,162,32,33,163],"vendor risk scoring","risk","risk scoring","methodology","risk-scoring","assessment","transfer","certifications","processor",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":171,"publishedAt":38},"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",[170],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},[32,172,133,173,160,174,175,33,163,156,146,176],"vendor privacy due diligence","review","onboarding","flow","analysis",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":190,"publishedAt":38},"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",[183,186,189],{"categoryNo":184,"categoryName":185,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":187,"categoryName":188,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},[191,192,32,193,30,194,115,133,195,163,196,197,198,144],"vendor privacy audit","audit","report","audit report","remediation","collection","remediation-tracking","classification"]