取引先から届いた1通のメールに「SCS評価制度の★3の取得状況をご回答ください」と書かれていた。あるいは、年次の取引条件の見直しの場で、来期以降は★の提示をお願いすることになると口頭で伝えられた。その日から社内の空気が変わり、情報システム部門に「うちは取れるのか」「いつまでに必要なのか」という問い合わせが集まり始めます。

先に結論を書きます。2026年9月15日時点で、SCS評価制度の★3は申請することができません。評価機関の指定も、研修事業者の公表も、まだ先の予定として置かれている段階です。つまり「今月中に取得して回答する」という選択肢は、制度の側に存在していません。

それでも、取引先への回答期限は先に来ます。ここで必要になるのは、取得の可否ではなく現在地の説明です。この記事では、取引先からセキュリティ評価として★3を要求された企業が2026年9月時点で実際に取れる対応を、回答文の作り方、自己点検の手順、証跡の残し方、既存のセキュリティチェックシートとの接続、社内の巻き込み先まで順に整理します。制度そのものの全体像はSCS評価制度とはにまとめているため、この記事では手順に紙面を割きます。

まず2026年9月時点の事実を揃える

対応の出発点は、社内と取引先で「何が決まっていて、何が決まっていないか」の認識を揃えることです。ここがずれたまま動き出すと、取得できない時期に取得前提の計画を立てることになり、後から全部を組み直す羽目になります。

制度の現況は3つだけ押さえれば足りる

取引先とのやり取りで最低限必要な事実は、次の3点です。

ここでよく起きる取り違えが、★1から★5までの5段階があり、下から順に取っていくという理解です。★1・★2はIPAが運用しているSECURITY ACTION（自己宣言）であり、SCS評価制度の段階ではありません。また★3を取得していなくても★4を取得できることは、IPAが明記しています。「まず★1から」という前提で社内の稟議が進んでいたら、早い段階で止めておきたいところです。

参考：IPA サプライチェーン強化に向けたセキュリティ対策評価制度

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

依頼文を事実に照らして読み替える

取引先から届く依頼文は、制度の細部まで踏まえて書かれているとは限りません。担当者が社内の方針をそのまま転記しているケースも多く、文面と制度の現況にずれがあります。受け取ったらまず、次のように読み替えます。

依頼文の表現を訂正することが目的ではありません。取引先の担当者も同じ情報不足のなかで動いています。事実を揃えたうえで、こちらから確認事項を返すほうが話が早く進みます。

確認すべきなのは、求められているのが★3なのか★4なのか、回答の期限はいつか、回答の形式は指定されているか、そして制度の運用開始前の現時点で何を提出すればよいと考えているか。この4点です。

「まだ取得できません」だけで終わらせない

事実を揃えると、回答としては「制度上まだ取得できません」の一文で足りるように見えます。ところが、これだけを返すと話が止まりません。数週間後に同じ依頼が別の部署から届いたり、取引条件の協議の場で改めて持ち出されたりします。

制度は任意でも、説明を求められる場面が先に来る

前提として、SCS評価制度は任意の制度であり、取引に規制措置を設けるものではありません。この点は経済産業省と内閣官房国家サイバー統括室が2026年4月27日に注意喚起として発表しています。特定のセキュリティ対策製品の導入が必須とされているわけでもありません。

それでも依頼が来るのは、制度が2社間の取引のなかで使われることを想定しているからです。委託元が委託先に適切な段階を提示し、委託先が実施状況を示す。この流れ自体は制度の想定に含まれています。さらに、取得した企業は登録組織台帳で公開されます。発注側から見れば、取引先の状況を確認できる材料が増えることになります。

制度が取引を規制しないことと、取引先が自社の基準で委託先を選ぶことは別の話です。義務かどうかという論点そのものは社内で必ず問われるため、SCS評価制度は義務かどうかの整理を先に読んでおくと、説明がぶれにくくなります。

発注側にも回答の理由がある

依頼してきた取引先の側も、自社の判断で動いているとは限りません。そのさらに上流の発注元から同じ確認を受けていて、回答を集めている途中というケースがよくあります。連鎖の途中にいる企業ほど、期限が短く、確認の粒度も粗くなりがちです。

