SCS評価制度★3とは？要求事項と取得に向けた対策を解説

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★3は、一般的なサイバー脅威に対処するために、サプライチェーンを構成する企業が最低限実装すべきセキュリティ対策の水準です。取得では、企業自身が要求事項への適合状況を評価し、その内容をSCSセキュリティ専門家が確認したうえで、経営層による自己適合宣誓を含む申請を行う仕組みが予定されています。 ★3への対応で重要なのは、チェックリストを埋めることではありません。情報資産やネットワークを把握し、責任体制、アカウント管理、脆弱性対策、マルウェア対策、取引先との役割分担、インシデント対応などを「実際に運用できる状態」にすることです。制度開始は2027年3月頃が予定されているため、従業員100～1,000名規模の企業では、現状把握と不足対策の洗い出しを先行して進めておくことが現実的です。 出典：IPA「SCS評価制度の詳細情報」  https://www.ipa.go.jp/security/scs/details.html 出典：経済産業省「SCS評価制度」  https://www.meti.go.jp/policy/netsecurity/scs.html この記事で分かること SCS評価制度★3の位置付けと、★4との違い ★3で求められる代表的な要求事項と実務上の対策 取得に向けて経営層・情報システム部門が準備すべきこと 申請までの進め方、期間や費用を左右する要因 脆弱性診断やペネトレーションテストをどのように活用すべきか SCS評価制度対応を支援する会社を選ぶ際の確認ポイント SCS評価制度★3とは SCS評価制度は、企業のセキュリティ対策状況を共通の基準で可視化し、委託元と委託先の双方が取引時に確認しやすくするための制度です。経済産業省と内閣官房国家サイバー統括室の監督のもと、IPAが制度を運営します。制度では★3、★4を設け、★5については今後具体化される予定です。 ★3は「一般的なサイバー脅威に対処しうる水準」とされ、広く認知された脆弱性の悪用、認証情報の窃取、マルウェア感染、不適切なアクセス権限など、企業が日常的に直面し得る脅威への基礎的な防御を重視します。経済産業省の資料では、★3は全てのサプライチェーン企業が最低限実装すべき対策として位置付けられています。 一方、★4では、初期侵入の防御に加えて、侵入後の被害拡大防止、監視・検知、インシデント対応、取引先管理などをより包括的に求めます。★3は専門家確認付きの自己評価、★4は第三者評価と技術検証という点でも違いがあります。なお、★4の取得前に★3取得が必須という仕組みではありません。 出典：IPA「SCS評価制度の詳細情報」  https://www.ipa.go.jp/security/scs/details.html ★3は「製品を買えば取得できる制度」ではない ★3対策というと、EDR、資産管理ツール、多要素認証製品などの導入を先に検討しがちです。しかし、経済産業省は、SCS評価制度の評価基準を達成するために特定のセキュリティ製品の導入を必須としていません。重要なのは、自社の規模やシステム構成に応じて要求事項を満たせているかです。 例えば、アカウント管理であれば「製品を導入していること」ではなく、入社・異動・退職時に権限を付与・変更・削除するルールがあり、不要な権限が残らないよう管理されているかが重要です。脆弱性対策も同様で、単に診断を実施した実績ではなく、対象資産を把握し、更新情報を確認し、必要なパッチを適用する運用まで含めて考える必要があります。 出典：経済産業省「SCS評価制度」  https://www.meti.go.jp/policy/netsecurity/scs.html なぜ今、SCS評価制度★3への対応が必要なのか SCS評価制度そのものは任意の制度です。ただし、取引先が調達条件や委託先管理の基準として★3を求める可能性があります。制度上の義務と、商取引上求められる条件は別に考える必要があります。経済産業省も、どの段階を契約上の要件とするかは取引当事者間で決めるものと説明しています。 従業員100～1,000名規模の企業では、大手企業のシステム開発、業務委託、製造、物流、BPO、クラウド運用などを担っているケースも多く、自社のセキュリティ事故が取引先の事業に波及する可能性があります。自社の情報漏えいだけでなく、VPNやリモートアクセス環境を経由した侵入、委託元から預かった認証情報の悪用、業務停止による供給遅延などがサプライチェーンリスクになります。 そのため、★3取得の検討は「認証マークを得るための作業」ではなく、取引継続に必要な最低限のセキュリティ水準を整理するプロジェクトとして扱う方が実務的です。営業部門や調達部門が取引先から受け取っているセキュリティチェックシートを集約すると、SCS評価制度への対応が既存の顧客対応負荷を減らすきっかけになる場合もあります。 出典：IPA「SCS評価制度」  https://www.ipa.go.jp/security/scs/index.html SCS評価制度★3で求められる代表的な要求事項 ★3・★4の正式な要求事項・評価基準はIPAから公開されています。★3を取得するには、定められた要求事項・評価基準を満たす必要があります。ここでは経営者や担当者が全体像をつかめるよう、★3で特に重要となる対策領域を実務の観点から整理します。 出典：IPA「要求事項・評価基準」  https://www.ipa.go.jp/security/scs/requirements-criteria.html 1．セキュリティ責任者と方針を明確にする 最初に必要なのは、誰がセキュリティに責任を持つのかを明確にすることです。情報システム部門が実務を担当していても、重大なインシデント対応や予算投入は経営判断を伴います。担当者名、責任範囲、報告経路、経営層へのエスカレーション方法を整理し、情報セキュリティ方針や関連規程に反映します。 実務では、規程が存在していても、退職者IDの削除期限、重要な脆弱性への対応期限、事故発生時の報告先などが曖昧なケースがあります。★3準備では、文書の有無だけでなく、そのルールが日常業務に組み込まれているかまで確認する必要があります。 2．情報資産とネットワークを一覧化する 守る対象が分からなければ、対策の漏れを把握できません。サーバー、PC、ネットワーク機器、クラウドサービス、SaaS、外部公開システム、リモートアクセス環境などを棚卸しし、管理責任者と用途を明確にします。また、取引先と接続しているネットワークや外部情報システムも把握します。 特に注意したいのが、部署単位で契約したSaaS、保守終了したサーバー、管理者不明の公開IP、過去のプロジェクトで残ったVPNアカウントです。資産管理台帳と実際の環境が一致していない場合、脆弱性対応やアカウント削除の対象から漏れる可能性があります。 3．ID・パスワード・アクセス権限を管理する 不正アクセス対策の基本は、利用者を正しく識別し、必要な人に必要な権限だけを付与することです。アカウント発行、権限変更、退職時の削除、管理者権限の付与、共有IDの利用などについてルールを定めます。パスワードの設定・管理や、システムの重要度に応じた認証強化も確認対象になります。 例えば、退職者のクラウドアカウントが数か月残っていた、管理者権限が異動後も維持されていた、といった状態は実務上のリスクです。人事情報とID管理を連動させ、定期的な棚卸しを行う仕組みにすると、制度対応後も運用しやすくなります。 4．ソフトウェア更新と脆弱性管理を行う OS、ミドルウェア、VPN機器、ファイアウォール、Webサーバー、業務アプリケーションなどについて、脆弱性情報を確認し、必要なアップデートを適切なタイミングで適用する体制が必要です。不要なソフトウェアを削除することも基礎的な対策に含まれます。 この領域では、Webアプリケーション診断やプラットフォーム診断が有効です。Webアプリケーション診断では、SQLインジェクションや認証・認可の不備などアプリケーション固有の問題を確認します。プラットフォーム診断では、公開サーバーやネットワーク機器の脆弱性、不要なポート、古いソフトウェアなどを確認します。ただし、診断を一度実施するだけでは不十分であり、発見事項の改修、再診断、継続的なパッチ運用につなげることが重要です。 5．マルウェア感染とネットワーク侵入に備える 端末やサーバーのマルウェア対策、内外ネットワーク境界の分離・保護など、侵入を防ぐ基礎的な対策も重要です。メール添付ファイルや偽のログインページから認証情報を盗まれた場合でも、被害が広がりにくい構成にしておく必要があります。 ペネトレーションテストは、実際の攻撃者に近い視点で、複数の弱点を組み合わせた侵入可能性を検証する手法です。★3取得にペネトレーションテストが一律に必須という意味ではありませんが、重要システムや外部公開環境について「設定上の弱点が攻撃経路にならないか」を確認したい場合には有効です。 6．取引先との役割と機密情報の扱いを明確にする SCS評価制度では、自社だけでなくサプライチェーン上の関係も重視されます。取引先や委託先とどのシステムを接続しているか、どの情報を共有しているか、インシデント発生時に誰が何をするかを整理します。秘密保持契約や業務委託契約に事故時の報告義務が書かれていても、現場担当者が連絡経路を把握していなければ実効性は十分ではありません。 7．インシデント対応手順を整備する 攻撃を100％防ぐことは現実的ではありません。そのため、感染端末の隔離、管理者への報告、取引先への連絡、ログ保全、原因調査、復旧判断などを事前に決めておくことが重要です。最低限の手順書を作るだけでなく、誰が意思決定者なのか、夜間休日の連絡方法、外部専門会社への連絡方法まで整理すると実務で機能しやすくなります。 SCS評価制度★3の取得に向けた具体的な進め方 ステップ1．適用範囲とプロジェクト責任者を決める 最初に、どの組織・拠点・IT基盤を対象として準備するかを整理します。SCS評価制度は主にインターネットに接続する自社IT基盤を対象としており、一般的にIT基盤に該当しない製造設備などのOTシステムや、委託元へ提供する製品そのものは直接の対象とはしない考え方が示されています。ただし、自社環境とOTが接続している場合などは、境界を機械的に切り分けず、実際の侵入経路を踏まえて確認する必要があります。 出典：経済産業省「SCS評価制度」  https://www.meti.go.jp/policy/netsecurity/scs.html ステップ2．要求事項に対する現状評価を行う 次に、IPAが公開している★3要求事項・評価基準に沿って、現状を「対応済み」「一部対応」「未対応」「確認が必要」などに分類します。この段階では、担当者へのヒアリングだけで判断せず、規程、設定画面、資産台帳、アカウント一覧、運用記録などの証拠を確認します。 準備しておきたい資料には、情報セキュリティ規程、組織図、情報資産台帳、ネットワーク構成図、クラウドサービス一覧、アカウント管理手順、脆弱性対応手順、バックアップ運用資料、インシデント対応手順、委託先管理資料などがあります。資料が存在しない場合は、ゼロから整備するのではなく、現場で既に行っている運用を確認し、必要な形に文書化する方が定着しやすくなります。 ステップ3．不足項目をリスクと優先度で整理する 未対応項目を一度に解消しようとすると、予算と人的負荷が大きくなります。外部公開システム、管理者権限、既知の重大脆弱性、退職者アカウント、バックアップ不備など、事故に直結しやすい項目から優先します。対応の優先度は、技術的な深刻度だけでなく、停止した場合の売上影響、取引先への波及、個人情報・機密情報の有無も考慮して決めます。 ステップ4．必要な対策を実装し、証跡を残す 規程を改定しただけでは、実装済みとは言えません。パッチ適用記録、アカウント棚卸し結果、教育実施記録、ログ確認記録、バックアップ復元テスト結果など、運用の証跡を残します。証跡は専門家確認を受ける際にも説明材料になります。 ステップ5．SCSセキュリティ専門家の確認を受ける ★3は専門家確認付き自己評価です。取得希望組織が自己評価を記入し、SCSセキュリティ専門家が内容を確認し、必要に応じて修正や助言を行います。最終的に専門家が提出内容を了承した場合に署名し、企業は経営層による自己適合宣誓を含めて事務局に申請します。IPAは、SCSセキュリティ専門家の公表を2027年1月頃から予定しています。 出典：IPA「SCSセキュリティ専門家・評価機関」  https://www.ipa.go.jp/security/scs/security-experts-organization/index.html 実施期間と費用を左右する要因 ★3対応に必要な期間は、会社規模だけでは決まりません。既存の規程や資産管理が整っている企業では短期間でギャップを整理できますが、拠点ごとにネットワーク管理が分かれている、クラウド契約が分散している、アカウント管理が手作業であるといった企業では、現状把握だけでも相応の時間が必要です。 実務上は、①対象範囲の決定、②現状評価、③不足対策の実装、④運用実績・証跡の整備、⑤専門家確認、⑥申請という工程に分けてスケジュールを引くと管理しやすくなります。制度開始直前に着手すると、機器更新や社内規程改定、予算承認が間に合わない可能性があるため、次年度予算の策定時期から逆算することが重要です。 IPAが2026年9月18日に公表した料金設定では、★3登録希望組織の登録料は、2028年3月31日まで1年間10,000円、2028年4月1日以降は1年間20,000円とされています。ここで注意したいのは、この金額は制度上の登録料であり、SCSセキュリティ専門家による確認、コンサルティング、システム改修、脆弱性診断などの費用とは別だという点です。 総費用を左右する主な要因は、対象拠点・システム数、既存規程の整備状況、資産棚卸しの難易度、アクセス管理やネットワーク改修の必要性、診断対象の数、専門家支援の範囲です。見積依頼では「★3取得支援一式」だけで比較せず、現状評価、改善計画、文書作成、技術対策、専門家確認、申請支援のどこまで含まれるかを明確にしましょう。 出典：IPA「SCS評価制度 料金設定のお知らせ」  https://www.ipa.go.jp/security/scs/rcu1hd00000075om-att/pricelist.pdf 社内稟議で説明すべきポイント 経営層への説明では、「制度対応が必要だから予算が欲しい」という説明だけでは判断しにくくなります。SCS評価制度★3への対応によって、どの経営リスクを下げるのかを具体化することが重要です。 例えば、主要顧客からのセキュリティ要求への対応、取引継続リスクの低減、ランサムウェア等による事業停止リスクの低減、委託元の情報漏えいリスクの低減、セキュリティチェックシート回答の効率化などを整理します。そのうえで、現状の不足項目、対応しない場合の影響、必要予算、完了時期、取得後の運用負荷を示すと、投資判断を行いやすくなります。 また、★3は任意制度であるため、「法律上必須」と説明するのは適切ではありません。主要顧客からの要求状況や、自社がサプライチェーン上で担う役割を踏まえて、必要性を説明することが重要です。 SCS評価制度★3の支援会社を選ぶポイント 制度の説明だけでなく、実装まで支援できるか 要求事項とのギャップを指摘するだけでは、担当者側に「何をどう直すか」という作業が残ります。規程整備、ネットワーク設計、アクセス制御、脆弱性対応、教育、インシデント対応まで、必要に応じて改善支援ができる会社かを確認しましょう。 技術評価とマネジメントの両方を扱えるか SCS評価制度は、文書だけでも、技術対策だけでも完結しません。例えば「脆弱性管理を行う」という規程があっても、外部公開サーバーに重大な脆弱性が残っていれば実効性に問題があります。反対に、高価なセキュリティ製品を導入していても、責任者や運用手順が曖昧であれば継続性に課題が残ります。 RFPや見積依頼では、制度対応の経験、技術診断の対応範囲、改善後の再確認、専門家確認との役割分担、成果物の内容、個人情報・機密情報の取り扱い、プロジェクト管理方法を確認すると比較しやすくなります。 成果物が取得後の運用に使えるか 成果物は、単なるチェック表だけでなく、適用範囲、要求事項ごとの評価、確認した証跡、不足事項、リスク、改善案、優先度、担当部門、期限を追える形が望まれます。取得後に同じ状態を維持するには、年次のアカウント棚卸し、脆弱性診断、教育、インシデント訓練などを継続計画に落とし込む必要があります。 SCS評価制度★3対応でよくある失敗と注意点 規程作成だけを先行させる 規程が整っていても、現場の運用と一致しなければ実効性はありません。文書を作る前に実態を把握し、既存運用を生かして必要なルールを追加する方が現場に定着しやすくなります。 情報システム部門だけで完結させる アカウント管理には人事、取引先管理には調達・営業、事故時の対外対応には法務・広報、予算には経営層が関係します。情報システム部門だけで進めると、要求事項は理解できても実装が止まることがあります。初期段階で関係部門を明確にしましょう。 脆弱性診断を「実施したこと」で終わらせる 診断は現状把握の手段です。重要なのは、発見事項を業務影響と悪用可能性で優先順位付けし、改修し、必要に応じて再診断することです。診断報告書を保管するだけでは、セキュリティ水準は改善しません。 制度開始直前まで準備を待つ ★3・★4の運用開始は2027年3月頃が予定されています。システム改修、予算確保、規程改定、証跡の蓄積には時間がかかります。正式申請の直前ではなく、現状評価だけでも早めに行うことが有効です。 出典：IPA「よくある質問」  https://www.ipa.go.jp/security/scs/faq.html Librus株式会社が提供できるSCS評価制度★3支援 Librus株式会社では、サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）への対応について、要求事項の読み合わせだけでなく、企業ごとの環境や取引関係を踏まえた実務設計を支援します。 具体的には、現状のセキュリティ対策と★3要求事項のギャップ整理、情報資産・ネットワーク・クラウド環境の棚卸し、規程・運用手順の整備、改善計画の策定、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、インシデント対応体制の整備、教育・訓練などを組み合わせて支援できます。 SCS評価制度だけを独立したプロジェクトとして考えるのではなく、既存のISMS、取引先監査、IPO準備、M&A、SOC／CSIRT、脆弱性管理などとの重複を整理することで、必要以上に運用を増やさないことも重要です。Librus株式会社は、技術と経営の両面から課題を整理し、経営層、情報システム部門、現場部門の間をつなぎながら、改善・運用まで一気通貫で支援します。 よくある質問 Q1．SCS評価制度★3は取得が義務ですか？ いいえ。制度自体は任意です。ただし、発注企業が取引条件として一定の★取得を求める可能性があります。自社の主要顧客や業界動向を確認し、商取引上の必要性を判断することが重要です。 Q2．SCS評価制度★3はいつから申請できますか？ IPAは★3・★4について2027年3月頃の運用開始を予定しています。制度運営基盤の整備状況等により変更される可能性があるため、最新情報はIPA公式サイトで確認してください。 Q3．★3を取得する前にISMSを取得する必要がありますか？ 必須ではありません。SCS評価制度★3・★4は代表的な脅威を踏まえて管理策を定めるベースラインアプローチであり、ISMSとは目的や評価の考え方が異なります。既にISMSを運用している企業は、既存の規程や証跡を活用できる可能性があります。 Q4．EDRや多要素認証製品を導入すれば★3を取得できますか？ 特定製品の導入だけで取得できる制度ではありません。要求事項を満たす方法は企業の規模やシステム構成によって異なります。製品導入と同時に、アカウント管理、資産管理、パッチ運用、インシデント対応などの運用も整備する必要があります。 Q5．脆弱性診断やペネトレーションテストは必須ですか？ ★3において、すべての企業に対して特定の診断サービスやペネトレーションテストを一律に必須とする考え方ではありません。ただし、外部公開システムや重要なIT基盤の技術的な弱点を把握するために、Webアプリケーション診断やプラットフォーム診断などが有効な場合があります。 Q6．★3の登録料はいくらですか？ IPA公表の料金設定では、2028年3月31日まで★3登録料は1年間10,000円、2028年4月1日以降は1年間20,000円です。専門家確認、コンサルティング、診断、システム改修などの費用は別途発生します。 Q7．まだ対象範囲が決まっていなくても準備を始められますか？ 始められます。まず、自社の主要なIT基盤、外部公開システム、クラウド利用、取引先との接続状況を整理し、要求事項とのギャップを把握することが有効です。対象範囲は、その結果を見ながら現実的に設計できます。 まとめ｜SCS評価制度★3は「取得準備」と「実際の改善」を同時に進める SCS評価制度★3は、サプライチェーンを構成する企業が、一般的なサイバー脅威に対処するための基礎的なセキュリティ対策を実装していることを示す仕組みです。専門家確認付き自己評価によって取得する制度であり、単なる書類作成ではなく、資産管理、アクセス管理、脆弱性対策、マルウェア対策、取引先管理、インシデント対応などを実際に運用できる状態にすることが重要です。 特に従業員100～1,000名規模の企業では、部門や拠点ごとにIT管理が分散していることも多く、最初の資産棚卸しとギャップ分析がプロジェクトの成否を左右します。2027年3月頃の制度開始を待ってから対策を始めるのではなく、現時点で公開されている要求事項を使って現状評価を行い、予算や改修期間を要する項目から対応を進めると、無理のない準備につながります。 SCS評価制度★3の対象範囲や進め方が決まっていない段階でもご相談いただけます Librus株式会社では、「自社が★3を目指すべきか判断したい」「要求事項と現状の差を把握したい」「どのシステムまで対象にすべきか整理したい」「脆弱性診断やペネトレーションテストをどこまで行うべきか検討したい」といった初期段階からご相談いただけます。 現状の体制・IT環境・取引先からの要求を整理したうえで、優先度の高い課題と、取得までに必要な対応を具体化します。対象範囲や実施方法が固まっていない場合でも、最初に論点を整理することで、不要なツール導入や過剰な対策を避けながら、社内稟議や予算策定につなげやすくなります。SCS評価制度への対応を、取得のためだけの作業ではなく、取引継続と事業継続に資する改善につなげたい企業はご相談ください。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 105-0004東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム https://librus.co.jp/contact

