[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AFM6KESB6GKESPVMBK7H63":3,"skill-same:01M6AFM6KESB6GKESPVMBK7H63":93},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6AFM6KESB6GKESPVMBK7H63","data-lineage-tracking",null,"Implements data lineage tracking for privacy compliance including origin tracking, transformation logging, access auditing, deletion verification, and cross-system lineage graphs. Covers source-to-sink mapping, GDPR Art. 30 RoPA integration, automated lineage discovery, and breach impact scoping. Keywords: data lineage, data provenance, data flow mapping, transformation logging, deletion verification.","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\u002Fskills\u002Fprivacy\u002Fdata-lineage-tracking\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务",[27,28,29,30,31,32,33,34,35,36,37,38,39],"lineage","data","data lineage tracking","verification","logging","integration","compliance","gdpr","privacy","flow","data flow mapping","data-classification","provenance","2026-11-10 10:12:30",false,"---\nname: data-lineage-tracking\ndescription: >-\n  Implements data lineage tracking for privacy compliance including origin tracking,\n  transformation logging, access auditing, deletion verification, and cross-system\n  lineage graphs. Covers source-to-sink mapping, GDPR Art. 30 RoPA integration,\n  automated lineage discovery, and breach impact scoping. Keywords: data lineage,\n  data provenance, data flow mapping, transformation logging, deletion verification.\nlicense: Apache-2.0\nmetadata:\n  author: mukul975\n  version: \"1.0\"\n  domain: privacy\n  subdomain: data-classification\n  tags: \"data-lineage, data-provenance, data-flow-mapping, transformation-logging, deletion-verification\"\n---\n\n# Data Lineage Tracking\n\n## Purpose\n\nMap and document the complete lifecycle of personal data through organizational systems, from initial collection point through all transformations, transfers, and storage locations to final deletion or anonymization.\n\n## Prerequisites\n\n- Data inventory or asset register identifying systems processing personal data\n- Network architecture documentation showing system interconnections\n- Access to system metadata, ETL configurations, and API documentation\n- Records of Processing Activities (RoPA) under GDPR Article 30\n\n## Workflow\n\n### Step 1: Define Lineage Scope\n\nDetermine scope boundaries for the lineage mapping exercise:\n\n1. **Data categories**: Identify which personal data categories to trace (identity data, contact data, financial data, behavioral data, special category data under Art. 9)\n2. **System boundaries**: Define which systems are in-scope (production databases, data warehouses, analytics platforms, third-party SaaS, backup systems)\n3. **Temporal scope**: Determine whether to map current-state lineage only or include historical data flows\n4. **Legal basis mapping**: Link each processing activity in the lineage to its GDPR Article 6 lawful basis\n\n### Step 2: Identify Data Sources (Collection Points)\n\nDocument every point where personal data enters the organization:\n\n1. **Direct collection**: Web forms, mobile apps, point-of-sale terminals, customer service interactions, paper forms digitized via scanning\n2. **Indirect collection**: Third-party data providers, publicly available sources, data brokers, partner organizations\n3. **Derived data**: Data generated through processing (risk scores, customer segments, behavioral profiles)\n4. **Inferred data**: Data inferred from other data points (creditworthiness, health predictions, preferences)\n\nFor each source, record:\n- Source identifier and type\n- Data categories collected (referencing Art. 30(1)(c) categories)\n- Legal basis under Art. 6(1) and, if applicable, Art. 9(2)\n- Information provided to data subjects per Art. 13 or Art. 14\n- Volume and frequency of collection\n\n### Step 3: Map Data Transformations\n\nDocument every transformation applied to personal data:\n\n1. **ETL processes**: Extract-Transform-Load pipelines moving data between systems\n2. **Aggregation**: Grouping individual records into summary statistics\n3. **Pseudonymization**: Replacing identifiers with tokens per Art. 4(5) and Recital 26\n4. **Anonymization**: Irreversible de-identification per WP29 Opinion 05\u002F2014\n5. **Enrichment**: Combining data from multiple sources to create enriched profiles\n6. **Format conversion**: Changing data formats (CSV to JSON, database migration)\n\nFor each transformation, record:\n- Input data categories and source system\n- Transformation logic description\n- Output data categories and destination system\n- Whether transformation changes the identifiability of data subjects\n- Retention period at destination per Art. 5(1)(e) storage limitation\n\n### Step 4: Document Data Flows and Transfers\n\nMap all movements of personal data between systems and parties:\n\n1. **Internal flows**: Between departments, systems, databases within the organization\n2. **Processor transfers**: To data processors under Art. 28 agreements\n3. **Third-country transfers**: Cross-border transfers requiring Art. 44-49 safeguards\n4. **Third-party disclosures**: To independent controllers (regulators, partners, law enforcement)\n\nFor each flow, record:\n- Source and destination system\u002Fentity\n- Transfer mechanism (API, file transfer, database replication, manual export)\n- Legal safeguard for international transfers (SCCs, BCRs, adequacy decision)\n- Encryption in transit and at rest\n- Frequency and volume\n\n### Step 5: Map Data Storage and Retention\n\nDocument where personal data resides at each stage:\n\n1. **Primary storage**: Production databases, CRM systems, HRIS\n2. **Secondary storage**: Data warehouses, analytics databases, reporting systems\n3. **Archival storage**: Long-term archives, cold storage, compliance archives\n4. **Backup storage**: Disaster recovery systems, backup tapes, cloud backup\n5. **Temporary storage**: Caches, message queues, log files, session storage\n\nFor each storage location, record:\n- Storage technology and location (on-premises, cloud region)\n- Retention period and legal basis for retention\n- Access controls and encryption\n- Deletion or anonymization mechanism at end of retention period\n\n### Step 6: Implement Automated Lineage Discovery\n\nDeploy tooling to automate lineage tracking:\n\n1. **Database-level lineage**: Query log analysis, column-level lineage from SQL parsing\n2. **Application-level lineage**: API call tracing, service mesh observability\n3. **Pipeline-level lineage**: ETL tool metadata (Apache Airflow lineage backend, dbt documentation)\n4. **Infrastructure-level lineage**: Network flow logs, data lake audit trails\n\nUse the `scripts\u002Fprocess.py` helper to parse system metadata and generate lineage graphs.\n\n### Step 7: Integrate with RoPA and Compliance\n\nLink lineage data to GDPR compliance documentation:\n\n1. **Art. 30 RoPA**: Each lineage path should map to a processing activity in the RoPA\n2. **DPIA triggers**: Flag lineage paths involving Art. 35(3) processing (large-scale profiling, systematic monitoring, special categories)\n3. **Data subject rights**: Use lineage to locate all data for DSAR responses (Art. 15 access, Art. 17 erasure, Art. 20 portability)\n4. **Breach impact scoping**: Use lineage to determine affected data subjects and categories during incident response per Art. 33(3)\n\n### Step 8: Maintain and Validate\n\nEstablish ongoing lineage maintenance:\n\n1. **Change management**: Update lineage when new systems, data flows, or processing activities are introduced\n2. **Periodic validation**: Quarterly review to verify lineage accuracy against actual system behavior\n3. **Stakeholder review**: Annual sign-off from data owners, system architects, and DPO\n4. **Completeness check**: Cross-reference lineage against data inventory and RoPA to identify gaps\n\n## Verification\n\n- [ ] All personal data categories have documented source-to-sink lineage paths\n- [ ] Each lineage node includes legal basis, retention period, and access controls\n- [ ] Transformation steps document identifiability impact\n- [ ] Cross-border transfers identified with Art. 44-49 safeguards documented\n- [ ] Lineage integrates with Art. 30 RoPA entries\n- [ ] Automated discovery covers at least database and pipeline layers\n- [ ] Quarterly validation schedule established with responsible owners assigned\n","# Data Lineage Tracking\n\n## Purpose\n\nMap and document the complete lifecycle of personal data through organizational systems, from initial collection point through all transformations, transfers, and storage locations to final deletion or anonymization.\n\n## Prerequisites\n\n- Data inventory or asset register identifying systems processing personal data\n- Network architecture documentation showing system interconnections\n- Access to system metadata, ETL configurations, and API documentation\n- Records of Processing Activities (RoPA) under GDPR Article 30\n\n## Workflow\n\n### Step 1: Define Lineage Scope\n\nDetermine scope boundaries for the lineage mapping exercise:\n\n1. **Data categories**: Identify which personal data categories to trace (identity data, contact data, financial data, behavioral data, special category data under Art. 9)\n2. **System boundaries**: Define which systems are in-scope (production databases, data warehouses, analytics platforms, third-party SaaS, backup systems)\n3. **Temporal scope**: Determine whether to map current-state lineage only or include historical data flows\n4. **Legal basis mapping**: Link each processing activity in the lineage to its GDPR Article 6 lawful basis\n\n### Step 2: Identify Data Sources (Collection Points)\n\nDocument every point where personal data enters the organization:\n\n1. **Direct collection**: Web forms, mobile apps, point-of-sale terminals, customer service interactions, paper forms digitized via scanning\n2. **Indirect collection**: Third-party data providers, publicly available sources, data brokers, partner organizations\n3. **Derived data**: Data generated through processing (risk scores, customer segments, behavioral profiles)\n4. **Inferred data**: Data inferred from other data points (creditworthiness, health predictions, preferences)\n\nFor each source, record:\n- Source identifier and type\n- Data categories collected (referencing Art. 30(1)(c) categories)\n- Legal basis under Art. 6(1) and, if applicable, Art. 9(2)\n- Information provided to data subjects per Art. 13 or Art. 14\n- Volume and frequency of collection\n\n### Step 3: Map Data Transformations\n\nDocument every transformation applied to personal data:\n\n1. **ETL processes**: Extract-Transform-Load pipelines moving data between systems\n2. **Aggregation**: Grouping individual records into summary statistics\n3. **Pseudonymization**: Replacing identifiers with tokens per Art. 4(5) and Recital 26\n4. **Anonymization**: Irreversible de-identification per WP29 Opinion 05\u002F2014\n5. **Enrichment**: Combining data from multiple sources to create enriched profiles\n6. **Format conversion**: Changing data formats (CSV to JSON, database migration)\n\nFor each transformation, record:\n- Input data categories and source system\n- Transformation logic description\n- Output data categories and destination system\n- Whether transformation changes the identifiability of data subjects\n- Retention period at destination per Art. 5(1)(e) storage limitation\n\n### Step 4: Document Data Flows and Transfers\n\nMap all movements of personal data between systems and parties:\n\n1. **Internal flows**: Between departments, systems, databases within the organization\n2. **Processor transfers**: To data processors under Art. 28 agreements\n3. **Third-country transfers**: Cross-border transfers requiring Art. 44-49 safeguards\n4. **Third-party disclosures**: To independent controllers (regulators, partners, law enforcement)\n\nFor each flow, record:\n- Source and destination system\u002Fentity\n- Transfer mechanism (API, file transfer, database replication, manual export)\n- Legal safeguard for international transfers (SCCs, BCRs, adequacy decision)\n- Encryption in transit and at rest\n- Frequency and volume\n\n### Step 5: Map Data Storage and Retention\n\nDocument where personal data resides at each stage:\n\n1. **Primary storage**: Production databases, CRM systems, HRIS\n2. **Secondary storage**: Data warehouses, analytics databases, reporting systems\n3. **Archival storage**: Long-term archives, cold storage, compliance archives\n4. **Backup storage**: Disaster recovery systems, backup tapes, cloud backup\n5. **Temporary storage**: Caches, message queues, log files, session storage\n\nFor each storage location, record:\n- Storage technology and location (on-premises, cloud region)\n- Retention period and legal basis for retention\n- Access controls and encryption\n- Deletion or anonymization mechanism at end of retention period\n\n### Step 6: Implement Automated Lineage Discovery\n\nDeploy tooling to automate lineage tracking:\n\n1. **Database-level lineage**: Query log analysis, column-level lineage from SQL parsing\n2. **Application-level lineage**: API call tracing, service mesh observability\n3. **Pipeline-level lineage**: ETL tool metadata (Apache Airflow lineage backend, dbt documentation)\n4. **Infrastructure-level lineage**: Network flow logs, data lake audit trails\n\nUse the `scripts\u002Fprocess.py` helper to parse system metadata and generate lineage graphs.\n\n### Step 7: Integrate with RoPA and Compliance\n\nLink lineage data to GDPR compliance documentation:\n\n1. **Art. 30 RoPA**: Each lineage path should map to a processing activity in the RoPA\n2. **DPIA triggers**: Flag lineage paths involving Art. 35(3) processing (large-scale profiling, systematic monitoring, special categories)\n3. **Data subject rights**: Use lineage to locate all data for DSAR responses (Art. 15 access, Art. 17 erasure, Art. 20 portability)\n4. **Breach impact scoping**: Use lineage to determine affected data subjects and categories during incident response per Art. 33(3)\n\n### Step 8: Maintain and Validate\n\nEstablish ongoing lineage maintenance:\n\n1. **Change management**: Update lineage when new systems, data flows, or processing activities are introduced\n2. **Periodic validation**: Quarterly review to verify lineage accuracy against actual system behavior\n3. **Stakeholder review**: Annual sign-off from data owners, system architects, and DPO\n4. **Completeness check**: Cross-reference lineage against data inventory and RoPA to identify gaps\n\n## Verification\n\n- [ ] All personal data categories have documented source-to-sink lineage paths\n- [ ] Each lineage node includes legal basis, retention period, and access controls\n- [ ] Transformation steps document identifiability impact\n- [ ] Cross-border transfers identified with Art. 44-49 safeguards documented\n- [ ] Lineage integrates with Art. 30 RoPA entries\n- [ ] Automated discovery covers at least database and pipeline layers\n- [ ] Quarterly validation schedule established with responsible owners assigned\n",{"name":5,"license":15,"metadata":45,"description":7},{"tags":46,"author":9,"domain":35,"version":47,"subdomain":38},"data-lineage, data-provenance, data-flow-mapping, transformation-logging, deletion-verification","1.0","main","9b2ef9eae161c00a17241d42a388571321b33e9f","skills\u002Fprivacy\u002Fdata-lineage-tracking",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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill data-lineage-tracking",{"tool":63,"command":64},"bunx","bunx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill data-lineage-tracking",{"tool":66,"command":67},"pnpm","pnpm dlx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill data-lineage-tracking","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdata-lineage-tracking\u002FSKILL.md",true,[71,77,83,87],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"assets\u002Ftemplate.md","ASSET","资产文件",8746,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdata-lineage-tracking\u002Fassets\u002Ftemplate.md",{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fstandards.md","REFERENCE","参考文档",4837,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdata-lineage-tracking\u002Freferences\u002Fstandards.md",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fworkflows.md",7278,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdata-lineage-tracking\u002Freferences\u002Fworkflows.md",{"path":88,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":91,"sourceHtmlUrl":92},"scripts\u002Fprocess.py","SCRIPT","脚本",20503,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fdata-lineage-tracking\u002Fscripts\u002Fprocess.py",[94,117,131,143,160,172],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":109,"publishedAt":40},"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",[100,105,108],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",{"categoryNo":106,"categoryName":107,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[110,111,35,33,112,28,113,114,115,116],"email","workplace email privacy","content","policy","testing","monitoring","metadata",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":125,"publishedAt":40},"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",[123,124],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[28,126,127,128,33,129,34,35,130],"whistleblower data","identity","reporting","data protection","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":40},"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":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[28,139,140,30,141,34,35,142],"vendor termination data","planning","extraction","certification",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":40},"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",[149],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[151,152,153,154,155,156,157,158,35,28,159],"vendor risk scoring","risk","risk scoring","methodology","risk-scoring","assessment","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":40},"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":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[35,168,34,169,156,170,36,28,159,152,142,171],"vendor privacy due diligence","review","onboarding","analysis",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":185,"publishedAt":40},"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",[178,181,184],{"categoryNo":179,"categoryName":180,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":182,"categoryName":183,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[186,187,35,188,30,189,33,34,190,159,191,192,193,140],"vendor privacy audit","audit","report","audit report","remediation","collection","remediation-tracking","classification"]