クラウド契約、委託先管理、個人情報保護、事故対応、内部統制をつなげて、登録証の有無だけでは見落としやすい確認ポイントを整理します。
クラウド契約、委託先管理、個人情報保護、事故対応、内部統制をつなげて、登録証の有無だけでは見落としやすい確認ポイントを整理します。
通常のISMSだけでは見えにくいクラウド固有リスクを、契約と管理体制の両面から確認します。
ISO27017クラウドセキュリティ認証は、クラウドサービスの提供又は利用に関する情報セキュリティ管理を、クラウド固有のリスクに照らして評価し説明するための制度です。企業法務では、セキュリティ部門だけの論点ではなく、契約、委託先管理、個人情報保護、越境移転、事故対応、内部統制、監査証跡、サプライチェーンリスク、経営判断の合理性に関わります。
日本で一般に使われるISO27017クラウドセキュリティ認証は、ISO/IEC 27017という国際規格だけを単独で認証する制度ではありません。JIS Q 27001又はISO/IEC 27001に基づくISMS認証を前提に、クラウドサービス固有の管理策が追加で特定され、実施されていることをJIP-ISMS517に基づいて認証する仕組みとして理解します。
相手方が認証取得を示す場合は、どの法人の、どのクラウドサービスについて、クラウドサービスプロバイダ又はクラウドサービスカスタマのどちらの立場で、どの認証機関により、どの範囲で、どの有効期限まで認証されているかを確認します。登録証の有無だけで安全性や法令対応を断定しないことが重要です。
次の一覧は、このページ全体で確認する論点をまとめたものです。制度名だけで判断すると見落としやすい範囲、責任分界、証跡、期限を並べているため、契約レビューや委託先評価で何を読み取るべきかを把握できます。
ISO/IEC 27017はクラウド管理策の手引であり、国内認証ではJIP-ISMS517とISMS認証との関係を確認します。
法人名、対象サービス、立場、事業所、サポート、再委託、有効期限まで確認します。
認証維持、失効通知、ログ提供、再委託、データ削除、事故通知を契約条項へ接続します。
ISO/IEC 27017、JIS Q 27017、ISMS、JIP-ISMS517、CSP、CSC、認証と認定を区別します。
ISO/IEC 27017は、ISO/IEC 27002を基礎に、クラウドサービスの提供及び利用に適用できる情報セキュリティ管理策の追加手引を示す国際規格です。2015年版はクラウドサービスプロバイダとクラウドサービスカスタマの双方を対象にし、第2版はISO/IEC 27002:2022に基づく追加ガイダンスとして公表過程にあります。
JIS Q 27017:2016はISO/IEC 27017:2015に対応する日本産業規格であり、2016年12月20日発行、2021年6月21日確認、ISO/IEC 27017:2015との対応関係はIDTとされています。国内制度を読む際は、JIS Q 27017とJIP-ISMS517を分けて確認します。
次の比較一覧は、似た用語の役割を整理したものです。用語の違いは、登録証の読み違いや契約条項の不足に直結するため、左列の名称と右列の実務上の意味を対応させて確認します。
| 用語 | 実務上の意味 |
|---|---|
| ISO/IEC 27017 | クラウドサービス固有の情報セキュリティ管理策と実施手引を示す国際規格です。単独の国内認証基準そのものではありません。 |
| JIS Q 27017 | ISO/IEC 27017:2015に対応する日本産業規格です。国内実務ではJIP-ISMS517の要求と併せて確認します。 |
| ISMS | 情報資産の機密性、完全性、可用性を守るため、リスク評価、管理策選定、運用、内部監査、継続的改善を行う仕組みです。 |
| JIP-ISMS517 | ISO/IEC 27017:2015に基づくISMSクラウドセキュリティ認証に関する国内要求事項です。クラウドサービス名、立場、リスク評価、適用宣言書への反映を確認します。 |
| CSPとCSC | CSPはクラウドサービスを提供する事業者、CSCは利用する組織です。SaaS事業者が外部IaaSを使う場合は、双方の立場を持つことがあります。 |
| 認証と認定 | 認証は認証機関による適合性の審査証明です。認定は認証機関の適格性を認定機関が確認する仕組みです。 |
CSPとCSCの区別は、SaaS、PaaS、IaaSの区分だけで決まりません。自社が顧客にクラウドサービスを提供し、その基盤として別のクラウドを利用する場合、自社は顧客との関係ではCSP、基盤クラウドとの関係ではCSCになります。この二重の立場は、責任分界、通知、ログ、再委託、個人情報保護法上の安全管理措置に影響します。
単独認証ではなく、ISMSをクラウド固有の管理策で拡張する認証として捉えます。
国内制度では、JIS Q 27001又はISO/IEC 27001に基づくISMS認証を取得している、又は取得する組織に対して、その適用範囲内のクラウドサービスの提供又は利用について、ISO/IEC 27017:2015のクラウド固有管理策が追加で特定され実施されていることを認証します。
ISO/IEC 27017はガイドライン規格であり、国内制度の要求事項はJIP-ISMS517です。そのため、契約書に認証維持とだけ書くのではなく、対象範囲、立場、認証基準、有効期限、認証機関、失効時の通知を具体化します。
登録証は、認証の有無ではなく、どの範囲で何が審査されたかを読む資料です。次の一覧は登録証で確認する項目と読み取り方を示しており、取引期間や委託先管理の合理性に直結する点を確認できます。
| 確認項目 | 読み取るポイント |
|---|---|
| 認証取得組織名 | 契約相手方、グループ会社、販売代理店、実運用主体を取り違えていないか確認します。 |
| 適用範囲 | 対象サービス名、事業所、開発、運用、サポート、データ処理が含まれるか確認します。 |
| 立場 | クラウドサービスプロバイダ、クラウドサービスカスタマ、又は両方のどれか確認します。 |
| 認証基準 | JIP-ISMS517-1.0への適合が記載されているか確認します。 |
| 基礎となるISMS | JIS Q 27001又はISO/IEC 27001認証が有効か、ISO/IEC 27001:2022への対応状況も確認します。 |
| 認証機関 | ISMS-ACが認定した認証機関か確認します。 |
| 有効期限と状態 | 取引期間をカバーするか、一時停止、取消し、範囲縮小がないか確認します。 |
ISMSクラウドセキュリティ認証は、製品又はサービスそのものの品質を保証するものではなく、組織のマネジメントシステム認証です。認証は安全性を高める有力な証拠ですが、事故が起きないこと、脆弱性が存在しないこと、すべての顧客データが常に完全に保護されることを保証するものではありません。
ISO/IEC 27001:2022への対応では、JIP-ISMS517-1.0の要求事項自体に大きな移行がない場合でも、基礎となるISMS認証、適用宣言書、JIS Q 27017:2016の管理策との対応を確認します。買収監査、IPO準備、金融機関の外部委託管理では、登録証だけでなく適用宣言書の更新状況も重要です。
クラウドの本質的特徴を踏まえ、通常の情報セキュリティ管理策を契約実務へつなげます。
NISTは、クラウドコンピューティングを、共有された構成可能なコンピューティング資源へネットワーク経由でオンデマンドにアクセスでき、少ない管理労力又はサービス提供者とのやり取りで迅速に提供・解放できるモデルとして説明しています。クラウドモデルは、5つの本質的特徴、3つのサービスモデル、4つの配置モデルで整理されます。
次の重要ポイントは、オンプレミス環境と比べてクラウドで管理責任が分散しやすい領域を示します。契約担当者にとって重要なのは、どのリスクがプロバイダ側、カスタマ側、又は双方の管理にまたがるかを読み取ることです。
インフラ、プラットフォーム、アプリケーションの管理責任が複数当事者に分かれます。
複数顧客のデータと処理が論理的に分離されるため、分離統制と誤設定防止が重要です。
機能追加、サポート終了、リージョン変更が顧客のリスク評価を変えることがあります。
事故時のログ、証拠、復旧作業を顧客単独で完結できない場合があります。
ISO/IEC 27017の詳細な規格本文は規格文書で確認しますが、実務上は次の管理領域が特に重要です。この一覧は、管理策の名称だけでなく、法務、監査、契約に落とし込む視点を読み取るために使います。
| 領域 | 法務・監査上の意味 |
|---|---|
| 役割と責任 | プロバイダとカスタマの責任分界を契約、運用手順、証跡へ落とし込みます。 |
| 利用方針 | どの業務と情報をクラウドに載せるか、禁止事項と承認手順を明確にします。 |
| サプライヤ関係 | 再委託、基盤クラウド、データセンター、サポート拠点を管理します。 |
| 情報資産管理 | 顧客データ、ログ、バックアップ、メタデータ、設定情報の所在と取扱いを定義します。 |
| アクセス管理 | 管理者権限、特権ID、サポートアクセス、APIキーを統制します。 |
| 暗号化・鍵管理 | 暗号化範囲、鍵の生成、保管、ローテーション、削除、顧客管理鍵の有無を確認します。 |
| ログ・監視 | インシデント調査、監査、紛争対応に耐えるログ取得と保全を設計します。 |
| データ返却・削除 | 契約終了、移行、バックアップ消去の証跡と責任を定義します。 |
| 可用性・事業継続 | SLA、RTO、RPO、リージョン障害、復旧試験を契約と運用へ反映します。 |
責任共有モデルは営業資料だけでは足りません。基本契約、サービス仕様書、SLA、セキュリティ仕様書、データ処理契約、再委託一覧、責任共有表、インシデント通知手順、ログ提供手順、データ削除証明手順、登録証、適用範囲文書、外部監査報告書の整合性を確認します。
対象外サービス、グループ会社、海外法人、販売代理店、海外証明書の取り扱いを確認します。
営業資料にISO27017取得済みと記載されていても、登録証では対象が特定サービス、特定事業所、特定提供形態に限定されていることがあります。複数SaaSのうち一部だけが範囲内である場合や、開発部門は範囲内でもサポート部門や外部委託の運用監視センターが実質的に範囲外となる場合があります。
認証範囲の確認は、委託先選定の合理性、取締役・管理職の注意義務、個人情報保護法上の安全管理措置、事故時の責任追及に影響します。そのため、取得有無ではなく、利用予定サービス、機能、データ処理、サポート、運用、再委託まで認証対象に含まれるかを確認します。
次の判断の流れは、認証表示を見た後に確認する順番を示します。上から順に、主体、サービス、立場、補足資料、海外証明書を確認することで、範囲外のリスクを早く見つけられます。
契約相手方、実運用主体、販売代理店、海外本社のどれかを見ます。
利用予定のサービス、オプション、API、サポートが含まれるかを見ます。
提供者、利用者、又は双方のどれで認証されているかを見ます。
範囲証明、認証機関への照会、表明保証を検討します。
維持義務、失効通知、変更通知を契約へ反映します。
グローバルクラウドでは、契約相手方、サービス運営主体、データ処理主体、サポート提供会社、請求主体が異なることがあります。日本法人の認証だけでは海外本社のサービス運用を十分に評価できない場合があり、海外本社の認証だけでは日本法人のサポート、オンボーディング、データ移行、顧客管理が範囲外になる場合があります。
海外のISO/IEC 27017証明書は、国内のISO27017クラウドセキュリティ認証と同一とは限りません。認証機関、認定機関、基準文書、審査範囲、審査方法、失効確認方法を個別に確認し、必要に応じてSOC 2、ISO/IEC 27001、ISO/IEC 27018、第三者監査報告、セキュリティホワイトペーパーを併用します。
プロバイダ、カスタマ、双方の立場を分けて、契約責任と運用責任を確認します。
クラウドサービスプロバイダは、顧客に対して安全にサービスを提供するため、セキュリティ設計、データ保存場所、論理分離、管理者アクセス、サポートアクセス、脆弱性管理、変更管理、インシデント通知、ログ、バックアップ、データ返却・削除、再委託、法令対応を説明できる体制を整えます。
クラウドサービスカスタマは、認証済みサービスを使うだけで安全管理義務を履行したことにはなりません。利用目的、保存データ分類、利用承認、ID管理、多要素認証、端末保護、設定ミス防止、暗号化設定、権限棚卸し、退職者・異動者のアクセス削除、ログ監視、契約終了時の確認が残ります。
次の比較一覧は、プロバイダとカスタマに残りやすい責任を分けたものです。どちらか一方に寄せて考えると契約上の空白が生じるため、各行で誰が説明し、誰が実施し、誰が証跡を保管するかを読み取ります。
| 区分 | 主な責任 | 契約上の確認 |
|---|---|---|
| プロバイダ | 基盤、サービス設計、論理分離、サポートアクセス、ログ提供、バックアップ、再委託管理を説明します。 | 仕様書、SLA、再委託一覧、事故通知、ログ提供、データ削除証明を確認します。 |
| カスタマ | ユーザー管理、設定、データ分類、アクセス権、端末、業務運用、個人情報保護対応を実施します。 | 社内規程、承認手順、管理者権限、MFA、棚卸し、退職者処理を確認します。 |
| 双方 | 事故通知、証拠保全、復旧、当局報告支援、データ移行、責任共有表を連携します。 | 通知期限、費用負担、調査協力、公表調整、契約終了時の責任分界を確認します。 |
SaaS事業者が外部IaaSを利用する場合など、クラウドサービスを提供しながら他のクラウドを利用する企業は、CSPとCSCの双方の立場を適用範囲に含めることが求められる場合があります。顧客へのSLA、漏えい通知、データ削除、監査対応を、基盤クラウドとの契約で裏付けられるかを検証します。
認証維持、失効通知、仕様変更、事故通知、再委託、データ削除を具体化します。
契約書では、受託者が対象サービスについてJIP-ISMS517に基づくISMSクラウドセキュリティ認証、又はこれと同等以上の情報セキュリティ管理体制を契約期間中に維持し、適用範囲、認証機関、有効期限、CSP又はCSCとしての立場を示す文書を提示する形に整理します。
同等以上という文言を使う場合は、ISO/IEC 27001、SOC 2 Type 2、ISMAP、ISO/IEC 27018、第三者ペネトレーションテスト、脆弱性管理報告、内部監査結果などのどれをどの範囲で評価するかを定義します。性質が異なる制度を単純に置き換えないことが重要です。
次の比較一覧は、契約レビューで条項化する主要論点を示します。認証取得の一文だけでは不足するため、各行の通知、資料提出、権利、支援を契約本文や別紙へどう配置するかを読み取ります。
| 条項 | 確認する内容 | 不足時のリスク |
|---|---|---|
| 認証維持 | 対象サービス、基準、認証機関、有効期限、範囲文書を明示します。 | 認証外サービスを範囲内と誤認するおそれがあります。 |
| 失効・範囲縮小通知 | 一時停止、取消し、更新不能、重大不適合を知った場合の通知期限を定めます。 | 委託先管理とリスク評価の見直しが遅れます。 |
| 仕様変更 | セキュリティ仕様書の優先順位、重大変更の事前通知、猶予期間を定めます。 | 顧客側設定やリスク評価が置き去りになります。 |
| インシデント通知 | 通知対象、期限、初報内容、続報、報告支援、証拠保全、公表調整を定めます。 | 法令報告や本人通知に必要な情報が不足します。 |
| 再委託・基盤クラウド | 範囲、国・地域、アクセス可能データ、変更通知、再々委託、削除を定めます。 | サプライチェーン上の事故や越境アクセスを把握できません。 |
| データ返却・削除 | 返却形式、期限、削除対象、バックアップ削除、ログ、削除証明、移行支援を定めます。 | 契約終了後のデータ残存や移行不能が争点になります。 |
インシデント通知条項では、不正アクセス、マルウェア、ランサムウェア、設定ミス、内部不正、可用性障害、漏えいのおそれを含めるかを確認します。通知期限は、個人情報保護委員会への速報や確報に間に合うよう、発覚後の時間単位で定めることが実務的です。
再委託条項では、基盤クラウド、監視、サポート、決済、メール配信、CDN、データ分析、AI機能の関与を確認します。再委託先一覧を入手するだけではなく、アクセスできるデータ、認証・監査状況、変更時の通知、事故時の情報提供義務まで確認します。
クラウド例外、安全管理措置、漏えい等報告、外的環境の把握を分けて確認します。
個人情報保護委員会のFAQでは、クラウドサービス利用が本人同意を要する第三者提供又は委託に該当するかは、保存データに個人データが含まれるかではなく、クラウドサービス提供事業者が個人データを取り扱うこととなっているかで判断すると説明されています。
クラウドサービス提供事業者が個人データを取り扱わないこととなっている場合、本人同意は不要であり、委託先監督義務も課されないとされます。ただし、契約条項で個人データを取り扱わない旨が定められ、適切なアクセス制御が行われている場合などが前提です。ISO27017クラウドセキュリティ認証の取得だけで、自動的にこの扱いが認められるわけではありません。
次の判断の流れは、個人情報保護法上のクラウド利用を整理する順番を示します。認証は安全管理措置の説明資料として有用ですが、委託該当性や本人への情報提供義務を置き換えない点を読み取ります。
契約条項、アクセス制御、サポート権限、ログ閲覧権限を見ます。
本人同意、委託先監督、クラウド例外の前提を分けます。
アクセス制御、暗号化、ログ、障害対応、データ保存国、削除方法を見ます。
所在国、サポート国、再委託先国、速報・確報に必要な情報を確認します。
委託先監督義務が課されない場合でも、利用企業には自ら果たすべき安全管理措置が残ります。クラウドサービスのセキュリティ、アクセス制御、暗号化、ログ、障害対応、データ保存国、契約終了時削除を確認する必要があります。
報告対象となる漏えい等が発生した場合、クラウドサービス提供事業者が個人データを取り扱わないこととなっているケースでは、利用企業が報告義務を負うと説明されています。個人情報保護委員会は、発覚後速やかな速報、原則30日以内の確報、不正目的のおそれがある場合の60日以内の確報を案内しています。クラウド事業者からの初報と続報が遅れると、利用企業は報告期限を守れない可能性があります。
外国にある第三者のクラウドサービスを利用する場合、日本国内サーバに保存されるケースでも、外国における個人情報保護制度等を把握したうえで安全管理措置を講じる必要があるとされています。リージョン、サーバ所在国、サポートアクセス国、再委託先国、ログ保存国、バックアップ保存国、生成AI機能の学習利用有無を確認します。
認証は免責ではなく、ログ、証拠、期限、連携体制を確認する出発点です。
認証を取得していても、事故は起こり得ます。重要なのは、事故時に、誰が、どのログを、どの期限で、どの形式で、どの法的責任のもとに提供するかです。セキュリティ、法務、個人情報保護、広報、経営、内部監査、デジタルフォレンジック、外部専門家、保険、顧客対応の連携が求められます。
個人情報保護委員会は、不正アクセスによる個人データ漏えい、マルウェア感染による不審通信、第三者からの漏えいのおそれの連絡、ランサムウェアにより個人データが暗号化され復元できない場合などを、報告が必要になり得る例として示しています。クラウドでは、設定ミスによりインターネット上で個人データが閲覧可能になる事例も重大です。
次の一覧は、事故発生時に統合する部門と役割を示します。部門ごとの役割を事前に分けておくことで、初動で証拠を失わず、法令報告と顧客説明に必要な情報を読み取れます。
検知、封じ込め、復旧、ログ保全、脆弱性対応を担います。
検知保全契約評価、報告要否、本人通知、当局対応、紛争リスクを整理します。
報告期限対外説明、プレスリリース、顧客FAQ、意思決定記録を管理します。
公表判断フォレンジック調査、サイバー保険通知、費用負担、証拠提出を整理します。
調査費用クラウドの事故では、プロバイダの事故なのか、カスタマ設定ミスなのかが争点になりやすいです。ストレージ公開設定、ID管理連携、APIキー漏えい、過大な管理者権限、監査ログ未設定はカスタマ側の管理不備と評価される場合があります。一方、基盤脆弱性、テナント分離不備、内部者アクセス、運用ミス、サポート機能の不備はプロバイダ側の統制不備となり得ます。
証拠保全では、顧客が取得できるログ、プロバイダ内部ログの提供可否、保存期間、タイムスタンプ、APIログ、認証ログ、管理者操作ログ、サポートアクセスログ、保全依頼手続、フォレンジック協力、法的手続への対応、費用負担を契約前に確認します。
ISO/IEC 27001、ISO/IEC 27018、SOC 2、ISMAP、サイバーセキュリティ経営ガイドラインを目的別に使い分けます。
ISO/IEC 27001はISMSの中心的な要求事項です。ISO27017クラウドセキュリティ認証はこれを前提に、クラウド固有の責任分界、マルチテナント、仮想化、データ削除、クラウド契約、顧客・提供者関係を追加的に扱います。
次の比較一覧は、関連制度を目的別に整理したものです。登録証の種類だけで優劣を決めるのではなく、対象が組織、サービス、個人情報、運用統制、政府調達のどれに近いかを読み取ります。
| 制度 | 主な焦点 | 実務上の使いどころ |
|---|---|---|
| ISO/IEC 27001 | 情報セキュリティマネジメントシステムの要求事項です。 | 全社的な情報セキュリティ管理、委託先管理、内部統制の基礎資料として使います。 |
| ISO/IEC 27017 | クラウドサービス固有の情報セキュリティ管理策です。 | CSPとCSCの責任分界、クラウド契約、ログ、削除、再委託を確認します。 |
| ISO/IEC 27018 | パブリッククラウドでPIIを処理するプロバイダ向けの保護ガイダンスです。 | HRTech、医療、教育、金融、マーケティングクラウドで個人情報保護の補強資料として使います。 |
| SOC 2 Type 2 | 一定期間の統制運用状況を保証報告として確認します。 | NDA下で詳細な統制、例外事項、運用実績を読み解く場面に向きます。 |
| ISMAP | 政府情報システム向けのクラウドサービスセキュリティ評価制度です。 | 公共案件や政府調達で、サービス単位の登録状況を確認します。 |
| サイバーセキュリティ経営ガイドライン | 経営者主導の体制、人材、サプライチェーン、インシデント対応を整理します。 | 認証取得だけで代替せず、経営判断と投資説明の枠組みとして使います。 |
SOC 2 Type 2報告書は、一定期間にわたる統制の運用状況を確認できる点で有用です。一方、通常はNDAのもとで提供され、記載範囲や例外事項の読み解きが必要です。ISO27017クラウドセキュリティ認証は対外的に示しやすい一方、登録証だけでは詳細な統制運用までは分かりません。
公共案件ではISMAP、民間B2B SaaSではISO27017、グローバル案件ではSOC 2やISO/IEC 27001、個人情報を重く扱う案件ではISO/IEC 27018を組み合わせると、説明の粒度を補完しやすくなります。
目的、範囲、立場、ギャップ、リスク評価、法務文書、内部監査、審査対応を順に整えます。
取得を目指す企業では、営業上の信頼獲得、公共案件、規制業種への販売、グローバル顧客への説明、内部統制強化、事故対応力向上など、目的によって範囲と優先順位が変わります。対象サービス名、提供形態、関係事業所、開発・運用・サポート、基盤クラウド、再委託、データ種類、顧客業種を明確にします。
次の時系列は、認証取得までの主要段階を示します。順番に意味があり、範囲と立場を固める前に文書整備へ進むと手戻りが大きくなるため、各段階で何を決めるかを読み取ります。
取得目的、対象サービス、事業所、データ種類、顧客業種、基盤クラウド、再委託先を整理します。
SaaS、MSP、BPO、生成AI API組込みなど、複雑な立場を早い段階で確認します。
ISMS、社内規程、クラウド利用規程、契約ひな形、アクセス管理、ログ管理、バックアップ、脆弱性管理を確認します。
顧客データ、API連携、外部ID連携、越境、リモートサポート、障害影響、顧客規制業種を踏まえます。
設定、ログ、権限、脆弱性対応、復旧試験、障害訓練、再委託管理、顧客通知記録を確認します。
適用範囲、技術構成、責任分界、リスク評価、証跡、内部監査、レビューを説明し、必要な是正を行います。
法務部門は、クラウドサービス利用規約、法人向け基本契約、データ処理契約、SLA、サポートポリシー、セキュリティホワイトペーパー、再委託先通知ポリシー、インシデント通知ポリシー、データ削除・返却ポリシー、プライバシーポリシー、個人情報取扱規程、外的環境把握資料、顧客向けFAQ、営業資料の認証表示ルールを整備します。
利用企業が質問票、証拠資料、中小企業向けの現実的確認を設計するための観点です。
クラウド利用企業は、ベンダーに対して、登録証、適用範囲、有効期限、認証機関、対象サービス、オプション、API、サポート、データ処理、CSP又はCSCの立場、基盤クラウド、再委託、データ所在地、アクセス管理、ログ、暗号化、脆弱性、事故通知、終了時対応、個人情報対応を確認します。
次の一覧は、質問票で確認する分類と問いを整理したものです。質問を並べるだけではなく、利用予定の業務とデータに照らして、不足している説明や証拠を読み取ることが重要です。
| 分類 | 質問例 |
|---|---|
| 認証 | ISO27017クラウドセキュリティ認証の登録証、適用範囲、有効期限、認証機関を提示できるか確認します。 |
| 対象範囲 | 利用予定のサービス、オプション、API、サポート、データ処理が範囲に含まれるか確認します。 |
| 立場 | 本サービスについてCSP、CSC、又は両方のどれで認証されているか確認します。 |
| 再委託 | 再委託先、再々委託先、サポート拠点、アクセス可能データを説明できるか確認します。 |
| ログ | 顧客が取得できるログ、ベンダーが保管するログ、保存期間、事故時提供可否を確認します。 |
| インシデント | 初報期限、続報、原因調査、再発防止、報告支援、証拠保全を確認します。 |
| 終了時 | データ返却、削除、バックアップ削除、削除証明、移行支援を確認します。 |
証拠としては、ISMSクラウドセキュリティ認証登録証、ISO/IEC 27001登録証、適用範囲説明書、セキュリティホワイトペーパー、SOC 2 Type 2報告書、ISO/IEC 27018関連資料、ISMAP登録状況、脆弱性診断サマリー、ペネトレーションテストサマリー、SLA実績、インシデント履歴、再委託先一覧、データ所在地資料、責任共有表、監査ログ仕様、データ削除手順書が有用です。
中小企業では、すべてのベンダーに詳細監査を行うことは難しい場合があります。次の重要ポイントは、最低限の確認を絞ったものです。リスクが高い情報を扱う場合は、この範囲にとどまらず、追加の契約交渉と監査を検討します。
登録証と有効期限、対象サービス、管理者権限と多要素認証、個人情報・営業秘密の保存可否、事故通知先と期限、データ削除・移行、退職者処理、バックアップ、重要データの経営承認、年1回の棚卸しを確認します。
契約前、契約条項、認証取得側の3場面で確認事項を分けます。
チェックリストは、認証表示を確認した後の見落としを防ぐために使います。次の比較一覧では、契約前、契約条項、認証取得側の3場面を分けているため、読者は自社の立場に近い列から確認できます。
| 場面 | 主な確認項目 |
|---|---|
| 契約前 | 法人名、対象サービス、開発・運用・サポート範囲、CSP又はCSCの立場、ISMS有効性、認証機関、有効期限、失効通知、事故通知、個人情報、再委託、ログ、削除、SLA、重要情報の追加審査を確認します。 |
| 契約条項 | 認証維持、範囲明示、登録証提出、重大変更通知、範囲縮小通知、セキュリティ仕様書、責任共有表、再委託、データ所在地、個人情報保護、初報・続報、報告支援、証拠保全、監査権、脆弱性対応、移行支援、削除証明、責任制限の例外、秘密保持、制裁・輸出管理、準拠法を確認します。 |
| 認証取得側 | 目的、対象サービス名、CSP又はCSCの立場、基盤クラウド、再委託、ギャップ分析、リスクアセスメント、適用宣言書、契約・SLA・セキュリティ仕様書、事故通知・証拠保全、内部監査、経営レビュー、表示ルール、維持審査と変更管理を確認します。 |
契約前チェックでは、登録証の法人名が契約相手方又は実運用主体と一致するか、当社が利用するクラウドサービス名が範囲に含まれるか、失効・一時停止・範囲縮小時の通知条項があるかを優先します。営業秘密、重要情報、規制対象情報を保存する場合は、標準的な確認だけで足りるかを慎重に見ます。
認証取得側では、営業資料の表示ルールも重要です。ISO27017取得済みと表示する場合は、対象サービス、認証範囲、認証基準、登録証番号を確認できる導線を用意し、範囲外サービスまで認証済みであるように見せない設計が必要です。
誤解されやすい点を、一般的な制度説明として整理します。
一般的には、ISO/IEC 27017はクラウド固有の管理策と手引を示すガイドライン規格とされています。国内のISMSクラウドセキュリティ認証では、JIP-ISMS517が要求事項として位置付けられます。具体的な認証範囲や基準文書は登録証と認証機関の情報で確認する必要があります。
一般的には、認証はリスク管理と管理策運用の仕組みが審査されたことを示しますが、事故ゼロを保証するものではありません。事故時の通知、ログ提供、証拠保全、復旧、報告支援は契約条項と運用実態によって変わります。
一般的には、ISMSクラウドセキュリティ認証は組織のマネジメントシステム認証であり、製品又はサービスそのものの品質保証ではありません。対象サービス名と適用範囲を登録証で確認する必要があります。
一般的には、全サービスが対象とは限りません。登録証や適用範囲文書に対象クラウドサービス名、事業所、運用、サポート、再委託が含まれるかを確認します。範囲外サービスを範囲内と扱うと、委託先管理や事故対応で問題になる可能性があります。
一般的には、カスタマ側にもユーザー管理、設定、データ分類、アクセス制御、個人情報保護、ログ監視などの責任が残ります。具体的な責任分界はサービスモデル、契約、責任共有表、利用方法によって変わります。
一般的には、委託先監督義務が課されない場合でも、利用企業は自らの安全管理措置として適切な措置を講じる必要があります。アクセス制御、契約条項、ログ、暗号化、データ所在地、外的環境の把握などを確認します。
一般的には、同一とは限りません。認証機関、認定機関、基準文書、審査範囲、失効確認方法を個別に確認し、必要に応じてSOC 2、ISO/IEC 27001、ISO/IEC 27018、第三者監査報告を併用します。
制度理解と実務確認に用いた公的・中立的資料です。