ISMSの情報資産とは？定義・具体例・管理方法を徹底解説【ISO27001対応】

「ISMSにおける“情報資産”って具体的に何を指すの？どこまで管理対象に含めればいいの？」
このような疑問を持つ担当者は少なくありません。

情報セキュリティの国際規格であるISO27001では、情報資産の特定と管理がリスクアセスメントの起点となり、認証審査でも最も重視されるポイントです。ところが、情報資産の範囲を曖昧にしたまま台帳を作成すると、審査で不適合を指摘されたり、実務で管理が形骸化してしまうリスクがあります。

この記事では、情報資産の定義や境界判断の基準から、紙情報・電子データ・ハードウェア・ソフトウェア・クラウドサービス・外部委託といった具体例まで体系的に整理します。さらに、洗い出しの手順やヒアリングのコツ、リスクアセスメントとの関係、管理台帳の作り方と運用方法、そしてよくある失敗事例とその対策までを実務目線で解説します。

最後までお読みいただくことで、情報資産管理の全体像を理解し、ISMSを効果的に運用するための実践的な知識が身につきます。セキュリティレベルを高め、組織の信頼性を強化するための第一歩として、ぜひ参考にしてください。

1.ISMS（ISO27001）における「情報資産」とは何か

(1) 情報資産の定義

ISMS（ISO/IEC 27001）における「情報資産」とは、組織にとって価値があり、保護すべき情報およびそれを扱う媒体・仕組みの総称を指します。

単なる「情報（データ）」だけでなく、保存・処理・伝送・活用するための媒体や仕組みも対象です。

【流れ】

• 個人情報が記載された帳票（情報＋紙媒体）
• 顧客データを扱うサーバ（情報処理設備）
• SaaSのCRMサービス（情報処理の仕組み）
• ソフトウェア（情報を扱うロジック）

(2) どこまでを情報資産とみなすか

判断基準は 「機密性」「完全性」「可用性」 のいずれかが損なわれた場合に、組織の事業継続や信用に影響を及ぼすかどうかです。

(3)情報資産と“その他の資産”の違い

ISO/IEC 27001:2022では、資産を複数カテゴリに分類します。
その中で 「情報資産」＝リスクアセスメントの起点 として最重要視されます。

2.ISMSで洗い出すべき情報資産の具体例一覧

ISMSでは、情報が生成・保管・利用・転送されるライフサイクル全体を考慮し、媒体や利用形態ごとに分類して洗い出すことが重要です。以下に、審査員が確認するレベルの具体例を整理します。

(1)紙情報

(2)電子データ

(3)ハードウェア

(4)ソフトウェア

(5)クラウドサービス・SaaS

(6)業務委託・外部プロバイダ関連

このように、紙・電子・ハード・ソフト・クラウド・外部委託の6分類で整理すると、漏れなく情報資産を洗い出すことができます。

3.情報資産の洗い出し方とポイント（台帳作成の前準備）

(1) 洗い出しの目的（リスクアセスメントへの連動）

情報資産の洗い出しは単なる棚卸しではなく、リスクアセスメントの起点とすることが目的です。

【流れ】

• 情報資産を特定
• 資産に対する脅威を特定
• 脆弱性を把握
• リスクを評価

不十分な洗い出しは、リスクアセスメントを形骸化させ、管理策の有効性を失わせます。

(2)抜け漏れを防ぐ手順

(3)現場ヒアリング・棚卸しのコツ

• 所有者の特定：業務責任者を情報資産のオーナーとする（IT部門が必ずしも所有者ではない）。
• 質問の工夫：「何を使っていますか？」ではなく「日々の業務で情報を扱うタイミングは？」と聞く。
• 残存コピーの確認：PCローカルや個人のクラウドに残るデータをチェック。
• 個人契約SaaSの確認：Chatwork、Notion、Dropboxなど、個人が契約しているサービスは漏れやすい。
• 重複管理の許容：コピーと原本が異なる部門にある場合、それぞれ台帳に記載。

(4)Saas・外部委託での注意点

このように、リスクアセスメントを起点とした洗い出し → 手順の体系化 → ヒアリングの工夫 → SaaS・外部委託の責任境界確認という流れで進めることが、ISMSにおける情報資産管理の正しいアプローチとなります。

4.情報資産とリスクアセスメントの関係

(1)情報資産 → 脅威 → 脆弱性 → リスク の流れ

ISMSにおけるリスクアセスメントは、情報資産を起点に「脅威 → 脆弱性 → リスク」を評価するプロセスで構成されます。

