システムオーナー（System Owner）

システムオーナーとは、特定のITシステムについて、業務上の目的と必要な保護水準を整理し、導入から運用・変更・廃止まで責任を持つ役割です。自分ですべての設定や監視を行う意味ではなく、「誰が何を決め、未解決の課題をどこへ報告するか」を明確にする立場です。

NIST SP 800-37 Rev.2では、システムの調達・開発・運用などに責任を持ち、セキュリティ計画の作成・維持や関係者との調整を担う役割として説明されています。ただし、役職名や兼務の扱いは組織によって異なります。日本企業に一律の役職設置を義務付ける定義ではありません。NIST SP 800-37 Rev.2、Appendix D

システム管理者や情報オーナーとの違い

役割を分ける軸は、肩書きよりも「何に責任を持つか」です。

• システムオーナー：システム全体の要求、変更の優先順位、維持・改善を取りまとめます。

• 情報オーナー・データオーナー：扱う情報の利用・共有・保護のルールを決めます。一つのシステムに複数の情報オーナーが関わる場合もあります。

• システム管理者：設定変更、アカウント管理、更新、バックアップなどを実施します。

• 運用担当者：監視や定例作業、一次対応など、割り当てられた手順を実行します。管理者との兼務もあります。

• CISO等：経営の方針を踏まえて組織全体のセキュリティ対策を推進します。個々のシステムのオーナーとは対象範囲が異なります。

• リスク承認者：残るリスクを受け入れて運用するか、権限の範囲内で判断します。システムオーナーという名称だけで、この権限まで自動的に得られるわけではありません。

NISTではシステムオーナー、管理者、情報オーナー、運用を承認するauthorizing officialを区別しています。国内の体制設計では、自社の職務権限規程に合わせて対応関係を決めます。NISTの役割整理。CISO等と経営者の関係は、経済産業省のサイバーセキュリティ経営ガイドラインも参考になります。

担当者を選ぶときに決めること

人事システムなら人事部門、販売管理なら営業・業務部門など、業務を理解する責任者が候補になります。IT部門の管理職を選ぶことも可能ですが、利用部門の要求を調整できることが必要です。「詳しい人だから」と担当者へ責任だけを渡すと、予算や停止判断ができないまま課題を抱えてしまいます。

選任時には、対象システムの範囲、利用部門、扱う情報、決裁できる変更や金額、上位者へ判断を求める条件、代理者を記録します。クラウドやSaaSでも、自社側の権限設定や情報の利用判断を誰が担うかは残ります。委託先との作業分担も契約・運用手順で合わせて確認しましょう。

経済産業省の「システム管理基準」は、IT業務に関わる責任と権限の文書化、役割間の整合、要員交替への備えを挙げています。以下の記録例は、それを自社で具体化するための実務例です。システム管理基準2023、II.10.2・II.10.3

RACIで整理する業務例

RACIは、実行する人（R）、その業務の決定・説明に責任を持つ人（A）、相談する人（C）、結果を知らせる人（I）を整理する方法です。次は人事システムを想定した例で、NISTなどが指定する固定の分担表ではありません。

例1：人事データを閲覧できる範囲の変更

Aを人事データの情報オーナー、Rを設定する管理者、Cをシステムオーナーとセキュリティ担当、Iを影響する利用部門とします。申請理由、閲覧範囲、有効期限、承認者を残します。

例2：事前承認された定例更新の実施

Aをシステムオーナー、Rを管理者・運用担当、Cを利用部門とセキュリティ担当、Iを利用者とします。実施日時、動作確認、切り戻し条件、作業結果を記録します。重大な停止や費用が生じる変更は、別途定めた決裁へ回します。

例3：脆弱性への対応を期限付きで延期

Aを社内で指定したリスク承認者、Rを対策案をまとめるシステムオーナー、Cを管理者・情報オーナー・セキュリティ担当、Iを運用担当とします。「今は対応できない」という連絡だけで、リスクを受容したことにしないのが要点です。

小規模な組織で同じ人が複数の役割を担う場合も、申請と承認、実行と点検の関係を確認します。重要な判断では上位者による確認を設けるなど、利益相反や見落としを減らす方法を決めます。

リスク判断と引継ぎに残す記録

対応延期などの判断には、少なくとも次を残すと後から見直せます。

• 対象、問題の内容、影響する業務・情報

• 検討した対策、延期の理由、代わりに行う対策

• 残るリスク、決裁権限のある承認者と判断日

• 対応責任者、期限、見直す条件、判断資料へのリンク

たとえば「月末処理後まで更新を延期し、それまでは接続元を制限する」と決めるなら、月末後の担当者と期限まで記載します。脅威の変化や代替対策の不調を検知した際の連絡先も必要です。

異動・退職時は、後任と引継ぎ日だけでなく、契約、構成資料、未解決のリスク、例外承認、更新予定、復旧手順、連絡網の所在を確認します。認証情報は安全な管理方法で移管し、引継ぎ資料へ平文で並べないようにします。

オーナーが不在だと何が起きるか

実務では、更新を止める理由だけが残り、誰も期限を決めない、不要な権限の承認者が見つからない、障害時に業務停止の判断が遅れる、といった問題が起こり得ます。監視を外部へ委託しても、通知を受けて業務上の判断をする相手が不明なら改善しません。

まず、重要なシステム一つについて「責任者・代理者・判断できる範囲・未解決課題」を確認してください。関連する役割はデータオーナー、対応の流れはインシデント初動対応とSOCの連携で解説しています。

確認日：2026年9月12日。NIST SP 800-37 Rev.2と経済産業省の公開資料を参照しています。