メール、決済アカウント、顧客ファイルの保存先が使えなくなったら、どの業務が止まるでしょうか。依存関係を書き出すと、何を守るための設定なのかが明確になります。
本シリーズは、2026年11月2日公開のNIST CSWP 50正式版に基づいています。原文の無雇用企業は、事業の所有者以外に有給従業員がいない事業を指し、所有者が一人に限られるという意味ではありません。本シリーズは、IT環境が比較的単純なフリーランスや個人開発者が、ひとりで事業を営む場面を中心に扱います。
以下の記入表、上位3件の選定、完了の目安は筆者による実務向けの整理です。NISTの原表や、適合を証明するものではありません。 原文10ページは、掲載表をチェックリストや適合判定基準としないことを明記しています。付録D–Jは別の表計算ファイルで提供されており、本記事では再現していません。
1. 継続する必要がある業務を定義する
「この事業は『』を継続して提供する必要があり、『』に依存し、中断すると『____』に影響する」と記入します。将来使うかもしれないすべてのシステムではなく、現在の実際の提供業務を対象にします。
NIST CSF 2.0には、統治、識別、防御、検知、対応、復旧の6機能があります。本記事は主に統治と識別、第2回は日常の防御と検知、第3回は対応と復旧の準備を扱います。6機能を合わせてリスクを管理するものであり、6項目を埋めれば認証を得られるわけではありません。原文9–10ページ
2. 維持できる資産台帳を作る
まずメール、決済、機密ファイル、パスワードマネージャー、事業に不可欠なクラウドサービスを確認し、業務端末やネットワークにつながるほかの機器も追加します。重要なアカウントの例は原文2ページにあり、資産にはソフトウェア、データ、外部サービスも含まれます。原文2–3ページ
資産ごとに、次の筆者作成の記入表を複製します。
| 項目 | 記入する内容 |
|---|---|
| 資産と用途 | 機器・サービス名、特定できる識別情報、支える業務 |
| 所有者と利用者 | 責任者、アクセスできる人や外部事業者、権限の期限 |
| データと機密性 | 受領、保存、送信する情報と顧客情報の有無 |
| 場所と依存関係 | 所在と、依存する端末・アカウント・サービス |
| 問題が起きた場合の影響 | 漏えい、改ざん、利用不能のどれか、止まる業務 |
| 現在の対策 | 固有のパスワード、MFA、更新を確認済みか。不明は要確認とする |
| 復旧の窓口 | 確認済みの提供元の復旧窓口と、復旧用連絡先の保管場所 |
| 次の対応 | 作業内容、担当者、見直し予定日 |
この通常の台帳に、実際のパスワード、トークン、復旧コードを記載しないでください。これは本記事で定める記録上の境界です。状態と管理された保管場所だけを記録します。助言者と共有する前に、顧客情報や機密のアカウント情報が含まれていないか確認します。
記録から実物を特定でき、利用者を確認できれば、その資産の記入は完了です。「クラウド、安全」だけでは足りません。私用と業務用の資産を兼用する場合は、その関係も記録します。原文は、できるだけ兼用を減らし、共用端末ではアカウントを分けることを勧めています。
3. 実際のデータの流れを一つ追う
進行中の顧客向け業務を一つ選び、順に記入します。
データの入手元：____
処理に使う端末・サービス：____
保存先・共有先：____
アクセスできる人：____
不要になる時点と処理方法：____外部委託先、自動化の連携、コンテンツ生成ツールも確認します。原文7ページのツールに関する節ではSIという語を使い、サービスの把握、保存期間、学習利用、アクセス権、機密保持条件の確認と、生成物の使用前の確認を勧めています。有料プランというだけで、情報が保存や学習に使われないとは判断できません。原文6–7ページ
顧客は、その方法で情報が収集、共有、保管されると想定しているでしょうか。サイバーセキュリティ対策だけで、すべてのプライバシー上の問題を扱えるわけではありません。業務に必要な期間を超える保管は、侵入がなくてもプライバシーリスクを生むことがあります。
4. 対応できる形でリスクを書く
NISTはリスクを、脅威、脆弱性、発生可能性、影響と関連付けています。「ハッカー」とだけ書いても、具体的な対応にはつながりません。原文4、12–13ページ
次の筆者作成の形式で記録し、今最も対応が必要な3件を選びます。3件という数は、着手時の作業量を抑えるためのもので、NISTの指定ではありません。
| リスクの記録 | 記入の手掛かり |
|---|---|
| 資産と事象 | どの資産に、どのような問題が起こり得るか |
| 確認できた弱点 | 発生を可能にする具体的な条件。未確認の想定は分ける |
| 発生可能性の根拠 | 観察事項や露出条件。割合を創作しない |
| 業務への影響 | 提供業務、顧客データ、資金、信用への影響 |
| 現在の対策と不足 | 実施済みの対策と、証拠がない部分 |
| 対応と見直し | 誰が何を行い、どう効果を確かめ、いつ見直すか |
影響が大きく、具体的な弱点が確認できる事項を優先します。判断材料が足りなければ、確認を次の作業にします。独自の点数で精密に見せないでください。原文は、すべての事業に共通する確率や採点基準を示していません。
5. 契約と提供元の責任を記録する
統治の節は、適用される法令、規制、契約上の要件を追跡し、提供元のリスクを評価するよう勧めています。安全対策を委託しても、システムとデータを守る経営者の責任は移りません。原文5–6、11ページ
責任を記録する表に、次の3種類の質問を加えます。
- 義務：どの条項が適用され、どの記録を残し、事故を誰に通知する必要があるか。不明点は適切な専門家に確認する。
- 提供元：誰がアカウントと権限を管理し、誰がバックアップし、問題時にどの確認済み窓口へ連絡するか。
- 利用終了：契約やサービスの利用が終わるとき、権限をどう削除し、不要なデータをどう扱うか。
提供元が安全性をうたっているだけで責任欄を空白にせず、米国の法令名をすべての国や事業に一律に当てはめないようにします。
完了時に残すもの
資産台帳、確認済みのデータの流れ一つ、優先する3件のリスク、義務と提供元について担当者を決めた確認事項を残します。不明点には次の対応を設定し、チェックマークで覆い隠さないようにします。
サービス追加、顧客データの用途変更、雇用開始の際には記録を更新します。事業が複雑になれば専門家の支援も検討します。本記事は、業界ごとの評価、契約の審査、適用法令の判断に代わるものではありません。
続けて第2回：アカウントと業務端末の保護、または第3回：バックアップと事故からの復旧へ進めます。