リスクアセスメントが終わり、評価済みのリスク一覧が手元にある。ここから先が、ISMSが「文書の束」になるか「経営の仕組み」になるかの分岐点です。リスク対応は、やることを決める工程ではなく、やらないことを決める工程でもあります。すべてのリスクに対策を打つことはできません。何を低減し、何を受け入れるかを、権限を持つ人が判断して記録する——この記録の有無が、審査での評価を大きく分けます。
実際、リスク対応で指摘を受ける理由の上位は、対策が不十分だからではありません。「受け入れる」と決めたことが記録されていない、「やる」と決めたことに期限と責任者がない、この2つです。どちらも対策の中身とは無関係で、記録の形式の問題です。つまり、正しい形式を最初から知っていれば避けられます。
本記事は、リスク対応の4つの選択肢の使い分け、対応計画の書き方、残留リスクの受容と承認の実務を整理します。前提となる評価は リスクアセスメントの進め方｜評価基準の設計、規格上の位置づけは 箇条6 計画｜リスクアセスメントと情報セキュリティ目的、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。
なぜここでつまずくのか
1. 「受容」を「何もしない」と読んでしまう
受容は、リスクを認識したうえで、追加の対応を行わないという積極的な意思決定です。「対応しなかった」ことと「受容すると決めた」ことは、記録上まったく違います。前者は漏れであり、後者は経営判断です。ところが実務では、リスク対応表の「対応方針」欄が空欄のまま残り、審査で「これは受容ですか、それとも未着手ですか」と問われることになります。
2. 対応を全部「低減」にしてしまう
4つの選択肢のうち低減しか使わないと、対応件数が膨れ上がり、計画が実行不能になります。回避（その業務をやめる）、移転（保険・委託先への転嫁）、受容は、いずれも正当な選択肢です。使わないのは選択肢の理解不足であって、慎重さではありません。
3. 計画が「やること」の羅列になっている
「アクセス制御を強化する」「教育を実施する」という粒度で書かれた対応計画は、実施状況を追跡できません。箇条9の監視・測定につながらず、内部監査でも「実施したかどうか判定できない」という状態になります。
4. 承認の主体が曖昧
規格は、リスク対応計画と残留リスクの受容について、リスク所有者の承認を得ることを求めています。ところが実務では、ISMS責任者が作った表を、誰も明示的に承認しないまま運用が始まる。承認の記録がないと、「誰がこのリスクを引き受けたのか」に答えられません。
何を決めるのか
対応の4つの選択肢
| 選択肢 | 内容 | 使いどころ | 記録すべきこと |
|---|---|---|---|
| 低減 | 管理策を追加・強化してリスクレベルを下げる | 最も一般的。事業上必要な活動に伴うリスク | 実施する管理策、責任者、期限、完了後の残留レベル |
| 回避 | リスクの原因となる活動をやめる／行わない | 事業価値に対してリスクが見合わない場合 | やめる活動の範囲、代替手段、意思決定者 |
| 移転（共有） | 保険、委託、契約条項でリスクを他者と分担する | 自社で対応するより合理的な場合 | 移転先、契約上の条項、移転しきれない部分 |
| 受容 | 追加対応をせず、現状のリスクレベルを受け入れる | 受容基準以下、または対応費用が損失を上回る場合 | 受容の理由、受容者、受容日、再評価の時期 |
選択肢の使い分けで最も誤解が多いのが「移転」です。 保険に入れば、あるいは委託先に任せれば、リスクがなくなるわけではありません。情報漏えいが起きたときの説明責任と信用の毀損は移転できません。 移転を選ぶ場合、「移転できた部分」と「自社に残る部分」を分けて記録し、残った部分を別途低減または受容する必要があります。医療情報を扱う委託の場合は特に、顧客である医療機関に対する責任は自社に残ります。委託先管理の実務は 外部委託先管理｜チェックシートと契約条項 で扱います。
「回避」も、実は有力な選択肢です。たとえば「開発者の端末に本番の患者データを一時的にコピーして不具合を調査する」という運用があるなら、運用そのものをやめて、マスキング済みの検証環境で調査するという回避が成立します。低減（端末の暗号化を強化する）よりも根本的で、しばしば安上がりです。
対応計画に必須の要素
規格が計画に求めるのは、何を実施するか、必要な資源、責任者、達成時期、結果の評価方法です。これを列にすると次のようになります。
| 列 | 内容 | 書き方の要点 |
|---|---|---|
| リスクID | アセスメント表との紐づけ | 必須。紐づかない対応は出所不明になる |
| 対応方針 | 低減／回避／移転／受容 | 空欄を残さない |
| 実施事項 | 具体的に何をするか | 「〜を強化する」ではなく、完了を判定できる記述にする |
| 採用する管理策 | 附属書Aの該当項目 | SoAとの整合をここで担保する |
| 責任者 | 実施を担う役職 | 個人名ではなく役職 |
| 必要な資源 | 予算、要員、外部支援 | 「予算措置が必要」だけでも書く |
| 期限 | 完了目標日 | 「順次」「継続的に」は不可 |
| 完了の判定方法 | 何をもって完了とするか | 成果物名、記録名で書く |
| 残留リスクレベル | 対応後に残る評価値 | 受容の判断の前提になる |
| 受容者・受容日 | 残留リスクを受け入れた人と日付 | ここが空だと必ず指摘される |
「実施事項」の書き方が計画の実行可能性を決めます。 次の対比が典型です。
| 追跡できない書き方 | 追跡できる書き方 |
|---|---|
| アクセス制御を強化する | 本番環境の管理者権限を棚卸しし、不要な権限を削除。以後は四半期ごとに棚卸しを実施 |
| 教育を実施する | 全従業者向けの情報セキュリティ教育を配信し、受講完了率100%を達成（未受講者は部門長へエスカレーション） |
| 委託先を管理する | 対象委託先12社にチェックシートを送付・回収し、リスクの高い3社には契約条項の改定を実施 |
| バックアップを見直す | 本番DBのバックアップについて、復旧手順書を作成し、年1回の復旧テストを実施して記録を残す |
実務の手順
手順1：受容基準以下のリスクを一括で受容する
評価済みリスクのうち、受容基準を下回るものは、個別に検討せず一括で受容として処理します。「リスク値◯以下のリスクは、リスクアセスメント手順書に定める受容基準に従い受容する」という決定を1つ記録し、リスク所有者またはトップマネジメントの承認を得る。これで大部分のリスクが片付きます。
ここを個別に検討し始めると、作業量が爆発します。受容基準を先に決めておく価値は、この工程で最大化されます。
手順2：対応が必要なリスクを優先順位付けする
受容基準を超えたリスクについて、リスク値の高い順に並べます。ここで、対応可能な件数を超えている場合は、基準の妥当性に戻って検討するか、複数年の計画に分割します。
手順3：各リスクに選択肢を割り当てる
低減が既定路線になりがちですが、まず回避が成立しないかを検討するのが実務的です。次に移転、最後に低減の順で検討すると、対応件数が現実的な水準に落ち着きます。
手順4：管理策を決定し、附属書Aと突き合わせる
対応に必要な管理策を決めたら、附属書Aの93管理策と比較して漏れを検証します。順序が重要で、附属書Aから選ぶのではなく、決めた管理策を93項目に照らして「必要なのに落としていないか」を見る工程です。この検証の記録がSoAの根拠になります。管理策の全体像は 附属書A 2022年版｜93管理策と4テーマの全体像、SoAの書き方は 適用宣言書（SoA）の書き方 をご覧ください。
手順5：期限と責任者を入れる
ここで計画が実行可能になるかが決まります。期限は、内部監査の実施時期から逆算して置くのが有効です。内部監査で「実施済み」と確認できる状態にしておくと、審査までの流れが整います。
期限の設定で現実的なのは、次のような区分です。
| 区分 | 期限の目安 | 対象 |
|---|---|---|
| 即時対応 | 1か月以内 | 現に発生しているリスク、設定変更で解決するもの |
| 短期 | 3か月以内 | 手順の整備、規程の制定、権限の棚卸し |
| 中期 | 認証取得までに完了 | 教育の実施、委託先チェックシートの回収、技術的対策の導入 |
| 長期 | 次年度以降 | 大規模なシステム改修、組織的な体制変更 |
「長期」に置いたリスクは、その期間中の残留リスクを受容する判断が別途必要です。 「来年やる予定だから対応済み扱い」は成立しません。対応完了までの間、そのリスクレベルを受け入れるという記録を残します。
手順6：残留リスクを評価し、受容の承認を得る
対応を実施しても、リスクはゼロになりません。対応後に残る水準を評価し、それを受け入れる承認をリスク所有者から得ます。この承認は、対応の実施前に行います。 「この対策を打った結果、残るリスクはこのレベルになる見込みであり、それを受け入れる」という判断だからです。
承認の記録形式は、次のいずれかで足ります。
- リスク対応計画書に承認欄を設け、リスク所有者が押印・署名する
- リスクアセスメント表に「残留リスクレベル」「受容者」「受容日」の列を設け、記入する
- マネジメントレビューの議事録に、残留リスクの受容を議題として記載し、決議を残す
3つ目が最も効率的です。個別のリスクごとに承認を取る手間を省きつつ、トップマネジメントの関与を示せます。ただし議事録には、受容したリスクが特定できる形（リスクIDの列挙、または「リスク対応計画書 v1.2 記載の残留リスク」といった参照）で書く必要があります。マネジメントレビューの進め方は マネジメントレビューの進め方と議事録 で扱います。
手順7：進捗を監視する仕組みに載せる
対応計画は作った時点では計画にすぎません。月次または四半期で進捗を確認し、遅延しているものを把握する運用が必要です。ここが箇条9の監視・測定につながります。
よくある失敗
残留リスクの受容が記録されていない
審査で最も確実に指摘される項目です。 規格が明示的に要求しているため、記録がなければ不適合になります。対策は手順6で、リスクアセスメント表に3列（残留リスクレベル・受容者・受容日）を足すだけでも要求を満たせます。
対応計画に期限がない／「順次」と書かれている
実施状況を追跡できず、内部監査でも判定できません。すべての行に日付を入れます。
責任者が個人名で書かれている
異動・退職で計画が宙に浮きます。役職で書きます。
受容基準以下のリスクを個別に検討している
作業量が爆発し、本来対応すべき高リスクに時間を割けなくなります。手順1で一括処理します。
「移転したから対応済み」としている
保険加入や委託で移転できるのは損害の一部であり、説明責任と信用は残ります。移転しきれない部分を明示し、それを別途低減または受容する必要があります。
回避を検討していない
低減しか選択肢に入っていない計画は、対応件数が多くなりがちです。「そもそもこの業務をやめられないか」を最初に問うことで、件数が減り、根本的な解決になります。
対応完了の判定基準がない
「実施した」と報告されているが、何をもって完了としたのかが不明。成果物名または記録名で完了を定義することで解決します。「受講完了率100%を示す受講記録」「四半期ごとの権限棚卸し記録」といった書き方です。
対応計画とSoAが整合していない
対応計画で「採用する」とした管理策が、SoAでは「適用外」になっている。あるいはその逆。手順4で附属書Aとの突合を行い、その結果をそのままSoAに反映することで防げます。審査で最も多い指摘は「SoAと実態の不一致」であり、その一形態がこれです。審査でよくある不適合と対策 もご覧ください。
ヘルスケア企業の例
医療機関向けSaaSを提供する企業
| リスク | 選択した対応 | 実施事項 | 残留リスクの扱い |
|---|---|---|---|
| マルチテナントのデータ分離不備 | 低減 | テナント境界のテストをCIに組み込み、リリース判定の必須項目にする。管理画面の越境参照経路を棚卸しして遮断 | 低減後も残るリスクを、開発責任者が受容 |
| サポート時の本番データ参照 | 回避＋低減 | 原則として本番参照を禁止し、マスキング済みの調査環境を用意。例外時は申請・承認・期限・ログを必須化 | 例外運用に伴う残留リスクをサポート部門長が受容 |
| 委託先（開発外注）からの漏えい | 移転＋低減 | 契約に秘密保持・再委託禁止・監査権を明記。年次チェックシートを実施 | 契約で移転できない説明責任は自社に残る旨を明記して受容 |
| 大規模障害による顧客の診療停止 | 低減＋移転 | 冗長化とバックアップからの復旧テストを年1回実施。SLAで責任範囲を明確化 | SLA上限を超える損害の可能性を経営層が受容 |
| 属人化した復旧手順 | 低減 | 復旧手順書を作成し、担当者以外による復旧テストを実施 | 完了後の残留リスクは低く、ISMS責任者が受容 |
2行目の**「回避＋低減」の組み合わせが実務上の要**です。本番データ参照を完全に禁止できる企業は多くありませんが、原則禁止＋例外の統制という設計にすることで、リスクレベルを大きく下げられます。責任分界の考え方は既存記事の AI電子カルテのセキュリティ設計｜責任共有モデル が参考になります。
PHR事業者
同意管理の不備は低減一択になります。受容や移転の余地が小さいためです。同意の取得・撤回・範囲変更が記録され、実際のデータ利用がその範囲内に収まることを技術的に担保する設計が対応事項になります。詳細は PHR事業者のISMS｜個人情報保護法との関係 をご覧ください。
治験・臨床研究システムを扱う企業
監査証跡の完全性に関するリスクは、受容の余地がほとんどない領域です。「対応費用が損失を上回るため受容」という論理が成立しにくく、低減を前提に計画を組むことになります。逆に言えば、ここで受容を選んでいる計画は、審査でも顧客のベンダー審査でも説明が難しくなります。
SaMDを開発する企業
ISMSのリスク対応と、製品安全性リスク（ISO 14971）のリスクコントロールが並存します。受容の判断基準が両者で異なる点に注意が必要です。情報セキュリティの受容基準は組織の許容度で決まりますが、製品安全性のリスク受容は患者への危害を前提とした別の基準で判断されます。SaMDとISMS・QMSの関係 で扱います。
共通：3省2ガイドラインとの関係
顧客である医療機関が求める安全管理措置は、多くの場合「低減」として対応計画に入ります。ガイドライン対応を別のプロジェクトにせず、リスク対応計画の1部分として管理すると、進捗確認が一本化でき、内部監査でも同じ枠組みで点検できます。ガイドラインの全体像は既存記事の 3省2ガイドラインとは、対応の実務は 3省2ガイドライン対応の実務ステップ をご覧ください。
まとめ
- リスク対応はやらないことを決める工程でもある。「受容」は積極的な意思決定であり、空欄とは違う
- 回避・移転・受容を選択肢に入れる。低減だけの計画は件数が膨れ、実行不能になる
- 移転は説明責任と信用を移転しない。移転しきれない部分を明示し、別途低減または受容する
- 対応計画には実施事項・責任者（役職）・期限・完了判定・残留レベルを必ず入れる。「順次」「継続的に」は不可
- 残留リスクの受容記録がないことは、審査で最も確実に指摘される。表に3列（残留レベル・受容者・受容日）を足すだけでも要求を満たせる
- 受容基準以下のリスクは一括で受容として処理し、高リスクへの検討時間を確保する
対応計画が固まったら、その結果を 適用宣言書（SoA）の書き方 に反映し、情報セキュリティ目的とKPIの立て方 で継続的な運用につなげます。前提となる評価基準の設計は リスクアセスメントの進め方｜評価基準の設計、方針との接続は 情報セキュリティ方針の書き方 をご覧ください。
ポテックは、ヘルスケア領域に特化してISMS認証取得を支援しています。対応計画の設計と受容の記録形式は、指摘を避けるうえで最も費用対効果の高い領域です。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- ISO 31000 Risk management｜ISO
- 日本産業標準調査会（JISC）
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
- 個人情報保護委員会
※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。