制定GDPR合规检查清单

GDPR电子商务网站合规检查清单

适用范围说明：
- 本清单围绕GDPR（一般数据保护条例）要求，并考虑与在线跟踪相关的欧盟电子隐私规则（ePrivacy 指令及成员国实施）。电商涉及的跨境传输、营销通信、支付与防欺诈场景均包含在内。
- 各成员国可能有税务、营销通信及儿童同意年龄的差异要求，应在实施前对目标市场进行本地化核查。

1.治理与责任
- 明确数据控制者与处理者角色；对支付服务商、物流、营销平台等第三方进行角色界定。
- 确定主设立地与主监督机构（适用一站式机制）。
- 非欧盟企业向欧盟提供商品/服务或监测行为时，指定欧盟代表（GDPR第27条）。
- 评估是否需要任命数据保护官（DPO）：大规模系统性监控、处理特殊类别数据或核心业务与处理相关时（GDPR第37条）。
- 建立并批准隐私治理文件：数据保护政策、数据保留与删除政策、事件响应流程、供应商管理政策。
- 对员工（客服、营销、技术、产品）开展定期隐私与安全培训，并记录培训证据。

2.数据盘点与记录（ROPA）
- 完成数据流映射：注册/登录、浏览与跟踪、购物车、订单、支付、交付、客服、退货与售后、营销与再营销。
- 建立处理活动记录（GDPR第30条）：目的、类别、数据主体类型、接收方、跨境转移机制、保留期限、技术与组织措施。
- 标识特殊类别数据与敏感指标（通常电商不需处理，但如健康、宗教、饮食忌口可能触及敏感数据）。
- 标识儿童数据处理并记录成员国适用的数字服务同意年龄（13–16岁的本地差异）。

3.合法性基础与目的限定
- 合同履行：订单处理、交付、客户支持。
- 法定义务：开票和税务留存、合规审计。
- 合法利益：防欺诈与风险控制、安全监控、服务改进的基础分析；完成合法利益评估（LIA），保留平衡测试记录与减轻措施。
- 同意：电子邮件/短信营销、非必要cookies/追踪、个性化广告与再营销。
- 自动化决策与画像（GDPR第22条）：如存在拒单/信用评估等具有法律或类似重大影响的自动化决策，提供人类干预、申诉权与解释；在隐私声明中披露。

4.透明度与隐私声明
- 提供清晰、分层的隐私声明：处理目的、法律依据、数据类别、接收方、跨境传输机制、保留期限、数据主体权利、DPO或联系人、投诉途径、是否为法定/合同要求及不提供的后果、自动化决策说明。
- 提供独立且细化的Cookie政策：逐项列出cookie/SDK、用途、存期、提供方、是否为必要/非必要。
- 维护版本管理与变更记录，重大变更时适当通知用户。

5.同意与Cookie/在线跟踪（与ePrivacy配套）
- 在加载非必要cookie/像素/SDK前获取有效同意；不得预勾选或捆绑同意；拒绝与接受同样容易。
- 使用合规的同意管理平台（CMP），支持目的级与伙伴级粒度、记录与证明同意、轻松撤回。
- 针对再营销/个性化广告单独同意；在不同设备与浏览器间同步撤回机制。
- 考虑成员国差异：某些国家对严格配置的一方统计分析提供有限豁免；以当地监管指南为准。
- 定期审计标签管理，防止“隐性”数据泄露与越权加载。

6.数据主体权利管理
- 建立权利请求流程与SLA：访问、更正、删除、限制、反对、数据可携、撤回同意；一般在1个月内答复，可视复杂度延长至最多2个月并通知原因。
- 验证请求者身份，记录请求与响应；避免过度收集验证数据。
- 提供可携格式（如CSV/JSON）并涵盖用户直接提供的数据及相关元数据（在适用范围内）。
- 为营销设置无障碍退订机制，默认提供反对权入口。

