compliance-checklist-generation

コンプライアンスチェックリストの作成

SOC2、HIPAA、PCI-DSS、GDPRなど、主要な規制フレームワークに対応する、体系的で実行可能なコンプライアンスチェックリストを作成します。このスキルでは、管理策を要件に対応付け、各管理策の準備状況を評価し、ギャップを特定して、優先順位を付けた是正計画を作成します。出力には、各管理策項目のステータス追跡、必要な証拠、作業量の見積もりが含まれます。

ワークフロー

1. 該当するフレームワークを特定する — 事業の種類、取り扱うデータ、顧客の要件、事業を展開する地域に基づいて、適用されるコンプライアンスフレームワークを判断します。医療系のSaaSにはHIPAAが必要です。クレジットカードを処理する企業にはPCI-DSSが必要です。エンタープライズ向けB2B SaaSの顧客からは、ほぼ必ずSOC2を求められます。EUのユーザーにサービスを提供するとGDPRが適用されます。複数のフレームワークでは管理策が重複することが多いため、重複作業を減らせる共通の管理策を特定します。

2. 管理策を要件に対応付ける — 各フレームワークを構成する管理策のカテゴリと個別の要件に分解します。SOC2では、5つのトラストサービス規準（セキュリティ、可用性、処理の完全性、機密性、プライバシー）にわたって対応付けます。HIPAAでは、管理的、物理的、技術的な保護措置を網羅します。PCI-DSSでは、12の要件ファミリーすべてに対応します。GDPRでは、原則、権利、義務を定める第5条から第49条に対応付けます。

3. 現状を評価する — 各管理策について、現在の実装状況を評価します。実装済み（証拠がある）、一部実装済み（管理策は存在するが、ギャップがある）、未実装（管理策がない）、または適用対象外（根拠を文書化済み）から選択します。可能な場合は、既存のドキュメント、ツールの設定、またはプロセスの成果物を証拠として参照します。

4. ステータスとギャップを含むチェックリストを作成する — 管理策のカテゴリごとに整理した構造化チェックリストを作成し、各項目に要件の説明、現在のステータス、必要な証拠、ギャップの説明（該当する場合）、是正に必要な作業量の見積もり（時間／日数）を記載します。カテゴリごとの全体的な準備状況を示す概要ダッシュボードも含めます。

5. 是正の優先順位を付ける — リスクの深刻度、監査への影響、実装に必要な作業量、複数のフレームワークに共通して適用できる範囲を組み合わせて、ギャップを順位付けします。影響が大きく作業量が少ないクイックウィンを優先します。SOC2、HIPAA、PCI-DSSのログ要件を同時に満たす単一のロギングソリューションの導入など、まとめて対処できる関連する是正項目をグループ化します。

使用方法

必要なフレームワーク、事業の種類、現在のセキュリティ態勢、今後予定されている監査の期限を指定してください。既存の管理策について詳しい情報があるほど、より正確なギャップ分析ができます。

プロンプトの例：

Generate a SOC2 Type II readiness checklist for our Series A startup. We're a B2B SaaS running on AWS. We use GitHub for code, Datadog for monitoring, and have about 20 employees. We need to be audit-ready in 6 months.

例

例1：スタートアップの SOC2 Type II 対応準備

入力： AWS 上で事業を展開する従業員20名の B2B SaaS スタートアップです。GitHub、Datadog、Google Workspace、Slack を使用しています。正式なセキュリティプログラムはまだありません。6か月後に SOC2 監査を予定しています。

出力：

対応準備状況の概要： 34% 対応済み（推定）

カテゴリ	管理策	実施済み	一部実施	未実施	対応準備状況
アクセス制御	12	3	4	5	28%
変更管理	8	5	2	1	63%
インシデント対応	6	0	1	5	8%
リスク評価	5	0	0	5	0%
監視とログ記録	7	4	2	1	57%
ベンダー管理	4	0	1	3	13%
人事とセキュリティ意識向上	6	1	2	3	17%

管理策の例（アクセス制御カテゴリ）：

#	要件	状況	必要な証拠	ギャップ／対応策	作業量
AC-1	すべての本番システムで MFA を必須にする	一部実施	AWS IAM ポリシーのスクリーンショット、IdP の設定	AWS コンソールでは MFA が有効ですが、EC2 インスタンスへの SSH アクセスでは有効になっていません。すべてのアクセス経路で MFA を有効にしてください。	2日
AC-2	最小権限の原則に基づくロールベースのアクセス制御	未実施	IAM ロール定義、アクセスマトリクス	正式な RBAC モデルがありません。ロールを定義し、AWS IAM ポリシー、GitHub のチーム、Google Workspace のグループに対応付けてください。	5日
AC-3	四半期ごとのアクセスレビュー	未実施	アクセスレビュー記録、承認ログ	プロセスがありません。マネージャーの承認を伴う、すべてのシステムアクセスの四半期レビューを導入してください。ツールの推奨：自動追跡には Vanta または Drata。	3日
AC-4	退職者のアクセス権を24時間以内に削除する	一部実施	退職手続きチェックリスト、プロビジョニング解除ログ	場当たり的なプロセスはありますが、文書化されていません。すべてのシステムを網羅したチェックリストを正式化し、可能な場合は ID プロバイダーを通じて自動化してください。	2日

