>
>
公開日
最終更新日
CIAとは、情報セキュリティを支える機密性・完全性・可用性の3要素です。機密性は「許可のない相手に情報を見せない」、完全性は「情報を正確で欠けのない状態に保つ」、可用性は「必要なときに情報やシステムを使える状態に保つ」という意味です。
本記事のポイント
CIAは、機密性・完全性・可用性の頭文字で、情報セキュリティを支える3要素です。
メール誤送信は機密性、データの誤更新は完全性、サーバーダウンは可用性の問題として整理します。
企業は、アクセス権管理、変更管理、バックアップと復元テストを業務への影響に合わせて実施します。
ISMSでは、情報資産ごとに3要素への影響を評価し、対策の担当者・期限・確認方法を決めます。
情報システム部門（情シス）と情報資産の管理責任者に向けて、日常業務の具体例からISMS（情報セキュリティマネジメントシステム）のリスク評価までを順に解説します。初めて読む場合は「CIAとは？情報セキュリティの3要素」の比較表で全体像をつかみ、すぐに着手したい場合は「初回30日の点検チェックリスト」へ進めます。ISMSの担当者は「ISMSで使うCIA評価基準と情報資産の管理手順」から読めます。
情報は2026年10月22日時点です。公的機関の注意喚起や対策例は推奨・手法として、点検日程や台帳の記入例は本記事の運用提案として記載し、法令・契約上の義務と区別します。
CIAとは？情報セキュリティの3要素
3要素を区別しておくと、事故が起きたときに、漏えい・改ざん・停止のどれに備える対策なのかを切り分けられます。
経済産業省のガイドラインは、JIS Q 27000の情報セキュリティの定義として、「情報の機密性、完全性及び可用性を維持すること」を掲載しています。情報を秘密にするだけでは、情報セキュリティの対策範囲を満たせません。正しい情報を、認可された利用者が必要なときに使える状態まで管理します。
機密性・完全性・可用性の比較と具体例
3要素は、守る対象と被害の起こり方で見分けます。
要素 | 意味 | 日常業務の具体例 | 主な対策 |
|---|---|---|---|
機密性 | 認可されていない相手に情報を使用・開示させない性質です。 | 顧客名簿を別の取引先に誤送信する、退職者がSaaSへログインする、共有フォルダを誤って公開する場合です。 | 権限の最小化、多要素認証、アカウント棚卸し、暗号化を行います。 |
完全性 | 情報の正確さと完全さを保つ性質です。 | 受注数量の誤更新、給与データの欠損、プログラムや設定の不正な変更が起きる場合です。 | 入力値チェック、変更履歴、承認、改ざん検知、バックアップを組み合わせます。 |
可用性 | 認可された利用者が要求したときにアクセスし、使用できる性質です。 | サーバー故障、回線障害、ランサムウェアによって受発注や顧客対応が止まる場合です。 | 冗長化、監視、復旧手順、オフラインバックアップ、復元テストを整えます。 |
たとえば、顧客名簿を社外へ持ち出された場合は機密性、住所を誤って上書きした場合は完全性、障害で検索できない場合は可用性が損なわれます。同じ情報資産でも、事故の内容によって評価する要素は変わります。
3要素の関係と優先順位
情シスは、利用部門の業務時間と停止時の影響を聞き取り、3要素の優先順位を決めます。
アクセス制限を厳しくしても、正規の担当者が締切前に必要な資料を取り出せなければ業務は止まります。反対に、利便性を優先して全員へ編集権限を付けると、誤更新や情報持ち出しの範囲が広がります。共有アカウントで制限を回避すると、変更者の特定も難しくなります。
顧客名簿は漏えい、会計データは誤集計、受発注システムは停止による影響を起点に評価します。ただし、会計データにも機密性はあります。重点を置く要素を決めても、残りの要素を評価対象から外さず、各資産について3要素を別々に記録します。
▶ 関連記事: 機密情報とは？個人情報との違いや管理体制・対策を図解で解説
▲ 情報セキュリティの基本3要素である機密性・完全性・可用性の意味、具体例、主な対策の比較。
2026年10月の注意喚起と企業がいま行う点検
2026年10月、国内で不正アクセスによる情報漏えいの公表が相次ぎ、IPAは10月9日に企業向けの注意喚起を出しました。IPAは、特定の製品やサービスの脆弱性を狙った攻撃とは断定されていないとしたうえで、外部に公開しているアプリケーションやサービスの侵害と、アカウントの侵害が起点になっているとみています。情報は2026年10月22日時点のものです。
IPAが挙げる「速やかに行うべき点検」
外部に公開しているアプリケーションの精査：自社で構築・運用している外部公開のアプリやサービスを確認し、直近のログに異常がないかを、直近1か月、その後3か月と段階的に範囲を広げて確認します。未適用の脆弱性対応パッチがあれば、できるだけ速やかに適用します。
利用している外部サービスの洗い出し：クラウドサービスやVPNサービスなどを、部署単位の利用も含めてすべて洗い出します。サービスごとにログの異常と、作った覚えのないアカウントや無効化したはずのアカウントが有効になっていないかを確認します。
保有データの再点検：「不要な情報は持たない」という基本原則のもと、保有する情報資産を正確に把握し、必要最小限にします。
IPAは、異常なログやアカウントが見つかった場合は速やかにセキュリティインシデントと判定し、専門のセキュリティベンダーに詳細調査を依頼するよう強く推奨しています。点検で異常がなかった場合も、認証機能（多要素認証・パスワード）の強化、アカウント棚卸の運用見直し、ログの取得内容と保持期間の見直しなどの対策を検討するよう求めています。
IPAは同じページで、経済産業省の「サイバーセキュリティ経営ガイドライン」にある「経営者が認識すべき3原則」も示しています。
サイバーセキュリティリスクを自社のリスクマネジメントの重要課題と認識し、自らのリーダーシップのもとで対策を進める。
自社だけでなく、国内外の拠点、ビジネスパートナーや委託先など、サプライチェーン全体の対策に目を配る。
平時も緊急時も、関係者と積極的にコミュニケーションをとる。
各機関の注意喚起を「いつ・誰がやるか」で整理した手順は、不正アクセス対策の記事にまとめています。
外部公開アプリ・外部サービス・保有データの点検表
IPAの3つの点検対象に沿って、情シスと各サービスの所有部門で次の一覧を作成します（項目は編集部の提案です）。公開範囲を変える際は、業務で使っている接続を特定してから実施します。
点検対象 | 調べる項目 | 結果に応じた対応 |
|---|---|---|
外部公開アプリ | 公開URL、管理画面、公開の必要性、認証、利用製品、更新状況を整理します。 | 不要な公開は閉じ、業務で必要な公開は認証・アクセス制限・修正の担当と期限を決めます。 |
利用している外部サービス | 所有部門、管理者、連携先、委託先、保存情報、契約終了時の処理を整理します。 | 所有者が不明なら新たなデータ投入を保留し、利用部門を特定して管理対象へ加えます。 |
保有データ | 保存場所、機微性、保存理由、保管期限、複製、バックアップを整理します。 | 保存目的を終えた情報は契約・法令上の保存要件を判断したうえで削除し、継続保管する情報は権限と復旧方法を定めます。 |
経営層は、情シスに点検を任せて終えるのではなく、停止を許容できる業務、追加費用、取引先への連絡責任者を決めます。侵害が疑われる場合は通常の棚卸しから対応を切り替え、不正アクセス発覚時の対応優先順位に沿って初動の順序を整理します。
2026年の統計と投資対象の判断
企業が製品を追加する際は、市場の拡大率ではなく、自社に残る未対策のリスクから導入対象を決めます。
総務省の令和8年版情報通信白書は、IDC Japanのデータとして、2025年の国内セキュリティ製品市場を前年比13.8％増の7,434億3,900万円と掲載しています。この数字は市場全体の売上額であり、自社の安全性や必要予算を示す数値ではありません。
たとえば、バックアップ製品を導入済みでも復元担当者が決まっていなければ、先に復旧手順を整えます。アクセスログを収集していても確認担当がいなければ、検知条件と連絡先を定めます。導入済みの機能、使っていない機能、運用で補う作業を分けてから追加投資を判断します。
▶ 関連記事: シャドーAIとは？情報漏洩リスクと情シス向け検知・対策ガイド
機密性とは？メール・アカウント・データの保護
機密性（confidentiality）とは、認可されていない相手に情報を使用させたり、開示したりしない性質です。
経済産業省のガイドラインが掲載するJIS Q 27000の定義では、対象に個人だけでなく、団体などのエンティティやプロセスも含みます。つまり、人の閲覧権限に加えて、アプリの連携権限や自動処理によるデータ取得も管理対象です。正式な定義は「認可されていない個人、エンティティ又はプロセスに対して、情報を使用させず、また、開示しない特性」です。
メール誤送信と外部共有の対策
顧客情報を送る業務では、宛先と共有対象者を送信・公開の前に限定します。
別の取引先へ見積書を送ったり、顧客名簿を添付したメールを誤送信したりすると、機密性が損なわれます。添付ファイルを共有リンクへ置き換える場合は、認証が必要な共有にし、有効期限と閲覧者を設定します。リンクを知る全員が開ける状態では、転送先まで情報が広がるおそれがあります。
添付ファイルを暗号化する場合も、同じメールにパスワードを書けば、メールを読める相手に両方が渡ります。情報の重要度が高いなら、宛先限定の共有、送信前承認、送信後にアクセスを止められる手段を組み合わせます。誤送信が発覚した際は、削除依頼だけで終えず、公開停止と閲覧・取得履歴の保全を並行して進めます。
アカウントと管理者権限の対策
異動・退職時は、人事情報と各サービスの利用者一覧を照合し、不要なアクセスを止めます。
SaaSに退職者のアカウントが残っている、異動前の編集権限が残っている、外部委託先の利用期限が設定されていない、といった状態を棚卸しで抽出します。停止対象が判明したら、連携処理やデータの所有権を引き継いでから無効化します。共有アカウントやサービスアカウントは、担当者の退職だけで機械的に削除せず、利用目的と接続先を特定します。
管理者の人数に一律の上限は設けません。組織の職務分掌、代替要員、緊急時の対応体制を照合し、管理操作が不要な利用者は一般権限へ変更します。社外から使うメール、VPN、SaaSの管理画面には多要素認証を適用し、緊急用アカウントは通常利用と分けて利用記録を残します。
保存データと通信経路の暗号化
保存時と通信時で暗号化する対象を分け、復号鍵や認証情報の管理者まで決めます。
ALSOKは、機密性を守る技術として、保存データのAES暗号化、通信経路のTLS、メールのS/MIMEやPGPを挙げています。システム担当者は、ストレージの暗号化設定と、利用者・外部サービスとの通信経路をそれぞれ点検します。
暗号化済みでも、正規の権限で大量にダウンロードできれば持ち出しは起こり得ます。鍵の閲覧・変更権限をデータの利用権限から分け、退職や委託終了に合わせて認証情報を失効させます。バックアップも暗号化するなら、障害時に鍵へアクセスできる代替担当者と保管場所を手順書へ記載します。
情報資産台帳へ保管対象を登録する前に、何を機密として扱うかを部門間でそろえます。分類基準の整理には、機密情報の定義・個人情報との違い・管理体制を使い、対象情報と閲覧可能な役割を台帳へ反映します。
完全性とは？データとシステムの正確さの維持
完全性（integrity）とは、情報が正確で、必要な内容が欠けていない性質です。
厚生労働省の資料は、JIS Q 27000に基づく完全性の定義として「正確さ及び完全さの特性」を掲載しています。不正な改ざんに限らず、誤入力、更新漏れ、重複処理、データ破損も完全性を損ないます。情報が社外へ漏れていなくても、売上や在庫が誤っていれば業務判断は変わります。
データの完全性とDBの整合性
データの完全性を保つには、入力値と更新処理の両方で矛盾を防ぎます。
たとえば、受注データの登録だけが成功し、在庫の引き当てに失敗すると、注文と在庫の対応が崩れます。プログラムの設定ミスで処理を二重実行した場合は、同じ注文が重複登録されるおそれもあります。複数の更新を一まとまりとして扱うDBのトランザクションを設計し、途中で失敗した際の取り消し処理を実装します。
金額や数量には範囲チェックを設け、必須項目、重複禁止、関連データの参照関係を制約として定めます。外部サービスとの連携では一度に取り消せない処理もあるため、再送時に重複させない識別子と、途中失敗を検出する照合処理を用意します。担当者は件数だけでなく、合計金額、未処理件数、注文と出荷の対応も照合します。
システムの完全性と変更管理
システムの完全性とは、プログラムや設定が承認された内容と一致し、意図しない変更や欠損がない状態です。
対象にはソースコード、実行ファイル、クラウドの権限設定、ファイアウォールのルール、ジョブの実行設定などが含まれます。プログラムの計算式や接続先を誤って変更すると、保存データまで誤更新されます。変更者・承認者・変更日時・理由を記録し、変更前後の差分と切り戻し方法を保存します。
重要な設定は管理画面の手作業だけにせず、エクスポートや構成管理で変更内容を残します。緊急変更は事前承認が難しい場合でも、作業記録を保存して事後レビューへ回します。
ハッシュ値と操作ログによる変更検知
ファイルの変更検知には、信頼できる基準値とのハッシュ比較と、変更者を追う操作ログを組み合わせます。
ハッシュ値は、ファイルの内容から計算する値です。保護された場所へ正常時の値を保存し、現在の値と比較すれば内容の変化を検出できます。ただし、比較元の値まで書き換えられると検知できません。また、値が一致しても、登録時点の内容が業務上正しかったとは証明できません。基準値の保護と業務データの照合は別の作業として実施します。
管理操作を追跡するなら、誰がアクセスしたかに加え、どの操作を記録し、誰が異常を判定するかを定めます。
復元後のデータを判定する合格条件
復元テストでは、ファイルが開けるかではなく、業務処理とデータの整合性が戻ったかを判定します。
受発注システムなら、指定時点の注文検索、在庫引当、出荷指示を実行し、関連するデータの件数と対応関係を照合します。会計データなら、仕訳明細と集計結果の一致を業務部門が判定します。不一致があれば、そのバックアップを復旧に使う前に原因を特定し、取得時点や復元手順を見直します。
可用性とは？システム停止とデータ利用への備え
可用性（availability）とは、認可された利用者が必要なときに情報やシステムへアクセスし、使用できる性質です。
経済産業省のガイドラインは、JIS Q 27000の可用性を「認可されたエンティティが要求したときに、アクセス及び使用が可能である特性」と定義しています。サーバーが動いていても、認証基盤や回線が止まってログインできなければ、利用者から見た可用性は失われます。
システムの可用性とインフラ対策
停止を許容できない業務では、サーバー・回線・電源・認証のどこが止まると利用不能になるかを調べます。
サーバー故障にはハードウェアの冗長化、回線障害には代替回線、停電にはUPSを用意します。UPSは短時間の電源維持や安全な停止に使い、長時間停電への備えは別途設計します。冗長機器が同じ電源や拠点へ集中していれば、共通の障害で両方が停止するため、切替先の独立性も点検します。
ALSOKは可用性の対策例としてUPSの設置とディザスタリカバリ計画を挙げています。機器を追加した後は、切り替え中に業務処理が継続するか、担当者が手順どおり復旧できるかを試験します。
データの可用性とバックアップ
データの可用性を確保するには、複製を持つだけでなく、障害や攻撃から独立した復元経路を用意します。
手段 | 主に備える問題 | 注意点 |
|---|---|---|
冗長化 | 機器故障時の停止を短くします。 | 誤削除や暗号化が複製先にも反映される構成では、正常なデータへ戻せません。 |
世代バックアップ | 過去の時点へ戻し、誤更新や破損から復旧します。 | 復元には時間がかかるため、取得間隔と復旧目標を合わせます。 |
オフラインバックアップ | 稼働環境から到達されにくい復元用データを残します。 | 保管媒体、更新手順、復号鍵、取り出す担当者を管理します。 |
代替業務 | 復旧中も受注や顧客対応を続けます。 | 復旧後の二重登録を防ぐため、記録の照合と再入力の責任者を決めます。 |
バックアップの成功通知だけで復旧可能と判定してはいけません。保存先へ入る認証情報、復元先の容量、ライセンス、復号鍵、連携先への接続までそろえて復元を試します。SaaSでは、CSVを出力できても添付ファイルや権限、変更履歴が戻らない場合があるため、必要な復元範囲を先に定めます。
ランサム攻撃と業務継続の対策
ランサム攻撃への備えでは、業務停止と情報持ち出しを別々の被害として評価します。
IPAは2026年1月29日公表の「情報セキュリティ10大脅威 2026」で、組織向け脅威の1位に「ランサム攻撃による被害」を挙げ、2016年から11年連続11回目の選出としています。同資料では、3位の「AIの利用をめぐるサイバーリスク」が初選出され、8位に「リモートワーク等の環境や仕組みを狙った攻撃」が入っています。
復旧計画では、復旧までの目標時間と、どの時点までのデータ損失を許容するかを分けます。受発注が止まるなら、電話・メール・紙帳票のどれで受注を続けるかを業務部門が決め、情シスは復旧順序と連絡先を手順書へ記載します。持ち出しが疑われる場合は、バックアップで業務が戻っても、漏えい調査や取引先対応を終了しません。
AIサービスへ入力する情報も管理対象に含めます。利用部門が承認外のサービスへ機密情報を入力する経路を整理する際は、シャドーAIによる情報漏洩リスクと情シス向け検知対策を参照し、利用可能なサービスと入力禁止情報を社内ルールへ反映します。
ISMSで使うCIA評価基準と情報資産の管理手順
ISMSの担当者は、情報資産ごとにCIAが損なわれた場合の影響を評価し、脅威と弱点を加えて対策の順序を決めます。
ISMSは、組織が情報セキュリティの管理状態を点検・改善しながら続けるための仕組みで、日本語では情報セキュリティマネジメントシステムと呼びます。ISOはISO/IEC 27001:2022を要求事項として公開し、経済産業省は2023年9月20日にJIS Q 27001の改正を公表しています。
ISMSの規格要求と、組織が選ぶ採点方法は区別します。3段階評価は実務で使う方法の一つで、すべての組織へ同じ点数計算を義務付けるものではありません。評価の基準と受容できるリスクを定め、担当者が変わっても同じ理由で判定できるように記録します。
情報資産の洗い出しと責任者の設定
台帳には情報そのものと、それを保存・処理するサービスや機器の関係を記載します。
顧客情報、見積書、会計データ、ソースコードを登録し、利用するSaaS、サーバー、PC、ネットワーク機器へひも付けます。所有部門、管理責任者、保管場所、利用者、委託先、保存期限も記載します。サービスの一覧だけでは、どの障害がどの情報へ影響するかを判断できません。
台帳を作る段階では、担当不明の資産を除外せず「責任者の決定待ち」として残します。業務部門が利用目的と必要な情報を決め、情シスが技術的な対策と復旧方法を記載します。情報の分類は前述の機密情報の解説とそろえ、同じ顧客情報に部門ごとで異なる公開基準を付けないようにします。
CIAの3段階評価と判定理由
3段階評価を採用する場合は、3を重大な影響、2を一定の影響、1を影響が小さい状態として定義します。
Codebookは、IPAの方法を参考にした資産評価の例として「3＝重大な影響、2＝一定の影響、1＝影響が小さい」というスコアを紹介しています。以下は、本記事で採用する運用例として、この3段階を業務の判定へ置き換えた記入基準です。影響額や停止時間の境界は、自社の契約と業務条件に合わせて決めます。
点数 | 機密性が失われた場合 | 完全性が失われた場合 | 可用性が失われた場合 |
|---|---|---|---|
3：重大な影響 | 機微な情報が流出し、顧客対応や事業継続へ重大な影響が出ます。 | 誤った会計・請求・出荷などが発生し、重大な損失につながります。 | 主要業務が止まり、許容時間内に代替できません。 |
2：一定の影響 | 限定的な範囲でも、関係者への対応や契約上の調整が発生します。 | 照合や修正が必要ですが、対象を特定して業務を回復できます。 | 業務が遅れますが、代替手段で一定期間は継続できます。 |
1：影響が小さい | 公開済み情報などで、追加的な影響が小さい状態です。 | 再取得や再作成が容易で、判断・取引への影響が小さい状態です。 | 停止しても、主要業務への影響が小さい状態です。 |
3要素の点数を単純に合計すると、一つの重大な影響が平均化される場合があります。本記事の運用例では、いずれかに3が付く資産を先にレビューし、評価理由と依存するシステムを読み合わせます。すべてを3にそろえず、事故が起きたときの対象範囲と代替手段を書いて差を付けます。
脅威・弱点・残るリスクの記録
CIAの点数は影響の評価なので、発生しやすさや管理上の弱点と合わせて対応を決めます。
対象資産について、漏えい・改ざん・停止による業務への影響を記載します。
不正ログイン、誤操作、故障などの脅威と、残存アカウント、未修正の機器、単一回線などの弱点を対応付けます。
既存対策を記録し、対策の不足に対して担当者・期限・完了条件を設定します。
対策後に残るリスクを責任者が判断し、追加対策または受容の理由を残します。
リスク管理の手引きにはISO/IEC 27005:2022、管理策の検討にはISO/IEC 27002:2022を参照できます。利用製品の脆弱性情報は、脆弱性対策情報データベースJVN iPediaで調べ、該当する製品があれば資産台帳の管理者へ修正判断を回します。
取引先向けの対策項目も整理する場合は、SCS評価制度の★3に向けたチェックリストの解説を別の確認資料として扱います。CIAの資産評価やISMSのリスクアセスメントを、このチェックリストの実施だけで代替しません。
▶ 関連記事: ISO/IEC 27001とは？ISMS最新基準の改正点と情シスの実務対応
▲ 情報資産が損なわれた際の事業影響に応じたISMSの3段階評価判定フロー。
情報セキュリティ7要素とCIAの補完関係
「情報セキュリティの7要素」と呼ばれる整理は、CIAに真正性・責任追跡性・否認防止・信頼性の4特性を加えたもので、本人性や操作の証拠まで扱えますが、固定した唯一の正式名称ではありません。
JNSAの2009年資料は、情報セキュリティに含めてもよい特性として真正性・責任追跡性・否認防止・信頼性を掲載しています。この4要素は、2009年の資料に基づく整理であり、現行のISMS認証要件として扱うのではなく、ID管理や操作ログの設計漏れを防ぐ補助観点として使います。
追加の要素 | 業務での意味 | 対策の例 |
|---|---|---|
真正性 | 利用者や情報が、主張している本人・本物と一致している性質です。 | 本人認証、電子署名、接続先の証明書を使います。 |
責任追跡性 | 操作を特定の利用者や処理まで追跡できる性質です。 | 個人別ID、操作ログ、時刻の同期で記録を対応付けます。 |
否認防止 | 実行した操作や取引を、後から否定されないよう証拠を残す性質です。 | 電子署名、送受信記録、改変しにくい証跡を残します。 |
信頼性 | 意図した動作や結果を一貫して得られる性質です。 | 処理結果の照合、動作試験、異常監視を行います。 |
たとえば、アクセス権を制限しても共有IDで更新していれば、誰が変更したかを追えません。顧客マスタの編集者を個人別IDへ切り替え、変更履歴と承認記録を対応付ければ、完全性と責任追跡性を一緒に扱えます。ログには個人情報や機密情報が含まれる場合があるため、閲覧権限と保存期限も設定します。
初回30日の点検チェックリストと資産台帳の記入例
初回点検では、対象の把握、不要なアクセスの是正、重要業務の復元テストの順に進め、結果を台帳へ残します。
以下の30日間は本記事の運用例です。侵害が疑われる場合はこの日程を待たず、初動対応へ切り替えます。通常の点検では、情シスが一覧を集め、業務部門が必要性と影響を判定し、権限変更や復旧の担当者を確定します。
点検の順序と担当の割り振り
対象を把握してから権限を変更し、最後に復旧を実演すると、業務への影響を追いながら是正できます。
期間の目安 | 担当 | 実施内容 | 完了条件 |
|---|---|---|---|
1〜7日目 | 情シスと各部門の管理者 | 外部公開アプリ、外部サービス、保有データ、管理者を一覧化します。 | 重要業務が使うサービスと情報の所有部門を特定します。 |
8〜14日目 | 人事、所有部門、情シス | アカウント・権限・共有範囲・認証設定を照合し、不要なアクセスを止めます。 | 停止・変更の記録と、継続利用する権限の理由を残します。 |
15〜21日目 | 業務責任者と情シス | CIA評価、停止許容時間、復旧目標、変更履歴の取得方法を決めます。 | 優先する資産と復元テストの合格条件を承認します。 |
22〜30日目 | 復旧担当と業務判定者 | 重要業務1件を復元し、データと業務処理を照合します。 | 結果、所要時間、不具合、再テスト予定を記録します。 |
確認先と判断をそろえたチェックリスト
各項目は確認だけで終えず、是正する条件と業務を維持する条件を記録します。
管理者権限の棚卸しと最小化：各SaaSのユーザー・権限管理から一覧を出します。職務上の必要性、代替要員、緊急時の体制を照合し、管理操作が不要な人は一般権限へ変更します。必要な権限は人数で削らず、役割と承認者を記録します。
退職者・休職者・委託終了者の照合：人事一覧とサービスの利用者一覧を突き合わせます。利用根拠のないアカウントは停止し、休職者や外部協力者は利用方針と契約期間に沿って権限を調整します。連携用IDなら、処理の移管後に認証情報を切り替えます。
外部共有リンクの点検：SharePoint、Google Driveなどの管理画面で公開範囲を調べます。期限のない共有は所有部門へ用途を照会し、継続利用するなら宛先と期限を設定し、用途がなければ公開を止めます。
多要素認証の適用状況：VPN、メール、管理画面の認証設定を調べます。利用できる経路は有効化し、対応できない経路は接続元制限などの代替策と見直し期限を記録します。
重要データの変更履歴：顧客マスタ、給与、受発注のログを調べます。変更者と変更内容を追えるならレビュー担当を決め、追えなければ編集権限を絞り、履歴を取得する方法を整えます。
復元テストの記録：直近1年以内の記録を初回点検の入口として調べます。記録がなければ最重要業務1件で計画し、記録があってもシステム構成や復旧目標が変わっていれば再テストします。
資産評価と復元テストの記入例
情報資産台帳には、点数だけでなく評価理由と復旧を判定する業務担当を残します。
次の表は架空の記入例です。高・中・低を3・2・1に対応付けています。停止許容時間は例示であり、実際には業務の締切、契約、代替手段を基に決めます。復元テストの日付と結果は、実施後に記入します。
資産・所有部門 | 保管場所 | C・I・A | 主な評価理由 | 停止許容時間 | 復旧担当・業務判定者 | 復元テスト合格条件 |
|---|---|---|---|---|---|---|
顧客名簿・営業部 | SaaSのCRM | 3・2・2 | 連絡先流出の影響が大きく、検索停止時は承認済みの代替手段を使います。 | 24時間 | 情シスの復旧担当・営業責任者 | 指定時点の顧客検索とCSV出力ができ、権限が想定どおりです。 |
受発注システム・物流部 | オンプレミスのサーバー | 2・3・3 | 在庫不整合と出荷停止が取引へ直結します。 | 4時間 | 情シスの復旧担当・物流責任者 | 注文検索、在庫引当、出荷指示を実行でき、注文と在庫が整合します。 |
会計データ・経理部 | クラウドストレージ | 3・3・2 | 機微な取引情報を含み、数値の誤りが決算へ影響します。 | 48時間 | 情シスの復旧担当・経理責任者 | 指定月の仕訳明細がそろい、集計結果が基準データと一致します。 |
台帳にはこのほか、外部委託先、保存期限、バックアップの取得間隔、最終テスト日、実測した復旧時間を記載します。復旧時間が目標を超えた場合は、データ量、転送時間、認証、作業待ちのどこで時間を使ったかを切り分けます。不合格なら原因・対処内容・再テスト日を追記し、業務部門が再判定します。
初回点検後のレビュー頻度
レビュー間隔は、資産の重要度、変更頻度、停止許容時間、法令・契約上の要件を基に設定します。
管理者の入れ替わりが多いSaaSや外部共有を頻繁に使うストレージなら、四半期ごとを運用例としてアクセス権を見直します。復元テストも年1回を出発点にしつつ、構成変更やバックアップ方式の変更後は次回の定期日を待たず実施します。人事異動、委託先変更、新しい外部連携の追加は、その都度台帳を更新する契機にします。
▶ 関連記事: 【SCS評価制度対応版】セキュリティチェックシートの作り方｜経産省ガイドライン準拠
▲ 初回30日間で資産把握から復元テストまでを完了させる点検の推進ステップ。
まとめ
情報セキュリティは、機密性・完全性・可用性（CIA）を維持することです。漏えい・改ざん・停止のどれに備える対策かを資産ごとに分けて評価します。
2026年10月のIPAの注意喚起は、外部公開アプリの精査、利用している外部サービスの洗い出し、保有データの再点検を速やかに行うよう求めています。
初回の点検では、外部公開資産と管理者権限・退職者アカウントの是正から始め、重要業務1件の復元テストまでを担当と期限付きで進めます。
まとめ
情報セキュリティの3要素であるCIAは、機密性で情報の開示先を制限し、完全性で正確さと欠けのない状態を保ち、可用性で必要なときの利用を支えます。情シスは、各資産の業務への影響を評価し、権限管理、変更管理、復旧手順を担当者と期限へ落とし込みます。
明日は、重要業務を一つ選び、使っている外部サービスと保有データ、管理者、バックアップの所在を台帳へ記入します。その業務の責任者と停止許容時間を決め、不要なアクセスの是正と復元テストの日程を確定します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
