2026年、セキュリティやIT統制まわりの制度が、立て続けに動いています。改正個人情報保護法の成立、SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）の制度構築方針、そして2024年度から適用された改訂J-SOX──。

制度の解説記事は、すでに世の中にたくさんあります。なので、この記事ではそこを繰り返しません。私が情シス・セキュリティの現場にいて、エンジニアや情シス担当が本当に知りたいのは、もっと手前の一点だと感じています。

「で、結局、うちは"何を"証跡として残しておけばいいのか」

制度は「体制を整えよ」「対策せよ」と言います。でも現場で手を動かす側が欲しいのは、"どのログを、どういう形で残しておけば、後で問われたときに示せるのか"という、具体的な地図です。この記事は、三つの制度を「求められる証跡」という一点で並べ直して、その地図を描くことを目指します。

（※各制度とも施行・運用はこれからで、規則やガイドラインは今後具体化される部分が残ります。ここでは「何が求められる方向にあるか」を、断定を避けて整理します。）

一の矢｜改正個人情報保護法 ── "統制していること"を証跡で示せるか

2026年7月に成立した改正個人情報保護法の要は、課徴金制度の新設です（日本で初めて、この分野に行政上の金銭的な制裁が入りました。適用範囲は一定の類型や大規模な侵害などに限定されます）。

技術者目線でこれを翻訳すると、こうなります。金銭的制裁が視野に入ると、「うちは個人データの取り扱いを、きちんと統制できている」と証跡をもって示せるかの重みが上がる、ということです。

では、何を残すのか。方向として求められるのは、たとえば以下のような記録です。

個人データへのアクセスログ（誰が、いつ、どのデータに触れたか）
権限の付与・変更の記録（誰がその権限を、いつ、誰の承認で得たか）
漏洩・不正アクセスを検知し、対応した記録
今回の改正で規律が強化された領域（16歳未満の個人情報、顔認証・指紋・声紋などの「特定生体個人情報」）を扱う場合の、取得・利用の記録

これらは特別な話ではなく、「ログとして残っているか、後から追えるか」という、エンジニアにとってはお馴染みの問いです。ただ、"制度が金銭的制裁付きでそれを求め始めた"という点が、これまでと違います。

二の矢｜SCS評価制度 ── 取引先に出せる"エビデンス"を持っているか

2026年3月に制度構築方針が公表されたSCS評価制度は、企業のセキュリティ対策の水準を★3・★4で可視化する仕組みです（★5は今後検討。評価ガイドは2026年秋ごろ、申請受付は2026年度末ごろが目標とされています）。★3は全企業が満たすべき基礎水準で、NIST CSF 2.0などの国際基準の機能分類（統治・識別・防御・検知・対応・復旧）を踏まえた自己評価が軸になります。

この制度が意味することは明快です。これまで「社内で納得していればよかった」セキュリティが、「取引先に、水準を説明できる形」 であることを求められ始めます。大企業のサプライチェーンに入る中小企業にとって、これは取引の条件として効いてきます。

技術者目線での翻訳は、「自社の対策の"実装状態"を、外部に見せられるエビデンスにできているか」です。ファイアウォールを入れた、MFAを有効化した、バックアップを取っている──それらが"やってある"だけでなく、"やってあることを示せる記録"になっているか。自己評価の各項目に対して、裏付けとなる設定や運用の証跡を紐づけられるか、が問われます。

三の矢｜改訂J-SOX ── N-2期からの"証跡"に、SaaSの棚卸しが要る

三つ目は、上場・監査の方向からです。ここは制度そのものより、"審査の現場"が変わった、という話です。

改訂J-SOX（2024年4月以後開始事業年度から適用）では、IT全般統制（ITGC）とクラウドなど外部委託先の管理が強化されました。その結果、IPO準備の現場では、上場の2年前（N-2期）からシステムが正しく運用され、証跡（ログ）が残っているかを確認する運用が定着しつつあります（対象はIPO準備・上場企業。監査の運用には個社差があります）。

エンジニアにとって、これは具体的な作業に落ちます。

