ISMSの構築で最も工数がかかり、最も差が出るのが箇条6です。リスクアセスメントの結果が適用宣言書（SoA）を決め、SoAが整備すべき規程を決め、規程が日々の運用を決める。箇条6は、以降のすべての作業の設計図にあたります。
ところが実務では、この箇条が「情報資産台帳を作って点数を付ける作業」に矮小化されがちです。数百行の台帳を機械的に埋め、リスク値を計算し、高リスクのものに管理策を割り当てる。形は整っていても、その結果が経営判断として意味を持っているかは別の問題です。審査員が見ているのはまさにそこです。
本記事は、箇条6の要求を実務の手順に翻訳し、リスク基準の設計、アセスメントの進め方、SoAの作り方、そして情報セキュリティ目的の立て方を整理します。前提となる適用範囲は ISO/IEC 27001 箇条4｜組織の状況、経営層の関与は 箇条5 リーダーシップ、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。
この箇条が求めていること
箇条6は大きく3つの部分に分かれます。
1. リスクおよび機会への取組み
箇条4で洗い出した課題と利害関係者の要求事項を踏まえ、ISMSが意図した成果を達成できるよう、取り組むべきリスクと機会を決めること。ここが箇条4と箇条6をつなぐ蝶番です。
この中に、情報セキュリティリスクアセスメントとリスク対応の具体的な要求が置かれています。
リスクアセスメントに求められるのは、要旨として次のとおりです。
- リスク基準を定めること。すなわち、リスクを受け入れる基準（受容基準）と、アセスメントを実施する基準
- 繰り返し実施したときに、一貫性があり妥当で比較可能な結果が得られること
- 情報の機密性・完全性・可用性が損なわれることに伴うリスクを特定すること
- 特定したリスクごとに、リスク所有者を決めること
- リスクが現実化した場合の結果と、その起こりやすさを分析し、リスクレベルを決めること
- リスクレベルをリスク基準と比較して評価し、対応の優先順位をつけること
リスク対応に求められるのは次のとおりです。
- アセスメント結果を踏まえ、各リスクに対する対応の選択肢を選ぶこと（低減・回避・移転・受容）
- 選んだ対応に必要な管理策を決定すること
- 決定した管理策を附属書Aと比較し、必要な管理策が漏れていないか検証すること
- **適用宣言書（SoA）**を作成すること。採用した管理策とその根拠、採用しなかった管理策とその理由、そして実装状況を含む
- リスク対応計画を策定すること
- リスク対応計画と、残留リスクの受容について、リスク所有者の承認を得ること
ここで重要なのは、附属書Aは出発点ではなく検証用のチェックリストだという位置づけです。93管理策を上から順に「やる／やらない」と埋めていく作り方は、規格の論理とは逆向きです。自社のリスクから必要な管理策を導き、その後で附属書Aと突き合わせて漏れを確認する——これが本来の順序です。
2. 情報セキュリティ目的およびそれを達成するための計画策定
関連する部門・階層で情報セキュリティ目的を設定し、文書化すること。目的は方針と整合し、測定可能であり（実行可能な場合）、適用される要求事項とリスクアセスメント・リスク対応の結果を考慮したものである必要があります。さらに、何を実施するか、必要な資源、責任者、達成時期、結果の評価方法を計画として定めます。
3. 変更の計画
ISMSの変更が必要になったとき、それを計画的に実施すること。組織改編、新サービス、システム移行などのたびに場当たり的に対応するのではなく、変更の影響を評価してから進める仕組みを求めています。
実務で作る成果物
| 成果物 | 目的 | 誰が承認するか |
|---|---|---|
| リスクアセスメント手順書 | 評価の基準・尺度・手順を定め、繰り返しても比較可能な結果を得る | ISMS責任者（基準はトップマネジメントの合意を得る） |
| 情報資産台帳 | 守る対象を特定し、アセスメントの単位を定める | 各部門の管理者 → ISMS責任者 |
| リスクアセスメント表 | リスクの特定・分析・評価の結果と、リスク所有者を記録する | リスク所有者（部門長・役員） |
| リスク対応計画 | 各リスクへの対応方針、実施事項、責任者、期限を定める | リスク所有者／トップマネジメント |
| 適用宣言書（SoA） | 93管理策の採否と根拠、実装状況を一覧で示す | トップマネジメント |
| 残留リスク受容の記録 | 対応後に残るリスクを誰が受け入れたかを明確にする | リスク所有者 |
| 情報セキュリティ目的管理表 | 目的・指標・目標値・責任者・期限・評価方法を定める | トップマネジメント |
| 変更管理の手順 | ISMSに影響する変更を計画的に扱う | ISMS責任者 |
リスク基準の設計が最初の分岐点です。 よくあるのは、結果（影響）と起こりやすさをそれぞれ3段階または5段階で評価し、積または和でリスク値を出す方式です。どちらでも構いませんが、受容基準の線をどこに引くかを先に決めることが肝心です。線を引かないまま評価を始めると、「高リスクが200件出てしまい対応しきれない」という状態になります。
リスク所有者の設定は、審査で必ず問われます。 リスク所有者とは、そのリスクについて対応を決め、残留リスクを受け入れる権限を持つ人です。ISMS責任者が全リスクの所有者になっている台帳は、権限の実態と合わないことが多く、指摘の対象になりやすい構造です。実務では、部門長または役員をリスク所有者に置くのが自然です。
SoAは認証の中核文書です。 93管理策すべてについて、採用の可否、その理由、実装状況を記載します。採用しない場合に必要なのは、「不要だから」ではなくリスクアセスメントの結果に基づく説明です。たとえば「自社は自社開発を行わないため、セキュアな開発に関する管理策は適用外」であれば、開発を外部委託していることが情報資産台帳と委託先管理の記録から確認できる必要があります。書き方は 適用宣言書（SoA）の書き方、管理策の全体像は 附属書A 2022年版｜93管理策と4テーマの全体像 をご覧ください。
つまずきやすい点
情報資産台帳が細かすぎる／粗すぎる
1台ごとのPCを1行にすると、数百行の台帳ができあがり、更新されなくなります。逆に「顧客データ」の1行で済ませると、リスクの粒度が粗すぎて具体的な管理策に落ちません。実務的には、情報の種類 × 保管場所（システム） を単位にすると扱いやすくなります。台帳の作り方は 情報資産の洗い出しと台帳の作り方 で詳述します。
リスク値が全部「中」になる
評価者が無難な中央値を選び続けると、優先順位がつきません。評価尺度の各段階に、判断可能な定義を文言で書くことで防げます。たとえば影響度なら「事業停止に至る」「顧客への報告が必要になる」「社内で完結する」のように、判定できる基準にします。
附属書Aから逆算してリスクを作っている
93管理策を先に並べ、それぞれに対応するリスクを後付けする作り方です。形式的にはSoAが埋まりますが、自社固有のリスク（たとえばマルチテナントのデータ分離不備、AI機能へのプロンプトインジェクション、委託先の再委託）が一つも出てこないため、審査で「リスクアセスメントが形式的である」と評価されやすくなります。
リスク対応計画に期限と責任者がない
「アクセス制御を強化する」とだけ書かれた対応計画は、実施状況を追跡できません。誰が・いつまでに・何をするかが書かれていなければ、箇条9の監視・測定につながりません。
残留リスクの受容が記録されていない
対応を実施してもリスクはゼロになりません。残った分を誰が受け入れたのかが記録されていないと、要求を満たしません。リスクアセスメント表に「残留リスクレベル」と「受容日・受容者」の列を設けるのが簡便です。
情報セキュリティ目的が測定できない
「セキュリティ意識を向上させる」は目的の宣言としては成立しても、達成を評価できません。次のように、指標と目標値をセットにすることで運用可能になります。
| 目的（悪い例） | 目的（改善例） | 指標 | 目標値 |
|---|---|---|---|
| セキュリティ意識を向上させる | 全従業者が年次教育を修了する | 年次教育の受講完了率 | 100%（年度末時点） |
| 脆弱性に速やかに対応する | 重大な脆弱性を一定期間内に修正する | 緊急度「高」の脆弱性の平均修正日数 | 14日以内 |
| インシデントを減らす | インシデントの検知と初動を早める | 検知から初動着手までの平均時間 | 4時間以内 |
| 委託先管理を強化する | 委託先の年次評価を完了する | 対象委託先の評価実施率 | 100% |
目的の立て方は 情報セキュリティ目的とKPIの立て方 で扱います。
審査で見られること
箇条6は、1次審査で文書の存在と論理の一貫性が、2次審査で実態との一致が確認されます。よく問われる観点は次のとおりです。
| 観点 | 審査で問われること |
|---|---|
| 基準の事前設定 | リスク基準・受容基準を、評価を始める前に定めていたか |
| 再現性 | 別の人が同じ手順でやっても、同等の結果になる設計か |
| リスク所有者 | 各リスクの所有者は、実際に対応を決められる権限を持つか |
| 附属書Aとの突合 | 決定した管理策を93管理策と比較し、漏れを検証した記録があるか |
| SoAの根拠 | 除外した管理策の理由が、リスクアセスメント結果と整合しているか |
| SoAと実態の一致 | 「実装済み」と書かれた管理策が、現場で実際に動いているか |
| 目的の測定 | 目的に指標と目標値があり、実績が記録されているか |
| 残留リスクの承認 | 残留リスクの受容について、所有者の承認記録があるか |
もっとも指摘が多いのは**「SoAと実態の一致」**です。SoA上は「実装済み」となっている管理策について、2次審査で現場に確認したら運用されていなかった、という形で表面化します。SoAを書く段階で、各管理策について「どの文書・どの記録で実装を示すか」を欄外にメモしておくと、審査対応が大きく楽になります。
審査での典型的な指摘は 審査でよくある不適合と対策、実地審査の進み方は 2次審査（実地審査）で見られること にまとめています。
ヘルスケア企業での具体例
医療SaaS事業者の場合
この業態のリスクアセスメントで欠かせないのが、マルチテナントのデータ分離に関するリスクです。テナントIDの取り違え、クエリのフィルタ漏れ、管理画面からの越境参照。いずれも影響度は最大級（他医療機関の患者データの漏えい）であり、一般的なIT企業の台帳には現れにくい項目です。
もう一つはサポート・保守時の本番データアクセスです。障害調査のために本番環境の患者データを参照する運用は現実に存在し、その手続き（申請・承認・期限・ログ）をリスク対応として設計する必要があります。責任分界の考え方は既存記事の AI電子カルテのセキュリティ設計｜責任共有モデル が参考になります。
PHR事業者の場合
利用者本人からデータを預かる構造上、同意管理の不備がリスク項目として立ちます。同意の取得・撤回・範囲変更が記録され、実際のデータ利用がその範囲内に収まっていることを示せるか。ここは個人情報保護法の要請とも重なるため、法規制対応とリスク対応を同じ計画で管理すると効率的です。詳細は PHR事業者のISMS｜個人情報保護法との関係 をご覧ください。
治験システムを扱う企業の場合
データインテグリティ（完全性）に重みを置いた評価基準が必要になります。一般的なISMSでは機密性の影響度が高く評価されがちですが、治験では「データが改ざんされていないこと」「監査証跡が欠落していないこと」の影響が極めて大きい。影響度の尺度そのものを、機密性・完全性・可用性で別に定義する設計が有効です。
SaMDを開発する企業の場合
リスクアセスメントがISMSのリスクと製品の安全性リスク（ISO 14971）の二系統になります。両者は目的が異なる（情報資産の保護と、患者への危害の防止）ため統合すべきではありませんが、接点は明示しておく必要があります。たとえば「ソフトウェア更新の配信経路が侵害される」というセキュリティリスクは、製品側では「誤動作による患者への危害」という安全性リスクに接続します。
いずれの業態でも、3省2ガイドラインが求める安全管理措置は、リスク対応計画の中に位置づけると管理が一本化できます。統合の考え方は ISMS文書と3省2ガイドライン対応文書の統合、ガイドライン側の全体像は既存記事の 3省2ガイドラインとは をご覧ください。
まとめ
- 箇条6は以降すべての作業の設計図。リスクアセスメント → SoA → 規程 → 運用という連鎖の起点になる
- 附属書Aは出発点ではなく検証用のチェックリスト。自社のリスクから管理策を導き、その後で93管理策と突き合わせる
- リスク基準と受容基準は、評価を始める前に決める。後から決めると対応しきれない件数が出る
- リスク所有者は、対応を決め残留リスクを受け入れる権限を持つ人。ISMS責任者が全件を持つ構造は指摘されやすい
- 審査で最も多い指摘はSoAと実態の不一致。各管理策の実装を示す文書・記録を紐づけておく
- 情報セキュリティ目的は指標と目標値をセットにする。測れない目的は箇条9につながらない
箇条6で決めた計画は、箇条7 支援｜力量・認識・文書化した情報 で人と文書の基盤を得て、箇条8 運用 で実行に移ります。その結果は 箇条9 パフォーマンス評価 で点検され、箇条10 改善 に戻ります。個別の実務は リスクアセスメントの進め方｜評価基準の設計 と リスク対応計画とリスク受容の判断 で詳しく扱います。
ポテックは、ヘルスケア領域に特化してISMS認証取得を支援しています。リスクアセスメントの基準設計とSoAの作成は、ヘルスケア固有のリスク項目を知っているかどうかで質が大きく変わる領域です。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- 日本産業標準調査会（JISC）
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
- 個人情報保護委員会
※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。