7.安全与技术组织措施（GDPR第32条）
- 加密：传输层TLS；静态加密涵盖备份与日志中的个人数据；规范密钥管理与轮换。
- 访问控制：最小权限、角色分离、管理员多因素认证、定期权限审查。
- 应用安全：安全开发生命周期、依赖库与漏洞管理、渗透测试与代码审计、日志与监控（含可疑登录/交易）。
- 运营安全：备份与灾备演练、变更管理、秘密信息管理、端点与云安全加固。
- 支付安全：避免存储完整卡号与CVV；采用令牌化与合规支付网关；遵循PCI DSS（行业标准，独立于GDPR但通常并行要求）。
- 假名化/数据最小化：业务非必须时不收集生日、性别等；对分析使用聚合或假名化数据。
- 防欺诈：在合法利益基础上实施设备指纹/风控时，控制数据范围与保留期，避免过度画像。

8.供应商与处理者管理（GDPR第28条）
- 与处理者签订数据处理协议（DPA）：处理目的与指示、保密义务、安全措施、次处理者的事先批准与清单、协助履行权利请求与合规、数据泄露通知、删除/返还条款、审计与证明。
- 建立次处理者变更通知与反对机制；维护供应商安全与隐私评估。
- 对支付、云、客服外包、营销平台、反欺诈提供商进行定期尽职调查。

9.跨境数据转移
- 识别从EEA向第三国的传输：云托管、支持工具、分析与广告平台。
- 采用合规传输机制：
  - 适足性决定（如EU–US Data Privacy Framework，适用于已认证的美国接收方）。
  - 标准合同条款（SCCs，2021版模块化），并进行传输影响评估（TIA）及必要的补充措施。
  - 跨国公司约束性公司规则（BCR）如适用。
- 定期复核传输风险与供应商认证状态；UK/CH市场分别采用本地机制（如UK IDTA或UK版SCCs、Swiss–US DPF）。

10.数据保留与删除
- 为各数据集制定保留期并记录依据：订单与开票（依据成员国税务/商业法）、客服会话、账户信息、营销偏好、日志与备份。
- 到期删除或不可逆假名化；同步处理备份与灾备副本的删除窗口与技术限制。
- 账户注销流程清晰，说明删除范围与不可删除项（如满足法定义务所需的发票）。

11.数据泄露响应（GDPR第33、34条）
- 建立检测、分级与根因分析流程；维护泄露登记。
- 在72小时内向主管监督机构通报可导致风险的个人数据泄露，提供性质、受影响类别与数量、联系人、后果与补救措施。
- 如存在高风险，向数据主体无不当延迟地通知，使用清晰易懂语言并提供防护建议。
- 事后改进措施与经验回馈到技术与流程。

12.儿童与青少年数据
- 针对信息社会服务（ISS）在线同意年龄按成员国介于13–16岁：实施年龄门槛与家长同意验证机制（合理努力）。
- 在营销与画像上采取更保守策略，避免对未成年人进行定向广告与再营销。

13.营销与通信合规
- B2C电子邮件/短信营销通常基于事先同意；如适用“现有客户软性同意”例外，需依据各国电子隐私法具体条件并提供轻松退订。
- 清晰的偏好中心与撤回机制；拒绝后立即停止处理相关目的。
- 与广告平台的受众匹配/相似受众：确保合法依据、数据加密上传、仅使用获得同意的地址或以合法利益并完成LIA（同时满足ePrivacy）。

14.隐私设计与默认（GDPR第25条）
- 默认最小化：仅收集订单与交付必需字段；用户画像与分享默认关闭。
- 在产品评审、A/B测试、个性化推荐前进行隐私评估；为新功能实施控制与目的限制。
- 面向用户提供清晰设置与解释，避免黑暗模式。

15.隐私影响评估（DPIA，GDPR第35条）
- 触发条件：大规模系统性监控、广泛画像、使用新技术可能引发高风险、处理特殊类别数据等。
- 执行DPIA：描述处理、评估必要性与比例性、风险识别与缓解措施；保留记录。
- 当高风险无法充分减轻时，事前咨询主管监督机构（GDPR第36条）。

