LOCKED
ブログ一覧に戻る
セキュリティ全般LOCKED

IT全般統制(ITGC)とは|4つの領域と評価・アクセス管理

関連トピック: 情報セキュリティコンプライアンス対応

IT全般統制(ITGC)は、J-SOX(金融商品取引法の内部統制報告制度)で、財務報告に使うシステムが正しく動き続ける土台を整える統制です。J-SOXの実施基準は、開発・保守、運用・管理、アクセス管理などの安全性の確保、外部委託の契約管理の4つを例に挙げています。2023年の改訂で、ITの委託とセキュリティ、評価の頻度の考え方が加わり、2024年4月1日以後に始まる事業年度から適用されています。

IT部門から見ると、J-SOXへの対応は情報セキュリティ コンプライアンスのうち、財務報告に関わるシステムに範囲を絞った部分にあたります。4つの領域で何を整えるのか。IT業務処理統制とどう分けるのか。何年に一度評価すればよいのか。どれも、監査の前に情報システム部門が答えを用意しておきたい問いです。2026年10月時点で金融庁が公表している基準・実施基準とQ&Aに当たりながら、順に整理しました。後半は、細かな論点に分かれるアクセス管理を、評価で確かめられることと残しておく記録に分けて扱います。

LOCKED は、LOCKED DAS と LOCKED MSO を組み合わせたサービス群です。IDの発行・停止と権限の申請・承認・棚卸しを LOCKED DAS で管理し、業務システムへのログインを LOCKED MSO にまとめて、二段階認証と監査ログをかけます。担うのは、アクセス管理の統制の一部と、評価で示せる記録です。

LOCKED DAS・MSO の製品資料を無料でお送りしています。アクセス管理の統制の見直しにお使いください。 製品資料をダウンロードする →

IT全般統制(ITGC)とは、業務処理統制が効く環境を守る統制

定義は実施基準にあります。「業務処理統制が有効に機能する環境を保証するための統制活動」で、通常は複数の業務処理統制に関係する方針と手続を指します(実施基準 Ⅰ.2.(6)②ロ a)。

例で考えます。販売管理システムが出荷データから売上を自動で計上し、与信限度を超えた受注を止めているとします。この自動の仕組みが業務処理統制です。ところが、承認のないプログラム変更で計算式が書き換わったり、権限のない人が計上データを直接直せたりしたらどうでしょう。仕組みが正しく作られていても、結果は信用できません。システムの変更で必要な統制が組み込まれなかったり、プログラムの改ざんや不正なアクセスがあったりすれば、業務処理統制の有効性は保証されなくなる可能性がある、と実施基準も書いています。だから、変更、運用、アクセス、委託先をまとめて押さえる統制が別に要ります。それがIT全般統制です。

J-SOXのなかでの位置づけ

J-SOXでは、上場会社などが事業年度ごとに内部統制報告書を作り、有価証券報告書と併せて提出します(金融商品取引法 第24条の4の4)。報告書は、公認会計士または監査法人の監査を受けます。評価するのは経営者です。範囲と手続きを決めて評価し、その結果を監査人が監査します。

基準は、内部統制を6つの基本的要素で説明しています。その一つが「ITへの対応」です。ITへの対応はIT環境への対応と、ITの利用及び統制からなり、そのうちITの統制が、さらにIT全般統制とIT業務処理統制に分かれます。完全で正確な情報処理には、両者が一体となって機能することが重要だとされています。

新しいツールを入れる義務はありません。ITへの対応を基本的要素に加えたのは、新しいシステムの導入や既存システムの更新を強いるためではない、と実施基準は明記しています。手作業で統制を回していることも、それだけで不備にはなりません(同 Ⅰ.2.(6))。

評価の作業は、経営者の指揮のもとで、経理部や内部監査部など既存の部署に担わせることも考えられます(同 Ⅱ.3.(1)①)。自分の業務を自分で評価する形は避けます。ふだんのIT内部監査と担当者が重なる会社もありますが、J-SOXの物差しは財務報告の信頼性です。

IT業務処理統制(ITAC)との違い

IT業務処理統制は、取引の側の統制です。業務を管理するシステムのなかで、承認された取引がすべて正確に処理・記録されるよう、業務プロセスに組み込まれています。具体例には、次のものが挙がっています。

  • 入力情報の完全性、正確性、正当性などを確保する統制
  • 例外処理(エラー)の修正と再処理
  • マスタ・データの維持管理
  • システムの利用に関する認証、操作範囲の限定などアクセスの管理