実際、サプライチェーンを狙った攻撃では、守りの薄い取引先が入口になる構造が繰り返し確認されてきました。攻撃の手口と国内の被害事例についてはサプライチェーン攻撃の対策と国内事例で整理しています。発注側が委託先の状況を把握したがる背景には、この構造があります。

こう考えると、返すべきなのは可否ではありません。「制度としてはこういう状況で、自社はここまで来ていて、ここから先はこの順序で進める」という3層の説明です。これなら現時点でも作れます。

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

回答は「取得済みか」ではなく「どこまで証跡が出せるか」で作る

ここが、この記事でいちばん伝えたい部分です。取得の有無で答えようとすると、制度が始まっていない以上、全社が横並びで「未取得」になります。それでは取引先にとって判断材料になりません。

代わりに使うのが、★3の評価基準81に対して自社がどこまで証跡を出せるかという軸です。取得済みかどうかではなく、到達度で答える。これがギャップ提示の考え方になります。

回答は3層に分けて書く

回答文の構造は、次の3層で固定してしまうと毎回作り直さずに済みます。

3層のうち、取引先がいちばん見たいのは2層目です。制度の現況は誰が答えても同じ内容になるため、差がつきません。自社の現在地を数字と範囲で書けるかどうかが、回答の質を決めます。

現在地は「領域ごとの到達度」で示す（ジョーシス独自の整理）

とはいえ、81の基準を1件ずつ開示する必要はありません。むしろ細かすぎる開示は、社内のセキュリティ状況を過剰に外へ出すことになります。適切なのは、領域ごとにまとめた到達度です。

この内容別の分け方は、制度が定めたものではありません。ジョーシスがIPAの公開データをもとに★3の81基準を内容の軸で独自に分類したところ、次の配分になりました。

この内容別の分類は、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものであり、制度が定めた区分ではありません。制度側が定めている大分類とは数え直す対象が違うため、2つを同じ表に混ぜて説明しないほうが安全です。

到達度を示す単位としてこの8領域を使うと、回答が具体的になります。「アイデンティティ・認証の27件については、ID台帳と多要素認証の適用状況を出力して提示できます。ログ・監視の3件は記録の保存期間の見直しを進めています」という書き方です。件数を添えるだけで、網羅性を意識して点検したことが伝わります。

もう一つ、この配分は準備の優先順位そのものでもあります。81件のうち27件、全体の3分の1がIDとアクセス権に関する基準です。取引先から具体的な質問が来るとすれば、最初に来る確率が高いのもこの領域になります。

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

回答文の骨格をそのまま使う

3層の構造を文章にすると、次のような形になります。取引先の様式が自由記述であれば、ほぼこのまま送れます。

「SCS評価制度につきまして、2026年9月15日時点では申請の受付が開始されておりません。評価機関および評価用ガイド等の公表が2026年度下期、制度の運用開始は2026年度末頃と想定されている段階です。そのため、現時点で★3の取得状況としてご回答できる内容はございません。

一方で、弊社では★3の評価基準81項目に対する自己点検を実施しております。現時点では、ID・アクセス権および端末の管理に関する項目について、管理台帳と設定状況の出力による記録の提示が可能です。規程類の整備と、年次で実施する点検の記録様式の統一については、2026年度内の完了を目標に進めております。

制度の運用が開始され次第、速やかに申請の手続きに入る方針です。進捗につきましては、四半期ごとにご報告させていただければと存じます。」

長さはこの程度で足ります。3つの段落がそれぞれ制度の現況、自社の現在地、到達計画に対応しています。差し替えるのは2段落目だけで、自己点検の結果に合わせて領域名と状況を書き換えます。

様式が指定されていて自由記述の欄がない場合は、この文面を別紙として添付します。チェック欄に「未取得」とだけ記入された回答と、別紙が付いた回答では、受け取る側の印象がまるで変わります。

書かないほうがよいこと

回答文で避けたい表現もあります。

取得予定日を断定で書くこと。運用開始が想定にとどまる以上、確定日として書けば後から訂正が必要になります。想定である旨を必ず添えます。