【流れ】

• 情報資産を特定（例：顧客データベース）
• 脅威を特定（例：不正アクセス、盗難、誤操作、火災）
• 脆弱性を特定（例：パスワード未設定、パッチ未適用、持ち出しルール不備）
• リスクを評価（例：顧客情報漏洩、業務停止）
  →リスク=資産の価値×脅威の発生可能性×脆弱性による影響度

実務上は「資産 → 典型脅威 → 典型脆弱性」のセットをテンプレ化しておくと、審査対応や管理策の紐付けが容易になります。

(2)情報資産ごとの典型的なリスク例

 (3)重要度（機密性・完全性・可用性）評価の考え方

情報資産の「価値」を定量的に評価するために、CIA（Confidentiality、Integrity、Availability）を用います。

実務では「低・中・高」の3段階評価を行い、その組み合わせをリスクレベル決定の基礎とします。

審査では「なぜその評価になったのか」という理由の説明が求められるため、業務影響ベースで判断するようにしましょう。

5.情報資産管理台帳とは？目的と役割

(1) 管理台帳の概要

情報資産管理台帳とは、特定されたすべての情報資産について、識別情報・所有者・重要度（CIA）・保管場所・管理状況などを網羅的に記載・管理する文書です。

ISMSの中核をなす文書の一つであり、リスクアセスメントシートや適用宣言書など他の管理文書の基盤となります。また、これは単なるリストではなく、「リスクアセスメントのインプット」かつ「運用・審査の中心資料」として機能します。

企業ごとに形式は異なりますが、必須要素は「資産情報 × 管理に必要な属性（責任・場所・重要度）」のセットです。

(2)なぜ必要なのか（審査視点と運用視点）

情報資産管理台帳は、審査対応の必須証跡であると同時に、日常運用の中心資料として機能し、ISMSの有効性を支える基盤となります。

6.情報資産管理台帳に必要な項目とフォーマット例

(1) 記載すべき項目（所有者／保管場所／重要度など）

情報資産管理台帳は、単なるリストではなく リスクアセスメントのインプット かつ 審査・運用の中心資料です。

以下の項目が必須であり、これらが欠けると審査で高確率で指摘されます。

(2)フォーマット例

Excelやスプレッドシートでの管理が一般的です。以下は実務でよく採用される構成例です。

 (3)帳の更新・レビューのルール化

情報資産管理台帳は「生きている文書」であり、更新ルールが不明確だと運用が破綻します。

【変更管理】

• 新規導入（SaaS追加、端末購入）
• 廃止（利用停止、端末廃棄）
• 設定変更（バックアップ範囲、アクセス権変更）
  →ISMS事務局へ通知するルールを必ず作成

【定期レビュー】

• 年1回または半期ごと
• 事業部ごとの棚卸し会議でCIA評価の妥当性を確認

【部門連携】

• クラウド・端末・紙の管理者が異なるため、システム部門・総務部門との連携を明文化することで漏れを防止

このように、必須項目を整理した台帳と更新ルールを組み合わせることで、審査対応と運用定着の両面で有効な情報資産管理が可能になります。

7.情報資産の管理運用方法

(1) 管理レベルの設定（資産ごとに管理の強度を変える）

全資産を同じ厳しさで管理すると非効率であり、台帳も破綻します。そこで、CIA評価（機密性・完全性・可用性）に基づき、管理レベルを階層化します。審査で見られるポイントは「重要度に応じて管理策が変わっているか」「リスクアセスと矛盾していないか」です。

(2)変更管理・追加削除のルール

情報資産はライフサイクル全体で管理します。ISMS運用の失敗の多くはここで発生するため、ルール化が必須です。

【追加（新規導入）】

• 新規PC／サーバ／SaaSアカウント発行、業務委託開始
• 利用開始前に必ず登録 → CIA評価 → アクセス権限設定 → 管理台帳へ反映

【変更】

• 保管場所変更、所有者変更、権限変更、バックアップ設定変更
• 変更申請書に基づき台帳修正、履歴を残すことで審査評価が高まる

【削除（廃止）】

• 退職者アカウント停止、端末廃棄、サービス契約停止
• 証跡（廃棄証明書、退職者処理記録）を必ず保管
• 特にクラウドは「退職者一覧とSaaSユーザ一覧の照合」を半期ごとに実施

(3) 廃棄手順（紙・電子・ハードウェアの３種類）

廃棄は機密性維持の最終防衛線であり、審査で必ず確認されます。

(4)クラウド資産の管理上の注意点

