[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AFT2D4YNX9065S4SM2VZ69":3,"skill-same:01M6AFT2D4YNX9065S4SM2VZ69":80},{"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":18,"publishedAt":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":41,"ownerDescription":42,"updatedAt":43,"install":44,"resources":57},"01M6AFT2D4YNX9065S4SM2VZ69","hipaa-interoperability",null,"Addresses HIPAA privacy and security requirements for health data interoperability under the 21st Century Cures Act, ONC Health IT Certification Program, and CMS Interoperability and Patient Access Final Rule. Covers information blocking prohibitions, FHIR API patient access, TEFCA exchange purposes, and privacy safeguards for health information exchange. Keywords: interoperability, information blocking, FHIR, TEFCA, Cures Act, patient access API, health information exchange.","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\u002Fhipaa-interoperability\u002FSKILL.md",[],[19,20,21,22,23,24,25],"hipaa","hipaa interoperability","security","cms","privacy","data","certification","2026-11-10 10:12:30",false,"---\nname: hipaa-interoperability\ndescription: >-\n  Addresses HIPAA privacy and security requirements for health data\n  interoperability under the 21st Century Cures Act, ONC Health IT\n  Certification Program, and CMS Interoperability and Patient Access Final\n  Rule. Covers information blocking prohibitions, FHIR API patient access,\n  TEFCA exchange purposes, and privacy safeguards for health information\n  exchange. Keywords: interoperability, information blocking, FHIR, TEFCA,\n  Cures Act, patient access API, health information exchange.\nlicense: Apache-2.0\nmetadata:\n  author: mukul975\n  version: \"1.0\"\n  domain: privacy\n  subdomain: healthcare-privacy\n  tags: \"hipaa, interoperability, information-blocking, fhir, tefca, cures-act, patient-access, hie\"\n---\n\n# HIPAA Interoperability — Cures Act, ONC, and CMS Requirements\n\n## Overview\n\nThe 21st Century Cures Act (Public Law 114-255, 2016) fundamentally changed the interoperability landscape by prohibiting information blocking and mandating standardized API-based patient access. The ONC Health IT Certification Program (45 CFR Part 170) and the CMS Interoperability and Patient Access Final Rule (CMS-9115-F, 85 FR 25510, May 1, 2020) together require health IT developers, healthcare providers, health information exchanges (HIEs), and health information networks (HINs) to support seamless data exchange while maintaining HIPAA privacy and security protections. The Trusted Exchange Framework and Common Agreement (TEFCA), launched operationally in December 2023, establishes a nationwide framework for health information exchange with defined exchange purposes and privacy requirements.\n\n## Regulatory Framework\n\n### 21st Century Cures Act — Information Blocking\n\n- **Section 4004**: Defines information blocking as a practice that is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information (EHI)\n- **Actors covered**: Health IT developers of certified health IT, HIEs, HINs, and healthcare providers\n- **EHI definition**: As of October 6, 2022, EHI is the electronic protected health information (ePHI) in a designated record set as defined under HIPAA (45 CFR §171.102), plus any other electronic health information identified by the Secretary\n\n### Information Blocking Exceptions (45 CFR Part 171)\n\n| Exception | Category | Description |\n|-----------|----------|-------------|\n| Preventing Harm (§171.201) | Not fulfilling requests | Practice is reasonable and necessary to prevent harm to a patient or another person |\n| Privacy (§171.202) | Not fulfilling requests | Practice is required by or consistent with HIPAA Privacy Rule obligations |\n| Security (§171.203) | Not fulfilling requests | Practice is directly related to safeguarding the confidentiality, integrity, or availability of EHI |\n| Infeasibility (§171.204) | Not fulfilling requests | Fulfilling the request is technically infeasible |\n| Health IT Performance (§171.205) | Procedures | Practice is for reasonable maintenance or improvements to health IT |\n| Content and Manner (§171.301) | Procedures | Actor fulfills a request in an alternative manner or with alternative content |\n| Fees (§171.302) | Procedures | Fees charged are reasonable and based on objective, verifiable criteria |\n| Licensing (§171.303) | Procedures | Licensing terms are reasonable and non-discriminatory |\n\n### CMS Interoperability and Patient Access Final Rule\n\n- **Patient Access API (§431.60)**: CMS-regulated payers (Medicaid, CHIP, QHP issuers on FFE) must implement a FHIR R4-based Patient Access API allowing patients to access claims, encounter, and clinical data\n- **Provider Directory API (§431.70)**: Payers must implement a publicly accessible FHIR-based provider directory\n- **Payer-to-Payer Data Exchange (CMS-0057-F, effective January 1, 2026)**: Payers must exchange patient data at the patient's request when they switch plans\n- **Prior Authorization API (CMS-0057-F)**: Payers must implement a FHIR-based prior authorization API\n\n### TEFCA Exchange Purposes\n\n| Exchange Purpose | Description | HIPAA Basis |\n|-----------------|-------------|-------------|\n| Treatment | Direct patient care | §164.506(c)(2) — TPO |\n| Payment | Claims, eligibility, coordination of benefits | §164.506(c)(3) — TPO |\n| Healthcare Operations | Quality assessment, care coordination | §164.506(c)(5) — TPO |\n| Public Health | Reporting to public health authorities | §164.512(b) |\n| Benefits Determination | Health plan coverage decisions | §164.506(c)(3) |\n| Individual Access | Patient right of access | §164.524 |\n\n## HIPAA Privacy Safeguards for Interoperability\n\n### Patient Access via FHIR API\n\n1. **Identity verification**: Verify patient identity using multi-factor authentication before granting API access (aligned with NIST IAL2\u002FAAL2)\n2. **Scope of access**: HIPAA right of access (§164.524) — entire designated record set except psychotherapy notes, information compiled for legal proceedings, and certain lab results under CLIA\n3. **Third-party app authorization**: Patient may direct data to third-party apps via SMART on FHIR; once data is shared with a non-covered entity app, HIPAA protections may no longer apply — disclosure notice required\n4. **Minimum necessary**: Does NOT apply to individual access requests (§164.502(b)(2)(v)) or treatment disclosures\n\n### HIE\u002FHIN Privacy Requirements\n\n1. Maintain BAAs with all participating providers per §164.502(e)\n2. Implement role-based access tied to exchange purpose\n3. Apply consent management per state law requirements (particularly for 42 CFR Part 2 substance abuse records and state-specific sensitive categories)\n4. Maintain accounting of disclosures per §164.528\n\n## Security Requirements for Interoperable Systems\n\n| Requirement | Regulation | Implementation |\n|------------|-----------|----------------|\n| Encryption in transit | §164.312(e)(1) | TLS 1.2+ for all FHIR API and HIE connections |\n| Access controls | §164.312(a)(1) | OAuth 2.0 \u002F SMART on FHIR authorization |\n| Audit controls | §164.312(b) | Log all API requests, queries, and data exchanges with timestamps and actor identity |\n| Integrity controls | §164.312(c)(1) | Digital signatures on exchange payloads; FHIR resource versioning |\n| Authentication | §164.312(d) | Unique user identification for all API consumers; system-level certificates for point-to-point |\n\n## Enforcement\n\n- **Information blocking penalties**: Health IT developers, HIEs, and HINs face civil monetary penalties up to $1 million per violation under ONC (final rule effective September 1, 2023). Healthcare providers face appropriate disincentives through CMS (final rule pending).\n- **HIPAA penalties**: Standard HIPAA enforcement under OCR applies to all privacy and security violations in the interoperability context.\n\n## Integration Points\n\n- **hipaa-privacy-rule**: Interoperability must comply with all Privacy Rule requirements for uses and disclosures\n- **hipaa-security-rule**: Technical safeguards for API and exchange security\n- **hipaa-minimum-necessary**: Minimum necessary standard applies to most interoperability disclosures (except individual access and treatment)\n- **hipaa-baa-management**: BAAs required for all HIE\u002FHIN participants and health IT vendors accessing PHI\n- **hipaa-breach-notification**: Breach notification obligations extend to interoperability-related incidents\n","# HIPAA Interoperability — Cures Act, ONC, and CMS Requirements\n\n## Overview\n\nThe 21st Century Cures Act (Public Law 114-255, 2016) fundamentally changed the interoperability landscape by prohibiting information blocking and mandating standardized API-based patient access. The ONC Health IT Certification Program (45 CFR Part 170) and the CMS Interoperability and Patient Access Final Rule (CMS-9115-F, 85 FR 25510, May 1, 2020) together require health IT developers, healthcare providers, health information exchanges (HIEs), and health information networks (HINs) to support seamless data exchange while maintaining HIPAA privacy and security protections. The Trusted Exchange Framework and Common Agreement (TEFCA), launched operationally in December 2023, establishes a nationwide framework for health information exchange with defined exchange purposes and privacy requirements.\n\n## Regulatory Framework\n\n### 21st Century Cures Act — Information Blocking\n\n- **Section 4004**: Defines information blocking as a practice that is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information (EHI)\n- **Actors covered**: Health IT developers of certified health IT, HIEs, HINs, and healthcare providers\n- **EHI definition**: As of October 6, 2022, EHI is the electronic protected health information (ePHI) in a designated record set as defined under HIPAA (45 CFR §171.102), plus any other electronic health information identified by the Secretary\n\n### Information Blocking Exceptions (45 CFR Part 171)\n\n| Exception | Category | Description |\n|-----------|----------|-------------|\n| Preventing Harm (§171.201) | Not fulfilling requests | Practice is reasonable and necessary to prevent harm to a patient or another person |\n| Privacy (§171.202) | Not fulfilling requests | Practice is required by or consistent with HIPAA Privacy Rule obligations |\n| Security (§171.203) | Not fulfilling requests | Practice is directly related to safeguarding the confidentiality, integrity, or availability of EHI |\n| Infeasibility (§171.204) | Not fulfilling requests | Fulfilling the request is technically infeasible |\n| Health IT Performance (§171.205) | Procedures | Practice is for reasonable maintenance or improvements to health IT |\n| Content and Manner (§171.301) | Procedures | Actor fulfills a request in an alternative manner or with alternative content |\n| Fees (§171.302) | Procedures | Fees charged are reasonable and based on objective, verifiable criteria |\n| Licensing (§171.303) | Procedures | Licensing terms are reasonable and non-discriminatory |\n\n### CMS Interoperability and Patient Access Final Rule\n\n- **Patient Access API (§431.60)**: CMS-regulated payers (Medicaid, CHIP, QHP issuers on FFE) must implement a FHIR R4-based Patient Access API allowing patients to access claims, encounter, and clinical data\n- **Provider Directory API (§431.70)**: Payers must implement a publicly accessible FHIR-based provider directory\n- **Payer-to-Payer Data Exchange (CMS-0057-F, effective January 1, 2026)**: Payers must exchange patient data at the patient's request when they switch plans\n- **Prior Authorization API (CMS-0057-F)**: Payers must implement a FHIR-based prior authorization API\n\n### TEFCA Exchange Purposes\n\n| Exchange Purpose | Description | HIPAA Basis |\n|-----------------|-------------|-------------|\n| Treatment | Direct patient care | §164.506(c)(2) — TPO |\n| Payment | Claims, eligibility, coordination of benefits | §164.506(c)(3) — TPO |\n| Healthcare Operations | Quality assessment, care coordination | §164.506(c)(5) — TPO |\n| Public Health | Reporting to public health authorities | §164.512(b) |\n| Benefits Determination | Health plan coverage decisions | §164.506(c)(3) |\n| Individual Access | Patient right of access | §164.524 |\n\n## HIPAA Privacy Safeguards for Interoperability\n\n### Patient Access via FHIR API\n\n1. **Identity verification**: Verify patient identity using multi-factor authentication before granting API access (aligned with NIST IAL2\u002FAAL2)\n2. **Scope of access**: HIPAA right of access (§164.524) — entire designated record set except psychotherapy notes, information compiled for legal proceedings, and certain lab results under CLIA\n3. **Third-party app authorization**: Patient may direct data to third-party apps via SMART on FHIR; once data is shared with a non-covered entity app, HIPAA protections may no longer apply — disclosure notice required\n4. **Minimum necessary**: Does NOT apply to individual access requests (§164.502(b)(2)(v)) or treatment disclosures\n\n### HIE\u002FHIN Privacy Requirements\n\n1. Maintain BAAs with all participating providers per §164.502(e)\n2. Implement role-based access tied to exchange purpose\n3. Apply consent management per state law requirements (particularly for 42 CFR Part 2 substance abuse records and state-specific sensitive categories)\n4. Maintain accounting of disclosures per §164.528\n\n## Security Requirements for Interoperable Systems\n\n| Requirement | Regulation | Implementation |\n|------------|-----------|----------------|\n| Encryption in transit | §164.312(e)(1) | TLS 1.2+ for all FHIR API and HIE connections |\n| Access controls | §164.312(a)(1) | OAuth 2.0 \u002F SMART on FHIR authorization |\n| Audit controls | §164.312(b) | Log all API requests, queries, and data exchanges with timestamps and actor identity |\n| Integrity controls | §164.312(c)(1) | Digital signatures on exchange payloads; FHIR resource versioning |\n| Authentication | §164.312(d) | Unique user identification for all API consumers; system-level certificates for point-to-point |\n\n## Enforcement\n\n- **Information blocking penalties**: Health IT developers, HIEs, and HINs face civil monetary penalties up to $1 million per violation under ONC (final rule effective September 1, 2023). Healthcare providers face appropriate disincentives through CMS (final rule pending).\n- **HIPAA penalties**: Standard HIPAA enforcement under OCR applies to all privacy and security violations in the interoperability context.\n\n## Integration Points\n\n- **hipaa-privacy-rule**: Interoperability must comply with all Privacy Rule requirements for uses and disclosures\n- **hipaa-security-rule**: Technical safeguards for API and exchange security\n- **hipaa-minimum-necessary**: Minimum necessary standard applies to most interoperability disclosures (except individual access and treatment)\n- **hipaa-baa-management**: BAAs required for all HIE\u002FHIN participants and health IT vendors accessing PHI\n- **hipaa-breach-notification**: Breach notification obligations extend to interoperability-related incidents\n",{"name":5,"license":15,"metadata":31,"description":7},{"tags":32,"author":9,"domain":23,"version":33,"subdomain":34},"hipaa, interoperability, information-blocking, fhir, tefca, cures-act, patient-access, hie","1.0","healthcare-privacy","main","9b2ef9eae161c00a17241d42a388571321b33e9f","skills\u002Fprivacy\u002Fhipaa-interoperability",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":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill hipaa-interoperability",{"tool":50,"command":51},"bunx","bunx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill hipaa-interoperability",{"tool":53,"command":54},"pnpm","pnpm dlx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill hipaa-interoperability","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fhipaa-interoperability\u002FSKILL.md",true,[58,64,70,74],{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},"assets\u002Ftemplate.md","ASSET","资产文件",4317,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fhipaa-interoperability\u002Fassets\u002Ftemplate.md",{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Fstandards.md","REFERENCE","参考文档",3964,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fhipaa-interoperability\u002Freferences\u002Fstandards.md",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fworkflows.md",9094,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fhipaa-interoperability\u002Freferences\u002Fworkflows.md",{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"scripts\u002Fprocess.py","SCRIPT","脚本",11041,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fhipaa-interoperability\u002Fscripts\u002Fprocess.py",[81,109,126,138,155,168],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":100,"publishedAt":26},"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",[87,92,95],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",{"categoryNo":93,"categoryName":94,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[101,102,23,103,104,24,105,106,107,108],"email","workplace email privacy","compliance","content","policy","testing","monitoring","metadata",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":119,"publishedAt":26},"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",[115,118],{"categoryNo":116,"categoryName":117,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000033","数据分析师",{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},[24,120,121,122,103,123,124,23,125],"whistleblower data","identity","reporting","data protection","gdpr","prevention",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":26},"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",[132],{"categoryNo":116,"categoryName":117,"taxonomyType":98,"taxonomyTypeDesc":99},[24,134,135,136,137,124,23,25],"vendor termination data","planning","verification","extraction",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":26},"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",[144],{"categoryNo":116,"categoryName":117,"taxonomyType":98,"taxonomyTypeDesc":99},[146,147,148,149,150,151,152,153,23,24,154],"vendor risk scoring","risk","risk scoring","methodology","risk-scoring","assessment","transfer","certifications","processor",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":26},"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",[161],{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},[23,163,124,164,151,165,166,24,154,147,25,167],"vendor privacy due diligence","review","onboarding","flow","analysis",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":181,"publishedAt":26},"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",[174,177,180],{"categoryNo":175,"categoryName":176,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":178,"categoryName":179,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},[182,183,23,184,136,185,103,124,186,154,187,188,189,135],"vendor privacy audit","audit","report","audit report","remediation","collection","remediation-tracking","classification"]