IT全般統制(ITGC)IT業務処理統制(ITAC)
守るもの業務処理統制が働き続ける環境個々の取引の処理と記録の正しさ
例開発・保守、運用・管理、アクセス管理などの安全性の確保、外部委託の契約管理入力のチェック、エラーの修正と再処理、マスタの管理、操作範囲の限定
評価の単位IT基盤ごと(管理する部門や運用方法のまとまり)原則としてシステムごと

アクセス管理が両方の列に出てくる点に注意してください。IDの登録・削除や特権IDのように、システムをまたいで共通の手続で行う管理は全般統制。ある会計システムで「仕訳を承認できるのは課長以上」と操作範囲を絞るのは業務処理統制。こう分けると整理しやすくなります。

2023年の改訂では、IT全般統制が有効と評価されても、それだけでIT業務処理統制も有効とは結論できないことが書き加えられました(同 Ⅱ.3.(3)⑤イ)。全般統制は前提です。業務処理統制の評価の代わりにはなりません。

対象は財務報告に関わるシステムに限られる

会社が使うすべてのシステムが、評価の対象になるわけではありません。金融庁の「内部統制報告制度に関するQ&A」(問38)は、財務報告に係る内部統制に関連するシステムが対象だと答えています。範囲は、財務諸表の重要な勘定科目からたどって決めます。勘定科目がどの業務プロセスとシステムにつながり、どの部署が使っているかを整理します。業務プロセスごとに使うシステムの一覧を作ると有用だ、とされています(実施基準 Ⅱ.3.(3)⑤ロ a)。

そのうえで、システムを支えるIT基盤(ITに関与する組織、規程・手順書、ハードウェア、基本ソフトウェア、ネットワーク、外部委託の状況)を把握し、全般統制の評価単位を決めます。実施基準の例はこうです。自社開発の販売・購買・物流のシステムはシステム部が、市販の会計パッケージは経理部が管理している。この場合、評価単位は「システム部」と「経理部」の2つになります(同 ⑤ハ)。クラウドも例外ではありません。会計サービスや経費精算サービスも、財務報告に関わるかどうかという同じ物差しで、範囲に入れるかを判断します。

ホワイトペーパー(無料)

2026年版 情シスが直面するIDガバナンス5大課題

2026年に情シスが直面するIDガバナンスの5つの主要課題を分析。SaaS増加、リモートワーク常態化、コンプライアンス強化などへの対応策を提示します。

無料でダウンロード

IT全般統制の4つの領域で整えること

4つの領域は、実施基準に2度出てきます。ITの統制を作る場面の具体例(Ⅰ.2.(6)②ロ a)と、経営者が評価する場面の「例えば、次のような点」(Ⅱ.3.(3)⑤ニ a)です。どちらも例示です。会社のIT環境に合わせて、統制を足し引きします。監査人が領域ごとに何を確かめるかは、実施基準 Ⅲ.4.(2)②ロに書かれています。

システムの開発、保守

プログラムや設定の変更が、承認とテストを経て本番に移されているかを見る領域です。監査人が確かめる点として、実施基準は次を挙げています。

  • 開発・調達・変更について、事前に経営者または適切な管理者の承認を得ていること
  • 開発の目的に合った開発手法を使っていること
  • 導入前に十分な試験を行い、利用部門とIT部門の管理者が結果を承認していること
  • 開発・変更の過程を記録・保存し、変更したときは内部統制の記録も更新していること
  • データの保管や移行で、誤りや不正を防ぐ対策を取っていること
  • 利用者が計画に沿って教育研修を受けていること

記録がなければ、承認を経たことは示せません。残す記録は、変更の申請と承認、テストの結果、本番に移した日時と担当者です。クラウドサービスではプログラムの変更を提供者が行うため、自社の側では勘定科目や承認経路といった設定の変更の管理が中心になります。

システムの運用・管理

日々の処理が決めたとおりに回り、止まっても戻せるかを見る領域です。地味ですが、記録は毎日たまります。監査人は、重要なデータやソフトウェアの消失に備えて内容を保存し迅速に復旧する対策があるか、障害や故障が起きたときに状況の把握・分析・解決が適切に行われているかを確かめます。バックアップの取得と復元の試験、夜間の処理の実行結果、障害の記録と対応の経緯が、この領域の記録になります。

内外からのアクセス管理などシステムの安全性の確保