クラウド事故は審査で最も警戒される領域であり、特別な運用ルールが必要です。

• アカウントアクセス権限の定期レビュー（四半期ごと）
• 管理者アカウントの明確化・共有禁止
• 二要素認証の徹底
• 外部共有リンクの管理（放置防止）
• 契約プラン変更時の台帳更新
• 利用終了時のデータ引き上げ手順を明文化
• AWS/Azure/GCPの設定ファイル（IaC）も情報資産としてバージョン管理し、変更履歴を追えるようにする

特に「外部共有リンクの放置」は審査で頻出の指摘事項であり、四半期ごとの権限棚卸しをルール化すると運用が安定します。

8.情報資産管理台帳の失敗事例とその対策

ISMSの運用で頻発する失敗事例と、その実務的な対策を整理します。審査現場でも指摘されやすい典型例をまとめました。

(1) 台帳が複雑化して運用不能になるケース

(2) SaaSの管理漏れ（最も多い不適合）

(3) 「情報資産＝機器一覧」になってしまう問題

(4) 対策まとめ（フォーマット整理・責任者明確化など）

• 台帳を「使える量」に減らし、余計な項目を排除する
• 部門ごとに資産管理責任者（オーナー）を明確化する
• 変更管理フローを必ず文書化する
• SaaS・クラウドは専用の管理観点を設定する
• 年1回の棚卸しを必ず行い、証跡を残す
• ISMS事務局は形式的管理を担い、実質的責任は現場の所有者に委ねる

これらを徹底することで、審査での指摘が大幅に減り、運用事故も防止できます。

9.まとめ

本記事では「ISMS（ISO27001）における情報資産」をテーマに解説しました。
要点をまとめておきましょう。

情報資産の定義と範囲について、以下を解説しました。

• 情報資産とは「組織にとって価値を持ち、保護すべき情報およびそれを扱う媒体・仕組み」の総称である
• 境界判断は「機密性・完全性・可用性（CIA）」の観点で行う
• 情報資産とその他の資産の違いを明確にし、付属書Aの分類に沿って整理する

洗い出すべき情報資産の具体例について、以下を示しました。

• 紙情報（契約書、申込書、議事録など）
• 電子データ（顧客DB、設計図、バックアップ、メールログなど）
• ハードウェア（PC、サーバ、ネットワーク機器、記録媒体など）
• ソフトウェア（業務システム、セキュリティソフト、開発ツールなど）
• クラウドサービス・SaaS（CRM、グループウェア、ストレージなど）
• 業務委託・外部プロバイダ関連（BPO、データセンター、クラウド事業者など）

情報資産の洗い出し方とポイントについて、以下を解説しました。

• 洗い出しはリスクアセスメントの起点であり、形骸化を防ぐために重要
• 業務プロセス起点と物理配置起点の二段階で網羅性を高める
• 現場ヒアリングでは「業務で情報を扱うタイミング」を聞くことが有効
• SaaSや外部委託は責任境界を明確にすることが必須

情報資産とリスクアセスメントの関係について、以下を整理しました。

• 情報資産 → 脅威 → 脆弱性 → リスクの流れで評価する
• 資産ごとの典型的なリスク（紙・電子・ハード・クラウド）を把握する
• CIA評価を「低・中・高」で行い、業務影響ベースで判断する

情報資産管理台帳の役割とフォーマットについて、以下を解説しました。

• 台帳は資産の識別情報・所有者・保管場所・重要度・管理策を記載する中核文書
• 審査視点では「資産の目録（A.8.1）」の証跡として必須
• 運用視点では責任の明確化、迅速な対応、バックアップ範囲の可視化に役立つ
• フォーマット例と更新・レビューのルール化を示し、定期棚卸しや変更管理を必須とする

管理運用方法と失敗事例の対策について、以下を解説しました。

• 管理レベルを「高度管理・通常管理・簡易管理」の3段階に分ける
• 追加・変更・削除のルールを明文化し、証跡を残す
• 廃棄は紙・電子・ハードごとに証跡を台帳へ紐付ける
• クラウド資産は四半期ごとの権限棚卸しや外部共有リンク管理が必須
• 失敗事例（台帳の複雑化、SaaS管理漏れ、機器一覧化）を防ぐため、粒度調整・責任者明確化・クラウド専用項目の追加を行う

本記事を参考に、情報資産の定義から洗い出し、リスク評価、台帳作成、運用、失敗防止までの流れを理解し、ISMSの有効性を高める取り組みを進めていただければ幸いです。