gdpr-privacy-notice-eu-oliver-schmidt-prietz

EU 全域 GDPR プライバシー通知ジェネレーター

管轄区域に応じた GDPR 準拠のプライバシー通知を、プロフェッショナルな .docx ドキュメントとして生成します。

ワークフローの概要

1. SCOPE    → Notice type, jurisdiction(s), template choice
2. INTAKE   → Type-driven collection: controller info, data inventory, legal bases
3. DRAFT    → Generate notice from template + type profile + collected info
4. VERIFY   → Art. 13/14 compliance check + type-specific checks + AI Act check
5. DELIVER  → .docx output via docx skill

ステップ 1：対象範囲、通知の種類、テンプレートの選択

通知の種類を特定する（最初の質問）

最初に、どの種類のプライバシー通知が必要かを確認します。references/NOTICE_TYPES.md を読み込み、次のように尋ねます。

「どの種類のプライバシー通知が必要ですか？」

種類	説明
ウェブサイト／アプリ	ウェブサイト、ウェブアプリ、モバイルアプリの訪問者、ユーザー、購読者向け
応募者／採用	求職者および候補者向け（Bewerber、candidats）
従業員	従業員、契約社員、インターン向け（Beschäftigte、salariés）
ビジネスパートナー（B2B）	販売業者、サプライヤー、顧客、パートナーの担当者向け
B2C 顧客	顧客／購入の関係にある一般消費者向け
複合型	複数の対象者向けの通知を 1 つ、または相互にリンクされた複数の通知にまとめる場合

選択した種類によって、次の内容が決まります。

• 最終ドキュメントに含める、または省略するセクション
• 情報の聞き取り時に確認するデータカテゴリ
• 想定される法的根拠
• 種類別の聞き取り質問
• 適用される保存期間の既定値

各種類の詳細なセクション構成、データプロファイル、法的根拠、聞き取り質問、保存期間の既定値については、references/NOTICE_TYPES.md を参照してください。

管轄区域を特定する

サービスの対象となる国／市場を尋ねます。該当するリファレンスを読み込みます。

対象市場	リファレンスファイル
ドイツ／DACH	references/DE.md
フランス	references/FR.md
その他の EU（AT、IT、ES、NL、BE、IE、UK）	references/OTHER_EU.md
常に読み込む	references/EU_COMMON.md

複数の管轄区域にまたがるサービスでは、関連するファイルをすべて読み込み、要件が異なる箇所（例：子どもの年齢基準、DPO の基準、保存規則）を記録します。

テンプレートの選択

ユーザーに次のように尋ねます。

「プライバシー通知は、プロフェッショナルな .docx ドキュメントとして作成します。ベースとして使用する既存のテンプレートまたはプライバシー通知はありますか？ ない場合は、あらかじめ用意されたテンプレートを使用します。」

オプション	対応
ユーザーがテンプレートを提供する	提供された .docx をベースとして使用します。構成、文言、書式を維持し、記入または調整のみを行います
ユーザーテンプレートなし	docx スキルを使用して references/templates.md から生成します

references/templates.md には、13 セクション構成、Art. 21 の異議申し立てボックス（視覚的に強調）、目的／保存期間の表、Cookie の表、AI／自動意思決定のセクション、子どものデータに関するセクション、ページ番号付きの適切なヘッダー／フッター、A4 書式、目次、および DE、FR、EN の完全な翻訳が含まれています。対象の管轄区域に合った言語を選択してください。

ユーザーがテンプレートを提供する場合：その構成と検証済みの文言を忠実に維持します。プレースホルダーの置き換えと、個別のケースに合わせた調整のみを行います。検証済みの法的文言を書き換えてはいけません。

多言語対応の判断ツリー

サービスが複数の管轄区域または言語グループを対象とする場合、言語の方針を決定してください。

シナリオ	方針
単一市場、単一言語	対象市場の言語による通知を1つ用意します（例：ドイツのみ → ドイツ語）
単一市場、国際的な従業員／ユーザー	主言語版と英語版を用意します。内容に矛盾がある場合にどちらの版が優先されるかを明記します。
2つの市場、2つの言語	案A：言語ごとに独立した通知を2つ用意し、それぞれ単独で完結させます。案B：視覚的に明確に区別した二言語通知を作成します（例：左右の列、または順に並べたセクション）。
EU全域／多数の市場	英語を主言語とし、主要市場向けに翻訳を用意します。各翻訳は部分訳ではなく、単独で完結した通知にします。
スイス企業（nDSG + GDPR）	スイスのnFADP（新連邦データ保護法）とGDPRの両方に対応します。一般的な方法は、両方の法制度に言及する単一の通知を、少なくともドイツ語＋フランス語（該当する場合はイタリア語も）で用意することです。注：nFADPには一般的な処理に対する同意要件はありませんが、GDPR第13条／第14条と同様の情報提供義務があります。