未整備の項目を伏せること。ギャップを示すのが目的なので、整っていない領域を書かないと、後で状況が変わったときに説明がつかなくなります。整っていないこと自体は不利になりません。整っていないことに気づいていない状態のほうが、取引先から見て不安要素になります。

そして、特定の製品を導入したから対応済みだと書くこと。制度は特定の製品の導入を必須としていません。製品名ではなく、どの記録を出せるかで書きます。

自己点検の進め方｜81の評価基準を3つに分けて現在地を出す（ジョーシス独自の整理）

回答の2層目を埋めるには、自己点検が要ります。評価基準を上から順に見ていくと、81件を前にして手が止まります。効率がよいのは、証跡をどう集めるかという軸で先に3つに分けてしまう方法です。

この3つの分け方は、制度が定めたものではありません。ジョーシスがIPAの公開データの各基準に、想定される証跡の取得手段を独自に割り当てて集計したところ、次の配分になりました。

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

分ける意味は、点検の担当者と所要期間がまるで違うところにあります。3つを同じ会議で同時に進めようとすると、進みの速い領域が遅い領域に引きずられます。

分類ごとに点検の入口を変える

システムで取る40件は、点検そのものは短時間で終わります。台帳が出せるかどうかが結論になるからです。逆に言えば、台帳が表計算ソフトで手管理されていて最終更新が半年前という状態だと、40件のほとんどが証跡として成立しません。台帳の項目設計と更新の仕組みについてはIT資産台帳の作り方と運用ルールで具体的に扱っています。

文書で示す25件でつまずきやすいのは、書類の数ではなく粒度です。たとえばパスワードのルールは評価基準では6つに分解されています。初期パスワードの変更、推測されやすい単語の禁止、多要素認証または一定回数の失敗によるロック、機器やサービス間での使い回しの禁止といった内容です。「パスワードポリシーは策定済みです」と答えるだけでは、6つのどれが記述されていてどれが抜けているかを示せません。

人手で回す16件は、実施していたかどうかより、実施を示す記録が残っているかが問われます。年1回の点検は、記録を取り始めた時点からしか積み上がりません。ここだけは点検の結果を待たずに着手する価値があります。

点検は評価基準の側から当てにいく

進め方の順序にもコツがあります。自社の既存文書や既存の運用を読み込んでから、足りないところを探す。この順序だと網羅性が確認できず、結局やり直しになります。

評価基準の側から「この条文に対応する記述や記録はどこにあるか」を当てていくほうが、時間も短く済みます。対応するものが見つからなければ、その基準は未整備として記録する。これだけで到達度の一覧ができあがります。

アクセス権の棚卸しのように、ISMSやJ-SOXの対応ですでに年次で実施している作業であれば、証跡はそのまま使える可能性があります。棚卸しの実務はアクセス権レビューの進め方と自動化で扱っています。

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

証跡づくりは申請前から始まる｜記録の型を先に決める

自己点検で現在地が出たら、次は証跡です。ここで多いのが、申請が始まってから記録を整えればよいという判断ですが、これは通りません。

年1回の記録は、始めた時点からしか積み上がらない

★3の有効期間は1年です。評価基準には、頻度そのものが書かれているものがあります。

年1回のものは、当然ながら年1回しか記録が作れません。運用開始の直前に着手しても、そのとき出せる記録は1回分だけです。月1回のものも同じで、半年分をさかのぼって作ることはできません。

だからこそ、申請できない時期にやる価値がいちばん高いのが記録の型づくりになります。

型は4項目でよい

記録の様式は複雑にしないほうが続きます。埋めるのは、誰が、いつ、誰に対して、何を実施したか。この4項目です。

3つ目の「誰に対して」は特に注意が必要です。周知の対象には役員も、派遣社員も、受入出向者も含まれることが条文に明記されています。「全社員へ周知済み」という記録だけでは、範囲を示せません。

すでに実施している作業でも、この4項目が揃っていないために証跡として使えない、という状態が最も惜しい結果になります。実施していないわけではないので、追加の負荷はほとんどありません。様式を決めて次回から使い始めるだけです。

どの基準にどのような記録が求められるかは、★3の自己評価で求められる証跡で領域別に例示しています。

