ISMSクラウドセキュリティ認証とは｜ISO/IEC 27017の取得要件と2026年改訂動向

ISMSクラウドセキュリティ認証（ISO/IEC 27017）は、ISMS（ISO/IEC 27001）認証を取得した組織が、その範囲内のクラウドサービスについてクラウド固有の管理策を実施していることを証明する、上乗せ型の第三者認証です。認証基準はISMS-ACが定めるJIP-ISMS517-1.0で、ISMSを取得していない組織は単独では取得できません。この記事では、規格と制度の仕組み、ISO/IEC 27001・27018・ISMAPとの違い、取得の流れと費用、そして2026年に発行段階へ進んだ改訂版の動向までを、現行版と改訂版を区別して整理します。クラウドを提供する事業者だけでなく、クラウドを利用する企業がカスタマの立場で取得・評価する観点も扱います。

まとめ：ISMSを前提にクラウド固有管理策を証明するアドオン認証の全体像

ISMSクラウドセキュリティ認証は、ISMS（ISO/IEC 27001）認証の範囲内で、クラウドサービスの提供または利用に固有の管理策が実施されていることを、ISMS-ACの認証基準JIP-ISMS517-1.0に基づいて証明する認証です。ISMSのアドオン（上乗せ）認証であり、ISMSを持たない組織が単独で取得することはできません。取得すると、取引先からの要求や入札の加点条件に応えやすくなり、クラウドの安全性を対外的に示せます。

一方で、行政機関や自治体のシステム調達を主目的にするなら、ISO/IEC 27017ではなく政府の評価制度ISMAPの登録が本筋です。目的を取り違えると、費用をかけても狙った調達にはつながりません。

規格面では注意が要ります。現行はISO/IEC 27017:2015で、ISMSに追加されるクラウド固有の管理策は7つです。改訂版（第2版）は2026年6月にFDIS（最終国際規格案）の投票を終え、発行段階に入りました。新規に取得するなら、前提となるISMSは2022年改訂版（附属書A 93管理策）に2024年の気候変動に関する追補を加えた最新の構成で組み立てます。

ISMSクラウドセキュリティ認証の位置づけとISO/IEC 27017が定めるクラウド固有管理策

ISMSに上乗せしクラウドの提供・利用の安全性を証明するアドオン認証という性格

ISMSクラウドセキュリティ認証は、情報セキュリティ全般を対象とするISMS（ISO/IEC 27001）に、クラウドサービス特有の管理策を上乗せして審査する仕組みです。ベースはあくまでISMSであり、クラウド分野だけを切り出して認証する制度ではありません。審査機関の説明でも、ISMSが一時停止・取り消し・範囲縮小となれば、クラウド側の認証もそれに連動すると明示されています。土台のISMSが揺らげば、認証全体が揺らぐ構造です。

ISO/IEC 27002を補完するクラウド向け実践規範というISO/IEC 27017の役割

ISO/IEC 27017は、情報セキュリティ管理策の実践規範であるISO/IEC 27002を、クラウドサービス向けに補う位置づけのガイドライン規格です。ISO/IEC 27002が示す管理策のうちクラウドに関係するものへ追加の手引を与え、さらにクラウド固有の管理策を加えます。国内では2016年にJIS Q 27017:2016として規格化されました。要求事項そのものを定める「マネジメントシステム規格」ではなく、実践の手引を示す「規範（code of practice）」である点が、ISO/IEC 27001との根本的な違いです。

現行2015年版がISMSに追加する7つのクラウド固有管理策の中身

現行のISO/IEC 27017:2015は、ISO/IEC 27002のクラウド関連管理策に加えて、クラウド固有の管理策を7つ追加します。実務でまず効くのは、提供者と利用者の責任分界に関わる項目です。