二言語文書のテンプレートの取り扱い：

• 主言語のテンプレートを構成のベースとして使用します
• 両方の言語版にすべての必須開示事項が含まれていることを確認します（翻訳漏れはコンプライアンス上の不備につながります）
• 優先される言語版を明示します（例：「相違がある場合、［ドイツ語／フランス語］版が優先されます。」）

多言語対応の確認チェックリスト（該当する場合はステップ4に追加）：

• すべての必須の第13条／第14条の開示事項が各言語版に含まれている
• 優先される言語版が明確に特定されている
• 法律用語が正しく翻訳されている（レビューなしの機械翻訳ではない）
• 各管轄区域の監督機関に関する情報が正確である
• 管轄区域固有の要件が、該当する言語版で扱われている

プラットフォームのサブタイプ（Webサイト／アプリの場合のみ）

通知の種類がWebサイト／アプリの場合、データカテゴリを想定するためにプラットフォームをさらに分類します。詳細は references/NOTICE_TYPES.md → 「Webサイト／アプリ」→「サブタイプとデータプロファイル」を参照してください。

サブタイプ	一般的に追加されるデータ
会社案内／企業サイト	お問い合わせフォーム、分析、Cookieのみ
Eコマース	アカウント、決済、注文履歴、配送、返品
SaaS／Webアプリ	アカウント、利用データ、機能ログ、APIキー、コラボレーションデータ
モバイルアプリ	デバイスID、プッシュトークン、権限（カメラ、位置情報、連絡先）、アプリの利用状況
マーケットプレイス	二重の役割（買い手／売り手）、評価、メッセージ、エスクロー決済
AI機能を備えたプラットフォーム	学習データ、AIへの入力／出力、モデルによる判断、プロファイリング

ステップ2：情報の収集

ドラフトを作成する前に、すべての情報を収集します。情報収集の指針として references/NOTICE_TYPES.md の種類別プロファイルを使用してください。各種類には、想定されるデータカテゴリ、法的根拠、種類固有の質問があらかじめ定義されています。

論理的なグループに分けて質問し、一度にすべてを尋ねないでください。まずグループA（常に適用）から始め、次に種類別プロファイルを使って、確認するカテゴリと尋ねる種類固有の質問を判断します。

グループA — 管理者の識別情報

• 会社名、法的形態、登録番号
• 登記上の住所
• 法定代理人（氏名＋役職）
• 連絡先メールアドレス＋電話番号
• DPOの選任状況 → 連絡先情報（専用メールアドレスを使用）

グループ B — データの棚卸し

各収集時点（フォーム、アカウント作成、購入、Cookie、アプリの利用）について：

• どのようなデータを収集しますか？
• 必須ですか、それとも任意ですか？
• 収集元はどこですか（ユーザーから直接、第三者、自動収集）？

確認するカテゴリー：

• 個人識別情報：氏名、メールアドレス、電話番号、住所、生年月日、写真
• アカウント：認証情報、設定、環境設定、アクティビティ履歴
• 技術情報：IP アドレス、デバイス ID、ブラウザーフィンガープリント、ログ
• 閲覧情報：閲覧したページ、クリック、セッション時間、リファラー
• 取引情報：注文、支払い方法（プロバイダー経由）、請求書
• コミュニケーション：メッセージ、サポートチケット、コメント
• 特別カテゴリー（Art. 9）：健康、生体認証、政治的信条、宗教、性的指向、民族的出自、労働組合、遺伝情報 — Art. 9 のデータが特定された場合：EU_COMMON.md → "Special Category Data (Art. 9)" を参照し、完全な受付手順を確認してください。カテゴリーごとに Art. 9(2) の例外を特定し、二重の法的根拠（Art. 6 + Art. 9(2)）を確認したうえで、追加の保護措置を文書化してください。通知の種類ごとによくある該当例：従業員（教会税、障害、病気休暇、組合費）、応募者（障害、健康、宗教）、B2C（薬局／保険／フィットネスの健康データ）。
• AI 関連：AI システムへの入力、AI が生成した出力、自動化されたスコア／意思決定