使っているSaaS（Salesforce、SmartHR、マネーフォワード／freee、AWS など）で、「誰が、どの権限を持っているか」の棚卸し
その権限が誰の承認で付与されたかの記録
本番環境への変更が、承認を経て記録されているか（変更管理）
これらが、二期分さかのぼって追える状態になっているか

単に「上場直前に3点セット（業務記述書・フロー図・RCM）を整えればよい」という時代ではなくなり、"日々の運用が証跡として残っているか"が問われるようになった、ということです。

この「ITGCが、NIST CSF 2.0の各機能と具体的にどう対応するのか」は、別の記事で対応表として整理しています。制度→ITGC→NIST CSFの対応を追いたい方は、そちらもあわせてどうぞ。
（→ 関連記事：NIST CSF 2.0 × ITGC マッピング）

三本の矢は、同じ一点に集約する

規制から、取引先から、監査から。方向はバラバラです。でも、求められている"証跡"を並べてみると、あることに気づきます。

どれも、突き詰めると「アクセス・変更・承認が、ログとして追えるか」に集約するのです。

改正個情法が求める「統制を示せるか」＝アクセスと権限変更の記録
SCSが求める「取引先に示せるエビデンス」＝対策の実装状態の記録
J-SOXが求める「N-2期からの証跡」＝アクセス権限・変更・承認のログ

これは、ITGC（IT全般統制）が昔から扱ってきたものの本質そのものです。つまり、三つの制度は別々に見えて、「アクセス・変更・承認を、追える形で残す」という一つの基盤を、それぞれの言葉で要求している。

だとすれば、制度が来るたびに個別に対応するのは、消耗します。三つに振り回されるのではなく、証跡の基盤を一度、腰を据えて作るほうが効く。これが、私がこの三本の矢を"同じ一点"と呼ぶ理由です。

ただし──"一度作る"では終わらない

ここで、正直に一つ付け加えます。

証跡の基盤は、エンジニアなら「設計して、一度作る」ことはできます。権限の棚卸しも、ログ設計も、変更管理のフローも、手を動かせば構築できる。

でも、制度が本当に問うのは、その先です。「作った状態が、その後も維持され、改善され、推移として残っているか」。監査がN-2期から二期分の証跡を見るのも、SCSが継続的な水準を問うのも、"一度作った"ではなく"運用され続けている"ことを確かめるためです。

そして、ここが一番の難所です。一度の構築は気合いで乗り切れても、「今、自社がどの水準にいて、次に何をどの順で固めればいいか」を、継続的に数字で把握し続けるのは、片手間では続きません。作って終わりにならず、現在地を測り、次の一手を決め、前回からの改善を推移で残す──この"運用のループ"こそが、本質であり必要な投資です。

私がSecuROIを作っているのは、まさにこの"運用のループ"を軽くしたいからです。20問・約15分で、NIST CSF 2.0／ITGC観点の現在地を数字にし、次に取り組むべき改善策と、投資対効果（ROI）をレポート化する。制度が求める"証跡の基盤"を、作って終わりでなく、測り続けられるものにする、という発想です。

設計上こだわっているのは、スコアの算出に生成AIを使わないことです。点数は決定論的に（同じ入力なら必ず同じ結果になるように）算出し、AIは文章化の翻訳だけに使う。理由は単純で、監査や取引先に示す"証跡"が、実行するたびに揺れては困るからです。再現性と監査耐性を、設計の芯に置いています。

まとめ

2026〜2027年、改正個情法・SCS・改訂J-SOXという三つの制度が、方向は違えど同じ「証跡」を求めてくる。
エンジニア／情シスにとっての本質は、「アクセス・変更・承認が、追える形でログに残っているか」 に集約する。
制度ごとの個別対応は消耗する。証跡の基盤を一度作るほうが効く。
ただし、本当の難所は"作る"ことより、"現在地を測り続け、推移で残す"運用のループにある。

制度に振り回される側でいるか、証跡の基盤を持って迎える側になるか。その分岐は、手を動かすエンジニアの現場から始まると、私は思っています。

▼関連：NIST CSF 2.0 × ITGC マッピング（別記事）
▼「SecuROI SCS評価制度対応無償ガイド」で検索