• クラウドサービス利用における、利用者と提供者の役割・責任の明確化
• 仮想環境の分離（テナント間でデータや処理が混ざらないようにする分離）
• 仮想マシンの要塞化（不要な機能を止め攻撃面を減らす設定）
• 管理者の運用手順とその操作の監視
• 利用者によるクラウドサービスの監視（ログ・アラートの取得）
• 仮想ネットワークと物理ネットワークのセキュリティ管理の整合
• 解約時のクラウド利用者アセットの撤去（データの返却・削除）

これらは並列に「全部やる」ものではなく、自社が提供者か利用者かで重点が変わります。提供者なら分離と要塞化、利用者なら責任分界の確認とログ監視から着手するのが現実的です。なお、この7という数は改訂版で見直される見込みで、詳細は後半の章で扱います。

JIP-ISMS517を基準とする認証制度の仕組みとCSP・CSCという適用対象

認証基準JIP-ISMS517-1.0とJIPDEC・ISMS-ACが担う認定と審査の役割分担

認証基準は、JIPDECが策定した「ISO/IEC 27017:2015に基づくISMSクラウドセキュリティ認証に関する要求事項（JIP-ISMS517-1.0）」です。ガイドラインであるISO/IEC 27017の管理策を、審査できる「要求事項」の形に落とし込むためにJIPDECが用意した日本独自の基準で、基本的に国内のISMS認証組織を対象にしています。認定機関はISMS-AC（情報マネジメントシステム認定センター）で、2018年4月にJIPDECから独立して法人化しました。実際に審査・登録を行う認証機関を、ISMS-ACがISO/IEC 17021-1やISO/IEC 27006に基づいて認定します。

ISMS（ISO/IEC 27001）取得を前提とし単独では取得できない制度上の制約

取得を希望する組織は、JIP-ISMS517とISO/IEC 27001の両方に適合する必要があります。順序として、ISMS認証を取得している（または同時に取得する）ことが前提で、クラウド認証だけを先に取ることはできません。ここでつまずくのが、ISMSを構築しないままクラウドの認証取得に動いてしまうケースです。土台がない状態では審査に入れず、結局ISMSの構築から仕切り直しになります。前提となるISMSの構築・運用は、ISMS運用の年間スケジュールと内部監査・更新審査の進め方もあわせて確認すると、取得後の維持まで見通せます。

提供者・利用者・両方という3つの適用対象と適用範囲に立場を明記する考え方

対象となるのは、クラウドサービスを提供する組織（クラウドサービスプロバイダ／CSP）、利用する組織（クラウドサービスカスタマ／CSC）、その両方にあたる組織です。たとえば他社のIaaSを使って自社のSaaSを提供している事業者は、CSPでありCSCでもあります。JIP-ISMS517-1.0は、自組織がどの立場で認証を受けるのかを適用範囲に明記することを求めています。立場が曖昧なままだと、確認すべき管理策の範囲が定まらず、審査でも適用範囲の指摘を受けやすくなります。

ISO/IEC 27001・27018・ISMAPとの違いと、目的別に見た取得制度の使い分け基準

ISO/IEC 27001（ISMS）との違いは母体規格と上乗せ規格という関係

ISO/IEC 27001（ISMS）は、組織が扱う情報資産全般を対象に、マネジメントシステムの要求事項を定める規格です。これに対しISO/IEC 27017は、その範囲内のクラウドサービスに固有の管理策を上乗せします。母体と上乗せの関係なので両者は競合せず、ISMSがあって初めてクラウド認証が成り立ちます。ISO/IEC 27001が「情報セキュリティ全体の仕組み」を問うのに対し、ISO/IEC 27017は「クラウド特有のリスクに、その仕組みのなかでどう対応しているか」を問う、と整理すると違いがつかめます。

ISO/IEC 27018との違いはクラウド全般の管理策と個人情報保護という守備範囲

ISO/IEC 27018は、パブリッククラウドで個人を特定できる情報（PII）を取り扱う際の保護に焦点を当てた規範です。ISO/IEC 27017がクラウドのセキュリティ全般を扱うのに対し、ISO/IEC 27018は個人情報の保護に守備範囲を絞ります。クラウド事業者が信頼性を示すため、両方を取得する例は珍しくありません。なお、個人情報の保護を国内向けに示す制度としてはプライバシーマーク（Pマーク、JIS Q 15001:2023）もあり、目的が近いぶん混同されがちです。違いはプライバシーマーク取得の流れと審査基準と照らすと整理できます。