データ、システム、ソフトウェアの不正使用、改ざん、破壊を防ぐために、適切なアクセス管理などの方針を定めているかを見る領域です。基準の書き方は短いものの、実務ではIDの登録・変更・削除の承認、退職者の取り消し、権限の棚卸し、特権ID、職務分掌と、確かめる論点が細かく分かれます。後の章で論点ごとに扱います。

外部委託に関する契約の管理

ITの業務を外部に委託しているとき、契約を適切に管理しているかを見る領域です。2023年の改訂で、評価の対象になる委託業務の例が増えました。情報システムの開発・運用・保守など、ITに関する業務を外部の専門会社に委託する場合です(実施基準 Ⅱ.2.(1)②イ)。委託業務が重要な業務プロセスの一部になっていれば、経営者は受託会社の内部統制の有効性も評価します。

やり方は選べます。自社で評価しても、受託会社が実施した評価の結果を使ってもかまいません。Q&A(問24)は、受託会社に報告を求める場合でも、日本公認会計士協会の保証業務実務指針3402に基づく報告書が必ず要るわけではないとしています。契約で求める統制、報告の受け取り方、委託先の担当者のIDと権限の扱いを、委託先ごとに決めておきます。

2023年の改訂で、IT全般統制に書き加えられたこと

企業会計審議会は2023年4月7日、財務報告に係る内部統制の評価及び監査の基準と実施基準を改訂しました。2008年4月1日以後に始まる事業年度に制度が適用されてから、15年余りを経た見直しです。改訂後の基準は2024年4月1日以後に始まる事業年度から適用され、3月決算の会社では2025年3月期が最初の年でした。金融庁は2023年8月31日、改訂を踏まえて「内部統制報告制度に関するQ&A」と事例集も改訂しています。

2026年10月時点で、金融庁の内部統制報告制度のページに並ぶ基準・実施基準の最新版は、この2023年の改訂です。3月決算の会社は、改訂後の基準による3回目の評価(2027年3月期)の期中にあります。評価範囲を選ぶ指標の例「売上高等のおおむね3分の2」などを段階的に削除するかどうかは、意見書で今後の検討事項とされています。

ITの委託と情報システムのセキュリティが「ITへの対応」に加わった

「ITへの対応」の説明に、記述が2つ加わりました(実施基準 Ⅰ.2.(6))。1つ目は、ITの開発・運用・保守の全部または一部を外部に委託するケースがあり、委託業務に係る統制の重要性が増していること。2つ目は、クラウドやリモートアクセスなどの技術を使うにあたり、サイバーリスクの高まりを踏まえて、情報システムのセキュリティを確保することが重要であることです。どちらもIT部門の守備範囲です。基準の定義にも、組織の内外のITに「適時かつ適切に」対応する、と「適時」が足されました。

筆者は、この2つの記述を、ITの使い方の変化を基準が追認したものと読んでいます。財務のシステムに、社外から、委託先の人も含めて入るのが当たり前になりました。アクセス管理と外部委託の領域では、統制の説明を求められる場面が改訂前より増えるはずです。

IT全般統制を複数年に一度評価するなら、年数を機械的に決めない

全般統制の項目で、前年度の評価結果が有効、かつ整備状況にも重要な変更がないものは、その旨を記録すれば、前年度の運用状況の評価結果を引き継げます。財務報告の信頼性に特に重要な影響を及ぼす項目は除きます。評価が複数年に一度になるのは、このためです。

改訂で加わったのは、この扱いへの注意書きです。経営者がIT環境の変化を踏まえて慎重に判断し、必要に応じて監査人と協議して行うこと。特定の年数を機械的に当てはめないこと。この2点です(実施基準 Ⅱ.3.(3)⑤ニ a(注))。自動化されたIT業務処理統制を複数年に一度テストする方法にも、同じ注意書きが付きました(同 ⑤ニ c(注))。

自動化された統制を過信しない

IT業務処理統制の評価にも、注意書きが加わりました(同 ⑤ニ b)。自動化された統制は、手作業より無効化しにくいものの、過信は禁物で、無効化のリスクを完全に防ぐのは難しい、という内容です。電子記録に変更の痕跡が残りにくいと、無効化が起きても発見が遅れることがある、とも書かれています。

業務処理統制の節に置かれた文ですが、全般統制にも関係します。誰がいつ何を変えたかの痕跡が残らない構成なら、その穴は変更管理とアクセス管理の側で埋めることになります。

評価範囲の指標は機械的に当てはめない

