A.5.3 職務の分離
| 項目 | 内容 |
|---|---|
| 改訂日 | 2024.04.01 |
| 適用範囲 | 全社・全従業員 |
| 管理策番号 | A.5.3 |
| 分類 | 組織的管理策 |
相反する職務及び責任範囲は、分離しなければならない。
組織の資産に対する不正若しくは意図しない変更又は誤用のリスクを低減するため。
実施の手引き
Section titled “実施の手引き”職務の分離は、一人の者が単独で資産にアクセスし、変更し、又は使用することができないようにすることで、エラー及び不正行為のリスクを低減する。
活動の開始、承認及び実行は、分離する必要がある。一人の者が相反する職務を遂行することが不可能又は実際的でない場合は、以下のような他の管理策を検討する必要がある。
- 活動の監視
- 監査証跡
- 経営陣による監督
職務の分離を設計する際には、以下を考慮する必要がある。
- 資産の取得、受領、支払いの承認を分離する
- システム開発と本番運用を分離する
- セキュリティ管理機能と一般的なIT機能を分離する
分離が必要な職務の例
Section titled “分離が必要な職務の例”| 職務1 | 職務2 |
|---|---|
| システム開発 | システム運用 |
| アクセス権申請 | アクセス権承認 |
| 変更要求 | 変更承認 |
| 監査実施 | 監査対象業務 |
当社における実施状況
Section titled “当社における実施状況”組織構成と職務分離の課題
Section titled “組織構成と職務分離の課題”当社は少人数組織であり、一人の者が複数の職務を兼務することが避けられない。特にシステム開発・運用においては、開発メンバーが設計・実装・本番反映を一貫して担当する体制となっている。このため、従来型の「人員による職務分離」を完全に実施することは実際的でない。
代替統制:重要な変更に対する経営層確認
Section titled “代替統制:重要な変更に対する経営層確認”上記の制約を踏まえ、当社では以下の代替統制を実施している。
役割分担
| 役割 | 担当者 | 責任範囲 |
|---|---|---|
| 技術的実装・運用 | 開発メンバー | システムの設計、実装、テスト、本番反映 |
| 経営判断・承認 | CEO(代表取締役) | 重要な変更に対する事業影響確認、承認 |
CEO確認対象となる変更
全ての変更ではなく、以下に該当する重要な変更についてCEOが確認・承認を行う。
- 顧客に影響を与える機能変更・追加
- セキュリティ・権限・データに関わる変更
- 外部公開される変更(新機能リリース等)
- 事業リスクを伴う変更
軽微な変更(バグ修正、内部改善、ドキュメント更新等)については、開発メンバーの判断で実施し、必要に応じて事後報告とする。
統制プロセス
重要な変更については、開発メンバーがリリースノートを作成し、CEOがその内容を確認・承認する。これにより「活動の開始」と「承認」が分離され、重要な変更が一人で完結しない体制を確保している。
CEOによる確認は、技術的な実装詳細(コミット単位)ではなく、リリース単位で以下の観点から行う。
- 事業としてその変更を承認できるか
- リスクを理解した上でリリースしたか
- 顧客・外部への影響を把握しているか
リリースノートの記載事項
| 項目 | 内容 |
|---|---|
| リリース日 | 変更を本番反映した日付 |
| 概要 | 何が変わったかの説明 |
| 影響範囲 | 顧客影響の有無、内部のみか外部公開か |
| セキュリティ影響 | セキュリティ・権限・データへの影響の有無 |
| ロールバック可否 | 必要に応じて記載 |
代替統制の妥当性
Section titled “代替統制の妥当性”この代替統制は、ISO 27001の実施の手引きに記載された「一人の者が相反する職務を遂行することが不可能又は実際的でない場合」の対応として、以下を満たしている。
- 経営陣による監督: CEOがリリース内容と影響を確認
- 監査証跡: リリースノートが変更履歴と承認の証跡となる
- 活動の監視: リリース単位での変更管理により、変更内容を追跡可能
-
- 組織的対策