① データ直接修正の正当性の確保と記録の為の統制
・データ直接修正は、どの様な目的で、誰の承認の基に、誰が行ったか等の記録を保管（証跡）し
監査等で、確認等の必要が生じた場合には、
データ修正前後の内容、承認の経緯、実施の内容等の証跡と共に速やかな提出が、
できる様なコントロールが必要である。
・データを直接修正する場合、データの修正・変更の前後で、データの状況（内容）を記録し、
証跡として残す必要がある。
また、データ直接修正の操作は単独では行わず、必ずセキュリティ基準に則り、
複数人で実施・チェックを行う。
・データ直接修正については、この様な仕組みの構築が必要となる。
② 「標準的な統制」 ： データ直接修正統制に於ける基礎的な制約条件
１．本番環境の維持管理
・ 本番環境とそれ以外（評価環境、テスト環境、開発環境、練習環境など）は、
ハードウエア、OS、ファイルシステムが別環境となっており、ユーザ登録簿もそれぞれに存在する。
２．DB更新ログの取得
・ データ直接修正の頻度が高い本番データに対しては、
更新者のユーザIDと更新日が分かる更新履歴や、更新ログが取られている。
３．DBMSのユーザリスト
・ DBMSを直接更新できるユーザの管理
①ユーザID一覧リスト（最終更新日付き）がシステムから出力できる。
②ユーザ登録簿の変更履歴ログがシステムから出力できる。
４．直接修正用ユーザリスト
・ データ直接修正を専用ツールやエディタ等で行っている場合のユーザの管理
①直接修正履歴ログがシステムから出力できる。
②ツールのユーザID一覧がシステムから出力できる。
③ 「標準的な統制」 ： データ直接修正に於ける標準的な統制
１．データ直接修正における事前承認
・ 通常業務または障害対応に拘らず、
業務アプリケーションを介さずに直接、本番データを修正する場合、事前承認の手続が存在する。
２．データ直接修正における事後確認
・ データ直接修正において、
依頼どおりに正しく修正作業が行われた事を事後確認（照合）する手続が存在する。
３．本番データへのアクセス制限（職務分掌）
・ データ直接修正において、
システム的にも依頼者自身がデータ直接修正が出来ない様になっている。
４．更新ログのモニタリング
・ ＤＢ更新ログが取られている場合、
第三者により異常な更新がないかどうか、定期的にモニタリングされている。
５．パスワード（本人確認、守秘）に関する仕組みの存在
・ DBMS及び直接修正用ツールの使用時には、パスワードを要求され、
そのパスワードにはシステム的な守秘の仕組みや人手による守秘の手続が存在する。
６．DBMSユーザの改廃手続
・ DBMSのユーザIDの付与、変更、削除に際しては、承認を含む然るべき手続が存在する。
７．直接修正ツールの改廃手続
・ 直接修正用ツールのユーザIDの付与、変更、削除に際しては、承認を含む然るべき手続が存在する。
④ 「データ直接修正に於けるリスク」 ： 統制が効かない場合に於いて以下のリスクがある
１．データ直接修正
・ 未承認の直接修正を受入れてしまう
・ 単純ミスによる修正の誤りに気づかない
２．データ修正権限管理
・ 正規の手続を通らずに不正にデータが修正される
・ 直接修正ができるIDが権限外の者に使用されてしまう
・ 不正に直接修正可能なIDが取得できる