ISMS（ISO/IEC 27001）の取得を終えたあと、あるいは取得の計画を立てている途中で、取引先から「クラウドの認証は持っていますか」と聞かれることがあります。そこで名前が挙がるのが ISO/IEC 27017 と ISO/IEC 27018 です。
この2つは、ISO 27001 とは別に単独で取る認証ではありません。ISMSを土台にして、その上に積み上げる追加認証です。この構造を理解しないまま見積りを取ると、「27017だけ取りたい」という成立しない要望を審査機関に出すことになります。
本記事では、27017 と 27018 がそれぞれ何を対象にしているのか、ISMSとどう接続するのか、クラウド事業者と利用者で要求が分かれるとはどういうことか、そして医療SaaS・PHR事業者にとって取る意味があるのはどういう場合かを整理します。ISMS全体の位置づけは ISMS（ISO/IEC 27001）とは｜ヘルスケア企業のための完全ガイド をご覧ください。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001・27017・27018 の規格本文および認定機関・審査機関の公表資料が正本です。実際の取得判断はそれらに基づいて行ってください。
2つの規格の位置づけ
まず全体像です。ISO/IEC 27000 シリーズには、認証の対象となる 要求事項規格（27001）と、実施のための 指針・ガイドライン規格 があります。27017 と 27018 は後者、つまりガイドライン規格に分類されます。
にもかかわらず「27017認証」「27018認証」という言い方が通用するのは、ISMS認証の付加認証（アドオン認証）として審査を受けられる仕組みが用意されているためです。国内では ISMS-AC が ISMSクラウドセキュリティ認証としてこの枠組みを運用しています。
| 規格 | 対象 | 位置づけ | 単独取得 |
|---|---|---|---|
| ISO/IEC 27001 | 情報資産全般 | 認証の土台となる要求事項規格 | 可（これが本体） |
| ISO/IEC 27017 | クラウドサービスの情報セキュリティ | 27002 の管理策にクラウド固有の実施手引と追加管理策を加えたもの | 不可（27001が前提） |
| ISO/IEC 27018 | パブリッククラウド上のPII（個人識別情報） | PII処理者としてクラウドを運用する際の実施手引 | 不可（27001が前提） |
ポイントは「27001の適用範囲の中でしか取れない」ことです。ISMSの適用範囲に含まれていないサービスについて、27017 だけを別途取ることはできません。逆に言えば、追加認証を視野に入れているなら、ISMS適用範囲を決める段階で対象サービスを含めておく必要があります。適用範囲の決め方は ISMS適用範囲の決め方 と ヘルスケア企業のISMS適用範囲設計 で扱っています。
ISO/IEC 27017 — クラウド固有の論点を埋める
27017 が扱うのは、オンプレミス前提の管理策では抜け落ちる論点です。仮想化基盤の分離、管理者権限の境界、ログの取得責任、契約終了時のデータ削除といった、「どこまでが自分の責任か」が曖昧になりやすい領域に実施手引を与えます。
大きく2種類の内容で構成されます。
- 27002 の各管理策に対する、クラウド向けの実施の手引（クラウド事業者向け／クラウド利用者向けで別々に書かれる）
- クラウド固有の追加管理策（仮想環境の分離、管理者の運用セキュリティ、モニタリング、資産の返却・削除など）
ここで実務上いちばん重要なのが、クラウドサービスプロバイダ（CSP）とクラウドサービスカスタマ（CSC）で、求められることが別々に書かれているという点です。
| 立場 | 典型的な組織 | 主に問われること |
|---|---|---|
| クラウドサービスプロバイダ（CSP） | SaaS/PaaS/IaaS を提供する事業者 | テナント間の分離、管理者操作の統制と記録、利用者に開示すべき情報の提供、契約終了時のデータ取扱い |
| クラウドサービスカスタマ（CSC） | クラウドを使って自社サービスを運営する組織、クラウドを業務利用する組織 | 利用するクラウドのリスク評価、設定責任の自覚、自社側でのアクセス管理・ログ・暗号鍵の管理 |
医療SaaS事業者の多くは、この両方に同時に該当します。自社の顧客（医療機関）から見れば CSP であり、AWSやAzureから見れば CSC です。認証を取る際も、両方の立場での管理策が審査対象になり得ます。この二重性は責任共有モデルの話と重なるので、AI電子カルテのセキュリティ設計｜責任共有モデル も併せてご覧ください。
ISO/IEC 27018 — クラウド上のPIIを守る
27018 は、パブリッククラウドで他者の個人識別情報（PII）を預かって処理する立場 — すなわち PII処理者 — に向けた実施手引です。誰の情報かというと、クラウドを使っている顧客の、そのまた先にいる個人です。医療SaaSで言えば、医療機関が入力した患者の情報がこれにあたります。
27018 が特徴的なのは、「預かった情報を自分の目的に使わない」ことを強く求める点です。具体的には次のような論点が並びます。
- 預かったPIIを、顧客の指示の範囲を超えて（たとえば広告やマーケティングに）使わないこと
- 再委託先の利用について、顧客に開示し、同意を得る手続を持つこと
- 法執行機関からの開示要請を受けた場合の取扱いと、顧客への通知の考え方
- PIIを保存する国・地域の開示
- 契約終了時のPIIの返却・削除と、その証跡
- PIIにアクセスできる要員の限定と、守秘義務の設定
このため、「あなたのサービスに預けたデータを、あなたが勝手に二次利用しないと証明してほしい」という顧客の懸念に、直接答える認証になります。生成AIの学習利用に対する不安が強い現在、この論点はヘルスケアでとくに刺さりやすくなっています。関連して 医療機関の生成AI利用｜法務・セキュリティの実務ガイド も参考になります。
なお、27018 は個人情報保護法やGDPRの遵守そのものを証明するものではありません。法令対応の枠組みとして整理したい場合は、次項で触れる ISO/IEC 27701 のほうが目的に合います。
27017・27018・27701 の使い分け
追加認証は3つ並ぶと混乱しやすいので、**「誰の、どんな不安に答えるのか」**で切り分けるのが実務的です。
| 規格 | 答える問い | 典型的な取得動機 |
|---|---|---|
| ISO/IEC 27017 | このクラウドサービスは、クラウド固有のリスクに対処できているか | SaaS/PaaSを提供しており、基盤・テナント分離・運用統制を説明する必要がある |
| ISO/IEC 27018 | 預けた個人情報を、事業者が目的外に使わないか | 顧客の個人データを大量に預かる。二次利用への懸念に答えたい |
| ISO/IEC 27701 | 個人情報保護のマネジメントシステムとして成立しているか | GDPR等を含む法令対応の体制を示したい。管理者／処理者の役割を整理したい |
27017 と 27018 は、同時に取得するケースが多い規格です。審査の対象範囲が重なるため、別々に受けるより効率がよいからです。一方 27701 は範囲が広く、取得の負荷も別格になります。詳しくは ISO 27701（PIMS）とは｜個人情報保護とISMSの接続 をご覧ください。
海外取引先が相手の場合は、どの認定機関の認定を受けた審査機関で取ったかが見られることがあります。ISMS-AC・UKAS・ANAB｜認定機関の違いと選び方 で扱っています。
医療SaaS・PHR事業者にとっての判断
「取るべきか」の答えは、取引先が何を見ているかで決まります。ヘルスケア領域では、次のような分岐になりやすいと考えられます。
追加取得が効きやすい場合
- 医療機関・製薬企業の調達仕様書やセキュリティチェックシートで、クラウド固有の管理策（テナント分離、鍵管理、削除証跡）を繰り返し問われている
- 顧客データの二次利用・AI学習利用に関する質問が頻出しており、契約書の文言だけでは納得を得にくい
- 海外の顧客・パートナーがおり、国内認証の説明に手間がかかっている
まずISMS単体で十分な場合
- 取引条件として明示されているのが「ISMS認証」のみ
- 自社は主にクラウド利用者側であり、提供者としての責任範囲が小さい
- ISMSの初回認証がまだで、運用が1周していない
順序としては、ISMSの運用を1周させてから追加を検討するのが現実的です。 27017・27018 は既存のISMSの仕組みに乗る形で運用されるため、土台がぐらついたまま範囲を広げると、内部監査もマネジメントレビューも負荷だけが増えます。
医療機関側が委託先に何を求めているかを知っておくと、判断の精度が上がります。ベンダーへのセキュリティチェックシート と 3省2ガイドラインとは｜医療情報システムの安全管理 は発注側の視点で書いています。
まとめ
- 27017・27018 は単独では取得できない。ISO/IEC 27001（ISMS）の認証を土台とする追加認証
- 27017 はクラウド固有の管理策。クラウド事業者（CSP）と利用者（CSC）で求められることが別に書かれており、医療SaaSは両方に該当することが多い
- 27018 は預かったPIIを目的外に使わないことを中心とした実施手引。二次利用・AI学習への懸念に直接答える
- 法令対応の体制として示したいなら 27701 のほうが目的に合う。27017と27018は同時取得が効率的
- 追加取得は、取引先が実際に何を問うているかを確認してから判断する。ISMSの運用を1周させてからが現実的
- 追加を視野に入れるなら、ISMS適用範囲を決める段階で対象サービスを含めておく
ポテックはヘルスケア領域に特化してISMS認証取得を支援しています。規程・台帳・教材のひな形を提供し、進行管理と審査機関とのやり取りを主導するため、御社には「どこまでを適用範囲に含めるか」といった判断に集中していただけます。クラウド向け追加認証を見据えた適用範囲の設計もご相談いただけます。
支援内容と料金は ISMS認証取得支援サービス をご覧ください。個別のご相談は お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27017 Information security controls for cloud services｜ISO
- ISO/IEC 27018 Protection of PII in public clouds acting as PII processors｜ISO
- ISO/IEC 27001 Information security management systems｜ISO
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
※規格の要求事項・管理策の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。付加認証の制度運用は改定されることがあります。