これはIT以外も含む改訂です。評価する事業拠点や業務プロセスを選ぶ指標の例(売上高等のおおむね3分の2、売上・売掛金・棚卸資産の3勘定)を、機械的に適用しないことが明記されました。範囲を決めるのは経営者です。計画の段階や状況が変わったときに、必要に応じて監査人と協議します(意見書 二(2)①)。業務プロセスの範囲が変われば、対象になるシステムとIT基盤も変わります。

承認、棚卸し、退職者の停止が LOCKED DAS・MSO でどう記録に残るかを、無料のデモでお見せします。 デモ・個別相談を申し込む →

IT全般統制の評価は、整備状況と運用状況の2段で進む

経営者による評価は、期末日を評価時点として行います(実施基準 Ⅱ.3.(1))。流れは、評価範囲の決定、整備状況の評価、運用状況の評価、内部統制報告書の提出、監査人による監査の順です。

整備状況の評価:統制が決めたとおりに置かれているか

まずは設計の確認です。統制が、リスクを十分に下げられるように設計され、実際に置かれているかを確かめます。手段は関連文書の閲覧、担当者への質問、観察などで(同 Ⅱ.3.(3)③)、アクセス管理なら、ID管理の規程、承認経路の設定、権限の設計、職務分掌のルールがその対象になります。整備状況を評価するときの留意事項には、「適切な職務の分掌が導入されているか」も挙がっています。

運用状況の評価:期中に決めたとおりに動いていたか

決めた統制が期中にそのとおり運用されていたかを確かめます。原則はサンプリングです(同 Ⅱ.3.(3)④ロ)。サンプルの件数や対象期間は、統制の重要性や複雑さ、担当者が行う判断の性質、実施者の能力、前年度の結果とその後の変更を考えて決めます。ITを利用した統制は、同じ処理を繰り返します。そのため、整備状況が有効と評価されれば、全般統制が有効であることを前提に、手作業の統制よりサンプル件数を減らし、対象期間を短くできます(同 ④ニ a)。

件数の目安はあるのでしょうか。監査人の手続の例なら、実施基準に載っています(同 Ⅲ.4.(2)①ロ)。日常反復する取引なら、統計上の二項分布を前提に、90%の信頼度を得るには統制上の要点ごとに少なくとも25件のサンプルが必要になる、という例です。全般統制の運用評価では、母集団を「期中に付けた権限」や「期中の退職者」のように定め、そこから抜いたサンプルの記録をたどります。

評価の記録は、縦覧期間の5年を目安に保存する

経営者は、評価の手続と結果、見つけた不備と是正措置を記録し、保存します(同 Ⅱ.3.(7))。形式に決まりはありません。会社がふだん作っている記録を使い、必要に応じて補えば足ります。保存期間は、有価証券報告書と添付書類の縦覧期間(5年)を勘案して同程度とすることが考えられる、とされています。ログには寿命があります。システムのログを証跡に使うなら、ログの保存期間が評価や監査で必要な期間より短くないかを、先に確かめておきます。

不備が見つかったときの扱い

IT全般統制に不備があっても、直ちに開示すべき重要な不備とは評価されません(同 Ⅱ.3.(4)③イ)。財務報告の重要な事項に虚偽記載が起きるリスクに、直接つながるものではないからです。とはいえ、軽く見てよいわけでもありません。業務処理統制が正しく作られていても、その運用を続けて保てない可能性があり、虚偽記載のリスクは高まります。経営者は、代わりになる統制や補う統制で目的が達成されているかを検討します。

Q&A(問14)には、こんな例があります。プログラムの変更管理に不備があっても、業務処理統制にかかわるプログラムが実際には変更されていないと事後に確かめられれば、そのシステムの統制は有効に機能していると位置づけられる、というものです。

IT全般統制のアクセス管理で見られる論点と記録

アクセス管理について、基準と実施基準の記述は多くありません。「内外からのアクセス管理などのシステムの安全性の確保」と、不正使用・改ざん・破壊を防ぐためのアクセス管理の方針までです。実務では、これを次のような論点に分けると、置く統制と残す記録を決めやすくなります。論点の分け方は当社の整理で、基準が項目として定めたものではなく、どの論点をどう評価するかは会社と監査人が決めます。