ISMAPとの違いは国際的な任意認証と政府調達の登録制度という目的の差

最も混同されやすいのがISMAPとの違いです。ISMAP（政府情報システムのためのセキュリティ評価制度）は、各府省庁がクラウドを調達する際の登録制度で、登録サービスは政府の統一基準で評価されます。ISO/IEC 27017が国際規格に基づく任意の第三者認証であるのに対し、ISMAPは政府調達の前提という、目的も審査の観点も異なる制度です。実務では、ISO認証の審査とISMAPの監査は要求の粒度が大きく離れており、片方を取れば他方が不要になる関係ではありません。主要な4つの位置づけを並べると違いが見えます。

政府・自治体のシステムを利用してもらう前提で評価されたいなら、登録先はISMAPです。クラウドの利用・調達がガバメントクラウドに関わる場合の前提条件は、ガバメントクラウドとISMAP登録の前提条件で具体的に確認できます。

政府調達が主目的ならISMAPを優先し取得を見送るべき条件

取得を見送ってよい場面もはっきりさせておきます。狙う取引が官公庁・自治体のクラウド調達に偏っているなら、ISO/IEC 27017だけを取っても入札の土俵に上がれません。この場合はISMAP登録を優先します。逆に、民間取引で「クラウドの安全性を第三者に示したい」「入札の加点を取りたい」という目的なら、ISO/IEC 27017が効きます。判断軸は単純で、評価する相手が政府ならISMAP、民間ならISO/IEC 27017、両にらみなら両方を検討する、という順で考えると外しません。

取得メリットとクラウド利用企業がカスタマの立場で行う取得・取引先評価の判断

取引先要求や入札加点という、取得が事業機会に直結するメリット

取得の実利は、対外的な信頼の証明にあります。大手企業や官公庁との取引では、委託先や利用するクラウドの選定時に情報の取り扱いを厳しく見る運用が広がっており、ISMS認証やISMSクラウドセキュリティ認証が取引・入札参加の条件、あるいは加点要素になっている例があります。裏を返せば、認証を持つことで参入できる取引が増えるということです。クラウド固有のリスクに管理策で対応していることを、契約交渉の場で口頭ではなく第三者認証として示せる点が強みになります。

取得組織は約660社という現状と、取得が進む企業の傾向

取得の広がりは数字でも確認できます。ISMS-ACの登録ベースで、ISMSクラウドセキュリティ認証の取得組織は2025年5月時点で約660組織でした。SaaSやマネージドサービスを提供する事業者を中心に、年々増加する傾向にあります。最新の組織数や具体的な取得企業は、ISMS-ACが公開する「ISMSクラウドセキュリティ認証取得組織検索」で随時確認できます。母数が数百規模にとどまる現状は、裏返せば早期取得が同業との差別化につながる余地が残っていることを意味します。

AWS等が取得済みのとき利用企業がカスタマとして重ねて取る意味

ここで見落とされがちなのが、クラウドを「利用する側」の視点です。AWSやMicrosoft Azure、Google CloudといったプラットフォームはISO/IEC 27017を取得済みですが、それは基盤側の話にとどまります。その上で自社サービスを組み立て、顧客にクラウドとして提供しているなら、自社はCSPであり、同時に基盤を使うCSCでもあります。基盤事業者の認証は、自社の認証を代替しません。利用するクラウドのセキュリティを自社の責任範囲としてどう管理しているかは、別途カスタマの立場で示す必要があります。

取引先のISO/IEC 27017取得を自社の調達基準へ落とす判断軸