グループ C — 目的と法的根拠

各処理活動について、法的根拠を特定してください。ガイダンスは EU_COMMON.md を参照してください。

ユーザーが確認できるよう、次の表を提示します。

目的	法的根拠	データカテゴリー
サービス提供／契約の履行	Art. 6(1)(b)	[記入欄]
アカウント管理	Art. 6(1)(b)	[記入欄]
法令／税務上の遵守	Art. 6(1)(c) — [具体的な法律]	[記入欄]
分析	Art. 6(1)(f) または同意	[記入欄]
マーケティング／ニュースレター	Art. 6(1)(a) 同意	[記入欄]
AI による処理	[ユースケースごとに特定]	[記入欄]

グループ D — 受領者と移転

• ホスティングプロバイダーと所在地
• 決済処理業者
• 分析ツール
• メール／マーケティングツール
• CRM／サポートツール
• AI／ML サービスプロバイダー（例：OpenAI、Google AI、Anthropic）
• その他の処理者
• EU／EEA 域外への移転 → 対象国と移転メカニズム（十分性認定、SCC、DPF、BCR）

DPA／Art. 28 の相互参照 — 特定した各処理者について：

• データ処理契約（GDPR Art. 28）が締結されていることを確認してください。締結されていない場合は、通知の最終化前に是正が必要なコンプライアンス上の不備として指摘してください。
• 通知に開示する内容：処理者名（またはカテゴリー）、目的、所在地、移転メカニズム。DPA の条項、再処理者の一覧、TOM はプライバシー通知に含めないでください。これらは Art. 28 の契約に記載する内容です。
• 開示しない内容：具体的な技術的／組織的措置（Art. 32）、再処理者の連鎖、料金、SLA の詳細。
• ある処理者との DPA が存在しないことをユーザーが確認した場合は、概要にその旨を記載し、直ちに是正するよう推奨してください。プライバシー通知では引き続き処理者名／カテゴリーを明記し、管理者が契約の正式化を進めている旨を追記してください。
• 共同管理（Art. 26）が該当する場合は、各当事者の責任とデータ主体の問い合わせ先を含め、その取り決めの概要を通知で開示する必要があります。

グループ E — Cookie とトラッキング

• 使用する Cookie のカテゴリー（必須、分析、マーケティング、ソーシャル）
• 具体的なツール（Google Analytics、Meta Pixel、Matomo、HubSpot など）
• CMP ソリューション（Usercentrics、Cookiebot、Axeptio、Didomi、Borlabs など）
• サーバーサイドトラッキングの有無。フィンガープリンティングの有無。
• Cookie の有効期間

グループ F — AI と自動処理

サービスで AI／ML を使用している場合：

• どのような AI システムを、どのような目的で使用していますか？
• 意思決定は完全に自動化されていますか。それとも人間が関与しますか？
• 意思決定は法的効果または同様に重大な影響をもたらしますか（Art. 22）？
• ユーザーデータはモデルのトレーニングに使用されますか？
• AI Act 上の分類：禁止／高リスク／限定的リスク／最小リスク？

グループ G — DPIA の指標（GDPR 第 35 条）

データ保護影響評価が必要となる可能性があるか確認します。以下の指標のうち2 つ以上に該当する場合は、ユーザーに知らせ、別個の成果物として DPIA を推奨してください。

1. 個人の体系的な評価／スコアリング（プロファイリング、信用スコアリング、業績評価）
2. 法的効果または同様に重大な影響をもたらす自動化された意思決定（第 22 条）
3. 公開されている区域の体系的な監視（CCTV、Wi-Fi トラッキング）
4. 特別カテゴリのデータまたは犯罪に関するデータを大規模に処理する（第 9 条／第 10 条）
5. 個人データの大規模な処理（大量、広範な地理的範囲、多数のデータ主体）
6. データ主体が合理的に予測しない方法で、異なる情報源のデータセットを照合または結合する
7. 脆弱なデータ主体（従業員、子ども、患者、高齢者）
8. 革新的なテクノロジーの利用（生体認証、AI／ML、IoT、個人データに関するブロックチェーン）

2 つ以上の指標に該当する場合：