論点評価で確かめること(例)残しておきたい記録(例)
IDの登録・変更・削除の承認決めた承認を経て行われ、記録が残っているか申請者・承認者・日時、付与や削除の結果
退職・異動のときの取り消し決めた期限までにIDを止め、権限を外したか人事の退職日・異動日と、停止・変更の日時
定期的な権限の棚卸し権限を定期的に見直し、要らない権限を外したか判定の結果、判定者・日時、外した記録
特権IDの管理管理者の権限を持つIDを把握し、付ける人を限り、使い方を確かめているか特権IDの一覧、付与の承認、利用の記録
職務分掌(職務の分離)相反する権限が同じ人に集まっていないか分ける組み合わせの定義、違反の一覧と対応
認証パスワードや多要素認証の設定が決めたとおりか設定の画面、設定変更の記録
ログによるモニタリングアクセスや設定変更の記録を残し、定期的に確かめているかログ、確かめた日と結果
外部委託先のアクセス委託先の担当者のIDと権限を、必要な範囲と期間に限っているか委託先IDの一覧、権限の期限

このうち、記録の残し方で評価のしやすさが変わる4つを補足します。

退職者のIDは「いつ止めたか」まで問われる

退職者の停止は、母集団とサンプルが分かりやすい統制です。そのぶん、記録の穴も目立ちます。母集団は期中の退職者全員です。抜き出した人ごとに、人事の退職日と、各システムでIDを止めた日時を突き合わせます。例を挙げます。「退職日の翌日までに止める」と決めていて、1件だけ1週間遅れていたとします。その場合は、遅れた理由と、遅れた間に使われていないかを確かめることになります。

止めた日時が残っていなければ、評価はここで止まります。人事の情報と停止の操作を結び付け、日時の残る形で運用しておくのが近道です。

権限の棚卸しは、見直した証拠と外した証拠をそろえる

棚卸しでは、権限を見直したことと、要らない権限を実際に外したことの両方が見られます。表計算ソフトの一覧を配って「問題なし」の返信を集めるだけでは足りません。誰がいつ何を判断したか、外す指示が実行されたかを追えないからです。判定者、日時、判定の理由、外した日時が一続きで残る形にします。期末日にも注意が要ります。経営者の評価は期末日が評価時点なので、その日に誰がどの権限を持っていたかを示せるかも確かめておきます。

特権IDは、数を絞り、使い方まで確かめる

管理者の権限を持つIDは、統制そのものを書き換えられます。会計システムの管理者が承認経路の設定を変えられるなら、承認の統制は管理者の善意に頼ることになります。それでは統制として弱いままです。最初は一覧づくりです。特権IDの持ち主と用途をはっきりさせ、付与は承認を経て必要な期間に限ったうえで、特権IDで行った操作を記録し、定期的に確かめます。サーバーのOSやデータベースの特権IDまで含めるなら、専用の特権ID管理の仕組みが要ることもあります。

職務分掌は、どの職務を分けるかを先に決める

職務を複数の者の間で適切に分担または分離することが重要だ、と実施基準は統制活動の説明で述べています(同 Ⅰ.2.(3))。挙がっている例は、取引の承認、記録、資産の管理を別の人に担当させることです。システムに置き換えると、次のような組み合わせが検討の対象になります。

  • 会計システムで仕訳を起票する権限と、承認する権限
  • 購買システムで取引先を登録する権限と、支払を承認する権限
  • プログラムを変更する権限と、本番環境に反映する権限

最初にやるのは、自社で分けるべき組み合わせを決めることです。決めるのは会社です。ツールは代わりに決めてくれません。決めた組み合わせを権限を付ける手続に組み込み、付ける前に気づけるようにしておくと、違反を後から探して外す手間が減ります。例外はありえます。同じ人に持たせるなら、その理由と、代わりに置く確認(上長によるログの確認など)を記録します。

アクセス管理の論点ごとに、評価で確かめることと LOCKED DAS・MSO で残せる記録を、対応表にまとめています。 監査と権限の棚卸し(J-SOX・ISMS・個人情報保護法)を見る →

IT全般統制を整える手順

順番は、評価の流れから逆算して決めます。

  1. 財務報告に関わるシステムと、その入口を一覧にする。重要な勘定科目からたどったシステムごとに、管理する部門、IT基盤、委託先、ログインの経路(ID管理の仕組みを通るか、直接か)、権限の種類を書き出します。
  2. 領域ごとに方針と手続を決める。実施基準の全社的な内部統制の評価項目の例には、経営者がIT全般統制とIT業務処理統制の方針と手続を適切に定めているか、という項目があります。変更管理、バックアップ、ID管理、委託先の管理の規程と、記録の置き場所をここで決めます。
  3. 期中に回し、評価の前に自分たちでサンプルを抜いてみる。記録がそろっているかは、実際に抜いてみないと分かりません。期の途中で一度試せば、記録の残っていない統制を期末までに直せます。
  4. 評価範囲と評価の頻度は、早めに監査人と協議する。2023年の改訂で、範囲の協議は評価の計画の段階で必要に応じて行うことが明確になり、複数年に一度の評価も、必要に応じて監査人と協議して判断するものとされました。