16.证据与审计准备
- 保留：同意与撤回日志、LIA、DPIA、TIA、DPA、培训记录、安全测试与审计报告、数据泄露记录、政策版本。
- 建立定期合规审查与整改计划；对外提供合适的合规证明（不披露敏感内部细节）。

17.平台与集成场景专项检查
- 第三方登录与社交像素：在隐私声明与同意管理中明确；评估是否存在共同控制关系并签署第26条安排（共同控制者协议），对用户透明。
- 市场/平台入驻与多方订单：明确各方控制者/处理者责任与权利路径。
- 客服与聊天机器人：限制收集敏感数据；提供数据保留与删除机制。

执行建议（简化实施顺序）：
- 第1步：完成数据流映射与ROPA。
- 第2步：确定法律依据矩阵，完成LIA与同意策略。
- 第3步：更新隐私声明、Cookie政策与CMP配置；下线非必要预加载标签。
- 第4步：签署/更新DPA与跨境机制（SCCs或DPF），完成TIA。
- 第5步：上线权利请求与退订流程；建立保留与删除计划。
- 第6步：加固安全控制与事件响应；视需要开展DPIA。
- 第7步：持续审计与证据留存。

此清单为实施与审计的基础结构。请根据目标市场的本地法律（税务留存年限、电子通信规则、儿童同意年龄）和具体业务流程进行细化与证据化落地。

GDPR Compliance Checklist for a SaaS Collaboration Platform

Scope and Role Definition
- Determine roles per processing activity:
  - For customer workspace content: typically processor to business customers; consider joint controllership for features that determine purposes jointly (e.g., shared anti-abuse datasets).
  - For vendor operations (billing, account management, service analytics, marketing): typically controller.
- Appoint roles as required:
  - Data Protection Officer (Art. 37) if large-scale monitoring or special-category processing.
  - EU representative (Art. 27) if no EU establishment but offering services to EU data subjects or monitoring their behavior.
- Identify main establishment in the EU to benefit from one-stop-shop with a lead supervisory authority (Art. 56).

Records of Processing and Data Mapping (Art. 30)
- Maintain Records of Processing Activities (RoPA) for both controller and processor operations, covering:
  - Purposes, categories of data subjects and personal data, recipients, international transfers, retention periods, and security measures (Art. 30(1)-(2)).
- Data inventory and data flow diagrams across environments (prod, staging, backups, analytics).
- Classify data: account identifiers, content, metadata, telemetry, authentication, billing, support logs.

Lawful Basis and Transparency (Arts. 5–6, 12–14)
- Define legal bases per purpose:
  - Contract (Art. 6(1)(b)) for providing the service to users.
  - Legitimate interests (Art. 6(1)(f)) for security, fraud prevention, product analytics compatible with user expectations; perform and document Legitimate Interests Assessments (LIA).
  - Consent (Art. 6(1)(a)) for non-essential cookies/trackers or optional features not necessary for service.
  - Legal obligation (Art. 6(1)(c)) for invoicing, tax, compliance.
- Provide layered privacy notices:
  - For end-users and admins (Arts. 13–14) with clear purposes, legal bases, recipients, transfer mechanisms, retention, rights, and contact details (DPO/EU rep where applicable).
- Ensure transparency for non-user personal data (e.g., invitees’ emails) and send notices where required or document Art. 14(5) exemptions if applicable.

Data Protection by Design and Default (Art. 25)
- Default-private settings for workspaces and documents; explicit user/admin actions required for external sharing.
- Minimize personal data collected and retained; disable or make optional intrusive telemetry.
- Segregate tenant data logically; apply strict purpose limitation controls in code and data pipelines.
- Provide admin-configurable controls: sharing restrictions, link expiration, watermarking, download/forwarding controls.