自己点検と証跡の蓄積をどこまでシステム側に寄せられるか整理したい場合は、IT資産とアカウントの一元管理の考え方をまとめた資料が参考になります。

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

既存のセキュリティチェックシート運用とどう接続するか

ここまでの手順を読んで、既視感を覚えた方もいるかもしれません。取引先から送られてくるセキュリティチェックシートへの回答は、多くの企業がすでに何年も続けている業務だからです。

蓄積してきた回答は資産になる

年に数回、取引先ごとに異なる様式のチェックシートが届き、その都度、情報システム部門が設問を読み解いて回答を作る。設問数が100を超えるものも珍しくありません。自動車業界のように業界団体のガイドラインに沿った様式が定着している領域もあります。

この蓄積は、SCSへの対応でそのまま資産になります。過去の回答には、自社のどの規程に何が書かれているか、どのシステムから何が出力できるかという情報が、すでに整理された形で入っているからです。

ただし、そのまま流用できる部分とできない部分があります。

大きく違うのは、証跡の扱いと更新の頻度です。従来のチェックシートは回答すれば完了するものが多いのに対し、★3は記録を提示し、それを毎年繰り返すことが前提になります。二択で答えていた設問を、記録で示す設問に読み替える作業が必要になります。

回答台帳を1本に集約する

現実的な接続のしかたは、チェックシートへの回答を取引先ごとに作り続けるのをやめて、社内に1本の回答台帳を持つ形に変えることです。

台帳の行は、★3の評価基準81に揃えます。各行に、対応する自社の規程の条項、証跡を出力できるシステム、直近の実施日、担当部門を書いておく。取引先から新しいチェックシートが届いたら、この台帳から該当する設問に当たる行を引いて回答を組み立てます。

列の構成は、最初から作り込まないほうが続きます。評価基準の番号と要求内容、対応する規程の条項、証跡の出どころ、直近の実施日、担当部門、そして現時点の状況。この6列で始めれば十分です。取引先ごとの設問との対応づけは、実際に依頼が来たときに列を1本足して記録していくほうが、使われる形に育ちます。

こうしておくと、SCSの自己点検と日々のチェックシート対応が同じ台帳の上で回ります。チェックシートに回答するたびに台帳の実施日が更新され、証跡の鮮度も保たれます。取引先ごとの様式の違いに毎回振り回される状態からも抜けられます。

副次的な効果もあります。台帳を持つと、回答の担当者が特定の一人に固定されなくなります。従来のチェックシート対応は、社内のどこに何があるかを把握している担当者の記憶に依存しがちでした。台帳に移しておけば、その人が異動しても回答の質が落ちません。★3が毎年の更新を前提にしている以上、属人化を先に外しておく価値は大きくなります。

自動車業界のように、業界団体のガイドラインに基づく自主点検が先に定着している場合は、そちらとの対応順序も整理しておく必要があります。どちらを先に進めるかで工数が変わるため、自工会ガイドラインとSCS評価制度の対応順序を併せて確認しておくと判断しやすくなります。

社内の誰を巻き込むか｜情報システム部門だけでは終わらない

取引先からの依頼が情報システム部門に届くため、そこで完結させようとする動きになりがちです。ところが評価基準の中身を見ると、情報システム部門の権限だけでは記録を作れない領域が確実に残ります。

人手で回す16件は、ほぼ他部門の協力が要る（ジョーシス独自の整理）

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

先ほどの3分類のうち、人手で回す16件の内訳は次のようになっています。

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

16件のうち9件が周知と点検です。周知の対象には役員や派遣社員、受入出向者も含まれるため、名簿を持っているのは人事になります。守秘義務の説明は法務の領域です。情報システム部門が単独で完了させられる項目は、実はそう多くありません。

部門ごとに、最初に依頼することを決めておく

巻き込みは、全体会議を開くところから始めると時間がかかります。最初の依頼内容を部門ごとに具体化しておくほうが早く動きます。

このうち後回しになりがちなのが調達・購買と各事業部です。取引先管理の基準は年1回の取引先の★確認を含みますし、部門が個別に契約しているSaaSは情報システム部門の台帳から漏れていることが多い。どちらも、着手が遅れると点検のやり直しが発生します。

