SCS評価制度の準備を進めていくと、途中で必ず同じところで手が止まります。対策そのものはすでに入っている。多要素認証も使っている。退職者のアカウントも止めている。それなのに、では何を出せば「やっている」と認めてもらえるのかが分からない。

ここが★3対応でいちばん時間を食う工程です。評価されるのは対策を実施したという事実ではなく、実施を示す記録のほうだからです。日付が入っていない権限一覧、誰に配ったのか分からない周知メール、いつ時点なのか読み取れない台帳。実務としては十分に回っていても、記録の形が整っていないために証跡として使えない。そうした状態が現場でよく起きています。

この記事では、★3の評価基準81件を対象に、証跡の現物イメージまで落とし込みます。どの領域で、何を、どの粒度で、どの頻度で残すのか。評価基準の文言から求められる記録を読み取る手順も含めて整理しました。基準日は2026年9月15日です。制度そのものの全体像はSCS評価制度とはで扱っているため、この記事は記録の側だけに絞ります。

SCS評価制度の証跡とは｜評価されるのは実施を示す記録

SCS評価制度の証跡とは、評価基準が求める対策を実施したことを、第三者が確認できる形で示す記録です。

言葉としては監査や内部統制で使われる「エビデンス」とほぼ同じ意味になります。ただしSCS評価制度では、★3であっても社内で完結しません。ここが証跡の作り方に効いてきます。

実施したことと、実施を示せることは別

制度対応の相談を受けていて最も多いのが、「対策はすでにやっています」という状態のまま止まっているケースです。

たとえば退職者のアカウント削除。人事から連絡が来たらその日のうちに止めている。運用としては問題ありません。ところが記録を探すと、削除した事実がどこにも残っていない。SaaSの管理画面には現在の状態しか出ておらず、いつ止めたのかを後から示せない。この状態だと、評価の場面では「実施している」と主張はできても、それを裏づけるものがありません。

評価基準は実施の有無を問うています。そして実施の有無を確認する手段が記録です。対策と記録は別々に用意するものではなく、対策を回す過程でそのまま記録が落ちてくる形にしておくのが本来の姿になります。

日付・対象者・内容がそろって初めて証跡になる

証跡として成立する条件を最小限まで削ると、3つに落ち着きます。いつ実施したのか、誰を対象にしたのか、何を実施したのか。この3点です。

3つのうちどれが欠けても、記録としての価値が一段落ちます。とくに落としやすいのが対象範囲です。セキュリティ研修の受講記録が残っていても、そのとき在籍していた全員が対象だったのかどうかが分からないと、範囲の網羅性を示せません。

もうひとつ、実務上は取得元も残しておくと後が楽になります。どのシステムのどの画面から出した情報なのか。これが残っていれば、翌年に同じ証跡を作り直すときに手順を思い出す必要がなくなります。

★3でも専門家の確認と署名が前提になる

★3は専門家確認付きの自己評価です。「自己評価」という言葉から社内だけで完結すると読まれがちですが、SCSセキュリティ専門家の確認と署名が前提になっています。

つまり証跡は、社内の事情を知らない第三者が読む前提で作る必要があります。社内では通じる略語、担当者の頭の中にしかない背景、口頭で補足してきた運用。これらは証跡の中に文字として入っていなければ伝わりません。

この前提を最初に置いておくかどうかで、記録の作り方が変わります。自分たちが後から見返すためのメモと、第三者が判断材料にするための記録は、必要な情報量が違います。

参考：IPA SCS評価制度 詳細情報

評価基準の文言から、求められる記録を読み取る

証跡を集める前に必要なのが、評価基準がどんな記録を求めているのかを読み取る作業です。ここを飛ばして手元にある資料から並べ始めると、量は増えるのに対応づけができない、という結果になりがちです。

★3の要求事項26と評価基準81が具体的に何を求めているかは、★3の要求事項26と評価基準81の全一覧で項目単位に整理しています。ここでは、読み取りの手順のほうを扱います。

文末の動詞で、証跡の型が決まる

評価基準の条文は、文末の動詞に注目すると求められている記録の型が見えてきます。

この読み替えができると、「何を出せばいいのか」の議論がかなり短くなります。文書を求めている条文に対して運用記録を出しても埋まりませんし、その逆も同じです。

頻度の語を拾う

SCS評価制度の評価基準には、頻度そのものが書き込まれています。ここは証跡の作り方に直結する部分です。