調達する側として、取引先のISO/IEC 27017取得をどう評価するかも実務的な論点です。相手が利用クラウドについてISMSクラウドセキュリティ認証を取得していれば、ISO/IEC 27017に沿って提供できる仕組みがあると判断でき、自社からの確認の手間を一定程度省けます。未取得なら、第三者監査の結果やSLAでセキュリティ事項を確認し、不足は自社側の管理策で補うことになります。「認証の有無」を二択で見るのではなく、自社が負うリスクのうちどこまで相手に委ねられるか、という観点で評価するのが実務的です。

認証機関の選定から審査までの取得ステップと費用・期間・適用範囲設計の実務

認証機関の選定から審査までの取得ステップとISMSとの取得順序

取得の進め方は、ISMSをすでに持っているかどうかで変わりますが、骨格は共通です。

1. ISMS-ACが認定した認証機関を選定する（クラウド分野の認定を受けた機関に限る）
2. 自組織がCSP・CSCのどちらか（または両方）かを決め、適用範囲を確定する
3. ISO/IEC 27017の管理策に対する現状を確認し、不足を洗い出す（フィット＆ギャップ）
4. 不足する仕組み・規程・運用を整備し、一定期間運用して記録を残す
5. 認証機関の審査（第一段階・第二段階）を受け、適合すれば登録される

ISMSを未取得なら、ISMSの構築・審査と並行して進めるのが効率的です。すでにISMSがあるなら、既存の規程をクラウド用に拡張する作業が中心になります。

費用を左右する要因とISMS同時取得・後追い取得で変わる工数の目安

費用と期間は、組織規模・認証範囲・ISMSの取得状況で大きく変わります。明確なのは、ISMSと同時に取得するか、ISMS取得後に後追いで取るかで工数が変わる点です。同時取得なら審査や構築を一体で進められ、後追いなら既存ISMSへの追加分が中心で、定期審査（サーベイランス審査）や更新審査に合わせると追加工数を抑えられます。一律の相場を鵜呑みにせず、複数の認証機関に自社の適用範囲を前提とした見積もりを取り、構築にかかる社内工数まで含めて比較するのが確実です。

適用範囲でCSP・CSCの立場を明記する設計と適用宣言書・内部監査の実務

審査で差がつくのは、適用範囲の設計と運用の記録です。特に押さえるべき実務は次の点です。

• 適用範囲にCSP・CSCの立場を明記し、対象のクラウドサービスを具体的に特定する
• 適用宣言書で、ISO/IEC 27017の管理策ごとに適用の有無と理由を示す
• JIP-ISMS517-1.0が求める内部監査を、あらかじめ定めた間隔で実施し記録する

外部のデータセンターを使う場合、その範囲の扱いは認証機関への確認が要ります。原則は適用範囲に含めますが、サーバやストレージをすべて委託先管理として管理できていれば、必須ではないと判断されることもあります。

ISO/IEC 27017改訂版の発行段階と現行2015年版から押さえる変更点・移行の考え方

改訂版（第2版）が2026年にFDIS投票を終え発行段階にある進捗

規格の改訂は、取得・更新を考えるうえで避けて通れません。ISO/IEC 27017の改訂版（第2版）は、ISO/IEC JTC1/SC27/WG1で審議が進み、2025年2月にDIS（国際規格案）、2026年4月にFDIS（最終国際規格案）へと進みました。ISOの公式記録では、2026年6月2日にFDISの投票を終え、規格は発行段階に入っています。2026年6月時点では発行直前で、現行のISO/IEC 27017:2015を置き換える予定です。ただし制度として使われるのは、この国際規格がJIS化され、認証基準JIP-ISMS517が改訂されてからで、移行スケジュールはISMS-ACの公表を待つ段階にあります。

拡張管理策の7から4への整理やCSN追加など見込まれる主な変更点

改訂版の変更点は、現時点ではDIS・FDIS段階の分析に基づく見込みであり、確定は発行版の確認が必要です。審査機関の解説では、ISO/IEC 27002:2022（国内はJIS Q 27002:2024）に整合させる更新が中心で、現行7つの拡張管理策が4つへ整理される方向と説明されています。あわせて、CSN（クラウドサービスパートナー）の役割と責任に関する記述が加わる見込みです。管理策の数が減ること自体は要求の緩和を意味せず、ISO/IEC 27002:2022の管理策側へ統合・再配置される面が大きい点に注意が要ります。