Security of Processing (Art. 32)
- Implement and document technical/organizational measures proportionate to risk:
  - Encryption in transit (TLS 1.2+ with modern cipher suites) and at rest; key management with rotation and access separation.
  - Strong authentication (MFA, SSO/SAML/OIDC, conditional access), least privilege, role-based access control, and privileged access management.
  - Secure SDLC, code review, dependency management, SAST/DAST, secrets management, and change control.
  - Vulnerability and patch management with defined SLAs; regular penetration testing.
  - Network security (segmentation, WAF, DDoS protections), endpoint hardening, and device management for admin/support endpoints.
  - Logging and monitoring of access to personal data; tamper-evident audit logs; anomaly detection.
  - Data integrity protections; backups with encryption; disaster recovery plans with tested RTO/RPO.
  - Support-access controls: just-in-time, ticket-based, approved and logged.
- Adopt security standards (e.g., ISO/IEC 27001) as evidence of controls (not a GDPR requirement).

Processor Obligations and Customer DPA (Art. 28)
- Execute a Data Processing Agreement with customers including:
  - Processing subject matter/duration, nature/purpose, data types, data subjects, and documented instructions.
  - Confidentiality, security measures (schedule), subprocessor controls, data subject request assistance, breach notification, deletion/return on termination, audits, and cooperation with authorities (Art. 28(3)).
- Maintain a public subprocessor list and change notification mechanism; allow objection process where appropriate.
- Flow down Art. 28 obligations to subprocessors and perform risk-based due diligence with periodic reassessments.

International Data Transfers (Chapter V)
- Identify all third-country transfers (hosting, support, telemetry).
- Use valid transfer mechanisms:
  - Adequacy decisions where available (including EU–US Data Privacy Framework for certified US importers).
  - 2021 SCCs (Modules 2/3) with Transfer Impact Assessments (TIAs) and supplementary measures per EDPB Recommendations 01/2020.
  - UK Addendum/IDTA for UK transfers; Swiss addendum where applicable.
- Implement policies for government access requests: assess legality, narrow scope, challenge unlawful requests, and provide transparency reports where permitted (Art. 48 considerations).

Data Subject Rights Enablement (Arts. 15–22)
- As controller (vendor operations): implement processes to handle access, rectification, erasure, restriction, portability, objection, and profiling/automated decision-making requests within one month, with identity verification and logging.
- As processor (customer content): implement mechanisms and APIs to assist controllers in fulfilling DSARs; do not respond directly without controller instruction, unless legally required.
- Provide self-service export and deletion tools where feasible; document exceptions and legal holds.

DPIAs and Risk Assessments (Arts. 35–36)
- Conduct DPIAs for high-risk processing such as:
  - Large-scale monitoring of user behavior, extensive profiling/analytics, use of AI on user content, or processing special-category data at scale.
- Document risk mitigations; if high risk remains, consult supervisory authority before processing.
- Maintain a DPIA register and review upon major changes.

Incident and Breach Response (Arts. 33–34)
- Maintain an incident response plan with roles, runbooks, and 24/7 escalation.
- Assess reportability: notify competent authority within 72 hours of awareness unless the breach is unlikely to result in risk to rights and freedoms.
- Notify affected data subjects without undue delay when there is likely high risk; include nature of breach, likely consequences, measures taken, and contact point.
- Notify customers promptly under the DPA with sufficient detail for their own assessments.

Retention and Deletion
- Define and publish retention schedules per data category and purpose.
- Implement secure deletion and irreversible pseudonymization where applicable; propagate deletions to replicas, caches, and search indexes.
- Manage backups: document retention, ensure deletion on lifecycle expiry, or ensure erased data is not reintroduced when restoring.
- Provide tenant-level retention and legal hold features for enterprise customers.

Cookies and Tracking (ePrivacy + GDPR)
- For marketing sites: implement a consent management platform for non-essential cookies; collect prior consent and provide granular controls and withdrawal.
- For the app: limit to strictly necessary cookies for service; obtain consent for additional tracking; document purposes and vendors.