上場準備(IPO)の会社が押さえること

上場すると、事業年度ごとに内部統制報告書を出します。新たに上場した会社には、上場した日などから3年を経過する日までの間、内部統制報告書の監査証明の免除があります。上場した年度の直前の事業年度で、資本金が100億円以上か、負債の合計額が1,000億円以上の会社は免除されません(金融商品取引法、内部統制府令 第10条の2)。免除されるのは監査だけです。内部統制報告書そのものは提出し、経営者の評価も行うので、IT全般統制の記録は上場の前から残る形にしておくと、最初の評価で慌てずに済みます。

LOCKEDでアクセス管理の統制を回し、評価で使う記録を残す

担えるのは、IT全般統制のうちアクセス管理の統制の一部と、その記録です。

起点は人事の情報です。LOCKED DAS は、人事の情報からIDを作成・変更・停止し、それ以外の権限は申請と多段の承認を経て付けます。申請者・承認者・日時は申請履歴に、付与・剥奪・無効化の結果と日時はプロビジョニング履歴に残ります。人事の情報で退職日を過ぎたら連携先のアカウントを止め、異動では権限を付け替えて、前の権限は引き継ぎの猶予期間のあとに外します。

棚卸しは、アクセスレビューで権限ごとに受認・取消・保留を判定します。最大10段階のレビューに、AIエージェントによる一次判定を組み合わせることもでき、判定者・日時・コメントと、判定を上書きした理由が残ります。特権にあたる権限には印を付けて、特権を持つアカウントを一覧にでき、付与は申請と承認を経て期限付きにもできます。職務分離は、同じ人に持たせない権限の組み合わせをポリシーで決め、付ける前に違反を警告し、違反しているユーザーをポリシーごとに一覧にします。日時を指定して、その時点で誰がどの権限を持っていたかも確かめられます(LOCKED DAS と連携したサービスの権限が対象)。期末日の確認に使えます。ただし、自動のルールで付いた権限などで、その時点の状態を完全に再現できない場合は、一覧の代わりに理由が表示されます。

ログインの側は LOCKED MSO が受け持ちます。LOCKED 経由でログインするサービスに、パスワードのルール、続けて失敗したときのロック、二段階認証をかけます。管理画面の操作は、日時・操作者・操作元のIPアドレス・操作の種類を監査ログに残し、最大1年分ずつCSVで書き出せます。委託先の担当者にも一人ずつIDを発行し、使えるサービスをグループで、入れる場所をIPアドレスなどの条件で絞れます。

LOCKEDの範囲外のものもあります。システムの開発・保守と運用・管理、IT業務処理統制、財務のシステムのなかでの操作の記録、OS・データベース・ネットワーク機器の特権IDと操作の録画、受託会社の内部統制の評価です。LOCKEDを通らないログインと、各サービスのなかでの操作も、LOCKEDの記録には残りません。

LOCKED そのものも評価の対象になり得ます。LOCKEDで承認や棚卸しを行えば、それ自体がITを利用した統制になるからです。その場合、LOCKEDの管理者の権限や設定の変更の管理も、評価で見られることがあります。管理者の権限は、LOCKED MSO ではオーナー・管理者・閲覧者で分けられます。LOCKED DAS の管理画面の監査ログは、期間を指定してサポートに依頼すると、数営業日で提出します。評価の範囲と手続き、有効かどうかの結論は、会社と監査人が決めます。

評価範囲のシステムやいまの運用に合わせた、アクセス管理の整え方を無料でご相談いただけます。 資料請求・お問い合わせはこちら →

参考資料

関連記事

よくある質問

LOCKED

この課題、LOCKEDで解決できます

「2026年版 情シスが直面するIDガバナンス5大課題」など、検討に役立つ資料を無料でご用意しています

LOCKEDシリーズの詳細資料を無料でダウンロード

導入事例、機能詳細、他社比較など、検討に必要な情報をまとめた資料をご用意しています

まずは資料で詳細を確認

製品資料で機能・料金・導入事例をまとめてご確認いただけます

資料をダウンロード