VIEW MORE

SCS評価制度に必要なインシデント対応体制とは？初動対応から報告まで

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）への対応では、攻撃を防ぐ対策だけでなく、異常を検知した後に被害を抑え、必要な相手へ報告し、事業を復旧できる体制が重要になる。結論から言えば、必要なのは「連絡網を作ること」ではない。判断権限、初動手順、証拠保全、社内外への報告、復旧判断、再発防止までを一つの業務プロセスとして整え、訓練で実効性を確認することである。 本記事では、従業員100～1,000名程度の企業を想定し、経営者と実務担当者が準備すべき内容を、初動対応から最終報告まで具体的に解説する。なお、SCS評価制度は制度設計や運用準備が進行中であり、申請時には経済産業省が公開する最新版の要求事項・評価基準を確認する必要がある。 この記事で分かること SCS評価制度を見据えたインシデント対応体制の全体像 発見直後から封じ込め、報告、復旧、再発防止までの実務手順 経営層、情報システム部門、現場部門、外部専門家の役割分担 報告先・報告期限を判断するための基準と、訓練・証跡の残し方 見積依頼や支援会社選定で確認すべきポイント SCS評価制度とインシデント対応体制の関係 SCS評価制度は、企業のサプライチェーン上の立ち位置や影響度に応じて、必要なセキュリティ対策を段階的に示し、取引先が対策状況を確認しやすくするための制度である。経済産業省の公表資料では、☆3・☆4・☆5の水準が想定され、☆3と☆4は2026年度末頃の制度開始が予定されている。制度への対応は、認証取得そのものを目的にするのではなく、取引先から求められる説明責任と、事故発生時の事業継続力を高める取り組みとして捉えることが大切だ。 出典：経済産業省：サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度） インシデント対応に関して重要なのは、方針や連絡先の存在だけではない。異常を検知できること、対応責任者が判断できること、影響範囲を把握できること、関係者へ適時に報告できること、そして訓練や点検を継続することが問われる。IPAの2026年版資料も、対応を「検知・初動対応」「報告・公表」「復旧・再発防止」の三段階で整理している。 出典：IPA：中小企業のためのセキュリティインシデント対応の手引き（2026年6月） なぜ今、インシデント対応体制が必要なのか サプライチェーンでは自社の事故が取引先の事業停止につながる 製造、物流、IT、人材、専門サービスなどでは、取引先から預かったデータ、接続用アカウント、共有システムを日常的に扱う。攻撃者が自社を踏み台にして取引先へ侵入すれば、自社の復旧だけで問題は終わらない。受発注停止、納期遅延、接続遮断、監査対応、契約見直しへ波及する可能性がある。このため、対応体制には「取引先への通知条件」と「接続を止める判断権限」をあらかじめ組み込む必要がある。 100～1,000名規模では、責任の空白が生まれやすい この規模の企業では、専任CSIRTがない一方、拠点、クラウド、委託先、子会社が増えていることが多い。情報システム部門が技術対応、総務が個人情報、広報が公表、営業が顧客説明を担当していても、全体を指揮する人が決まっていないケースは珍しくない。事故発生後に会議を開いて役割を決めるのでは遅い。平時に指揮命令系統と代行順位を決めておくことが重要となる。 法令・契約・業界ルールで報告が必要になる 個人データの漏えい等で個人の権利利益を害するおそれがある場合、個人情報保護委員会への報告と本人通知が必要となる。委員会は速報を概ね3～5日以内と案内している。業種によっては所管省庁への報告、犯罪性がある場合は警察への相談、契約に基づく委託元への通知も検討しなければならない。重要なのは、法務・個人情報担当を初動から参加させ、報告要否の判断を後回しにしないことである。 出典：個人情報保護委員会：漏えい等報告・本人への通知の義務化について 対応しなかった場合に起こり得る問題 初動が遅れると、感染端末から認証情報が窃取され、管理者権限の奪取やバックアップ破壊へ進むことがある。反対に、慌てて端末の電源を切ったり初期化したりすれば、メモリやログに残る調査材料を失い、侵入経路や漏えい範囲を説明できなくなる。技術的な失敗は、顧客対応や法的判断の遅れに直結する。 報告の遅れや不正確な公表は、事故そのもの以上に信用を損なう場合がある。第一報で原因や漏えい件数を断定し、その後訂正を重ねれば、取引先は管理能力に疑問を持つ。第一報では確認済み事実、未確認事項、実施済み措置、次回更新予定を分けて示すべきだ。 経営面では、復旧費、フォレンジック調査費、法律相談費、通知・問い合わせ対応費に加え、受注停止や契約解除による逸失利益が発生し得る。インシデント対応体制はIT部門の作業手順ではなく、事業継続と取引維持の仕組みである。 対象となる企業・システム・場面 対象は、SCS評価制度への申請を直接予定する企業だけではない。主要顧客からセキュリティ調査票を受ける企業、委託元の情報やシステムを扱う企業、M&A・IPO・大手企業との新規取引を控える企業にも有効である。対象システムは、基幹系だけに限定しない。Webアプリケーション、クラウド、VPN、メール、ID管理、工場・倉庫の設備、委託先が運用する環境まで、事故が取引先や事業継続に与える影響で優先順位を決める。 例えば、顧客向けWebシステムにはWebアプリケーション診断、サーバーやネットワークにはプラットフォーム診断が有効である。さらに、攻撃者が複数の弱点を組み合わせて目的を達成できるかを検証するにはペネトレーションテストが役立つ。ただし、これらは予防・検証策であり、インシデント対応体制の代替ではない。診断結果を監視ルール、対応手順、復旧計画へ反映して初めて、一連の管理になる。 SCS評価制度を見据えたインシデント対応の実施手順 1．経営層が対応方針と判断権限を決める 最初に、何を守るか、どの程度の停止を許容するか、誰が緊急停止や外部公表を決めるかを定める。経営層は、重要業務ごとの最大許容停止時間、顧客・社会への影響、法令・契約上の報告義務を確認し、対応責任者と代行者を任命する。現場に丸投げせず、事業停止と復旧の優先順位を判断する役割を担う。 2．対象範囲と重要資産を可視化する 資産台帳、ネットワーク構成図、クラウド一覧、データフロー、委託先一覧、取引先との接続関係を整える。すべてを同時に詳細化する必要はない。まず、停止すれば売上・生産・出荷に影響するシステム、機密情報を保有する環境、取引先へ接続する経路を優先する。資産の所有部門と技術的な管理者を分けて記録すると、事故時の連絡が速くなる。 3．検知・連絡受付を一本化する 従業員が「怪しいメールを開いた」「端末が暗号化された」「取引先から不審な通信を指摘された」と気づいたとき、迷わず連絡できる窓口を設ける。電話、チャット、専用メールなど複数経路を用意し、夜間・休日の受付方法も決める。連絡内容は、発見日時、端末・アカウント、現象、直前の操作、業務影響、連絡者を基本項目とする。 4．深刻度を分類し、対応体制を立ち上げる 深刻度は、技術的な派手さではなく、情報の機密性、影響人数、重要業務の停止、取引先への波及、攻撃継続の可能性、法令・契約報告の要否で判断する。重大事案では、インシデント責任者の下に、技術、法務・個人情報、事業部門、広報・顧客対応、経営判断の各担当を配置する。外部のフォレンジック会社、保守ベンダー、弁護士、保険会社への連絡条件も決めておく。 5．封じ込めと証拠保全を両立する 感染端末やサーバーはネットワークから隔離し、不正アカウントの停止、侵害された認証情報の変更、外部公開の一時停止などを行う。ただし、電源断、再起動、初期化、ログ削除は証拠を失うおそれがある。操作前に、実施者、日時、対象、目的、結果を記録し、必要に応じてメモリ、ディスク、ログ、クラウド監査証跡を保全する。証拠はアクセス権を限定し、取得者と受渡履歴を残す。 6．影響範囲を調査し、報告要否を判断する 発生日時、侵入経路、影響したアカウント・端末・データ、外部送信の有無、業務停止範囲を時系列で整理する。調査中で断定できない事項は「未確認」と明記する。報告先は、経営者、取締役会、委託元、顧客、個人情報保護委員会、所管省庁、警察、IPA、JPCERT/CCなどから、法令、契約、被害拡大防止の必要性に基づいて選ぶ。 7．第一報、続報、最終報を使い分ける 第一報の目的は、早期に事実と対応状況を共有し、相手が被害拡大防止策を取れるようにすることだ。発覚日時、確認済みの事象、現時点の影響、実施済み措置、顧客側に依頼する行動、問い合わせ先、次回更新予定を記載する。続報では調査の進展と影響範囲を更新し、最終報では根本原因、被害、対応経過、復旧確認、再発防止策、実施期限と責任者を示す。 8．安全を確認して復旧し、再発防止を管理する 復旧は、単にシステムが起動することではない。侵入経路の閉鎖、認証情報の再設定、マルウェア除去、バックアップの健全性、監視強化を確認したうえで段階的に行う。再発防止策は、緊急・短期・中長期に分け、重大度、悪用可能性、事業影響、実施難易度で優先順位を付ける。経営会議等で期限と担当を追跡し、完了後に再診断やペネトレーションテストで有効性を確かめる。 報告先と報告内容を平時に整理する 主な報告先判断の根拠第一報で重視する内容経営層・取締役会事業・財務・信用への影響業務停止、顧客影響、判断が必要な事項委託元・主要取引先契約、接続関係、被害波及防止影響可能性、遮断措置、相手に依頼する対応個人情報保護委員会個人情報保護法上の報告対象概要、漏えい項目、原因、二次被害防止策警察・IPA・JPCERT/CC等犯罪性、届出、技術支援・情報共有攻撃手口、痕跡、被害状況、支援依頼顧客・本人・社会法令、被害防止、説明責任確認済み事実、注意事項、問い合わせ窓口 出典：参考：IPAのインシデント対応手引き・報告先一覧 平時に準備すべき資料と成果物 実効性を示すには、規程だけでなく、使える資料と運用記録が必要になる。準備すべき主な資料は、インシデント対応方針、対応手順書、緊急連絡網、役割分担表、深刻度基準、資産台帳、ネットワーク・データフロー図、委託先・取引先一覧、法令・契約上の報告要件一覧、証拠保全手順、第一報・最終報のひな形、復旧判定チェックリストである。 成果物には、文書の制定日・承認者・版数を含める。訓練では、参加者、想定シナリオ、判断内容、所要時間、発見した課題、改善担当、期限を記録する。SCS評価制度への説明では、「文書がある」だけでなく、「誰がいつ点検し、訓練で何を改善したか」を示せる状態が望ましい。個人情報や機密情報を含む記録は、保管場所、閲覧権限、保存期間、廃棄方法を定める。 実施期間と費用を左右する要因 期間の目安は、現状把握から基本体制・手順の整備まで2～4か月、机上演習と改善まで含めると3～6か月程度で考えると計画しやすい。これは一般的な目安であり、対象拠点、システム数、委託先数、既存規程の成熟度、経営会議の承認サイクルによって変わる。SCS評価制度の最新要件とのギャップが大きい場合や、SOC・ログ管理・バックアップなど技術対策を同時に整備する場合は、より長い期間が必要になる。 費用は、対象範囲、インタビュー対象部門、規程や台帳の整備量、演習の規模、技術検証、24時間対応の有無、フォレンジックやインシデントレスポンスの待機契約を含むかで変動する。社内稟議では、制度対応費だけでなく、取引継続、顧客監査への回答力、事故時の停止時間短縮、報告遅延リスクの低減という効果を説明すると判断しやすい。 支援会社の選び方とRFP・見積依頼時の確認項目 支援会社は、制度文書を作成できるだけでなく、実際のインシデント対応、デジタルフォレンジック、診断、復旧支援まで理解しているかを確認したい。紙上の手順が技術的に実行できなければ、緊急時には機能しない。経営層への説明、現場ヒアリング、委託先との責任分界整理を一貫して支援できることも重要である。 RFPや見積依頼では、①参照するSCS評価制度資料の版、②対象組織・拠点・システム、③現状調査の方法、④作成・改訂する成果物、⑤演習シナリオと参加部門、⑥技術検証の範囲、⑦課題の優先順位付け方法、⑧機密情報の保管・再委託条件、⑨支援終了後のフォロー、⑩実際の事故発生時の支援可否を確認する。価格だけでなく、社内で運用を継続できる状態まで移管されるかを比較すべきだ。 よくある失敗と注意点 連絡網を作って終わる 担当者名が並んでいても、誰が重大度を判定し、誰が停止・公表を決めるか不明では動けない。権限、代行順位、判断期限まで定める。 IT部門だけで手順を作る 報告・公表、顧客補償、事業停止はIT部門だけでは決められない。法務、個人情報、広報、営業、事業責任者、経営層を設計段階から参加させる。 委託先と責任分界が曖昧 クラウドや保守を委託していても、顧客・当局への説明責任まで移転するとは限らない。ログ取得、初動、報告、証拠保全の担当と時間条件を契約・運用手順で確認する。 訓練が台本の読み合わせになる 実効性を見るには、情報が不足した状態で判断する訓練が必要だ。ランサムウェア、Webアプリケーション侵害、委託先からの漏えいなど、自社の事業に近いシナリオを使い、連絡速度と意思決定を測る。 復旧を急ぎ、根本原因を残す バックアップから戻しても、侵入経路や窃取された認証情報が残れば再侵入される。復旧条件を明文化し、脆弱性診断、プラットフォーム診断、ペネトレーションテスト、監視強化を適切に組み合わせる。 Librus株式会社が提供できる支援 Librus株式会社は、サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）にかかるコンサルティングとして、現状評価、対象範囲の整理、要求事項とのギャップ分析、規程・手順・証跡の整備、経営層向け説明、机上演習、改善計画の策定を支援する。企業ごとの事業、組織、取引関係、既存システムを踏まえて個別に設計するため、既成の規程を導入するだけの対応にはしない。 また、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習、SOC／CSIRT構築、インシデントレスポンス、デジタルフォレンジックまで一気通貫で対応できる。制度対応で見つかった課題を、技術面と経営面の双方から整理し、改善・運用までつなげられる点が強みである。大企業から中堅・中小企業まで、M&A、IPO、取引先監査など重要局面にも対応している。 よくある質問 Q1．SCS評価制度への対応では、CSIRTの設置が必須ですか？ 名称としてのCSIRTより、責任者、役割、連絡経路、判断権限、外部支援先が明確で、実際に機能することが重要である。専任組織が難しい企業では、既存部門を横断する仮想チームとして設計できる。最終的には申請時点の評価基準を確認する必要がある。 Q2．情報システム担当者が数名でも体制を作れますか？ 可能である。社内は意思決定と事業影響の把握に集中し、24時間監視、フォレンジック、法的助言など専門性が必要な機能を外部と分担する設計が現実的だ。外部委託しても責任者と連絡手順は社内に残す。 Q3．インシデント対応手順はどの頻度で見直すべきですか？ 少なくとも年1回を基本とし、組織変更、システム更改、主要委託先の変更、重大インシデントや訓練後にも見直す。連絡先だけは人事異動の都度更新し、夜間連絡が通じるかも確認する。 Q4．机上演習では何を確認しますか？ 検知から責任者への連絡時間、重大度判定、隔離・停止判断、取引先や当局への報告、公表文の承認、復旧判断を確認する。正解を当てる場ではなく、手順と責任の空白を見つける場として実施する。 Q5．事故時に端末の電源を切ってはいけないのですか？ 常に禁止という意味ではない。被害拡大防止を優先しつつ、電源断で揮発性データやログを失う可能性を考慮する。可能ならネットワーク隔離を先に行い、専門家の指示を受ける。人命や設備安全に関わる場合は、安全確保を最優先する。 Q6．取引先への報告は、事実が確定してからでよいですか？ 契約上の期限や被害拡大のおそれによっては、確定前の第一報が必要になる。確認済み事実と未確認事項を分け、次回更新時刻を示す。自社だけで判断せず、法務・契約担当を交えて決める。 Q7．診断やペネトレーションテストだけで十分ですか？ 十分とは限らない。診断は弱点発見、ペネトレーションテストは攻撃経路の検証に有効だが、検知、報告、復旧、再発防止の組織運用は別途必要である。両者を連携させることで対応力が高まる。 Q8．まだ対象範囲が決まっていなくても相談できますか？ 相談できる。主要取引、重要業務、保有情報、システム構成、委託関係を確認し、優先順位の高い範囲から段階的に決める方法がある。最初から全社一律で始める必要はない。 まとめ：SCS評価制度対応は、動ける体制まで整備する サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）を見据えたインシデント対応では、方針、責任者、初動手順、証拠保全、報告先、復旧条件、再発防止を一つの流れとして整備する必要がある。重要な結論は、「誰が、何を根拠に、いつまでに判断するか」を平時に決め、訓練で確認することだ。 制度対応を取引先への説明資料づくりで終わらせず、事業停止時間の短縮、顧客との信頼維持、法令・契約対応の迅速化につなげることが望ましい。制度の最新版を確認しながら、自社の重要業務とサプライチェーン上の責任に合う体制を構築したい。 SCS評価制度への対応方針を、現状整理から相談できます Librus株式会社では、SCS評価制度の対象範囲や進め方が決まっていない段階から相談を受け付けている。現状の規程・体制・システムを整理し、優先すべき課題、必要な成果物、想定期間、技術対策の要否を可視化することで、経営会議や社内稟議に必要な判断材料を整えられる。インシデント対応手順の策定、机上演習、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、改善・運用まで、必要な範囲を組み合わせた支援が可能だ。まずは、取引先から求められている水準や現在の悩みを共有いただきたい。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