Special Categories and Children’s Data
- Avoid processing special-category data unless necessary and lawful (Art. 9); if customers may upload such data, provide warnings, support safeguards, and ensure appropriate security.
- If offering services directly to children in the EU, implement age-gating and parental consent where national laws require (digital consent age varies, 13–16).

Accountability and Governance (Arts. 5(2), 24)
- Maintain privacy policies, SOPs, training records, data breach register, DSAR logs, and compliance metrics.
- Conduct periodic internal audits and management reviews; track remediation to closure.
- Vendor/counsel review of major product changes; Privacy Review embedded in SDLC.
- Maintain documented roles, responsibilities, and board-level oversight of privacy and security.

Customer-Facing Documentation Pack
- Public privacy notice and cookie notice.
- DPA with security schedule and subprocessor list.
- Transfer mechanisms (SCCs/DPF) details and TIA summaries upon request.
- SOC 2/ISO 27001 reports or equivalent assurances (if available).
- Support access policy and transparency report.

Product-Specific Controls for Collaboration Platforms
- External sharing governance: domain allow/deny lists, guest management, link types (restricted/org/public), expiration, password protection.
- Content management: admin audit logs, eDiscovery/export, data classification labels, and DLP integrations.
- Search and indexing: respect access controls; implement privacy-preserving telemetry.
- Optional E2EE for sensitive spaces or items if offered; document key management and limitations.
- Admin APIs and SCIM provisioning with least privilege scopes and comprehensive logging.

Testing and Continuous Improvement
- Run periodic DSAR handling drills, breach tabletop exercises, and restoration/deletion tests.
- Validate RoPA accuracy and data flow diagrams at least annually or upon major changes.
- Monitor regulatory updates and guidance from EDPB and national authorities; adjust controls accordingly.

Operational Ready-to-Verify Items
- RoPA completed and reviewed.
- Lawful bases mapped; LIAs and DPIAs on file.
- DPO/EU representative appointed if required.
- Customer DPA and subprocessor contracts executed; subprocessor page live.
- Transfer mechanisms implemented; TIAs completed; UK/CH addenda in place where relevant.
- Security controls implemented and evidenced; pen test report available.
- DSAR workflows operational; metrics tracked; SLAs met.
- Retention schedules enforced; deletion propagation verified.
- Incident response tested within the last 12 months; breach templates ready.
- Consent management live on marketing properties; records of consent maintained.

Note: This checklist addresses GDPR requirements and related ePrivacy obligations as they apply to a SaaS collaboration platform. Adjust to your specific processing operations, risk profile, and the jurisdictions of your users and infrastructure.

GDPR-Compliance-Checkliste für eine Gesundheitsmanagement‑App

Hinweise zum Kontext:
- Gesundheitsdaten sind besondere Kategorien personenbezogener Daten (Art. 9 DSGVO). Für deren Verarbeitung sind sowohl eine Rechtsgrundlage nach Art. 6 als auch ein Erlaubnistatbestand nach Art. 9 erforderlich.
- Bei groß angelegter Verarbeitung von Gesundheitsdaten ist regelmäßig ein Datenschutzbeauftragter (DSB) zu bestellen (Art. 37 Abs. 1 lit. c DSGVO).
- Die nachfolgenden Prüfpunkte fokussieren auf DSGVO; ergänzend können Anforderungen aus der ePrivacy-Richtlinie/TTDSG (z. B. für App-Tracking/SDKs) relevant sein.

