ISMS構築でいちばん時間を使うのは規程づくりです。方針を書き、リスクアセスメント表を埋め、適用宣言書を仕上げる。ここまで来ると「あと少しで審査だ」という気持ちになります。
ところが審査で不適合が出やすいのは、文書そのものではありません。決めたルールが実際に回っていた証跡が薄いところです。バックアップの取得ルールはあるが検証した記録がない。委託先チェックシートの様式はあるが、今期の回収記録がない。サーバ構成を変えたが、変更の承認記録がどこにも残っていない——こうした穴は、箇条8の領域で顔を出します。
本記事は、ISO/IEC 27001 の**箇条8（運用）**が何を求めているのかを、実務で作る成果物と審査での見られ方に落として整理したものです。箇条6で決めたことをどう実行に移し、どこまで記録を残せばよいのかを判断できる状態を目指します。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の運用判断はそれらに基づいて行ってください。
箇条8が求めていること
箇条8は3つの項目で構成されます。いずれも「新しく何かを決める」箇条ではなく、既に決めたことを実行し、実行したことを示す箇条です。
| 項番 | 要求の趣旨 | 前段でこれを決めている |
|---|---|---|
| 8.1 運用の計画及び管理 | ISMSに必要なプロセスを計画し、実施し、管理する。計画どおり実施したと確信できる程度に記録を残す。計画した変更を管理し、意図しない変更は影響をレビューして必要なら手を打つ。外部から提供されるプロセス・製品・サービスを管理する | 箇条6（計画）、箇条7（支援） |
| 8.2 情報セキュリティリスクアセスメント | あらかじめ定めた間隔で、また重大な変更が提案または発生したときに、リスクアセスメントを実施し結果を文書化する | 6.1.2 で評価基準と手順を確定済み |
| 8.3 情報セキュリティリスク対応 | リスク対応計画を実施し、結果を文書化する | 6.1.3 で対応方針と適用宣言書を確定済み |
ここで押さえるべき構造は単純です。箇条6が「決める」、箇条8が「やる」、箇条9が「点検する」、箇条10が「直す」。 箇条8は真ん中にあり、上流の決定と下流の点検をつなぐ役割を負っています。
各箇条の位置づけは 箇条4｜組織の状況、箇条5｜リーダーシップ、箇条6｜計画、箇条7｜支援 で解説しています。全体像は ISMS（ISO/IEC 27001）とは をご覧ください。
「確信が持てる程度」という記録の基準
8.1 は、プロセスが計画どおり実施されたと確信を持てる程度に文書化した情報を保持することを求めています。ここが実務上の判断ポイントです。すべての作業を逐一記録する必要はありませんが、「やったはずです」という口頭説明だけでは足りません。
判断の目安は、第三者がその記録だけを見て「いつ・誰が・何を・どういう結果で実施したか」を再構成できるかです。再構成できないなら記録が足りていません。
変更管理が明示されたこと
2022年版では、8.1 に計画した変更の管理と意図しない変更のレビューが明確に書かれています。加えて本文側に 6.3（変更の計画）が新設され、ISMSそのものの変更も計画的に行うことが求められるようになりました。
実務上の意味は次のとおりです。
- システム構成やサービス内容を変えるときは、セキュリティ影響を評価してから変える
- 変えた記録（申請・承認・実施・確認）を残す
- 意図せず変わってしまったもの（設定ドリフト、緊急対応での暫定変更、委託先都合の仕様変更）は、後追いでレビューして必要なら戻すか正式化する
2013年版との差分は ISO/IEC 27001:2022への移行｜2013年版との差分 にまとめています。
実務で作る成果物
箇条8で新たに大量の規程を作る必要はありません。作るのは主に記録です。ただし、記録が自然に溜まる置き場所と様式を先に決めておかないと、審査直前に手作業で作り直すことになります。
| 要求 | 残す記録の例 | 置き場所の決め方 |
|---|---|---|
| 運用プロセスの実施（8.1） | アクセス権限の付与・変更・削除申請、バックアップ取得と復元検証の結果、脆弱性対応の記録、ログレビューの実施記録、入退室記録 | 既存の業務ツール（チケット、IdP、監視SaaS）の出力をそのまま証跡にできないか先に検討する |
| 変更の管理（8.1） | 変更申請書または変更管理チケット、セキュリティ影響評価、承認者、リリース記録、切り戻し判断 | 開発のPR運用と別立てにせず、PRテンプレートに影響評価欄を足す方が続く |
| 外部提供プロセスの管理（8.1） | 委託先一覧、選定時の評価記録、年次のチェックシート回収、契約上のセキュリティ条項、サブ委託の把握 | 委託先一覧を正とし、評価記録を紐づける |
| リスクアセスメントの実施（8.2） | 実施日・参加者・対象範囲を含むリスクアセスメント表の版、重大変更を契機に実施した回の記録 | 表を上書きせず、版として残す |
| リスク対応の実施（8.3） | リスク対応計画の進捗、完了エビデンス、未完了項目の理由と次期計画 | 目的管理表と対応計画の粒度を揃える |
記録は「作るもの」ではなく「溜まるもの」にするのが原則です。 月次で手作業のExcelを埋める運用は、担当者が忙しくなった月に必ず途切れます。すでに業務で使っているツールの出力を証跡として認める設計にしておくと、運用が続きます。
文書と記録の体系設計は ISMS文書体系｜何をどこまで作るか、委託先管理の実務は 外部委託先管理｜チェックシートと契約条項 で扱っています。
リスクアセスメントを「いつ」やるか
8.2 は、定めた間隔と重大な変更が提案または発生したときの両方を求めています。年1回の定期実施だけを運用に組み込み、後者が抜けている組織は少なくありません。
「重大な変更」の例をあらかじめ列挙しておくと、現場が判断できるようになります。
- 新しいクラウドサービスの採用、既存サービスの提供リージョン変更
- 取り扱う情報の種類が増える（匿名加工情報から個人情報へ、など）
- 適用範囲に関わる拠点・部門・子会社の増減
- 重大インシデントの発生
- 委託先の変更、または委託先での重大な事故
- 適用される法令・ガイドラインの改定
評価基準の設計そのものは リスクアセスメントの進め方｜評価基準の設計、対応の判断は リスク対応計画とリスク受容の判断 をご覧ください。
つまずきやすい点
1. 記録の日付が後から揃っている
審査でいちばん印象が悪いのは、記録の作成日が審査直前に集中している状態です。四半期ごとに実施すると決めたログレビューの記録が、3回分まとめて同じ週に作られていれば、実施していなかったと判断されます。
対策は単純で、頻度を実態に合わせて下げることです。月次でできないなら四半期にする。四半期でできないなら半期にする。規格は頻度を指定していません。守れない頻度を宣言することの方が、はるかにリスクが高いという判断をしてください。
2. 変更管理が開発フローの中に埋もれている
エンジニアリング組織では、変更管理はすでにPull RequestとCI/CDで回っていることがほとんどです。問題は、それをISMSの記録として提示できる形にしていないことです。
審査で「直近のインフラ変更を1件見せてください」と言われたとき、PRのURLを開いてレビュー承認とマージ記録を示せるなら十分です。逆に、PRにセキュリティ影響の検討が一切書かれておらず、承認者が起票者自身であれば、そこが指摘対象になります。
3. 委託先管理が契約書だけで止まっている
外部から提供されるプロセス・製品・サービスの管理は、契約にセキュリティ条項を入れて終わりではありません。選定時の評価、定期的な状況確認、変更時の再評価までが一連の要求です。
とくに見落とされるのがクラウド事業者です。「AWSは大手だから評価不要」という運用にしていると、責任分界の整理が委託先管理の記録として残りません。責任共有モデルの考え方は AIカルテのセキュリティ設計と責任共有モデル で扱っています。
4. 緊急対応の暫定措置が正式化されない
障害対応で一時的に権限を広げた、検証のために本番データをコピーした、といった緊急時の逸脱は現実に起こります。問題は、それが「意図しない変更」として後追いレビューされず、暫定のまま残ることです。
緊急変更の手順（事後承認のルート、期限、原状復帰の確認）を先に決めておくと、逸脱そのものが不適合にならずに済みます。
5. 「実施した」の粒度が揃っていない
リスク対応計画に「アクセス制御の強化」とだけ書いてあると、何をもって完了かが決まりません。結果として、審査で完了エビデンスを示せなくなります。対応計画は完了判定ができる粒度で書くのが原則です。
審査で見られること
箇条8は、文書審査（1次審査）よりも実地審査（2次審査）で重点的に確認される領域です。審査員は記録をサンプリングし、決めたとおりに回っていたかを追います。
| 見られる観点 | 典型的な確認のされ方 | 準備 |
|---|---|---|
| 計画と実施の一致 | 「年間計画では四半期ごととあるが、実施記録を全期間分見せてください」 | 頻度は実行可能な設定にし、抜けた回は理由と是正を記録しておく |
| 記録の再構成可能性 | 「この作業は誰が承認しましたか。記録で示せますか」 | 実施者・承認者・日付が残る様式にする |
| 変更管理の実態 | 「直近3か月の本番環境への変更を1〜2件、申請から実施まで追わせてください」 | 代表的な変更を1件、事前に通しで確認しておく |
| リスクアセスメントの契機 | 「この期間に新サービスを導入していますが、リスク評価は実施しましたか」 | 重大変更の定義を文書化し、該当した回の記録を紐づける |
| 外部委託の管理 | 「委託先一覧の中からこの2社について、評価の記録を見せてください」 | 一覧と評価記録の紐づけを維持する |
| リスク対応の進捗 | 「対応計画で未完了の項目は、いつまでにどうしますか」 | 未完了を隠さず、理由と次期計画をセットで示す |
未完了項目があること自体は不適合ではありません。 未完了を把握しておらず、説明もできない状態が問題になります。この考え方は箇条10の是正処置と地続きです。詳しくは 箇条10 改善｜不適合と是正処置 をご覧ください。
審査全体での典型的な指摘は 審査でよくある不適合と対策、実地審査の進み方は 2次審査（実地審査）で見られること にまとめています。
ヘルスケア企業での具体例
ヘルスケア領域では、箇条8の運用が3省2ガイドラインの要請と重なることが多く、ここを統合できるかが工数を左右します。
病院向けSaaSを提供している場合
リリースのたびに医療機関側の運用に影響が出るため、変更管理の記録は自社だけの問題になりません。リリース前のセキュリティ影響評価、医療機関への事前通知、切り戻し手順の確認までを一連の記録として残しておくと、ISMSの証跡と顧客説明資料を兼ねられます。医療機関側がどう見ているかは 3省2ガイドラインとは が参考になります。
電子カルテのリモート保守を行っている場合
保守接続は「外部から提供されるプロセス」であると同時に、自社が医療機関に提供するプロセスでもあります。接続の申請・承認・作業ログ・接続終了の確認を記録として残すことが、箇条8とガイドライン双方の要求を同時に満たします。
医療情報を外部保存している場合
クラウド事業者・データセンター事業者は委託先管理の対象です。責任分界を文書化し、事業者側の第三者認証や監査報告（ISO 27001、ISO 27017、SOC 2 など）を評価記録として保持する運用にすると、毎年の確認が現実的な工数に収まります。
リスクアセスメントの契機が発生しやすい
医療分野は法令・ガイドラインの改定が比較的頻繁です。改定を「重大な変更」の一つとして定義に含めておくと、8.2 の臨時実施が自然に発火します。ISMS文書とガイドライン対応文書の統合は ISMS文書と3省2ガイドライン対応文書の統合 で扱っています。
インシデントは箇条8の記録を試す機会になる
実際に何かが起きたとき、初動で参照するのは箇条8で整備した手順と記録です。手順書が現実の連絡経路と食い違っていれば、その時点で分かります。演習と実地の記録は インシデント対応手順の作り方 をご覧ください。
まとめ
箇条8について押さえるべき点は次のとおりです。
- 箇条8は新しく決める箇条ではなく、決めたことを実行して証跡を残す箇条である。上流は箇条6、下流は箇条9
- 記録の基準は「計画どおり実施したと第三者が再構成できるか」。すべてを記録する必要はないが、口頭説明では足りない
- 2022年版では変更管理が明示された。計画した変更の管理と、意図しない変更の事後レビューの両方が要る
- リスクアセスメントは定期実施だけでなく重大な変更を契機とする実施も求められる。何が重大かを先に定義しておく
- 外部委託は契約条項で終わらない。選定評価・定期確認・変更時の再評価までが一連
- 審査で最も露見しやすいのは記録の薄さ。守れない頻度を宣言するより、実行可能な頻度に下げて確実に回す方が安全
ポテックは、ヘルスケア領域に特化してISMS認証取得と運用を支援しています。記録が自然に溜まる運用設計、変更管理と開発フローの接続、委託先評価の様式まで、御社の実態に合わせて整備します。運用が回りはじめた2年目以降の維持もご支援できます。
支援内容と料金は ISMS認証取得支援サービス をご覧ください。現状の運用記録が審査に耐えるかどうかのご相談は お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- JIS Q 27001:2023｜日本産業標準調査会
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
※規格の要求事項の解釈および認証の取扱いは、規格本文と認定機関・審査機関の公表資料をご確認ください。審査での確認方法は審査機関・審査員により異なります。