取引先からSCS評価取得を求められたら？受注を守る対応方法

サプライチェーン強化に向けたセキュリティ対策評価制度への実務対応 取引先から「SCS評価を取得してほしい」と連絡を受けた場合、最初に行うべきことは、回答期限、求められる段階、対象となる契約・拠点・システム、未取得期間中の取扱いを確認することです。そのうえで、要求事項との差分を調べ、受注継続に直結する不足から改善します。申請だけを急いでも、規程・運用・技術対策・証跡がつながっていなければ評価対応は進みません。 サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、取引先ごとに異なりがちなセキュリティ要求を共通の基準で可視化し、サプライチェーン全体の対策水準を高めるための制度です。従業員100～1,000名規模の企業にとっては、情報システム部門だけの認証対応ではなく、営業、法務、総務、人事、経営層を含む「受注を守るプロジェクト」として扱うことが重要です。 この記事で分かること 取引先からSCS評価取得を求められた直後に確認すべき事項 ★3・★4の違いと、自社に求められる段階の考え方 要求事項へのギャップ分析、改善、技術検証、証跡整備の進め方 期間・費用を左右する要因と、社内稟議・ベンダー選定のポイント 取得準備を一過性で終わらせず、受注維持と事業継続につなげる方法 SCS評価制度とは SCS評価制度は、企業のサプライチェーン上の立ち位置や想定リスクに応じて必要な対策水準を示し、実施状況を段階（★）で可視化する制度です。経済産業省と内閣官房国家サイバー統括室の監督のもと、独立行政法人情報処理推進機構（IPA）が運営します。委託元が取引契約などで委託先に適切な段階を提示し、対策の実施を促して確認する利用場面が想定されています。 2026年9月6日時点で、★3・★4は2027年3月頃の運用開始が予定されています。★5の要求事項、評価方法、開始時期は検討中です。また、★3・★4を取得するには、それぞれに定められたすべての要求事項・評価基準を満たす必要があります。申請方法や申請・登録費用は今後公表予定であり、未確定の費用を確定情報のように予算化しない注意が必要です。 制度の最新情報：IPA「SCS評価制度」公式サイト／IPA「よくある質問」 ★3と★4は単なる優劣ではなく、想定リスクに応じて選ぶ 制度は企業同士を競わせる格付けを目的とするものではありません。取引先がどの段階を求めているかを確認し、自社の判断だけで低い段階に置き換えないことが基本です。一般に、★3は基礎的な組織対策とシステム防御を確実に行う水準、★4はより高度な組織ガバナンスや継続的改善、第三者評価を伴う水準として準備されます。正式な判断は、IPAが公開する要求事項・評価基準と取引先の指定条件に基づいて行います。 なぜ今、SCS評価取得が取引条件になり得るのか 委託元にとって、委託先の停止や情報漏えいは自社の事業停止、顧客対応、監督責任に波及します。典型例は、保守用アカウントの侵害から委託元環境へ侵入されるケース、受発注システムがランサムウェアで止まり納品できなくなるケース、委託先が保管する設計図・顧客情報が漏えいするケースです。Webサービス企業であれば、脆弱なWebアプリケーションから顧客情報を窃取される経路も考えられます。 従来は発注企業ごとの質問票に回答する運用が中心でした。しかし、質問の粒度や証跡の要求がばらばらだと、委託元は比較しにくく、委託先には回答負担が積み上がります。SCS評価制度は、この非効率を共通基準によって緩和する狙いがあります。したがって今後、調達要件、契約更新、入札参加、取引先監査の確認資料として利用される可能性があります。法令上の一律義務と決めつけるのではなく、個別契約上の要請として重要性を判断すべきです。 対応しなかった場合に起こり得る問題 未取得だけで直ちに取引停止になるとは限りません。問題は、取引先からの要請に対して、責任者も計画もなく「検討中」としか答えられない状態です。調達部門から代替候補との比較材料に使われたり、契約更新時に改善計画や追加保証を求められたりする可能性があります。新規案件では、提案内容や価格が優れていてもセキュリティ条件を満たさず、選定対象から外れるおそれもあります。 さらに、形式的な回答で実態を伴わない場合、事故発生後に説明の整合性が問われます。信用毀損、復旧費用、顧客対応、売上停止が重なるため、SCS評価対応は情報システム予算だけでなく、売上防衛、事業継続、取締役のリスク管理という観点で扱う必要があります。 まず取引先に確認する5つの事項 1．期限と取引上の位置づけ 回答期限、取得期限、契約更新日を確認します。「推奨」「将来の必須化を検討」「契約条件」「入札参加条件」では緊急度が異なります。取得まで猶予がある場合は、改善ロードマップの提示で取引継続が可能かも協議します。 2．求められる段階と対象範囲 ★3か★4か、全社か特定事業か、国内拠点だけか海外拠点も含むかを明確にします。契約対象サービスに利用するクラウド、データセンター、開発・保守委託先、リモートアクセス環境が範囲に入るかも確認します。 3．提出を求める証拠 マーク取得だけを求めるのか、申請前の自己評価、改善計画、脆弱性診断報告書、教育実績、インシデント対応体制なども必要かを確認します。報告書の原本提出は機密情報の露出につながるため、要約版、閲覧方式、秘密保持契約の利用も検討します。 4．未取得期間中の暫定措置 取得予定日、責任者、未達項目、代替統制を記載した計画書で暫定対応できるか確認します。制度開始前であれば、その事実を共有しつつ、要求事項に沿った準備状況を説明するのが現実的です。 5．再委託先への要求 自社だけが整備しても、重要業務を担う再委託先やSaaS事業者の管理が抜ければリスクは残ります。再委託の許可、事故報告期限、アクセス権管理、契約終了時のデータ削除など、委託先管理の範囲を取引先とそろえます。 SCS評価取得に向けた具体的な対応手順 ステップ1．経営責任者と推進体制を決める 経営層は、対象事業、目標段階、取得目標時期、許容できる残余リスク、予算枠を決定します。実務責任者を情報システム部門に置く場合でも、規程は総務・法務、教育は人事、委託先管理は購買、顧客説明は営業が担います。部門横断の会議体と意思決定者を先に定めると、改善が停滞しにくくなります。 ステップ2．必要資料と資産情報を集める 最初に、組織図、情報セキュリティ規程、資産台帳、ネットワーク構成図、アカウント一覧、クラウド・SaaS一覧、委託先一覧、事故対応手順、バックアップ設計、教育記録、過去の診断・監査報告書を集めます。文書があるかだけでなく、承認日、最新版、実施記録、対象者、例外処理まで確認します。 ステップ3．要求事項とのギャップを可視化する 各要求事項について「適合」「一部適合」「未適合」「対象外候補」に分け、根拠資料と責任部門をひも付けます。対象外は自己判断で除外せず、業務やシステム構成から妥当性を説明できるようにします。ギャップ表には、現状、必要な改善、優先度、担当者、期限、概算費用、確認方法を記載します。 ステップ4．事業影響を基準に改善順位を決める 優先順位は、単に項目数や導入の容易さで決めません。インターネット公開、特権ID、機密情報、停止時の売上影響、既知の脆弱性、攻撃可能性を組み合わせます。たとえば、多要素認証がない管理者アカウント、外部公開機器の重大な脆弱性、復元試験をしていないバックアップは、早期に是正すべき候補です。 ステップ5．規程・運用・技術対策を一体で改善する 規程だけを作っても運用記録がなければ実効性を示せません。一方、製品を導入しても責任者や監視手順がなければ継続しません。アクセス権の申請・承認・棚卸し、パッチ適用期限、ログ監視、バックアップ復元試験、インシデント連絡網、委託先評価、教育・訓練を、担当と頻度を含めて設計します。 ステップ6．技術検証で実態を確認する Webアプリケーション診断は、認証、入力処理、セッション管理などWeb固有の弱点を確認します。プラットフォーム診断は、サーバー、ネットワーク機器、OS、ミドルウェアの設定や既知脆弱性を調べます。ペネトレーションテストは、攻撃者の視点で複数の弱点を組み合わせ、重要情報や権限に到達できるかを検証するものです。目的が異なるため、「診断を1回実施した」だけで一律に代替できるわけではありません。対象資産と評価基準に応じて組み合わせます。 ステップ7．証跡を整え、模擬評価を行う 成果物には、適用範囲、要求事項ごとの判定、判定根拠、参照証跡、未達事項、是正計画、リスク受容の承認記録を含めます。規程、設定画面、ログ、会議議事録、教育受講記録などの証跡は、取得日と責任者が分かる状態にします。最後に第三者の視点で模擬評価を行い、文書と実態の不一致、説明の属人化、証跡の欠落を洗い出します。 対象範囲の決め方 範囲を狭くすれば安く早くなるとは限りません。共通の認証基盤やネットワークが全社で共有されている場合、特定部署だけを切り出しても依存関係の確認が必要です。反対に、契約対象と無関係な拠点まで含めると負担が膨らみます。まず守るべき取引・情報・サービスを特定し、それを支える人、端末、サーバー、クラウド、委託先、物理拠点をたどって境界を決めます。境界外との接続と責任分界も文書化します。 期間と費用を左右する要因 公式の申請・登録費用は2026年9月6日時点で未公表です。したがって予算は、制度側に支払う費用と、自社の準備・改善に必要な費用を分けて考えます。後者は、対象拠点・システム数、目標段階、既存規程の成熟度、資産台帳の精度、クラウドや委託先の数、技術診断の範囲、製品導入の有無、証跡の不足量によって変動します。 実務上は、初動確認と簡易ギャップ分析、詳細評価、改善、証跡蓄積、評価準備の順に進めます。小規模な範囲でも運用記録を一定期間蓄積する必要があるため、短期集中だけでは完了しない場合があります。取引先の期限から逆算し、まず重大な不足と暫定措置を示し、その後に中期改善を続ける二段階の計画が有効です。 社内稟議で説明すべき内容 稟議では「認証取得費」だけを提示せず、対象取引の売上・粗利、更新時期、未対応時の営業影響、事故時の停止影響、現状の不足、必要な人員と外部費用を説明します。成果を、①取引先への回答、②SCS評価取得準備、③重大リスクの低減、④今後の監査回答の共通化に分けると、投資効果を理解してもらいやすくなります。 また、規程整備や診断で終わらず、改善後の再診断、ログ監視、アカウント棚卸し、教育、インシデント訓練を運用費として見込む必要があります。初年度だけ予算を確保すると、更新時に証跡が不足し、再び突貫対応になりかねません。 支援会社の選び方とRFPで確認する項目 支援会社は、制度の説明だけでなく、要求事項を現場の設定・運用へ落とし込めるかで選びます。RFP（提案依頼書）や見積依頼では、対象範囲、目標段階、期限、既存認証、希望成果物、機密情報の取扱条件を伝えたうえで、次の点を確認します。 ギャップ分析、改善設計、技術検証、証跡整備、評価準備のどこまで含むか 要求事項ごとの判定根拠と、対象外判断の考え方を示せるか Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストを目的別に設計できるか 発見事項を技術的な深刻度だけでなく、事業影響と期限で優先順位付けするか 報告書の再利用権、保管場所、暗号化、再委託、削除方法を明示するか 改善後の再確認、継続監視、教育・訓練まで支援できるか 制度上の評価機関・専門家としての役割と、取得準備コンサルティングの役割を混同していないか 特に、支援会社が制度上の登録評価機関であるかのような誤認を招く説明には注意が必要です。準備支援と正式評価は役割を切り分け、最新のIPA公表情報で確認します。 よくある失敗と注意点 質問票を埋めることが目的になる 回答を完成させても、設定や運用が伴わなければ証跡確認で止まります。要求事項を業務プロセスへ変換し、誰がいつ何を記録するかまで決めます。 すべてを情報システム部門に任せる 委託先契約、採用・退職、教育、事故広報は情報システム部門だけでは完結しません。経営スポンサーのもとで各部門の責任を明確にします。 診断範囲が資産台帳と一致しない 公開資産の漏れや、開発・検証環境の除外があると、実際の攻撃面を見落とします。資産棚卸しを先に行い、除外理由を残します。 重大度の高い脆弱性だけを直して終わる 個別の脆弱性を修正しても、特権管理、ログ監視、バックアップ、事故対応などの仕組みが弱ければ再発します。技術対策と管理策を同じ改善計画で管理します。 取引先に機密情報を渡しすぎる 構成図や診断報告書は攻撃者に有用な情報を含みます。必要性、閲覧者、保存期間、二次利用、廃棄方法を確認し、必要に応じて要約やマスキングを行います。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度への対応方針整理から、対象範囲の設定、要求事項とのギャップ分析、規程・運用設計、技術的な対策、証跡整備、改善後の確認まで一気通貫で支援します。診断結果を渡して終えるのではなく、経営層、情報システム部門、現場部門の間に立ち、実行可能な改善計画へ落とし込みます。 必要に応じて、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築・運用、インシデント対応、デジタルフォレンジック、教育・訓練を組み合わせます。グローバルスタンダードを踏まえながらも、日本企業の稟議、予算、人員、委託構造に合わせて個別設計する点が特徴です。大企業との取引を持つ中堅・中小企業、M&A・IPO・取引先監査など重要局面にある企業にも対応します。 よくある質問 Q1．SCS評価制度への対応は法律上の義務ですか？ 制度自体をすべての企業に一律に義務付けるものと捉えるべきではありません。ただし、委託元が契約や調達条件として取得を求める場合、受注・契約更新に実質的な影響が生じます。個別契約と要請文を確認してください。 Q2．★3と★4のどちらを目指すべきですか？ 取引先の指定がある場合は、その段階が出発点です。指定がない場合は、扱う情報、サービス停止の影響、サプライチェーン上の役割、既存対策を踏まえて判断します。単純に企業規模だけでは決まりません。 Q3．制度開始前でも準備できますか？ 可能です。公開済みの要求事項・評価基準を使い、対象範囲の整理、ギャップ分析、重大リスクの改善、証跡の蓄積を始められます。今後公開される解説書や申請方法に合わせて更新します。 Q4．ISO/IEC 27001やプライバシーマークがあれば十分ですか？ 既存の管理体制や証跡は活用できますが、SCS評価制度の要求事項を自動的にすべて満たすとは限りません。重複を生かしながら、項目単位で差分を確認します。 Q5．脆弱性診断は必須ですか？ 必要な技術検証は対象システムと要求事項により判断します。Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストは目的が異なるため、リスクと評価範囲に合う手法を選びます。 Q6．取得までどの程度かかりますか？ 一律には決まりません。対象範囲、未達項目、製品導入、社内承認、委託先調整、運用証跡の蓄積期間で変わります。まず短期間のギャップ分析を行い、取引先期限に対する現実的な工程を作ることが重要です。 Q7．費用はいくらですか？ 公的な申請・登録費用は今後公表予定です。準備費用は、対象数、目標段階、診断範囲、規程・運用の成熟度、改善内容によって変わります。範囲と成果物をそろえた見積比較が必要です。 Q8．取引先への最初の回答はどうすべきですか？ 受領した旨を伝え、段階、範囲、期限、契約上の位置づけ、必要証跡を確認します。その後、現状評価の日程、責任者、暫定措置、取得・改善計画の提示日を回答します。根拠なく取得可能と断言しないことが大切です。 まとめ｜SCS評価対応は受注を守る経営課題 取引先からSCS評価取得を求められたら、まず要請条件を明確にし、サプライチェーン強化に向けたセキュリティ対策評価制度の要求事項と自社の実態との差を確認します。その後、事業影響の大きいリスクから改善し、規程・運用・技術対策・証跡を一つの計画で整えます。 SCS評価制度への対応は、マーク取得だけが目的ではありません。取引先への説明力を高め、事故による供給停止を減らし、営業部門が安心して案件を提案できる基盤を作る取り組みです。制度の詳細は今後も更新されるため、公式情報を確認しながら、期限に余裕を持って準備を進めることが受注維持につながります。 SCS評価取得の準備段階からご相談いただけます 「取引先から要請が来たが、何を回答すべきか分からない」「★3・★4のどちらが必要か整理できていない」「対象範囲や予算が決まっていない」という段階でもご相談いただけます。Librus株式会社が要請内容と事業影響を整理し、必要なギャップ分析、改善の優先順位、技術検証、社内稟議に使える工程を具体化します。早期に論点を可視化することで、過剰投資を避けながら、取引先への説明と受注継続に必要な準備を進めやすくなります。 参考資料 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」 IPA「SCS評価制度」 IPA「要求事項・評価基準」 IPA「よくある質問」 IPA「関連制度・施策」 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE