パスポートは一つ、スタンプは複数 — レポート一つで複数の規制に対応する
EU NIS2、DORA、ISO 27001、韓国 ISMS-P、日本 APPI、シンガポール CII。要求される書類の名前はそれぞれ違いますが、土台は重なっています。規制ごとに何を要求し、リスク評価レポートがそのどこを埋めるのかを表にまとめました。
旅行の荷造りをしたことがあると思います。国ごとに要求されるものが違います。ある国では事前にビザを取らなければならず、ある国では入国申告書を書けと言われ、ある国ではワクチン接種証明書を見られます。窓口も違えばスタンプの形も違います。
ところが、そのすべての窓口で同じように差し出すものが一つあります。パスポートです。「この人が誰なのか」は国ごとに証明し直すものではありません。一度作っておいた身元書類を、六か国の窓口で六回見せるだけです。
規制対応も似た形をしています。この記事はその話です。
名前が違うからといって、違うことを聞いているわけではない
事実 地域ごとに要求される文書の名前が違います。EU には NIS2 指令があり、金融業界には DORA があります。国際標準としては ISO 27001 があり、個人情報の面では GDPR 第32条がかかってきます。韓国には ISMS-P があり、2027年から義務化されます。日本には APPI の安全管理措置が、シンガポールにはサイバーセキュリティ法の CII 規定があります。
推定 名前だけを並べると六つの宿題のように見えます。ところが窓口を一つずつのぞいてみると、聞かれている内容が重なっています。「あなたのシステムのリスクをどうやって把握し、その結果として何をどう措置したのか。」 表現は違っても、結局はこの質問です。パスポートを六回見せるのと同じ構造です。
窓口ごとに何を聞かれるのか
事実 下の表の左側は各制度が要求するもので、右側はリスク評価レポートがそのうちどのマスを埋めるのかです。右側のマスに注目してください。全部ではなく一部です。
| 地域 | 制度 | 要求するもの | レポートが埋める部分 |
|---|---|---|---|
| EU | NIS2 (第21条) | リスク管理措置の文書化 · 監督当局の監査時の立証 | リスク分析 · アクセス制御 · 暗号化措置の技術的証跡 |
| EU | DORA (第9条) | ICT リスク管理 · 脆弱性スキャン · ネットワーク点検などのレジリエンステスト | クラウド ICT リスク評価 · テスト証跡 |
| Global | ISO 27001 · GDPR 第32条 | リスクベースのセキュリティ措置の策定 · リスク評価の文書化 | ISO 27005 リスク評価のインプット · 技術的セキュリティ措置の証跡 |
| KR | ISMS-P (2027年義務化) | 情報保護・個人情報の統合審査におけるリスク評価・技術統制 | リスク評価 · 技術統制項目の審査根拠資料 |
| JP | APPI 安全管理措置 | 「必要かつ適切な」技術的安全管理措置の文書化 | 技術的セキュリティ措置の文書化成果物 |
| SG | Cybersecurity Act (CII) | 年1回のリスク評価 · 2年ごとの独立監査 | 年次クラウドリスク評価の成果物 · 監査への備え |
推定 表を縦に眺めると、右側のマスの単語が繰り返し出てきます。リスク評価、技術的証跡、文書化。六か国の窓口で六回要求されるものが同じ種類の書類一枚だということです。
なぜ一つで済むのか — 根が同じだから
事実 RMF のリスク評価レポートは NIST SP 800-30 と ISO 27005 の方法論で作成されます。どちらも特定の国の専用ではなく、リスクをどう測りどう記述するかを定めた国際標準です。そして NIS2 の側は CIR 2024/2690(EU 実施規則)と ENISA 技術実装ガイダンス(2025年6月)を参照して整理します。
推定 各国の制度がこれらの標準を土台にしているため、標準的なやり方で一度きちんと測っておけば、複数の窓口で再利用できます。パスポートを発給するときに使った身元情報が、どの国の入国審査でも通用するのと同じです。もちろん審査官が要求する様式と付帯資料は窓口ごとに異なる場合があります。
パスポートは入国許可ではない
ここで比喩をもう一段押し進める必要があります。パスポートがあるからといって、どの国にも入れるわけではありません。パスポートは**「自分が誰かを証明する書類」であって、「入ってよいという許可」**ではありません。許可はその国の審査官が出します。
その書類はこういう見た目です。リスク等級の分布と要約が前に来て、PDF や DOCX に書き出して窓口に提出します。
事実 RMF レポートも同じ位置にあります。規制対応の技術的根拠資料です。証明書の発行、インシデント報告(NIS2 第23条など)、法的代理は含みません。 スキャン結果を PDF や DOCX に書き出して監査・審査に提出したり、レビュー用の根拠として使ったりするところまでが、この書類の役割です。
事実 スタンプを押す場所は別にあります。EU 監督当局・CSIRT の窓口とインシデント報告チャネルは NIS2 代理人の役割であり、個人情報に関する問い合わせ対応は GDPR 第27条代理人の役割です。パートナー企業である Prighter が、現地法人なしにこの二つの代理人の役割を担います。技術的検証と法律代理は互いを代替できず、二つが噛み合うことで EU 現地法人を設立せずに EU の顧客を受け入れる構造になります。
書類はどこに残るのか
事実 第5回で扱った話につながります。スキャン結果とレポートは顧客が指定した S3 バケットに保存され、顧客が所有する KMS キーで暗号化されます。データが顧客のストレージ境界を出ることはありません。なお韓国と日本は EU 十分性認定国であるため、データ移転の面では条件が有利な方です。
推定 パスポートを他人の引き出しに預けておかないのと同じです。複数の窓口で見せる書類であればあるほど、それが自分の手の中にあるという事実が重要になります。
押さえておきたいこと
- この記事は法的助言ではありません。 「こうすれば NIS2 に準拠します」と言える立場ではありません。準拠しているかどうかの判断は、監督当局と審査機関、そして各社の法律顧問がすることです。
- RMF レポートは証明書ではありません。 規制対応の技術的根拠資料です。証明書の発行も、インシデント報告も、法的代理も含みません。
- 表の右側のマスは制度全体をカバーしません。 各制度には、組織・手続き・教育・サプライチェーンのように技術スキャンでは確認できない要求事項も併せてあります。埋まるのはリスク評価と技術統制のレイヤーです。
- 審査の現場でどの形式を要求されるかは窓口ごとに異なります。 同じ根拠資料であっても、提出様式と追加の説明は個別に確認する必要があります。
- 制度は改正されます。この記事は2026年8月時点で公開されている文書に基づいて書きました。