• ユーザーに次のように知らせます：「説明された処理活動に基づくと、GDPR 第 35 条に基づくデータ保護影響評価（DPIA）が必要と思われます。」
• 通知への影響を説明します。プライバシー通知には、DPIA が実施されたことを記載する必要があります（ただし、DPIA の内容そのものは開示しません）。
• 次のように推奨します：「DPIA は独立したコンプライアンス対応であり、処理を開始する前に実施する必要があります。このプライバシー通知スキルでは通知を作成できますが、DPIA は独立した文書として作成してください。」
• 各国の必須 DPIA リストを確認します（DE：DSK-Liste、FR：DPIA が必要な処理業務に関する CNIL のリスト）。

ドラフト作成前の要約

情報収集後、ユーザーが確認できるよう、構造化された要約を作成します。

NOTICE TYPE: [Website / Applicant / Employee / B2B / B2C / Combined]
CONTROLLER: [Name, form, address]
JURISDICTION(S): [Countries]
PLATFORM: [Type / Sub-type if website]
DPO: [Yes/No + contact]
DATA CATEGORIES: [List by collection point]
PURPOSES + BASES: [Table]
PROCESSORS: [List with locations]
TRANSFERS: [Countries + mechanisms]
COOKIES: [Categories + tools + CMP — if applicable per type]
AI PROCESSING: [Yes/No + details]
RETENTION: [Key periods — cross-check with type defaults]
SPECIFICS: [Anything unusual]
SECTIONS TO INCLUDE: [Based on type section map]
SECTIONS TO SKIP: [Based on type section map]

ドラフト作成に進む前に、ユーザーに確認します。

ステップ 3：通知を作成する

種類に応じたセクションの選択

選択した通知の種類に対応する references/NOTICE_TYPES.md のセクションマップを使用します。✅ または ⚠️（該当する場合）が付いたセクションのみ含めます。❌ が付いたセクションは省略します。これにより、応募者向け通知における Cookie の表など、関連性のない内容を避けられます。

複数の対象者を対象とする複合通知については、構成の選択肢（単一の包括的な通知、個別の通知、または段階的な通知）を references/NOTICE_TYPES.md →「複合通知」で確認してください。

標準構成（全項目 — 種類に応じて調整）

PRIVACY NOTICE / DATENSCHUTZERKLÄRUNG / POLITIQUE DE CONFIDENTIALITÉ
[Company Name]
Last updated: [DATE]

1. WHO WE ARE (Controller identity + DPO)
2. WHAT DATA WE COLLECT (by category, with source + mandatory/optional)
3. WHY WE PROCESS YOUR DATA (purposes + legal bases table, incl. retention per purpose)
4. WHO RECEIVES YOUR DATA (recipients + processors)
5. INTERNATIONAL TRANSFERS (countries + safeguards)
6. HOW LONG WE KEEP YOUR DATA (retention table — can be merged with section 3)
7. YOUR RIGHTS (all applicable rights + exercise procedure)
8. COOKIES & TRACKING (categories + management + CMP reference)
9. AI & AUTOMATED DECISIONS (if applicable — Art. 22 + AI Act)
10. DATA SECURITY (general measures, no sensitive technical details)
11. CHILDREN'S DATA (if applicable — age threshold + mechanism)
12. CHANGES TO THIS NOTICE (notification method)
13. CONTACT (email + postal + form link)

作成ルール

• 言語：管轄区域の言語で作成します。複数の管轄区域にまたがる場合は、準拠する版を明確に示し、主要言語を先に記載します。
• 語調：読者に「あなた」／「Sie」／「vous」と呼びかけます。法律の専門家でなくても理解できる、明確で平易な表現を使用します。
• 異議を申し立てる権利（第 21 条）：他の権利とは明確に区別し、目立つ形で提示する必要があります（GDPR 第 21 条第 4 項）。ドイツ語の通知では、「WIDERSPRUCHSRECHT」という独立したセクションを設けるのが一般的です。
• 法的根拠：条文番号を正確に引用します（例：「Art. 6(1)(f) DSGVO」。単に「正当な利益」とするのではなく、条文番号を記載します）。
• 保存期間：曖昧な表現ではなく、法的な根拠を添えて具体的な期間を示します。
• AI に関する開示：AI を使用する場合、第 22 条が厳密には適用されない場合でも、専用のセクションを設けます。AI Act は透明性を求めています。
• 表：目的／法的根拠／保存期間、および Cookie のカテゴリには表を使用します。読みやすさが向上します。
• 内部参照なし：最終文書に、このスキル、CNIL のガイド、その他の作成補助資料への参照を含めてはなりません。