現行2015年版での新規取得とISMS前提規格2022年版＋気候変動追補の扱い

では、いま新規に取得するならどう動くか。制度の認証基準JIP-ISMS517-1.0は現行のISO/IEC 27017:2015に基づくため、構築・審査は現行版で進めます。前提となるISMSは、ISO/IEC 27001:2022（国内はJIS Q 27001:2023、附属書A 93管理策）が現行です。2013年版からの移行期限は2025年10月31日で終了しており、いまは2022年版での運用が前提になります。さらに2024年の気候変動に関する追補（ISO/IEC 27001:2022/Amd 1:2024、国内はJIS Q 27001:2025として2025年5月20日に公示）への対応も求められます。改訂版の発行を待つよりも、現行版で取得して運用を回し、発行後に移行する方が、取引や入札のタイミングを逃さずに済みます。

ISMSクラウドセキュリティ認証に関するよくある質問

取得を検討する際に質問が集まりやすい論点を、5つにまとめて簡潔に回答します。

ISO/IEC 27017とISO/IEC 27001（ISMS）の違いは何ですか？

ISO/IEC 27001は組織の情報資産全般を対象に、情報セキュリティマネジメントシステム（ISMS）の要求事項を定める規格です。ISO/IEC 27017は、そのISMSの範囲内にあるクラウドサービスに固有の管理策を上乗せする実践規範です。両者は競合せず、母体のISMSがあって初めてクラウド認証が成立します。ISO/IEC 27017は単独では取得できず、ISMS認証の取得が前提になります。

ISO/IEC 27017は単独で取得できますか？

できません。ISMSクラウドセキュリティ認証は、ISMS（ISO/IEC 27001）認証に上乗せするアドオン認証で、認証基準JIP-ISMS517はISMSとの両方への適合を求めています。ISMSを未取得の組織は、まずISMSを構築・取得する（または同時取得する）必要があります。なお、母体のISMSが一時停止・取り消し・範囲縮小となった場合は、クラウド側の認証もそれに連動します。

ISMSクラウドセキュリティ認証の取得企業数はどれくらいですか？

ISMS-ACの登録ベースで、2025年5月時点の取得組織は約660組織でした。SaaSやマネージドサービスを提供する事業者を中心に、増加傾向が続いています。具体的な企業名や最新の組織数は、ISMS-ACが公開する「ISMSクラウドセキュリティ認証取得組織検索」で確認できます。母数が数百規模である現状は、早期取得が同業との差別化につながりやすいことも示しています。

ISO/IEC 27017とISMAPはどちらを取得すべきですか？

評価する相手で決まります。官公庁・自治体のクラウド調達を狙うなら、政府の評価制度ISMAPへの登録が前提で、ISO/IEC 27017だけでは入札の土俵に上がれません。民間取引でクラウドの安全性を第三者に示したい、入札の加点を取りたいという目的なら、ISO/IEC 27017が有効です。両方の取引を狙うなら、目的ごとに使い分け、両制度の取得を検討します。

ISO/IEC 27017はいつ改訂され、最新版に切り替わりますか？

改訂版（第2版）は2026年6月2日にFDIS（最終国際規格案）の投票を終え、ISOの記録上は発行段階に入っています。2026年6月時点では発行直前で、現行のISO/IEC 27017:2015を置き換える予定です。ただし日本の認証制度で使われるのは、国際規格のJIS化と認証基準JIP-ISMS517の改訂を経てからで、移行スケジュールはISMS-ACの公表を待つ段階です。当面は現行2015年版での取得・運用が続きます。

関連記事

• クラウド・バイ・デフォルト原則と政府のクラウド推進方針：ISMAPを含む政府のクラウド活用の枠組みを、調達側の視点から整理しています。