1) Governance, Rollen und Verantwortlichkeiten
- Verantwortlicher bestimmen und dokumentieren (Art. 4 Nr. 7, Art. 5 Abs. 2).
- Ggf. gemeinsam Verantwortliche regeln (Art. 26): Vereinbarung zur transparenten Aufgaben-/Pflichtenverteilung, Informationsbereitstellung an Betroffene.
- Auftragsverarbeiter einbinden (Art. 28): Vertrag mit TOMs, Weisungsbindung, Unterauftragsvergabe, Audit- und Informationsrechte.
- Datenschutzbeauftragten bestellen (Art. 37): Qualifikation, Unabhängigkeit, Veröffentlichung der Kontaktdaten (Art. 37–39).
- Verzeichnis von Verarbeitungstätigkeiten führen (Art. 30): Zwecke, Kategorien, Empfänger, Löschfristen, TOMs, Drittlandtransfers.
- Richtlinien/Policies etablieren: Datenschutz, Informationssicherheit, Löschung, Incident Response, Rechteausübung, Umgang mit Gesundheitsdaten.

2) Rechtsgrundlagen und Zweckbindung
- Für jede Verarbeitung einen Zweck definieren (Art. 5 Abs. 1 lit. b).
- Rechtsgrundlagen nach Art. 6:
  - Einwilligung (Art. 6 Abs. 1 lit. a) oder
  - Vertragserfüllung (Art. 6 Abs. 1 lit. b) für erforderliche Funktionen der App.
- Zusätzlicher Erlaubnistatbestand für Gesundheitsdaten (Art. 9):
  - Explizite Einwilligung (Art. 9 Abs. 2 lit. a) ist für Consumer‑Gesundheitsapps regelmäßig erforderlich.
  - Alternativ nur, wenn anwendbar: vitales Interesse (lit. c), Gesundheitsversorgung durch Angehörige der Gesundheitsberufe mit berufsrechtlicher Geheimhaltung (lit. h). Prüfen und dokumentieren.
- Interessenabwägung für nicht‑sensible Daten bei berechtigtem Interesse (Art. 6 Abs. 1 lit. f): Abwägung dokumentieren; nicht geeignet für besondere Kategorien ohne Art. 9‑Erlaubnis.
- Kopplungsverbot beachten: Einwilligungen dürfen nicht für nicht notwendige Zwecke zur Nutzung der App erzwungen werden.
- Minderjährige (Art. 8): Altersgrenze des Mitgliedstaats prüfen (typisch 13–16). Altersverifikation und ggf. Zustimmung der Eltern implementieren und dokumentieren.

3) Transparenz und Informationspflichten
- Datenschutzhinweise bereitstellen (Art. 12–14): präzise, verständlich, mehrschichtig. Inhalte: Zwecke, Rechtsgrundlagen (Art. 6/9), Kategorien, Empfänger, Speicherdauer, Rechte, DSB‑Kontakt, Drittlandtransfers, Profiling/ADM (falls zutreffend).
- In‑App Einwilligungsdialoge: granular, spezifisch je Zweck/Kategorie, explizit für Gesundheitsdaten (klare affirmative Handlung), nachweisbar (Consent‑Logs), Widerruf jederzeit so einfach wie die Erteilung (Art. 7).
- Änderungen von Zwecken/Empfängern: rechtzeitig informieren; ggf. erneute Einwilligung einholen.

4) Datenminimierung und Speicherbegrenzung
- Nur erforderliche Daten erheben (Art. 5 Abs. 1 lit. c). Voreinstellungen datenschutzfreundlich (Art. 25).
- Löschkonzept/Retention planen (Art. 5 Abs. 1 lit. e): Fristen pro Zweck, automatisierte Löschung, Backup‑Löschung/Rotation, Protokollierung.
- Genauigkeit sicherstellen (Art. 5 Abs. 1 lit. d): Mechanismen zur Berichtigung.
- Pseudonymisierung einsetzen, wo möglich (Art. 4 Nr. 5, Art. 32); beachten: bleibt personenbezogen.
- Anonymisierung nur bei belastbarer Irreversibilität; andernfalls weiterhin DSGVO‑Pflichten.

