>
>
公開日
安全管理措置の4分類を整理し、情報システム部門向けにアクセス制御、特権の最小化、異動・退職時の権限変更、棚卸し、認証と検知の運用を解説します。不要な個人データの消去や法務と共有する管理表まで具体化し、現行の義務と将来の見直しを区別します。担当者と証跡を結び付けた運用設計に役立ちます。
安全管理措置とは
個人データを安全に取り扱うために、組織・人・設備・システムの各面で講じる対策のことです。企業の情報システム部門の担当者・管理者にとって、アクセス制御と権限管理は技術的対策の一部であり、社内の責任分担や記録と結び付けて設計します。本記事の情報は2026年10月22日時点のもので、個人情報保護委員会とデジタル庁の公表資料を根拠にしています。
本記事のポイント
権限は業務上の必要性に対応付けます。
認証と検知を組み合わせます。
不要データの消去も管理対象です。
法務との共有には判断と証跡を残します。
組織的・人的・物理的・技術的対策の役割
4分類は、管理体制、人の行動、設備や媒体、システムの対策を分担して捉えるための整理です。個人情報保護委員会は、通則編の別添「講ずべき安全管理措置の内容」で、これらに加えて基本方針、取扱規律、外的環境の把握も扱っています。4分類の実施だけで全体が完結する説明は避けます。
役割分担を設計する場合は、次の表を作業と記録の対応付けに使います。法定様式ではなく、情シスの運用設計例です。
分類 | 情シスの作業例 | 関係部署の例 | 残す記録の例 |
|---|---|---|---|
組織的 | 責任者・報告経路の整理 | 法務・各業務部門 | 体制図・判断記録 |
人的 | 利用ルールの周知・教育 | 人事・教育担当 | 教材・受講記録 |
物理的 | 機器・媒体の保管管理 | 総務・施設管理担当 | 持出記録・廃棄記録 |
技術的 | アクセス制御・認証・検知の設定 | システム管理者・利用部門 | 権限台帳・操作ログ |
個人情報保護委員会は、技術的安全管理措置に関する公表資料で、アクセス制御、アクセス者の識別と認証、不正アクセス等の防止・検知などを手法の例示として挙げています。権限設定を見直す場合は、設定値だけでなく、誰の業務に必要かという承認理由も記録に結び付けます。
法第23条と第22条の位置付け
法第23条の安全管理と、第22条のデータ内容の正確性の確保等は、分けて整理する対象です。個人情報保護委員会は、通則編の「個人データの管理」で両者を区別し、第24条の従業者の監督、第25条の委託先の監督も扱っています。法務と対応範囲を整理する場合は、アクセス管理の実施だけを根拠に関連義務への対応完了とはせず、論点ごとの判断と証跡を残します。
技術的安全管理措置で見直すこと
技術的安全管理措置は、アクセス制御だけで完結させず、認証・防御・検知を組み合わせ、対策を多層的に講ずる方針で運用します。
個人情報保護委員会は、2026年に公表した10月7日の注意喚起資料で、情報システムを使用して個人データを取り扱う場合の技術的対策として、アクセス制御、アクセス者の識別と認証、外部からの不正アクセス等の防止、情報システムの使用に伴う漏えい等の防止、不正アクセス等の検知等の5項目を挙げています。以下の担当分担、実施契機、完了記録の設計は、これらを日常業務に落とし込むための記事独自の運用提案です。
アクセス制御の範囲
アクセス制御では、誰がどの個人データに対して何をできるかを、業務単位で対応付けます。
新規の権限付与では、申請者に対象データ、利用目的、必要な操作、利用期限を示してもらい、業務責任者が必要性を承認します。閲覧だけで足りる業務なら、更新や出力までまとめて許可しません。システム管理者は承認内容に沿って設定し、申請内容と設定結果を同じ管理番号で関連付けます。
画面上の操作以外にも接続手段がある場合は、その経路も対象に含めます。業務責任者による必要性の判断と、管理者による設定作業を分ければ、設定できる人だけの判断で権限が広がる運用を避けられます。
特権の最小化
特権とは、利用者管理やシステム設定の変更などを可能にする強い権限であり、不要な業務では通常権限を使う設計にします。
デジタル庁は、政府情報システム向けガイドラインの管理者権限に関する記述で、管理者権限の利用者を必要最小限にし、アクセスを多要素認証等で保護することを規定しています。これは同ガイドラインの適用対象における規定であり、民間事業者すべてへの一律の法的義務として扱いません。
社内運用へ取り入れるなら、通常業務と管理作業のアカウントを分け、管理作業には承認した目的と期限を対応付けます。作業が終わった場合は、付与した権限の解除まで記録します。日常業務の利便性だけを理由に、管理者権限を常用しない設計が判断の軸です。
異動・退職時の権限変更
異動・退職時は、人事上の変更通知から権限変更の完了までを、一つの案件として追跡します。
人事担当が発効日と対象者を通知した場合は、システム管理者が対象アカウントを特定し、業務責任者が変更後に残す権限を判断します。退職なら利用停止、異動なら旧業務の権限解除と新業務に必要な権限付与を分けて処理します。
関連する接続手段がある場合は、継続中の接続や連携用の認証情報も処理対象に含めます。管理画面でアカウントを停止しただけで完了にせず、対象一覧、処理結果、実施者、完了時刻を変更通知にひも付けます。停止できない接続手段が残る場合は、代替の遮断策と解消担当を記録し、未完了として管理します。
権限の棚卸し
権限の棚卸しでは、所属の一致ではなく、現在の業務でそのデータと操作が必要かを判断します。
定期点検の対象を作る場合は、アカウントと権限の一覧に、利用目的、承認者、期限を添えて業務責任者へ渡します。所属が変わっていなくても担当業務が終わっているなら解除対象にし、必要性を説明できない権限は残す前提にしません。
実施頻度は法定の一律値として置かず、権限変更の多さや取り扱うデータに応じた社内基準として設定します。定期点検の間に業務終了が判明した場合は、その時点で変更処理へ回します。解除によって業務が止まる懸念があるなら、責任者が代替手順と判断期限を定め、保留のまま放置しない運用にします。
フィッシング耐性を含む多要素認証
多要素認証は異なる認証要素を組み合わせる仕組みですが、要素を増やすことと、偽の認証画面などに対するフィッシング耐性は同じではありません。
導入判断では認証方式だけでなく、端末紛失や利用不能時の復旧手段も対象にします。通常時だけを検証し、復旧時の本人確認を設計しない運用は避けます。
対応方式と復旧手段を公式資料で把握できる場合は、対象業務と利用者を絞り、認証、復旧、管理者による解除の手順を検証します。業務を継続できることまで確かめたうえで対象を広げます。
方式や復旧手段を把握できない場合は、先に現行方式を整理します。その間はアクセス元の制限や利用承認などの代替管理を設計し、方式不明のままフィッシング耐性があると評価しません。
不正アクセスの検知
不正アクセスの検知は、ログの取得から通知、担当者による確認、初動判断までを一続きで設計します。
ログとは、認証や操作などの履歴です。取得できる項目が分かる場合は、通常と異なるアクセスや権限変更を確認する条件を決め、通知先と不在時の引継ぎ先を割り当てます。自動取得が可能なら収集を自動化し、不可能なら手動取得の担当と実施記録を管理します。
契機 | 作業 | 担当 | 判断条件 | 証跡 |
|---|---|---|---|---|
利用申請 | 対象データと操作の審査・設定 | 業務責任者・管理者 | 業務上の必要性と期限が明確か | 承認記録・設定結果 |
異動・退職通知 | 権限変更と接続手段の処理 | 人事担当・管理者 | 発効日までに旧権限を処理できたか | 対象一覧・完了時刻 |
定期点検・業務終了 | 権限の継続・解除判断 | 業務責任者 | 現在も対象データと操作が必要か | 判断理由・解除結果 |
ログ収集予定 | 自動収集の稼働確認、または手動取得 | 運用担当 | 対象期間に取得漏れがないか | 取得履歴・欠落時の対応記録 |
異常の通知 | 履歴確認と初動判断 | 確認担当・対応責任者 | 本人の操作か、不審な操作が続いているか | 確認結果・停止等の判断記録 |
通知を受けた場合は、確認担当が対象アカウントと操作内容を調べ、不審な操作の継続が疑われるなら対応責任者へ引き継ぎ、利用停止などの初動を判断します。通知の発生だけを完了条件にせず、判断結果まで残します。
不要な個人データの消去
不要な個人データは、利用目的と保存理由を整理し、保存の要否を判断してから消去します。アクセス範囲を狭める安全管理措置に加え、保有するデータ自体を見直す運用です。
個人情報保護委員会は、個人情報保護法ガイドライン（通則編）で、法第22条の「データ内容の正確性の確保等」と、第23条の「安全管理措置」を区分しています。ここでは、条文の詳細や一律の消去期限を補わず、保存判断から完了記録までの運用案を示します。
利用目的と保存理由の整理
保存理由を説明できるデータには期限と管理責任者を設定します。理由を説明できないデータは、法務・業務部門に保存要否の判断を依頼します。
棚卸しを行う場合は、データごとに利用目的、現在の利用状況、保存理由を整理します。継続保存の理由がある場合は、その根拠に沿って期限を設定します。「いつか使うかもしれない」だけで保管を続けたり、利用頻度が低いだけで消去を決めたりしない運用にします。保存要否を判断できない場合は、アクセス範囲を制限し、判断担当者と再検討日を付けて判断待ちとして管理します。
複製とバックアップの扱い
消去対象を洗い出す際は、共有領域、出力ファイル、端末上の複製、バックアップも管理対象の候補に含めます。
本体の削除だけで、全ての複製の処理が完了したとは扱いません。保存先ごとに対象と処理方法を整理します。バックアップを直ちに処理できない場合は、残存理由、管理責任者、処理予定を例外として記録します。復元する場合にも消去済みデータの扱いを定め、通常利用へ戻す前に処理対象を照合する設計にします。
消去判断と完了記録
消去を実施する場合は、承認から作業、例外処理、完了確認までを分けて記録します。
フェーズ | 判断・作業と記録内容 |
|---|---|
保存理由の整理 | 利用目的と保存根拠を整理し、判断できなければアクセス範囲を制限して判断待ちにします。 |
承認 | 保存不要と判断した場合は、対象範囲、業務への影響、消去方法について承認を得ます。 |
消去作業 | 承認済みの場合は、対象と方法を記録したうえで、承認範囲内のデータを処理します。 |
例外記録 | 未処理の複製などが残る場合は、理由、責任者、対応予定を残します。 |
完了記録 | 実施日、作業者、確認者、処理結果と残存する例外を記録します。 |
誤消去や業務停止を避けるため、他業務との共用や復旧への影響が判明した場合は、作業を止めて承認範囲を見直します。証跡、つまり判断や作業を後からたどる記録には、個人データそのものを不用意に複製しません。対象を特定できる管理番号や保存先、承認記録を残せる場合は、それらを使って追跡できる形にします。
▲ 不要な個人データを消去する際の一連の作業手順と記録の流れ。
法務と共有する管理表の作り方
この管理表は、法的な位置付けと実装状況を分けて記録し、情シスの実施内容と法務の判断を結び付ける道具です。適法・違法を機械判定する表ではなく、根拠、業務上の条件、実装、例外、証跡を別々に残します。
管理表の項目設計
管理表は、対象と対策ごとに記録を分け、判断の根拠まで追える項目構成にします。以下は実在企業の導入実績ではなく、異動時の権限変更を題材にした運用設計例を兼ねるテンプレートです。
項目 | 記入内容・運用設計例 |
|---|---|
対象システム・データ | 顧客管理システム／顧客の連絡先 |
業務目的 | 担当顧客への連絡。異動後も利用が必要な範囲は業務部門が記入 |
根拠資料 | 参照する法令・ガイドラインの該当箇所、社内規程、版・確認日。未確認なら明記 |
判断区分 | 法的な位置付けを法務が記入。確認中なら「未確認」 |
現状 | 旧所属の権限削除、新所属の権限付与について、実装状況と証跡の有無を別記 |
担当者 | 情シスの実施者、業務部門の承認者、法務の判断者、更新責任者の氏名 |
実施契機 | 異動通知の受領、権限変更の申請 |
証跡の保管先 | 承認記録、変更履歴、設定記録の保管先と実施日 |
例外理由 | 引継ぎで旧権限を残す理由、対象範囲、期限、承認者、代替措置 |
次回見直し契機 | 引継ぎ終了、例外期限の到来、業務目的の変更 |
同じ項目で、管理者権限、認証、検知、不要データの消去も別の記録として追加します。管理者権限なら利用者と用途、認証なら適用範囲、検知なら通知先と対応担当、消去なら保存理由と対象範囲を業務条件として残します。空欄を埋めるために未確認事項を「対応済み」にせず、表の完成を法令適合の保証にしません。
情シス・法務・業務部門の分担
共同管理では、情シスが実装と証跡、業務部門が利用の必要性、法務が根拠と法的な位置付けを担当する運用にします。各部門の担当者に加え、記録の更新を取りまとめる責任者も明示します。
個人情報保護委員会が公表した中小規模事業者の安全管理措置に関する調査報告では、従業員数100人以下の事業者4,661者のうち、個人情報保護に関する担当者がいるとの回答は36.3％でした。兼任も含む結果であり、全企業には一般化せず、責任者の明示を考える背景として扱います。
変更時の更新と例外管理
管理表を継続して使う場合は、定期的な見直しだけでなく、業務や設定が変わった時点で更新します。
更新契機 | 更新する内容 |
|---|---|
異動・退職 | 利用の必要性、権限変更・停止の結果、承認記録 |
システム変更 | 対象データ、管理者権限、検知設定、証跡の保管先 |
認証方式の変更 | 適用範囲、設定結果、適用できない対象と代替措置 |
保存理由の変更 | 保存の必要性、消去対象、実施結果、例外期限 |
実施内容を裏付ける証跡があれば「実施済み」として管理します。証跡がなければ、実装を確認できる場合は「実装済み・記録不足」、実装も不明なら「実装未確認」と分けます。前者は記録の取得、後者は設定確認から進め、未実装と判明した場合は対応担当と期限を決めます。例外を残す場合も、期限到来時に継続理由を再判断し、過去の承認だけで延長しない運用にします。
社内管理情報と対外説明の区分
社内管理表と本人向けの説明は、用途を分けて管理します。個人情報保護委員会は、講じた措置を本人の知り得る状態に置く方法に関するFAQで、ホームページに講じている対策の概要と問合せ窓口を掲載し、問合せに遅滞なく回答する体制も該当すると説明しています。
対外説明を作る場合は、管理表から説明用の概要を切り出し、公開範囲を法務と整理します。内部の権限一覧や詳細な構成情報をそのまま全面公開せず、説明内容と社内の実装状況に食い違いがないかを照合します。
▲ 安全管理措置の実装状況と証跡の有無に応じた管理表の区分判定手順。
アクセス管理で避けたい失敗パターン
安全管理措置としてのアクセス管理は、設定の有無だけでなく、権限変更から通知後の判断・対応までを管理対象にします。以下は実在企業の事故や実測結果ではなく、運用設計上の失敗パターンです。
権限変更と棚卸しの形骸化
権限の棚卸し、つまり付与済み権限の必要性を見直す作業では、退職者だけでなく異動者の旧権限も対象にします。退職者アカウントの停止だけで完了すると、異動前の権限が見直しから漏れます。承認者が業務上の必要性を判断せず、一括承認する設計も避けます。
人事通知を受けたら、業務責任者が継続・削除を判断し、設定担当へ引き継ぐ流れにします。継続するなら理由を記録し、必要性が不明なら承認済みにはせず、判断先と回答期限を定めます。
認証と検知への過信
多要素認証やログ収集を導入しても、権限の見直しと通知後の対応は省きません。多要素認証は異なる種類の要素を組み合わせる本人確認であり、業務に必要な権限を判断する作業とは分けて設計します。
認証手段を失った際の復旧負担、通知の確認工数、例外承認の負担も見込みます。通知を出すなら確認担当と不在時の引継先を置き、利用停止・継続調査の判断条件を定めます。例外を認めるなら期限と解除担当も記録します。
例示による機械的な適法性判断
例示を一つでも満たさなければ違法、と機械的に判断する運用は避けます。委員会文書の例示の扱いは次章で整理します。例示との違いがあれば、対象業務と代替策を整理して法務への判断材料にします。
失敗パターン | 運用上の問題 | 修正案 |
|---|---|---|
異動者の旧権限が残る | 人事通知と変更作業の断絶 | 通知から業務責任者の判断へ接続 |
棚卸しの一括承認 | 必要性の判断不足 | 継続理由と承認者を記録 |
認証・ログへの過信 | 復旧・通知対応の担当不在 | 担当、判断条件、例外期限を設定 |
例示だけで適法性を判断 | 業務実態や代替策の検討不足 | 差異と対応理由を法務へ共有 |
対策の追加よりも、担当・判断条件・記録の不足を埋める方針で、次章の管理表に整理します。
現行の義務と将来の見直しの区分
安全管理措置の実装では、将来の見直しに関する情報を現行の義務へ置き換えず、根拠を確認できる対策と検討段階の事項を分けます。
現行資料から読み取れる範囲
現行の対応判断は、個人情報保護委員会の通則編を根拠に整理し、同委員会が2026年10月7日に報道発表で公表した注意喚起は技術的対策の整理に併せて参照します。同委員会は、通則編の別添「講ずべき安全管理措置の内容」に、組織的・人的・物理的・技術的な措置などを定めています。
また、同委員会は10月7日の注意喚起で、情報システムを使用して個人データを扱う場合に、アクセス制御、識別と認証、不正アクセス等の防止、漏えい等の防止、不正アクセス等の検知等を挙げています。
見直しが検討段階にある事項
例示の見直しに関する事項は、現行の義務としては扱いません。例示だけで違法性や罰則を独自に判定せず、罰則の金額・適用条件も扱いません。
将来の例示見直しへの備え
現行資料で根拠を確認できる対策は実施し、将来の例示に関する事項は管理表の検討欄に分けて記録します。情報システムでは、防止策と検知策を組み合わせて運用します。
区分 | 管理表での扱い |
|---|---|
現行資料で根拠を確認できる事項 | 通則編・注意喚起に対応する対策を実施欄へ記載します。 |
検討段階にある事項 | 改訂内容・例示の解釈・見直し日程を検討欄へ分離します。 |
条件付きの運用提案 | 個人情報保護委員会などの公表資料で改訂内容が公開されれば、資料名・公表日・対象範囲を記録して対応を判断し、公開されるまでは検討欄に残します。 |
▲ 安全管理措置の管理表における現行根拠のある事項と未確認事項の区分。
まとめ
安全管理措置の改善は、アクセス制御、認証、検知、不要データの消去を管理表で結び付けるところから始めます。現行の義務への対応と将来の見直しは分けて扱い、見直しを待って対応を先送りしないようにします。
最低限の段階では、新製品の購入より先に、既存システムの権限と担当を対応付けます。次の段階では、高リスクな個人データを扱うシステムから異動・退職時の権限変更と棚卸しの記録を整え、複数システムへの展開や認証・検知の見直しは、運用が回り始めてから広げます。
担当するシステムを一つ選びます。
本文の管理表に、権限の付与理由、変更担当、完了の証跡を記入します。
これは着手範囲の提案であり、法定の実施単位ではありません。製品の導入も検討する場合は、本文の管理表の項目をそのまま要件整理に使い、権限・認証・検知・消去の記録をどの機能で残せるかを照合します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