ステップ 4：コンプライアンスの確認

納品前に、以下の順序で体系的な最終確認を行います。

1. ステップ 1 で読み込んだ管轄区域の参照ファイル（DE.md、FR.md、OTHER_EU.md）を再読します。以下を照合します。

• 管理者の登記上の所在地に対応する監督機関の名称、住所、URLが正しいこと
• 保存期間が、一般的な既定値ではなく、管轄区域固有の法的根拠と一致していること
• 定型文（第 21 条の異議申立て権、苦情申立て権、管理者の紹介）が、参照ファイルで検証された管轄区域の文言を使用していること
• まだ対応していない管轄区域固有の要件がないこと（例：DE の従業員／応募者に関する § 26 BDSG、FR のマーケティングに関する Art. L.34-5 CPCE）

2. EU_COMMON.md →「必須開示事項チェックリスト」に照らして、第 13 条／第 14 条の必須開示事項を確認します。すべての項目が記載されているか、適用されない場合は理由が明示されている必要があります。

3. 追加確認：

• 第 21 条の異議申立て権が、他の項目と分けて目立つように記載されている
• 正しい監督機関が記載されている（管轄区域の参照ファイルを確認）
• DPO が任命されている場合、その連絡先が記載されている
• Cookie のセクションが、実際の Cookie の使用状況と一致している（種類に応じて含める場合）
• 保存期間が具体的である（基準を示さずに「必要な期間」などとしていない）
• 移転の仕組みが、実際の処理者の所在地と一致している
• 該当する場合、AI／自動意思決定について対応している
• 未成年者がサービスを利用できる場合、子どものデータについて対応している
• 特別カテゴリのデータ（第 9 条）：二重の法的根拠（第 6 条＋第 9 条第 2 項）が開示され、具体的な例外が特定され、追加の保護措置が記載されている
• 対象となる管轄区域の言語に合っている
• プレースホルダーテキスト（[...]、___、TODO）が残っていない
• 更新日が記載されている
• セクションが種類別のセクション構成に合っている（無関係なセクションがなく、必須セクションの欠落もない）

4. 種類別の確認（references/NOTICE_TYPES.md を参照）：

応募者：§ 26 BDSG が参照されているか（DE）？タレントプールへの同意は個別に取得しているか？不採用後の保存期間は、同意がない限り 6 か月以内か？採用担当者からデータを取得した場合、第 14 条を適用しているか？

従業員：主要な法的根拠として § 26 BDSG を使用しているか（DE）？該当する場合、労働者評議会に言及しているか？IT のモニタリングを開示しているか？複雑な保存期間の一連の流れがすべて記載されているか？

B2B：データ主体から直接データを取得していない場合、第 14 条の開示を行っているか？データの情報源を開示しているか？連絡担当者と契約主体の違いが明確か？

B2C 顧客：ソフトオプトインの条件を満たしているか（DE：§ 7(3) UWG）？決済処理業者を開示しているか？ロイヤルティプログラムの条件が明確か？該当する場合、プロファイリングを開示しているか？

5. AI 法への準拠（AI 機能がある場合）：

• ユーザーに、AI とやり取りしていることを通知している（AI 法第 50 条）
• 該当する場合、AI 生成コンテンツを開示している
• 高リスク AI：透明性に関する義務を満たしている
• GDPR 第 22 条の権利と AI システムとの関連を開示している

ステップ 5：.docx として納品

docx 生成スキル（Claude.ai Projects では /mnt/skills/public/docx/SKILL.md、Claude Code では docx-processing-anthropic スキル）を使用して、最終文書を生成します。docx スキルが利用できない場合は、適切に書式設定した Markdown を代替として生成します。

文書の書式設定基準

• 用紙サイズ：A4（EU 文書の標準）
• フォント：本文は Arial または Calibri、11pt、見出しはそれに比例して大きくする
• 余白：全方向 2.5 cm（EU 標準）＝ 1417 DXA
• 構成：見出しに番号を付ける（1.、2.、3. など）。3 ページを超える文書には目次を付ける
• 表：細い罫線、網かけしたヘッダー行、読みやすいセルの余白
• ヘッダー：会社名または「プライバシー通知」
• フッター：ページ番号、「最終更新日：[DATE]」

