情報資産台帳は、ISMS構築のなかで最も「作れるが維持できない」文書です。初回は気合いで数百行を埋められます。問題はその半年後で、システムが増え、SaaSが入れ替わり、部門が再編されても台帳は初回のまま。内部監査で「更新されていない」と指摘され、審査の直前に慌てて手を入れる——この循環に入ると、台帳はリスクアセスメントの土台としての機能を失います。
原因のほとんどは、最初の粒度設計にあります。細かすぎる台帳は更新できません。粗すぎる台帳はリスクアセスメントに使えません。この2つの失敗の間に、維持可能で、かつリスクの単位として意味のある粒度があります。
本記事は、台帳の粒度・範囲・評価・更新の4点を実務の手順として整理します。前提となる適用範囲は ISMS適用範囲の決め方、この台帳が入力になるリスクアセスメントは 箇条6 計画｜リスクアセスメントと情報セキュリティ目的、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。
なぜここでつまずくのか
1. 「資産」を「モノ」と読んでしまう
情報資産という言葉から、多くの人はPC・サーバ・USBメモリといった物理的な装置を思い浮かべます。その結果、台帳が**資産管理台帳（固定資産の一覧）**になります。ところがISMSが守る対象は情報そのものであり、装置はその置き場所にすぎません。「ノートPC 47台」という行からは、何のリスクも導けません。「そのPCに何が入っているのか」が問われるべき情報です。
2. 網羅性を先に追いかけてしまう
「漏れがあると指摘される」という不安から、まず全部書こうとします。結果として行数が膨張し、1行あたりの記述が薄くなり、更新コストが跳ね上がります。台帳の目的はリスクアセスメントの単位を定めることであり、資産の完全な一覧を作ることではありません。
3. 評価尺度を決めずに評価を始める
機密性・完全性・可用性を3段階で評価する、という枠だけ決めて記入を始めると、評価者ごとに基準がずれます。同じ「顧客データ」に対して、営業は機密性3、開発は機密性2と付ける。この台帳から出るリスク値は比較できません。
4. 更新の仕組みを設計していない
「年1回見直す」とだけ決めた台帳は、年1回の作業が誰の仕事にもなっていないため、実際には更新されません。更新は日付ではなくイベントに紐づける必要があります。
何を決めるのか
台帳を作り始める前に、次の4つを決めます。ここを決めずに記入を始めると、途中で方針が変わり、全行の書き直しになります。
| 決めること | 選択肢 | 推奨 |
|---|---|---|
| 粒度（1行の単位） | 個体単位／情報の種類×保管場所／業務プロセス単位 | 情報の種類 × 保管場所（システム） |
| 範囲 | 電子データのみ／紙を含む／人の知識を含む | 電子・紙・属人的な知識まで（後述） |
| 評価軸 | C・I・Aの3軸／重要度1軸 | C・I・Aの3軸。尺度の定義を文言で書く |
| 更新トリガー | 定期のみ／イベント駆動 | イベント駆動＋年次の棚卸し |
粒度の原則は「管理策を同じくする単位でまとめる」ことです。ノートPC 47台は、同じ端末管理ポリシー・同じ暗号化設定・同じ持出しルールで管理されているなら、1行で構いません。逆に、同じ「顧客データ」でも、本番DBにあるものと、サポートがダウンロードして手元に置いているCSVでは、管理策がまったく違います。これは2行に分けるべきです。
判断の目安を表にすると次のようになります。
| 台帳の行 | 良し悪し | 理由 |
|---|---|---|
| 「ノートPC（営業部 12台）」 | 可 | 同一の管理策で運用される端末群。1行で足りる |
| 「ノートPC-0047（山田）」 | 不可 | 個体を書くと数百行になり、異動のたびに更新が必要 |
| 「顧客データ」 | 不可 | 粗すぎる。どこにあるかが書かれておらず管理策に落ちない |
| 「患者情報（本番DB／クラウド）」 | 良 | 情報の種類と保管場所が特定でき、管理策が導ける |
| 「患者情報（サポート用ファイル共有）」 | 良 | 同じ情報でも保管場所が違えば別のリスクになる |
| 「ソースコード（GitHub Organization）」 | 良 | SaaS上の情報資産。アクセス権と外部公開設定が論点になる |
| 「業務委託契約書（原本／本社金庫）」 | 良 | 紙の資産。物理的管理策の対象 |
台帳に含める範囲は、次の5分類で考えると漏れが出にくくなります。
| 分類 | 例 | 見落とされやすいもの |
|---|---|---|
| 電子データ | 本番DB、バックアップ、ログ、設計書、ソースコード | ログとバックアップ。本体だけ書いて複製先を落とす |
| SaaS上のデータ | チケット管理、CRM、チャット、ファイル共有 | チャットに貼られた顧客データ。統制外で最も溜まる |
| 紙媒体 | 契約書原本、押印済み申請書、受領書 | 電子化後も残っている原本 |
| ソフトウェア・サービス | OS、ミドルウェア、自社アプリケーション | 可用性の観点で台帳に載せる必要がある |
| 人・知識 | 運用手順の暗黙知、障害対応のノウハウ | 属人化しているノウハウ。可用性リスクとして立つ |
最後の「人・知識」は省略されがちですが、「その人が抜けたら本番環境の復旧ができない」という状態は、可用性に対する実在のリスクです。台帳に1行置いておくと、リスクアセスメントで「手順の文書化」という対応が自然に導けます。
実務の手順
手順1：評価尺度を先に定義する
台帳を1行も書く前に、C・I・Aそれぞれの尺度を文言で定義します。ここが全体の品質を決めます。数字だけの尺度（1〜3）は必ず解釈がぶれるため、判定できる文言を付けます。
| 評価 | 機密性（漏えいしたら） | 完全性（改ざん・欠落したら） | 可用性（使えなくなったら） |
|---|---|---|---|
| 3（高） | 患者・利用者本人に回復不能な不利益。監督官庁への報告や公表が必要 | 診療・治療の判断を誤らせる。監査証跡として成立しなくなる | 顧客の業務が停止する。数時間の停止も許容されない |
| 2（中） | 顧客・取引先への報告が必要。契約上の問題が生じる | 業務のやり直しが発生する。訂正で回復可能 | 社内業務に支障。1営業日程度なら代替手段がある |
| 1（低） | 公開情報、または漏えいしても実害がない | 誤りがあっても影響が限定的 | 停止しても業務に大きな支障はない |
ヘルスケア企業では、完全性の尺度を機密性と別に設計することが重要です。一般的なIT企業の台帳は機密性に重みが寄りますが、診療情報や治験データでは「改ざんされていないこと」「欠落がないこと」の影響が機密性と同等かそれ以上になります。
手順2：部門ごとに「扱っている情報」を挙げてもらう
装置からではなく、情報から入ります。各部門に「日常業務でどんな情報を扱っているか」を挙げてもらい、その後で「それはどこに保管されているか」を聞く。この順序だと、SaaSやチャットに溜まっている情報が出てきます。
手順3：保管場所ごとに行を分け、重複を統合する
同じ情報が複数の場所にあれば行を分けます。逆に、異なる情報が同じ管理策で運用されているなら統合します。この作業で行数は一度増えて、その後減ります。
手順4：管理責任者を1行ごとに置く
台帳の各行に、その資産の管理責任を持つ部門・役職を書きます。ここが後のリスク所有者の候補になります。個人名ではなく役職で書くのが維持のコツです。異動のたびに台帳を直す必要がなくなります。
手順5：評価を入れ、重要度を算出する
C・I・Aの3軸を評価し、最大値または合計で資産の重要度を出します。どちらでも構いませんが、最大値を採るほうがヘルスケアでは実態に合うことが多いと考えられます。3軸の1つでも高ければ、その資産は高い管理を要するためです。
手順6：更新トリガーを規程に書く
ここが維持可能性を決める工程です。台帳の更新を、次のようなイベントに紐づけます。
| トリガー | 誰が起票するか | 台帳への反映 |
|---|---|---|
| 新しいSaaS・クラウドサービスの導入 | 導入を申請する部門 | 導入承認のフローに台帳追記を組み込む |
| 新サービス・新機能のリリース | 開発責任者 | リリース判定のチェック項目に入れる |
| 部門の新設・統廃合 | 人事・総務 | 組織変更の手続きに含める |
| 委託先の追加・変更 | 契約を結ぶ部門 | 委託先管理の手続きと連動させる |
| 従業者の入退社・異動 | 人事 | 役職で書いていれば原則として不要 |
| 年次棚卸し | ISMS事務局 | 各部門へ確認を依頼し、差分のみ更新 |
ポイントは「台帳を更新する作業」を独立したタスクにしないことです。既存の承認フロー（SaaS導入申請、リリース判定、契約締結）に1項目として組み込むと、更新が自然に発生します。年次棚卸しは、その取りこぼしを拾う保険と位置づけます。
台帳の列構成は、最低限として次を備えておけば実務に耐えます。
| 列 | 内容 |
|---|---|
| 資産ID | 一意の識別子 |
| 資産名 | 情報の種類 |
| 保管場所・媒体 | システム名、クラウド名、物理的な場所 |
| 管理責任部門・役職 | 個人名ではなく役職 |
| 形態 | 電子／紙／知識 |
| 機密性・完全性・可用性 | 各1〜3 |
| 重要度 | 最大値または合計 |
| 個人情報の該当 | 該当／要配慮個人情報／非該当 |
| 保管期間・廃棄方法 | 契約・法令上の要請を反映 |
| 更新日 | 最終確認日 |
「個人情報の該当」列を設けておくと、個人情報保護法の対応と台帳が一本化できます。 医療情報は要配慮個人情報に該当し得るため、この列で識別しておくと、法令対応の棚卸しを別途行う必要がなくなります。
よくある失敗
PCを1台ずつ書いて数百行になる
最も多い失敗です。行数が増えると、1行あたりの情報が薄くなり、誰も読まなくなります。同じ管理策で運用される群は1行に統合してください。
「顧客データ」の1行で済ませる
逆方向の失敗です。保管場所が特定できないため、具体的な管理策が導けません。リスクアセスメントの段階で「アクセス制御を強化する」という抽象的な対応しか出てこず、対応計画が実行不能になります。
ログとバックアップが台帳に載っていない
本番DBは書かれているのに、そのバックアップとアクセスログが載っていない。これは実務でよく見る漏れです。バックアップは本体と同等の機密性を持ち、ログは完全性の要です。両方とも独立した行として扱う必要があります。
チャットとファイル共有が抜けている
Slackのチャンネルに貼られた顧客のCSV、共有ドライブの「一時」フォルダ。統制の外で最も情報が溜まる場所ですが、台帳には現れません。手順2で「情報から入る」と出てきます。
評価が全部「2」になる
尺度に文言の定義がないと起こります。手順1を先に済ませることで防げます。判定できる文言を書くのが唯一の対策です。
管理責任者が個人名で書かれている
異動・退職のたびに台帳全体を直すことになり、更新が止まります。役職で書きます。
台帳と実態が乖離しているのに気づけない
更新トリガーが定期のみだと、必ず起こります。審査では、台帳に載っていないシステムが現場で稼働しているという形で表面化します。イベント駆動の更新を既存フローに埋め込むのが対策です。
台帳が「作って終わり」の文書になっている
台帳の価値は、リスクアセスメントの入力として使われることで生じます。台帳を作ったのにリスクアセスメント表が別の資産リストで動いている、という状態は形式的な運用と評価されます。リスクアセスメントの進め方｜評価基準の設計 と接続させてください。
ヘルスケア企業の例
医療機関向けSaaSを提供する企業
台帳の中核は患者情報ですが、保管場所ごとに分けることが決定的に重要です。
| 資産名 | 保管場所 | C | I | A | 論点 |
|---|---|---|---|---|---|
| 患者情報 | 本番DB（クラウド） | 3 | 3 | 3 | マルチテナントのデータ分離 |
| 患者情報 | 本番DBのバックアップ | 3 | 3 | 2 | 保管先の暗号化と保持期間 |
| 患者情報（抽出データ） | サポート用ファイル共有 | 3 | 2 | 1 | 抽出の申請・承認・削除期限 |
| 患者情報（不具合調査用） | 開発者の作業端末 | 3 | 2 | 1 | 本来置くべきでない場所。リスク対応で禁止・代替を設計 |
| アクセスログ | ログ基盤 | 2 | 3 | 2 | 改ざん防止と保持期間 |
| ソースコード | GitHub Organization | 2 | 3 | 2 | 外部公開設定、退職者のアクセス失効 |
| 顧客（医療機関）との契約書 | 本社金庫（紙） | 2 | 3 | 1 | 物理的施錠、持出し記録 |
| 本番環境の復旧手順 | 担当者の頭の中 | 1 | 2 | 3 | 属人化。文書化がリスク対応になる |
4行目のように、「本来あるべきでない場所にある情報資産」を台帳に正直に書くことが、実は最も価値があります。台帳から消せば見えなくなりますが、実態は変わりません。書いたうえでリスク対応として「調査は本番のマスキング済み環境で行う」といった対策を設計するほうが、審査でも評価されます。
PHR事業者
利用者本人から預かるデータに加えて、同意の記録を独立した資産として立てるのが有効です。同意の取得・撤回・範囲変更の履歴は、完全性の要求が極めて高い情報です。詳細は PHR事業者のISMS｜個人情報保護法との関係 をご覧ください。
治験・臨床研究システムを扱う企業
監査証跡（Audit Trail）を最重要資産の1つとして台帳に立てます。 完全性の評価は最高位になり、「欠落がないこと」「事後の改変ができないこと」がリスク対応の焦点になります。本体データだけを台帳に載せて監査証跡を落とすと、この領域の中核リスクが評価対象から外れます。
医療機関を顧客に持つ場合の共通論点
顧客である医療機関は3省2ガイドラインに基づき、委託先が扱う情報の所在を確認します。台帳が「どの情報がどこにあるか」を答えられる形になっていれば、そのままチェックシート対応の資料になります。 二度手間を避けるため、台帳の列にガイドライン対応で聞かれる項目（保管場所の国、再委託の有無など）を追加しておくのも実務的です。ガイドラインの全体像は既存記事の 3省2ガイドラインとは、クラウド利用時の論点は 医療機関のクラウドセキュリティ をご覧ください。
まとめ
- 台帳の目的はリスクアセスメントの単位を定めることであり、資産の完全な一覧を作ることではない
- 粒度は情報の種類 × 保管場所（システム）。同じ管理策で運用される群は1行に統合する
- 電子データだけでなく、SaaS・紙・属人的な知識まで含める。ログとバックアップの漏れが多い
- C・I・Aの尺度は、台帳を書く前に文言で定義する。数字だけの尺度は必ず評価がぶれる
- 更新は日付ではなくイベントに紐づける。SaaS導入申請・リリース判定・契約締結の既存フローに1項目として埋め込む
- あるべきでない場所にある情報も正直に書く。消すのではなく、リスク対応として是正を設計する
完成した台帳は、次の工程の入力になります。リスクアセスメントの進め方｜評価基準の設計、リスク対応計画とリスク受容の判断 へと続きます。範囲の設計をまだ終えていない場合は ISMS適用範囲の決め方 を先にご覧ください。
ポテックは、ヘルスケア領域に特化してISMS認証取得を支援しています。台帳のひな形と、ヘルスケア固有の資産項目の設計をご提供できます。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- 日本産業標準調査会（JISC）
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
- 個人情報保護委員会
※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。