とくに14日以内のパッチ適用は、記録の設計を誤ると示せなくなります。パッチが当たった状態は管理画面を見れば分かりますが、脆弱性が公開されてから何日で当たったのかは、公開日と適用日が両方残っていないと計算できません。現在の状態だけを見せる台帳では、この基準は埋まらないということです。

対象範囲の語を拾う

もうひとつ拾っておきたいのが、誰を対象にするのかという語です。周知に関する条文には、役員・従業員・派遣社員・受入出向者までが対象として明記されています。

正社員だけを対象にした研修記録では範囲が足りません。派遣社員や出向で来ている方にどう伝えたのか、その記録が別に要ります。人の出入りがあるたびに説明の機会が発生するため、入社時のオリエンテーションに組み込んでおくのが現実的な形になります。

在籍者名簿と受講者リストを突き合わせて、差分がゼロであることを示す。この1枚があると、範囲の網羅性についての説明がほぼ不要になります。

参考：IPA SCS評価制度 要求事項・評価基準

証跡の取り方は3つに分かれる（ジョーシス独自の整理）

この3つの分け方は、制度が定めたものではありません。IPAが公開している評価基準を、証跡をどう集めるかという観点でジョーシスが独自に整理したものです。

★3の81評価基準は、証跡をどう集めるかという軸で見ると3つに分かれます。

なお、この3分類は、IPAが公開している要求事項・評価基準の各基準に、想定される証跡の取得手段をジョーシスが割り当てて集計したものです。制度が定めた区分ではありません。

3つがつながって、ようやく1つの基準が埋まる

この分け方で気をつけたいのは、3つが独立していないことです。ひとつの基準を埋めるために、3種類の証跡が同時に要る場面が出てきます。

パスワードの取り扱いが分かりやすい例になります。まず規程にルールを書く。これが文書の証跡です。次に、そのルールどおりにIdP側の設定が入っていることを示す。これがシステムの証跡です。最後に、ルールを全社に周知した記録を残す。これが人手の証跡になります。

規程だけがあって設定が伴っていない、あるいは設定は入っているのに誰にも伝えていない。どちらの状態でも、その基準は満たしたことになりません。3つを別々のプロジェクトとして進めると、この整合を取る工程が最後にまとめて降りかかってきます。

集め始める順番

先に着手すべきなのは、時間の経過でしか積み上がらないものです。

システムから取る証跡は、台帳と設定が整っていれば取得そのものは短時間で終わります。文書も、書く工数はかかるものの、腰を据えれば期間内に作り切れます。積み上がらないのは人手の記録のほうです。年1回の点検記録は、実施した年からしか存在しません。去年やっていなければ、去年の分は作れない。

つまり、記録の様式を先に決めて実施を始めておく作業だけは、申請の時期が確定するのを待つ理由がありません。ここは後述します。

参考：IPA「★3・★4 要求事項及び評価基準」（Excel・2026年4月21日版／2026年9月15日取得）

ID・アクセス権の証跡｜件数が最も多い領域

以下で使う件数の分け方は、前述のとおりジョーシスが独自に整理したものです。制度が定めた区分ではありません。

システムから取る40件のうち、アイデンティティに関するものが15件を占めます。管理者IDが5件、ユーザIDが4件、認証強度が4件、ロックが2件という内訳です。

★3の81基準を内容で分け直すと、アイデンティティ・認証が27件で全体の33%と最多になります。証跡の準備でもここが最大の山になると考えて差し支えありません。

この内訳も、内容で分け直した件数も、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものであり、制度が定めた区分ではありません。

何を残すか

この領域で必要になる証跡を、現物のイメージで並べます。

一覧そのものは多くの組織がすでに持っています。差が出るのは列のほうです。作成日と最終ログイン日が入っていない一覧は、休眠アカウントの有無を示せません。付与日と業務上の必要性が入っていない管理者権限の一覧は、権限が必要な人に限定されていることを示せません。

どの粒度で残すか

粒度の判断で迷いやすいのが、アカウント単位まで出すのか、件数のサマリーで足りるのかという点です。

実務としては、サマリーと明細の両方を持っておくのが安全です。サマリーは「対象アカウント1,240件のうち多要素認証適用は1,238件、未適用2件」のように1行でまとめたもの。明細は、その未適用2件が何のアカウントで、なぜ適用できないのかまで書いたものになります。

