01 システム分類と適用判定

目的

本基準は、情報システムに適用する統制目的、実装基準、証跡基準、例外承認権限を決定するための分類方法を定義する。

全システムへ同じ深さの統制を適用してはならない。重要システムには深い統制と高い証跡鮮度を要求し、低リスク補助システムには最低限の所有者管理、データ管理、終了管理を要求する。

判定単位

分類は、原則としてSystem ID単位で行う。ただし、次の場合はサブシステム、環境、テナント、データ基盤、外部サービス単位で追加判定を行う。

• 同一システム内で、公開系、管理系、分析系、開発系、本番系のリスクが大きく異なる。
• 同一SaaS内で、部門ごとにデータ分類、外部共有、管理者権限が異なる。
• 共通基盤として他システムへ認証、ログ、鍵、CI/CD、ネットワークを提供する。
• AI、機械学習、データ分析、外部API連携など、独立したリスクが存在する。

判定軸

分類時は、次の判定軸を確認しなければならない。

判定軸	確認内容
業務重要度	停止時の売上、顧客、業務、社会的影響。
データ分類	個人情報、機密情報、決済情報、認証情報、規制対象データの有無。
外部公開	インターネット公開、外部API、外部利用者、サポートアクセスの有無。
利用者範囲	社内限定、委託先、顧客、一般利用者、海外拠点、子会社。
権限影響	特権ID、管理者、機械ID、広範な読み書き権限の有無。
法規制	金融、決済、個人情報、医療、輸出管理、契約上の規制。
外部依存	SaaS、クラウド、委託先、再委託、共同利用基盤、外部API。
共通基盤性	他システムへ認証、通信、監視、鍵、CI/CD、データ連携を提供するか。
復旧要件	RTO、RPO、業務継続、代替手段の有無。
AI/Data利用	生成AI、モデル、プロンプト、学習データ、分析基盤、外部送信の有無。

分類

分類	定義	対象例
Tier 0	複数システムのセキュリティ、可用性、運用に影響する全社共通基盤。	IdP、認証基盤、鍵管理、監視基盤、ネットワーク中核、CI/CD基盤、端末管理基盤。
Tier 1	重要業務、顧客、規制、決済、社会的影響を持つ重要システム。	基幹、決済、顧客情報、規制対象業務、重要な対外サービス。
Tier 2	通常業務を支える標準的な業務システム。	部門業務、社内利用アプリ、標準的なクラウドアプリ。
Tier 3	低リスクの補助システム。機微情報を扱わず、利用範囲と影響が限定的なもの。	小規模ツール、限定利用の補助台帳、検証用の一時環境。
External	組織外の提供者、委託先、子会社、共同利用基盤へ依存するシステムまたは機能。	SaaS、業務委託、MSP、BPO、外部API、子会社環境。
AI/Data	AI、モデル、データ分析、プロンプト、外部AIサービスを利用するシステムまたは機能。	生成AI利用、機械学習基盤、分析DWH、AIエージェント。

ExternalとAI/Dataは、Tier 0からTier 3へ追加する属性である。たとえば、Tier 1かつExternal、Tier 2かつAI/Dataのように併記する。

適用深度

分類	証跡鮮度	例外承認	監査観点
Tier 0	日次から週次。重要ログと特権操作は継続監視。	CISOまたはリスク委員会。重大例外は経営報告。	共通統制の継承範囲、証跡完全性、管理者アクセス。
Tier 1	週次から月次。重大脆弱性、ID、ログは短いSLAを適用。	システムオーナーとCISO。重大例外は経営報告。	重要統制の有効性、例外妥当性、復旧可能性。
Tier 2	月次から四半期。変更時証跡を重視。	システムオーナー。重大例外はセキュリティ部門確認。	標準統制の適用、証跡鮮度、是正状況。
Tier 3	四半期から年次。変更、廃止、データ変更時は再確認。	システムオーナー。基準未達は期限付き管理。	所有者、利用範囲、データ、ID、終了手順。
External	契約更新、年次、重大変更、事故発生時。重要SaaSは四半期。	契約責任者、システムオーナー、必要に応じ法務。	責任分界、監査報告、削除、通知義務、再委託。
AI/Data	利用開始時、モデル変更時、データ変更時、定期レビュー。	システムオーナー、データ責任者、必要に応じ法務。	入力データ、外部送信、人間承認、出力利用、ログ。

最低適用基準

すべての分類に対して、次の最低基準を適用する。Tier 3であっても省略してはならない。

• System IDを付与する。
• Owner IDを付与する。
• 利用目的を記録する。
• 利用者範囲を記録する。
• 扱うデータ分類を記録する。
• 外部依存の有無を記録する。
• IDと権限の付与、変更、削除の責任者を定める。
• 廃止時のデータ削除、権限削除、契約終了を記録する。

判定手順

分類は、次の順序で行う。

1. System IDを付与する。
2. システムオーナーを決定する。
3. 業務重要度、データ分類、外部公開、法規制、復旧要件を確認する。
4. Tier 0からTier 3のいずれかを決定する。
5. External属性とAI/Data属性を追加判定する。
6. 適用する統制目的IDを02から選定する。
7. 証跡契約を04に基づき作成する。
8. 未達がある場合は05に基づき例外登録する。
9. 06に基づき評価指標へ反映する。

自動的にTier 0とする条件

次のいずれかに該当する場合、原則としてTier 0とする。

• 複数システムの認証、認可、ID連携を提供する。
• 複数システムの鍵、証明書、シークレットを管理する。
• 複数システムの監視、ログ収集、検知を担う。
• 複数システムのCI/CD、アーティファクト、リリースを担う。
• 複数システムのネットワーク中継、境界防御、管理経路を担う。
• 侵害時に複数システムへ横展開される可能性が高い。

自動的にTier 1以上とする条件

次のいずれかに該当する場合、原則としてTier 1以上とする。

• 顧客情報、決済情報、認証情報、規制対象データを扱う。
• インターネット公開され、顧客または外部利用者が利用する。
• 停止時に重要業務、顧客対応、決済、法令対応へ重大影響がある。
• 法規制、業界基準、顧客契約により統制要求が明示されている。
• 侵害時に情報漏えい、改ざん、不正送金、権限昇格の重大リスクがある。

再判定条件

次の場合は分類を再判定しなければならない。

• 扱うデータ分類が上がった。
• インターネット公開、外部API、外部利用者が追加された。
• 委託先、SaaS、クラウド、外部APIが追加または変更された。
• RTO、RPO、業務重要度が変更された。
• AI、機械学習、データ分析、生成AIが追加された。
• 重大インシデント、監査指摘、重大脆弱性が発生した。
• システム統合、分割、移管、廃止、子会社展開が行われた。

判定証跡

分類判定では、次の証跡を残さなければならない。

証跡	内容
分類判定記録	判定日、判定者、承認者、Tier、External、AI/Data該当性。
業務影響評価	停止時影響、代替手段、RTO、RPO。
データ分類記録	データ種別、保存場所、外部共有、削除要件。
外部依存記録	SaaS、委託先、再委託、外部API、責任分界。
再判定履歴	変更理由、変更前後の分類、承認者。

参考資料（出典）