5) Technische und organisatorische Maßnahmen (TOMs) – Sicherheit der Verarbeitung
- Risikobewertung durchführen (Art. 32 Abs. 1): Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit.
- Kryptografie:
  - Transportverschlüsselung (TLS 1.2/1.3) für alle Endpunkte.
  - Ruhende Daten verschlüsseln (z. B. AES‑256); Schlüsselmanagement, Trennung von Schlüssel und Daten.
  - Mobile: Nutzung sicherer Plattform‑Keystores; keine sensiblen Daten in Logs.
- Zugriffskontrollen: Least Privilege, Rollenrechte, MFA für Admins, regelmäßige Rezertifizierung von Rechten.
- Sicherheitsentwicklung (SDLC): Threat Modeling, Code‑Reviews, SAST/DAST, Abhängigkeits‑Scans, Penetrationstests, sichere API‑Designs (Rate‑Limiting, AuthN/Z).
- Protokollierung/Monitoring: Sicherheitsrelevante Ereignisse, Schutz vor unbefugtem Zugriff auf Logs, Erkennung von Anomalien.
- Integrität/Verfügbarkeit: Backup/Restore testen, Notfallpläne/BCP, Patch‑Management, Härtung von Servern/Containern.
- Drittanbieter‑SDKs minimieren und bewerten: Datenflüsse dokumentieren, Telemetrie begrenzen, keine unautorisierte Übermittlung von Gesundheitsdaten.
- Data Leakage Prevention: Ausgeschlossene Übermittlung an Werbenetzwerke ohne explizite, granulare Einwilligung und zusätzliche Schutzmaßnahmen.
- Privacy by Design/Default umsetzen (Art. 25): Zweckbindung, Datenminimierung, standardmäßig restriktive Freigaben.

6) Datenschutz‑Folgenabschätzung (DSFA/DPIA)
- Prüfen, ob DSFA erforderlich (Art. 35): groß angelegte Verarbeitung von Gesundheitsdaten, systematische Überwachung, neue Technologien.
- DSFA durchführen: Beschreibung der Verarbeitung, Notwendigkeit/Verhältnismäßigkeit, Risikoanalyse für Rechte/Freiheiten, Maßnahmen zur Risikominderung.
- Bei verbleibendem hohem Risiko Konsultation der Aufsichtsbehörde (Art. 36).
- Einbindung des DSB in DSFA‑Prozess (Art. 39).

7) Rechte der betroffenen Personen (Art. 15–22)
- Prozesse und SLAs implementieren: Antwort binnen 1 Monat (Art. 12 Abs. 3).
- Rechte: Auskunft, Berichtigung, Löschung, Einschränkung, Widerspruch, Datenübertragbarkeit (Art. 20; gilt bei Einwilligung/Vertrag und automatisierter Verarbeitung), Nichtunterliegen ausschließlich automatisierter Entscheidungen mit rechtlicher/ähnlicher erheblicher Wirkung (Art. 22).
- Identitätsprüfung, Register über Anfragen, Fristen und Entscheidungen.
- Standardisierte Antworten; Ablehnungen nur rechtmäßig (z. B. offenkundig unbegründet/exzessiv), dokumentieren.

8) Datenweitergaben und Empfänger
- Empfängerlisten und Zwecke dokumentieren (Art. 30).
- Datenverarbeitungsverträge mit Dienstleistern (Art. 28): TOMs, Löschung nach Auftragsende, Subunternehmerfreigabe, Unterstützung bei Betroffenenrechten und DSFA.
- Keine Weitergabe von Gesundheitsdaten zu Marketing-/Werbezwecken ohne explizite Einwilligung (Art. 9 Abs. 2 lit. a); ePrivacy/TTDSG für Zugriff auf Endgerätinformationen zusätzlich beachten.
- Datenübermittlungen an Gesundheitsdienstleister: Rechtsgrundlagen prüfen (Art. 6/9), Vertraulichkeits- und Berufsgeheimnisregelungen beachten.