未適用や例外がゼロである必要はありません。例外があることそのものよりも、例外を把握していないことのほうが問題になります。把握して、理由を書いて、代替の対策を添える。この形にしておけば、説明の材料として機能します。

どの頻度で残すか

退職IDの削除は常時、全アクセス権の棚卸しは年1回と頻度が示されています。

退職IDについては、削除の速さそのものよりも、削除までにかかった日数が記録に残ることのほうが重要になります。人事の連絡が来てから手作業でアカウントを止めていく運用だと、どうしても数日から数週間のずれが生まれます。そのずれが記録に残ってしまう点が、従来の内部統制対応とは少し違うところです。削除手順の設計については退職者アカウントの削除手順で具体的に扱っています。

年1回のアクセス権棚卸しは、実施したこと自体よりも、誰が確認して何を判断したのかが残っているかどうかで質が決まります。棚卸しの進め方と自動化の考え方は、アクセス権レビューの進め方と自動化にまとめています。

端末・脆弱性とネットワークの証跡

この節で使う件数の分け方も、前述のとおりジョーシスが独自に整理したものです。制度が定めた区分ではありません。

アイデンティティに続いて件数が多いのが、端末と脆弱性の10件、ネットワークの7件です。端末側は資産把握3件・マルウェア対策3件・構成2件・パッチ2件、ネットワーク側は境界防護5件・構成把握1件・通信監視1件という内訳になります。

この内訳も、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものであり、制度が定めた区分ではありません。

端末側で残すもの

端末側は、台帳と設定状況をそろえる作業が中心になります。台帳だけでは足りず、その台帳が実態を写しているかどうかまで示せる形にしておくのがここでの要点です。必要になる証跡を、含めたい項目と頻度の目安とあわせて並べます。

端末の証跡で見落としやすいのが、台帳に載っていない端末の扱いです。台帳が申請ベースで作られていると、申請を通さずに使われている端末が写りません。利用実態の側から取得した情報と突き合わせて、差分がないことを確認する。この突き合わせの記録自体が、把握できていることの裏づけになります。

パッチについては、先ほど触れたとおり公開日と適用日の両方が必要です。管理ツールから出せるのが現在の適用状態だけである場合、脆弱性の公開日は別途記録しておく必要があります。運用としては、重大な脆弱性が公表されたタイミングで対応チケットを起票し、そのチケットの起票日と完了日を証跡に使う形が扱いやすくなります。

ネットワーク側で残すもの

ネットワークは7件と件数こそ少ないものの、証跡の作り方が他と異なります。台帳を出せば済む領域ではなく、設定変更の手続きが記録として残っているかどうかが問われるためです。

構成図は、作った日付が入っていないものが意外と多く見つかります。いつ時点の構成なのかが分からない図は、現状を把握できていることの証跡になりません。更新日と更新者を図の中に入れておくだけで扱いが変わります。

ログの分析についても同様です。ログが保存されていることと、分析していることは別の話になります。月1回の認証ログ監視であれば、いつ、どのログを、誰が見て、どう判断したのかを1行ずつ残していく。何も検知されなかった月も「該当事象なし」と記録に残しておく必要があります。空白の月があると、実施していなかったのか記録し忘れたのかを区別できません。

SCS評価制度が求めるIT環境の把握そのものについては、SCS評価制度が求めるIT環境の把握で範囲の切り方から扱っています。

証跡を集める作業をどこまで機械化できるか整理したい場合は、ITデバイスとSaaSアカウントの一元管理の考え方をまとめた資料が参考になります。

5分でわかるジョーシスの資料をダウンロードする

文書の証跡｜11種類ほどを評価基準の粒度に合わせる

ここで使う25件という数え方も、前述のとおりジョーシスが独自に整理したものです。制度が定めた区分ではありません。

文書で示す25件は、作る書類の種類そのもので見ると11種類ほどにとどまります。

この内訳も、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものであり、制度が定めた区分ではありません。

難所は種類の数ではなく、粒度と整合性のほうにあります。

粒度が合っていないと、あることを示せない

パスワードのルールが分かりやすい例です。評価基準の側では6つに分解されています。初期パスワードを変更すること、推測されやすい単語の設定を禁止すること、多要素認証を使うか一定回数の失敗でロックすること、機器やサービス間で使い回さないこと。こうした要素がそれぞれ独立した基準として立っています。