ファイルを生成する前に、docx スキルの手順を確認してください。新しい文書には docx-js を使用します。docx スキルの重要なルール（DXA 幅、リストの LevelFormat.BULLET、表の ShadingType.CLEAR など）をすべて遵守してください。

納品

.docx ファイルには、以下を記載してください。

1. 含めた内容の簡単な確認
2. 未解決の質問や、置いた前提
3. 公開前に法務レビューを受けることの推奨

IMPORTANT: 公開前に、必ず有資格の法律顧問による通知のレビューを受けるよう推奨してください。このツールは文書の作成を支援するものであり、法的助言に代わるものではありません。

生成後のチェックリストと承認ワークフロー

社内レビューと公開のプロセスを進めるため、以下のチェックリストをユーザーに提示してください。

法務レビュー：

• 有資格のデータ保護法務担当者／DPOがプライバシー通知をレビューした
• 個々の処理活動に適した法的根拠がすべて確認されている
• 保存期間が現行の法的要件に照らして確認されている
• 移転の仕組みが有効かつ最新であることが確認されている（特にDPF認証、SCCのバージョン）
• 第9条の特別カテゴリーの処理について、二重の法的根拠と保護措置がレビューされている

技術レビュー：

• 記載されているすべての処理者とツールが実際に使用されている（古い情報が含まれていない）
• Cookieの表が、ウェブサイトで実際に設定されるCookieと一致している（ブラウザーの開発者ツールで監査）
• データフローが技術アーキテクチャと一致している（IT／エンジニアリング部門が確認）
• 連絡先情報（メール、郵送先、DPO）が正確で、適切に管理されている

翻訳QA（複数言語の場合）：

• 各言語版を、法律の専門知識を持つネイティブスピーカーがレビューした
• 法律用語が確認されている（機械翻訳をそのまま使用していない）
• すべての版に、内容上の相違がない
• 準拠版が明確に示されている

公開要件：

• どのページからも2クリック以内で通知にアクセスできる（DE：BGHの要件）
• 適宜、ウェブサイトのフッター／アプリ設定／オンボーディングフローにリンクされている
• 監査証跡のため、発効日とともに旧版がアーカイブされている
• Cookieバナー／CMPが更新され、現行のプライバシー通知を参照している
• 更新された通知について、従業員／応募者に通知した（該当する場合）

継続的なレビューの契機 — 以下の場合に通知を見直すようユーザーに推奨してください。

• 新しい処理者やツールを導入したとき
• 新しい処理目的を追加したとき
• 法的枠組みに変更があったとき（新たな十分性認定、裁判所の判決、規制当局のガイダンス）
• 会社が合併、買収、または再編を行ったとき
• 開示されていない処理が明らかになるデータ侵害が発生したとき
• 最低でも年1回

相互参照

• 侵害対応：ユーザーが侵害通知の手順も必要とする場合は、breach-sentinel スキルを案内してください
• DPIA：処理に高いリスクが伴う可能性がある場合は、別途、データ保護影響評価（GDPR第35条）の実施を推奨してください
• Cookieポリシー：プライバシー通知に統合することも、別の文書にすることもできます。ユーザーの希望を確認してください

文体ガイド

推奨	避ける表現
「あなた」／「あなたのデータ」／「Sie」／「Ihre Daten」	「ユーザー」／「データ主体」／「der Betroffene」
短く明快な文	難解で長い法律文
複雑な処理には具体例を示す	曖昧な表現（「さまざまなデータ」、「多様なデータ」）
構造化された情報には表を使う	目的や保存期間を長文で列挙する
条文を正確に引用する	「適用法令に従って」などの一般的な表現
能動態を使う	避けられる場合は受動態
法的な正確さを保ちつつ、平易な言葉を使う	法律用語だけの表現、または過度に単純化した表現

関連するGDPRスキル

このスキルは単独でも使えますが、他のEUデータ保護スキルと組み合わせることもできます。必要なスキルを個別にインストールするか、組み合わせて使用してください。

• DPIA Sentinel — 第35条 データ保護影響評価
• GDPR Breach Sentinel — 第33条／第34条 侵害対応と通知
• Transfer Impact Assessment (TIA) — 第V章 移転影響評価
• DPA Art. 28 — 管理者・処理者間の契約（AVV）
• Legitimate Interest — 第6条第1項(f)号 正当な利益に関する評価（LIA）／比較衡量テスト