優先的な是正措置（1か月目）： リスク評価（他のすべての管理策に必要な基盤）、すべてのシステムでの MFA の必須化、正式なアクセス制御ポリシー文書、インシデント対応計画の草案。

例2：E コマースの GDPR 対応

入力： EU を拠点とし、家電製品を販売する E コマースサイトです。氏名、住所、メールアドレス、決済データ、閲覧行動を収集しています。メールマーケティングには Google Analytics、Meta Pixel、Mailchimp を使用しています。EU の全加盟国に商品を発送しています。

出力：

対応準備状況の概要： 42% 対応済み（推定）

GDPR の領域	要件	遵守済み	ギャップ	対応準備状況
適法な根拠と同意	8	3	5	38%
データ主体の権利	7	2	5	29%
データ処理記録	4	1	3	25%
国際移転	3	1	2	33%
セキュリティ対策	6	4	2	67%
データ侵害の通知	3	1	2	33%
DPO とガバナンス	4	2	2	50%

管理策の例（データ主体の権利）：

#	要件	状況	ギャップ／対応策	作業量
DSR-1	アクセス権（第15条）— 30日以内に回答	未実施	ユーザーに関して保有するすべてのデータを収集する自動プロセスがありません。データベース、Google Analytics、Mailchimp からデータをエクスポートできるようにしてください。社内ツールを構築するか、プライバシー管理プラットフォームを使用してください。	5日
DSR-2	消去権（第17条）— 請求に応じて削除	一部実施	メインデータベースからは削除できますが、アナリティクス、バックアップ、Mailchimp からは削除できません。すべてのデータストアを洗い出し、全システムにわたって連鎖的に削除する仕組みを導入してください。	4日
DSR-3	データポータビリティ権（第20条）— 機械可読形式でのエクスポート	未実施	エクスポート機能がありません。ユーザーデータをエクスポートする JSON/CSV エンドポイントを構築してください。	3日
DSR-4	詳細なオプトイン設定を備えた Cookie 同意	一部実施	Cookie バナーはありますが、あらかじめチェックされたボックスを使用しているため、準拠していません。カテゴリごとの詳細な選択肢とすべて拒否するオプションを備えた、準拠した CMP（例：Cookiebot、OneTrust）に置き換えてください。	2日

ベストプラクティス

• まず単一のフレームワークから始めて、範囲を広げます — SOC2 のセキュリティ基準は HIPAA の技術的保護措置や PCI-DSS と大きく重複しているため、最初のフレームワークが基盤になります。
• フレームワーク間で管理策を対応付け、共通する要件を特定して、複数の規格を同時に満たす管理策への作業の重複を避けます。
• コンプライアンス自動化プラットフォーム（Vanta、Drata、Secureframe）を利用して、監査前に慌てて準備するのではなく、証跡を継続的に収集します。
• 「該当なし」とする根拠を正式に文書化します — 監査人は N/A の項目ごとに質問し、文書化された根拠を求めます。
• 定期的な管理策（四半期ごとのアクセスレビュー、年次リスク評価、ペネトレーションテスト）に対してカレンダーにリマインダーを設定し、監査期間の合間に抜けが生じないようにします。
• チェックリストを常に更新する文書として扱います — 是正対応中は毎週ステータスを更新し、コンプライアンスを達成した後は四半期ごとに見直します。

安全上の境界

• 出力は、法的助言ではなく、情報提供を目的とした草案作成や問題点の洗い出しとして扱います。
• 適用される法域と関連する施行日を特定し、要件の変更について最新の一次情報源で確認します。
• 文言が準拠している、法的強制力がある、または完全であると断言しないでください。不確実な点を明示し、重要な判断については適格な弁護士への相談を推奨します。
• ユーザーが確認し、明示的に許可することなく、法的条件を提出、公開、承諾、署名、または送信しないでください。

エッジケース

• 既存のセキュリティプログラムがないスタートアップ — まずリスク評価を実施して、ベースラインを確立します。クラウドネイティブの機能（AWS CloudTrail、GitHub のブランチ保護、Google Workspace のセキュリティ設定）を使えば、多くの管理策を迅速に導入できます。まずは情報セキュリティ、許容される利用、インシデント対応など、基盤となるポリシーを優先します。
• 複数のフレームワークにまたがる監査 — SOC2、HIPAA、PCI-DSS を同時に目指す場合、各社内管理策を各規格の該当要件に対応付ける、統一された管理フレームワークを構築します。監査人は、重複する管理策について共通の証跡を受け入れる場合があります。
• サーバーレスまたは PaaS アーキテクチャを利用する企業 — 共有責任モデルのもと、多くのインフラストラクチャ管理策はクラウドプロバイダーの責任になります。継承する管理策（物理セキュリティ、ハイパーバイザーのパッチ適用）と、顧客側に残る管理策（アプリケーションセキュリティ、アクセス管理）を文書化します。
• 急速な成長や頻繁な組織変更 — 従業員数や役割構成に依存する管理策（アクセスレビュー、セキュリティトレーニングの受講完了）には、拡張可能なプロセスが必要です。入社・退職時のチェックリストを自動化し、セキュリティトレーニングを人事の入社手続きのワークフローに組み込みます。
• 買収によるコンプライアンスの継承 — 企業を買収しても、その企業のコンプライアンス状況が自動的に引き継がれるわけではありません。買収先のコンプライアンスギャップ評価を実施し、自社のコンプライアンス体制に統合するためのスケジュールを策定します。