これに対して「パスワードポリシーは策定済みです」という回答だけでは、6つのどれが記述されていてどれが抜けているのかを示せません。規程の中の該当箇所を、基準ごとに指し示せる状態にしておく必要があります。

実務としては、評価基準の番号を左列に、対応する文書名と条項番号を右列に置いた対応表を1枚作るのが早道です。この表があれば、抜けている箇所もそのまま可視化されます。

方針・規程・手順・記録の4階層をつなぐ

もうひとつ求められるのが、階層のつながりです。上位の方針があり、それを具体化した規程があり、実際の作業に落とした手順があり、実施した記録がある。この4つがつながっていることが問われます。

現場でよく見つかるのが、手順書だけが存在する状態です。担当者が実務のために作った手順書は詳細まで書かれているのに、その根拠となる規程や方針と結びついていない。この状態は指摘の対象になります。逆に、方針と規程だけがあって実際の作業手順に落ちていない状態も、運用されている証跡が出てきません。

既存の文書から出発する場合は、ISMSやプライバシーマークで作ってきた体系が使えることも多くあります。ただし、そのままの形で通るとは考えないほうが安全です。評価基準の条文単位で突き合わせて、どの文書のどこが対応しているかを示す工程は残ります。文書体系そのものの作り方は、情報セキュリティポリシーの作り方と運用設計で策定ステップから扱っています。

改訂履歴そのものが証跡になる

文書を作ったあと、意外と効いてくるのが改訂履歴です。

★3の有効期間は1年で、毎年の更新が必要になります。2年目以降は、前年から何が変わったのかを示す場面が出てきます。改訂日・改訂内容・承認者が版ごとに並んでいれば、そのまま説明の材料になります。

さらに、文書を改訂したときには周知の記録も連動して必要になります。対応方針を改正した場合、改正したこと自体を全社へ周知する基準が別に立っているためです。文書の改訂と周知の記録をひとそろいで残す運用にしておくと、翌年の準備がかなり軽くなります。

周知・点検の証跡｜人手16件は記録の型で決まる

ここで使う16件という数え方も、前述のとおりジョーシスが独自に整理したものです。制度が定めた区分ではありません。

人手で回す16件は、作業そのものの難易度は高くありません。それでも準備でつまずきやすいのは、記録の形が決まっていないためです。

この内訳も、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものであり、制度が定めた区分ではありません。

周知の証跡は4点セットで残す

周知の記録は、次の4つが埋まる様式を先に作っておくと、実施のたびにそのまま証跡になります。

ここに1列足すとすれば、到達の確認です。配信しただけでは、届いたかどうかが分かりません。開封状況や受講完了の記録、あるいは確認した旨の返信を集める形にしておくと、範囲の網羅性まで示せるようになります。

未読者や未受講者が残ることは珍しくありません。その場合は、再送した記録と、最終的な未対応者の人数と対応状況まで書いておけば、管理できている状態として説明できます。

年1回の点検は、結果より過程を残す

年1回の点検は、推進体制・情報管理ルール・インシデント対応体制が対象になります。

点検の記録で抜けやすいのが、何を確認したのかという項目の部分です。「点検を実施し、問題なしと判断した」だけの記録では、どこまで見たのかが分かりません。確認項目をあらかじめリスト化しておき、項目ごとに確認結果を書く形にしておけば、その場で証跡になります。

指摘事項が出た場合は、是正した記録までセットにします。指摘が出ること自体は減点材料ではありません。点検が形骸化していないことを示す材料として、むしろ有利に働きます。

申請・承認は、往復がそろっていること

設定変更の申請と承認は、片側だけが残っているケースをよく見かけます。申請のチケットはあるけれど誰が承認したのか記録がない、あるいは承認のやり取りがチャットに流れて後から追えない。

申請日・申請内容・申請者・承認者・承認日・実施日。この6つが1件ごとに並ぶ形にしておけば足ります。既存のワークフローツールやチケット管理を使っているなら、そのエクスポートがそのまま証跡になります。新しい仕組みを入れる必要はありません。

毎年やり直しになる

人手16件がほかの領域と決定的に違うのが、毎年ゼロから積み直すという点です。

★3の有効期間は1年です。更新のたびに、その年に実施した周知と点検の記録が新しく必要になります。前年に出したものを再提出して済ませる形にはなりません。★4を目指す場合も同じで、3年更新のあいだ毎年の自己評価を評価機関へ提出する必要があります。★3と★4で運用の負荷がどう変わるかは、★3と★4の違いを要件・評価方法・有効期間で比較した記事で扱っています。