9) Internationale Datenübermittlungen (Kapitel V)
- Datenflüsse in Drittländer identifizieren.
- Angemessenheitsbeschluss prüfen (Art. 45); andernfalls Standardvertragsklauseln (SCCs) oder andere geeignete Garantien (Art. 46).
- Transfer Impact Assessment (TIA) durchführen; ggf. ergänzende technische/organisatorische Maßnahmen implementieren (Schrems II).
- Transparenz in Datenschutzhinweisen; laufende Überprüfung der Rechtslage/Empfängerländer.

10) Vorfallmanagement und Meldungen
- Incident‑Response‑Plan: Erkennung, Bewertung, Eindämmung, Forensik, Kommunikation.
- Verletzungen melden (Art. 33): 72‑Stunden‑Frist an Aufsichtsbehörde, Dokumentation im Verletzungsregister.
- Benachrichtigung der betroffenen Personen bei hohem Risiko (Art. 34): klare Sprache, Art der Daten, wahrscheinliche Folgen, Maßnahmen/Empfehlungen.
- Übungen/Prüfungen des Notfallplans; Lessons Learned dokumentieren.

11) Qualitäts- und Nachweisführung (Accountability)
- Regelmäßige Audits/Reviews: DSFA‑Updates, TOM‑Wirksamkeit, Vendor‑Due‑Diligence, Einwilligungsroutinen.
- Schulungen für Mitarbeiter mit Datenzugriff (Datenschutz und Sicherheit).
- Nachweise aufbewahren: VVT, DSFA, Einwilligungsprotokolle, Schulungsnachweise, Richtlinien, Protokolle zu Datenlöschungen und Vorfällen.

12) App-spezifische technische Prüfpunkte
- Plattformberechtigungen (Sensoren, Standort, Kontakte) strikt nach Notwendigkeit; klare Nutzerinformation vor Zugriff.
- Lokale Datenspeicherung: minimale Menge, verschlüsselt, Schutz vor Jailbreak/Root‑Risiken.
- Schnittstellen (APIs) hart absichern; Token‑Schutz im mobilen Client; Schutz vor Replay/Man‑in‑the‑Middle.
- Aktualisierungsprozess mit Datenschutz‑Review vor Release; Change‑Management dokumentieren.

13) Profiling und automatisierte Entscheidungen
- Profiling‑Zwecke und Logik dokumentieren; Transparenz bereitstellen (Art. 13/14).
- Prüfen, ob Entscheidungen ausschließlich automatisiert sind mit rechtlicher/erheblicher Wirkung (Art. 22); ggf. menschliches Eingreifen, Anfechtungsrecht und Erklärungen sicherstellen.
- Minimierung sensibler Merkmale in Modellen; Bias‑Management und Testprotokolle.

14) Spezifische Inhalte der Datenschutzhinweise (Check)
- Verantwortlicher, DSB‑Kontakt.
- Zwecke und Rechtsgrundlagen (Art. 6/9), Kategorien, Quellen (falls nicht direkt erhoben).
- Empfänger/Kategorien, internationale Transfers und Garantien.
- Speicherdauern/Löschfristen.
- Betroffenenrechte und Ausübungswege.
- Widerrufsrecht bei Einwilligung (Art. 7 Abs. 3).
- Beschwerderecht bei einer Aufsichtsbehörde (Art. 77).
- Automatisierte Entscheidungen/Profiling (falls zutreffend).

15) Optional: Regulatorische Grenzfälle
- Medizinprodukte‑Einstufung prüfen (MDR). Bei Klassifizierung als Medizinprodukt ergeben sich zusätzliche, nicht‑DSGVO‑spezifische Pflichten; Schnittstellen zur DSGVO (z. B. Risikomanagement, Post‑Market‑Surveillance) beachten.

Ergebnisdokumentation:
- Für jeden Prüfpunkttyp sind Zustand, Maßnahmen, Verantwortliche, Fristen und Nachweise zu erfassen. Die Dokumentation dient als Accountability‑Beleg und erleichtert die Kommunikation mit Aufsichtsbehörden.