もう一つ。退職IDの削除は常時対応が求められる領域です。人事からの退職連絡が届いてから手作業でアカウントを止めていく運用だと、数日から数週間のずれが生まれます。そのずれ自体が記録に残る点が、従来の内部統制対応とは違うところです。手順の設計は退職者アカウントの削除手順で具体的に扱っています。

90日でやることの順序

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

最後に、依頼を受けてから最初の90日で進める順序をまとめます。運用開始が2026年度末頃の想定であることを踏まえた並びです。

順序で重要なのは、一次回答を45日以内に出すことです。自己点検が完全に終わってから回答しようとすると、2か月も3か月も無回答の期間が続きます。取引先にとっては、回答がないこと自体が不安材料になります。到達度が途中でも、点検中であることと現時点で分かっている範囲を書いて出すほうが、関係の維持には効きます。

45日目までに整っていない項目があっても問題ありません。むしろ、そこが到達計画の中身になります。

回答期限が2週間しかない場合

取引先の都合で、回答期限が2週間程度しか残っていないこともあります。その場合は自己点検を全領域でやりきることをあきらめて、範囲を絞ります。

優先するのは、アイデンティティ・認証の27件です。評価基準の3分の1を占めるうえ、ID台帳と多要素認証の適用状況は比較的短時間で出力できます。ここだけでも到達度を出して一次回答に載せれば、点検の網羅性は残りの領域として到達計画に書けます。

やってはいけないのは、点検が終わらないことを理由に期限を過ぎることです。回答がないと、取引先の社内では「対応していない企業」として扱われます。制度上の義務がないことと、取引先の管理台帳に記録が残ることは別の話になります。

よくある質問

取引先に「いつ取得できますか」と聞かれたら何と答えればよいですか

確定日は答えられません。2026年9月15日時点で申請は始まっておらず、運用開始は2026年度末頃が想定されている段階だからです。回答としては、想定時期であることを明示したうえで、運用開始後すみやかに申請する方針と、それまでに整える項目を書き添える形が現実的になります。

取引先から回答期限を切られています。未取得であることが不利になりませんか

未取得であること自体は不利になりません。2026年9月15日時点では誰も取得できず、制度としても任意で、取引に規制措置を設けるものではないためです。不利に働くのは、期限までに何も返さないことのほうです。制度の現況、自社の到達度、到達までの計画の3層で書けば、点検の途中でも回答として成立します。

ISMSを取得していれば、そのまま回答に使えますか

一部は使えますが、そのままでは足りません。ISMSとSCS評価制度の関係について公式な整理は2026年9月15日時点で公表されておらず、免除規定も確認できていません。ISMSで作った規程や記録が証跡として使える場面はあるため、評価基準の条文ごとに対応づける作業が必要になります。

★3と★4のどちらを前提に準備すればよいですか

取引先から提示された段階に合わせます。★3は要求事項26・評価基準81で有効期間1年、★4は43・153で3年更新となり、実地審査と技術検証が加わります。★3を取得していなくても★4を取得できるとIPAが明記しているため、★4を求められている場合に★3から段階を踏む必要はありません。

まとめ

取引先からSCS評価制度の★3を求められたときに、2026年9月15日時点で押さえておきたい点は3つです。

1つ目は、まだ申請できないこと。評価機関・評価用ガイド等の公表は2026年度下期、運用開始は2026年度末頃の想定です。取得を前提にした社内計画を組むと、時期の訂正が繰り返し発生します。

2つ目は、それでも回答は作れること。取得済みかどうかではなく、評価基準81に対してどこまで証跡が出せるかで答える。制度の現況、自社の現在地、到達計画の3層で書けば、現時点の情報だけで成立します。

3つ目は、記録の型づくりが最優先だということ。年1回の実施記録は、始めた時点からしか積み上がりません。誰が、いつ、誰に対して、何を実施したか。この4項目が埋まる様式を決めて運用を始めるところから、準備は動き出します。

制度が始まるのを待つ必要はありません。台帳を整え、記録の型を決め、回答台帳に集約する。この3つは今日から着手できます。

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

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

関連記事：ISMS対応で押さえる統制と実装ステップ

関連記事：情報セキュリティポリシーの作り方｜策定ステップと運用設計