だからこそ、記録の様式を決めておく価値が大きくなります。様式が決まっていれば、実施した時点で証跡が完成します。様式がないと、実施の事実はあるのに記録の形がそろわず、証跡として使えないまま作り直しになります。

参考：IPA SCS評価制度 よくある質問

専門家の確認で見られる点

★3はSCSセキュリティ専門家の確認と署名が前提になっています。ここで何が見られるのかを想定しておくと、証跡の作り方が具体的になります。

基準と証跡の対応表があるか

確認する側から見て最初に必要になるのが、どの基準にどの証跡が対応しているのかという地図です。

証跡のファイルだけを大量に渡されても、どれがどの基準に対応するのかを読み解く作業から始まってしまいます。基準の番号、求められていること、対応する証跡のファイル名、補足。この4列の対応表を1枚作っておくと、確認の工程がそのまま進みます。

この対応表は、社内の準備段階でも役に立ちます。空欄がそのまま未対応の一覧になるためです。証跡を集める前にこの表の枠だけ作っておくと、何が足りないのかが早い段階で見えます。

時点がそろっているか

証跡ごとに取得日がばらばらだと、全体として今の状態を示せているのかが判断しにくくなります。

アカウント一覧は4月に取ったもの、端末台帳は8月に取ったもの、権限一覧は昨年のもの。こうなると、組み合わせて読んだときに整合しません。基準日を決めて、その前後の一定期間内に取得したものでそろえる。この方針を最初に決めておくと後の手戻りが減ります。

実務としては、評価を受ける時期から逆算して証跡の取得月を決め、台帳系は同じ月にまとめて出力するのが扱いやすくなります。

未達や例外をどう書いているか

すべての基準を完全に満たした状態でなければ話が進まない、ということはありません。むしろ、未達の項目を把握していて、いつまでにどう対応するのかを書けている状態のほうが、管理できていることの証明になります。

例外についても同じです。技術的な制約で多要素認証を適用できないアカウントがある。その場合は、対象、理由、代替として実施している対策、見直しの時期。この4点を書いておけば、説明の材料として成立します。

隠す、あるいは触れない。この対応がいちばん不利になります。確認の過程で出てくる話であれば、先に自分たちで整理して出しておくほうが結果的に早く進みます。

証跡の作り置きが効く｜今日から始められること

2026年9月15日時点で、SCS評価制度の申請はまだできません。評価機関・評価用ガイド等の公表は2026年度下期、運用開始は2026年度末頃の想定とされています。

それでも証跡の準備を先に始める理由があります。記録は、集め始めた時点からしか積み上がらないためです。とくに人手で回す16件は年1回の実施記録が求められるため、直前にまとめて作ることができません。

1. 記録の様式を先に決める

いちばん費用がかからず、いちばん効くのがこれです。周知の4点セット、点検の確認項目リスト、申請と承認の6項目。この3つの様式を決めて、今期の実施分から使い始める。それだけで、来年の準備が1年分先に進みます。

様式は凝る必要がありません。表計算ソフトの1シートで十分です。重要なのは、誰が実施しても同じ形で残ることのほうです。

2. 台帳をシステムから取り出せる状態にする

システムで取る40件は、台帳と設定状況をAPIで取り出せるかどうかがすべての前提になります。

かつては年に一度の資産棚卸しで台帳を更新し、その間の変更を差分で追いかける運用が一般的でした。現在は各システムのAPI経由で利用実態を自動取得し、台帳を常に最新に保てるようになっています。制度が求める常時の維持に応えるには、この形に寄せるのが現実的です。

手作業で維持している台帳の場合、証跡として出したときに最終更新日が半年前になっている、という状態が起きがちです。台帳があること自体ではなく、鮮度が問われる点に注意が必要になります。

3. 基準と証跡の対応表の枠を作る

3つ目が、先ほど触れた対応表です。基準の側から出発して、対応する証跡の欄を埋めていく。

既存の文書を読み込んでから足りないところを探す進め方より、基準の側から当てていくほうが早く終わります。前者は網羅性を確認できないため、途中でやり直しになりがちです。

証跡を集める部分は仕組みで引き受けられる（ジョーシス独自の整理）

ここで示すカバー率も、制度が定めたものではありません。前述の3分類と同じく、ジョーシスが独自に整理した区分にもとづく集計です。

ジョーシスの集計では、システムから証跡が取れる40件のうち29件、73%を Josys 12件、Josys EMS 13件、IdP 4件の組み合わせでカバーできます。内訳としては、Josysでカバーするものが25件、既存のIdPで足りるものが4件です。

この数値は、IPAが公開している要求事項・評価基準の各基準に、想定される証跡の取得手段をジョーシスが割り当てて集計したものであり、制度が定めた区分ではありません。評価基準番号との1対1対応でもありません。

内容としては、JosysがID台帳と入退社にともなうアカウントの発行・削除、SaaS台帳、委託先の管理、棚卸しの記録を受け持ちます。Josys EMS が端末台帳、パッチ適用、暗号化、サポート切れの検出、マルウェア対策の状況を受け持ちます。多要素認証やパスワードポリシー、認証方式の設定は、すでに導入されている Microsoft や Google などのIdPの設定状況がそのまま証跡になります。

残る41件は、文書25件と人手16件です。こちらは規程の整備と社内の運用で埋める領域になります。ジョーシスでは、対応状況の横断的な可視化、対応に必要な文書の自動更新、改善計画の策定、日々の実行タスクの提案を一気通貫で支援する「SCSオンボード機能（仮称）」を2026年12月にリリース予定です。名称は仮称であり、提供時期とあわせて今後変更となる可能性があります。

自社の証跡がどこまで機械的に集まる状態なのかを確認したい場合は、実際の画面で確認いただけます。

オンラインデモを予約する

よくある質問

証跡はいつから集め始めればよいですか

記録の様式を決める作業は、今すぐ始めて損がありません。年1回の点検や全社周知の記録は、実施した年からしか存在しないためです。申請の受付開始を待ってから集め始めると、1年分の空白がそのまま残ります。台帳系の証跡は後からでも取得できますが、実施記録は時間の経過でしか積み上がりません。

スクリーンショットや表計算ソフトのファイルでも証跡になりますか

形式そのものに指定はありません。日付・対象範囲・内容が読み取れることのほうが要件になります。スクリーンショットの場合は、取得日と何の画面かが写っているかを確認してください。表計算ソフトのファイルは、取得日と取得元を1行目に書いておくと扱いやすくなります。加工したものは、加工前の元データも残しておくと説明が楽になります。

ISMSで作った記録はそのまま使えますか

流用できる場面はあります。ただし、そのまま通るとは考えないほうが安全です。ISMSとSCS評価制度の関係について、公式な整理は2026年9月15日時点で公表されておらず、免除規定も確認できません。評価基準の条文単位で、どの文書のどの部分が対応するかを示す工程は残ります。既存の記録を出発点にして、粒度の差を埋めていく進め方が現実的です。

証跡はどのくらいの期間保管すればよいですか

保管期間について、制度側の定めは2026年9月15日時点で公表されていません。実務上は、★3の有効期間が1年で毎年更新となるため、少なくとも前回の評価時に提出した一式を次の更新まで保持しておく形になります。前年分と当年分を並べて差分を説明できる状態にしておくと、更新時の負荷が下がります。

まとめ

SCS評価制度の証跡について、押さえておきたい点を整理します。

評価されるのは対策を実施したことではなく、実施を示す記録です。日付・対象範囲・内容の3つがそろって、初めて証跡として機能します。★3も専門家の確認と署名が前提になるため、社内の事情を知らない第三者が読む前提で作る必要があります。

証跡の取り方は、システムで取る40件、文書で示す25件、人手で回す16件の3つに分かれます。ひとつの基準を埋めるために3種類の証跡が同時に必要になる場面があり、別々に進めると最後に整合を取る工程が残ります。

なお、ここで触れた証跡の取り方の3分類は、制度が定めた区分ではありません。ジョーシスが独自に整理したものです。

そして、記録は集め始めた時点からしか積み上がりません。申請はまだできませんが、周知と点検の様式を決めること、台帳をシステムから取り出せる状態にすること、基準と証跡の対応表の枠を作ること。この3つは今日から始められます。

ジョーシスでは、ITデバイスとSaaS、アカウント情報を一元管理し、評価のときに出せる証跡として蓄積する仕組みを提供しています。自社の現状をどこまで機械的に把握できるか確認したい場合は、資料をご覧ください。

5分でわかるジョーシスの資料をダウンロードする

関連記事：IT内部統制とは｜基礎知識とJ-SOX対応の実務