SCS評価制度の取得費用は？評価料金と対策コスト・予算の考え方

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の取得を検討するとき、経営層や情報システム部門が最初に気になるのが「結局、いくら必要なのか」という点です。結論から言えば、SCS評価制度の費用は、IPAに支払う登録料だけで判断できません。実際の予算は、登録料に加えて、★3の専門家確認、★4の第三者評価・技術検証、社内規程や証跡の整備、脆弱性対策、必要に応じたWebアプリケーション診断・プラットフォーム診断・ペネトレーションテスト、さらに社内担当者の工数まで含めて考える必要があります。 2026年9月18日にIPAが公表した料金では、2028年3月31日までの申請について、★3登録希望組織の登録料は10,000円（税込・1年分）、★4は60,000円（税込・3年分）です。2028年4月1日以降は、★3が20,000円（税込・1年分）、★4は60,000円（税込・3年分）とされています。ただし、これは制度運営側に支払う登録料であり、取得に必要な総費用ではありません。 本記事では、従業員100～1,000名程度の企業を想定し、SCS評価制度の費用構造、予算を左右する要因、見積もり時の確認事項、社内稟議での説明方法、費用を抑えながら実効性を高める考え方まで実務的に解説します。 この記事で分かること SCS評価制度で公式に公表されている登録料 登録料以外に発生する専門家確認・評価・技術検証・改善対応の費用 ★3と★4で予算構造が異なる理由 Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストを予算に入れる判断基準 経営層・情報システム部門が社内稟議で説明すべきポイント 見積依頼時に確認すべき項目と、支援会社の選び方 SCS評価制度の取得費用は「登録料＋評価・確認＋改善費用」で考える SCS評価制度の費用を考える際は、少なくとも「制度上の登録費用」「評価・確認に関する外部費用」「要求事項を満たすための改善費用」「社内工数」の4つに分けると整理しやすくなります。登録料だけを見ると負担は限定的ですが、実務では現状と要求事項の差分を埋めるための対策費が総額を大きく左右します。 費用区分主な内容金額の決まり方登録料IPAの台帳に★3・★4を登録するための費用IPAが公表確認・評価費用★3の専門家確認、★4の第三者評価・実地審査等専門家・評価機関との契約で決定技術検証費用★4で必要となる脆弱性診断等の技術検証対象範囲・方式・事業者で変動改善・対策費用規程整備、MFA、端末防御、ログ、バックアップ、脆弱性対応等現状とのギャップで変動社内工数資料収集、証跡整理、部門調整、審査対応、稟議等組織規模・対象範囲・成熟度で変動 IPAが公表している★3・★4の登録料 IPAの「SCS評価制度 料金設定のお知らせ」（2026年9月18日）では、登録希望組織の登録料が次のとおり示されています。料金には消費税・地方消費税が含まれ、適用時期は申請日が基準です。 区分2028年3月31日までの申請2028年4月1日以降の申請★310,000円（1年分）20,000円（1年分）★460,000円（3年分）60,000円（3年分） 重要なのは、この金額を「取得費用の総額」と誤解しないことです。★3では要求事項への適合確認、★4では第三者評価と技術検証が必要であり、これらの外部費用は登録料とは別に発生します。評価機関や技術検証事業者のサービス料金は制度として一律に決められているわけではなく、対象範囲や作業量に応じて個別に見積もられるのが基本です。 なぜ今、SCS評価制度の予算を検討しておく必要があるのか SCS評価制度は任意制度ですが、委託元が取引先に対して必要な★を提示し、対策状況を確認する利用方法が想定されています。そのため、自社が制度対応を後回しにしている間に、主要顧客の調達基準や委託先評価に★3・★4が組み込まれる可能性があります。特に、大企業のサプライチェーンに入っている企業、機密情報や個人情報を預かる企業、システム運用・開発を受託する企業では、セキュリティ評価が営業・調達・契約更新に影響しやすくなります。 予算面では、制度開始直前にまとめて対策しようとすると、規程整備、システム改修、製品導入、診断、審査準備が同時並行になり、費用と社内負荷が膨らみやすくなります。反対に、現状分析を先に行い、必須対策・優先対策・中長期対策に分けて年度予算へ落とし込めば、無駄な製品導入や重複投資を抑えやすくなります。 ★3と★4では費用の構造が異なる ★3は「要求事項への適合」と「確認可能な証跡」が予算の中心 ★3を目指す場合、まず要求事項・評価基準に対して自社の現状を棚卸しし、不足項目を埋めます。費用が発生しやすいのは、アクセス権限管理、多要素認証、端末保護、バックアップ、パッチ・脆弱性管理、インシデント対応手順、委託先管理、教育、ログ管理などです。すでにISMS等を運用している企業は既存規程や証跡を活用できる可能性がありますが、文書が存在するだけでは十分ではありません。実際の運用記録や承認履歴、棚卸し結果など、実施を説明できる証跡が必要です。 外部のSCSセキュリティ専門家による確認を依頼する場合、その費用も予算化します。金額は制度で一律に定められていないため、対象拠点数、資料量、事前支援の有無、確認回数などを見積条件として明示することが重要です。 ★4は第三者評価・実地審査・技術検証まで含めて考える ★4では、評価機関による第三者評価に加え、技術検証が求められます。IPAは評価機関の業務として、文書確認・実地審査・技術検証を含む第三者評価を示しています。技術検証は、外部公開資産や対象システムに対する脆弱性診断等が中心になるため、対象IP数、Webアプリケーション数、認証有無、ネットワーク構成、クラウド利用範囲などによって費用が変動します。 ここで、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストを同じものとして扱わないことが重要です。Webアプリケーション診断はWeb機能の脆弱性、プラットフォーム診断はOS・ミドルウェア・ネットワーク機器等の脆弱性を確認します。ペネトレーションテストは、想定シナリオに基づき実際に侵入可能性や影響を検証するため、一般に対象設計や試験内容がより個別化されます。SCS評価制度に必要な技術検証の範囲と、自社がリスク低減のために追加で実施したい検証を切り分けることで、過不足のない予算を組みやすくなります。 SCS評価制度の総コストを左右する7つの要因 1. 現状のセキュリティ成熟度 既存の規程、ISMS、端末管理、ID管理、バックアップ、ログ、教育、脆弱性管理が整っているほど追加対策は少なくなります。反対に、ルールが部門ごとに分散していたり、運用証跡が残っていなかったりすると、整備工数が増えます。 2. 対象範囲 本社だけか、複数拠点・工場・子会社まで含むかで資料数と審査対応が変わります。システムについても、社内IT、クラウド、外部公開サービス、委託先環境のどこまでを対象とするかを先に定める必要があります。 3. 目指す段階 ★3と★4では確認方法が異なり、★4は第三者評価・技術検証を含むため外部費用が増える可能性があります。取引先から要求される水準、自社の営業戦略、扱う情報の重要性から目標を決めます。 4. 不足している技術対策 MFA、EDR、資産管理、ログ収集、バックアップ強化、脆弱性管理などを新規導入する場合は初期費用と継続費用の両方が発生します。製品購入ありきではなく、要求事項とリスクに対して必要な対策を選ぶべきです。 5. 診断・技術検証の対象量 IP数、Web画面数、API数、認証方式、クラウド資産、試験環境の有無、再診断回数などが見積金額に影響します。 6. 社内の証跡整備状況 アクセス権棚卸し、教育記録、インシデント訓練、委託先評価、バックアップ復旧テスト等の記録が整理されていると、審査準備が効率化します。 7. 外部支援の範囲 ギャップ分析のみ、規程整備まで、ツール選定まで、診断まで、審査対応までなど、委託範囲によって支援費用が変わります。 予算は「取得費」ではなく3段階で組む 社内稟議では、SCS評価制度の予算を一括の「認証取得費」として申請するより、次の3段階に分けると説明しやすくなります。 第1段階：現状把握・ギャップ分析 要求事項に対して何が満たせており、何が不足しているかを確認します。ここで対象範囲と優先順位を固めることで、後工程の見積精度が上がります。 第2段階：不足対策の実装・運用 規程、技術対策、教育、証跡取得、委託先管理、インシデント対応などを整えます。複数年度で対応できる項目と、申請前に必須の項目を分けることが重要です。 第3段階：確認・評価・登録 ★3の専門家確認、★4の第三者評価・技術検証、必要な是正・再確認、IPAへの登録を行います。 この分け方にすると、「登録料は小さいのに、なぜ数十万～数百万円規模の予算が必要になる可能性があるのか」といった経営層の疑問に対して、制度費用と改善投資を分離して説明できます。なお、ここで示した金額レンジは例示していません。2026年10月22日時点で、専門家・評価機関・技術検証・コンサルティングの公式な一律料金は公表されておらず、個社の条件によって変動するためです。 費用を抑えるために最初にやるべきこと 対象範囲を広げすぎない 「会社全体を全部見てもらう」と曖昧に依頼すると、調査・資料収集・診断対象が膨らみます。取引上どの事業・拠点・システムに★が必要なのかを確認し、その範囲から着手します。ただし、形式的に範囲を狭めて実際のリスクを外すのは適切ではありません。情報の流れや委託関係を踏まえ、説明可能な範囲設定にする必要があります。 既存のISMS・社内規程・監査証跡を再利用する すでにISMS、Pマーク、取引先監査、内部統制、BCP、IT資産管理などを運用している場合、既存文書や証跡をSCS評価制度の要求事項にマッピングすると、ゼロから作り直す費用を抑えられます。重要なのは「既存資料があるか」ではなく、「要求事項に対して何を根拠に適合と説明できるか」です。 製品導入の前に運用で解決できるか確認する セキュリティ対策では、新しいツールを入れれば解決するとは限りません。権限棚卸し、アカウント廃止、パッチ適用ルール、委託先管理、教育、バックアップ復旧訓練など、既存機能と運用改善で対応できる項目もあります。ギャップ分析の前に製品を購入すると、過剰投資になりやすいので注意が必要です。 見積依頼前に準備するとよい資料 支援会社や評価関連事業者へ見積もりを依頼する前に、組織図、拠点一覧、ネットワーク概要図、システム・クラウド一覧、外部公開資産一覧、情報資産管理台帳、セキュリティ規程、アクセス権限管理の記録、教育・訓練記録、委託先一覧、インシデント対応手順、バックアップ方針、直近の脆弱性診断報告書などを整理しておくと、見積精度が上がります。すべてがそろっていなくても、欠落している資料自体がギャップの把握につながります。 RFP・見積依頼で確認すべきポイント ★3・★4のどちらを前提とした支援か ギャップ分析、規程整備、証跡作成支援、技術対策、診断、審査対応のどこまでが含まれるか Webアプリケーション診断・プラットフォーム診断・技術検証の対象数と単価条件 再診断・是正確認の回数と追加料金条件 現地対応が必要な場合の交通費・出張費の扱い 報告書・成果物の内容、経営層向け説明資料の有無 機密情報・個人情報・診断データの保管方法と削除方針 評価機関との独立性・利益相反に問題がないか 取得後の運用・更新支援が別料金かどうか 価格だけを比較すると、後から「規程整備は対象外」「再診断は追加費用」「評価機関との調整は含まれない」といった差が出やすくなります。総額と作業範囲を同時に比較することが重要です。 SCS評価制度の予算策定でよくある失敗 登録料だけを予算化する 最も起きやすい失敗です。登録料は制度上の費用の一部であり、不足対策や専門家確認、評価、技術検証の費用は別です。まずギャップ分析を行い、総費用を見積もる必要があります。 診断費用だけ計上し、是正費用を入れない 脆弱性診断で問題が見つかった場合、設定変更、改修、機器更新、クラウド構成変更などの是正費用が発生します。また、是正後に再診断が必要になる場合もあります。診断費と是正費を別枠で考えると予算超過を防ぎやすくなります。 各部門の工数を無視する SCS評価制度対応は情報システム部門だけで完結しません。総務、人事、法務、購買、営業、開発、経営層などが関わる場合があります。資料収集、承認、契約見直し、教育、委託先管理などの社内工数もスケジュールと予算の一部として扱うべきです。 取得を目的化し、運用費を見ない セキュリティは取得時だけ整えれば終わるものではありません。ログ監視、端末保護、脆弱性管理、教育、バックアップ確認、権限棚卸しなどには継続費が発生します。初年度の構築費と翌年度以降の運用費を分けて稟議することが重要です。 SCS評価制度の支援会社を選ぶポイント 支援会社を選ぶ際は、制度文書の読み解きだけでなく、実際のセキュリティ対策まで対応できるかを確認します。SCS評価制度では、規程・運用・技術対策・証跡がつながっていることが重要です。そのため、コンサルティングだけでなく、脆弱性診断、ペネトレーションテスト、SOC／CSIRT、インシデント対応、教育など、発見した課題を改善までつなげられる体制があると、複数ベンダー間の調整コストを抑えやすくなります。 また、経営層向けには取引継続・信用・事業継続の観点、情報システム部門には技術対策と運用負荷、現場部門には具体的な変更点を説明できる支援会社が望ましいでしょう。制度取得だけでなく、その後の運用を前提に設計できるかが重要です。 Librus株式会社が支援できること Librus株式会社では、SCS評価制度への対応について、要求事項の読み解きだけでなく、現状分析、対象範囲の整理、ギャップ分析、優先順位付け、規程・証跡整備、技術対策、診断、改善、運用まで一気通貫で支援できます。 特に、SCS評価制度の費用を検討する段階では、「何にいくらかかるか」を先に断定するのではなく、自社の現状と目標とする★、取引先から求められる水準、対象システム、既存対策を確認したうえで、必須対応と推奨対応を分けることが重要です。Librusでは、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築・運用支援、インシデントレスポンス、デジタルフォレンジック、セキュリティ教育、SBOM、リスクアセスメントなどの技術サービスとコンサルティングを組み合わせ、企業ごとの環境に応じた計画を設計します。 大企業から中堅・中小企業まで、M&A、IPO、取引先監査など経営上の重要局面を含め、技術と経営の両面から支援できることがLibrusの特徴です。SCS評価制度についても、取得そのものだけでなく、取引継続や営業上の信頼性向上につながる運用を重視します。 SCS評価制度の費用に関するよくある質問 Q1. SCS評価制度の取得費用はいくらですか？ 公式に確定している登録料は、2028年3月31日までの申請で★3が10,000円（税込・1年分）、★4が60,000円（税込・3年分）です。ただし、専門家確認、第三者評価、技術検証、不足対策、社内工数は別途必要です。 Q2. ★3と★4ではどちらの方が費用が高くなりますか？ 一般に、★4は第三者評価・実地審査・技術検証を伴うため、外部費用は増えやすいと考えられます。ただし、総額は現状の対策状況と対象範囲で変わります。 Q3. ISMSを取得していれば費用を抑えられますか？ 既存の規程、リスク評価、教育、監査、アクセス管理等を活用できる場合は、整備工数を抑えられる可能性があります。ただし、SCS評価制度の要求事項に対して不足がないかを別途確認する必要があります。 Q4. 脆弱性診断は必ず必要ですか？ ★4では技術検証が求められます。具体的な対象や方法は制度文書・評価機関との調整に基づき決めます。★3でも、自社のリスクや取引先要求に応じて診断が有効な場合があります。 Q5. ペネトレーションテストまで必要ですか？ 必ずしも全社がペネトレーションテストを実施するとは限りません。要求事項、対象システムの重要性、既存診断の結果、取引先要求を踏まえて必要性を判断します。 Q6. 取得までの期間はどの程度見ておくべきですか？ 一律には決められません。規程や技術対策が整っている企業と、ゼロから整備する企業では大きく異なります。制度開始前からギャップ分析を実施し、改善期間を確保することが重要です。 Q7. 予算申請では何を説明すればよいですか？ 登録料、外部確認・評価費、技術検証費、改善費、継続運用費を分け、取引継続、顧客要求、事業継続、信用毀損リスクとの関係を説明すると理解を得やすくなります。 Q8. まだ★3か★4か決まっていなくても相談できますか？ 可能です。主要取引先、扱う情報、事業の重要性、現在の対策状況を確認し、どの水準を目指すべきか、どこから予算化すべきかを整理するところから進められます。 まとめ｜SCS評価制度の予算は「登録料」より「不足対策」を見積もる SCS評価制度の登録料は、2028年3月31日までの申請で★3が10,000円（1年分）、★4が60,000円（3年分）と公表されています。しかし、企業が実際に確保すべき予算は登録料だけではありません。専門家確認、第三者評価、技術検証、規程・証跡整備、Webアプリケーション診断やプラットフォーム診断、必要に応じたペネトレーションテスト、システム改修、社内工数、取得後の継続運用まで含めて考える必要があります。 費用を適正化する最も有効な方法は、いきなり製品や診断を発注するのではなく、まず自社の対象範囲と現状を整理し、SCS評価制度の要求事項とのギャップを把握することです。必須対応と中長期改善を分ければ、稟議の精度を高めながら、取引先から求められるセキュリティ水準にも計画的に対応できます。 SCS評価制度の費用・対象範囲がまだ決まっていない段階からご相談いただけます 「★3と★4のどちらを目指すべきか分からない」「登録料以外にどの程度の対策が必要か把握できていない」「来年度予算にどこまで計上すべきか整理したい」といった段階でも問題ありません。Librus株式会社では、現状のセキュリティ対策、主要取引先からの要求、対象システム、既存のISMSや社内規程などを確認し、優先して対応すべき項目と後から改善できる項目を整理します。これにより、必要以上に対策範囲を広げたり、不要なツールを先に購入したりすることを避けながら、取得・取引継続に必要な予算の全体像を把握しやすくなります。対象範囲や実施方法がまだ固まっていない場合も、初期整理からご相談いただけます。 参考情報 IPA「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」：https://www.ipa.go.jp/security/scs/index.html IPA「SCS評価制度 料金設定のお知らせ」（2026年9月18日）：https://www.ipa.go.jp/security/scs/rcu1hd00000075om-att/pricelist.pdf IPA「SCS評価制度の詳細情報」：https://www.ipa.go.jp/security/scs/details.html IPA「要求事項・評価基準」：https://www.ipa.go.jp/security/scs/requirements-criteria.html 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」：https://www.meti.go.jp/policy/netsecurity/scs.html 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

SCS評価制度★４取得に必要な対策｜第三者評価・技術検証を解説

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★４は、サプライチェーン企業が標準的に目指すべき対策水準として位置づけられています。★３よりも広い範囲で、組織ガバナンス、取引先管理、システム防御・検知、インシデント対応、復旧までを包括的に求める点が特徴です。 結論から言えば、★４取得の準備では「規程を整える」「チェックシートを埋める」だけでは足りません。評価機関による第三者評価では文書確認に加えて実地審査が行われ、技術検証では対象IT基盤に対する脆弱性診断が実施されます。そのため、制度要求を満たすルール、実際の運用、設定・ログ・台帳などの証跡、外部公開資産の技術的な安全性を一体で整える必要があります。 本記事では、従業員100〜1,000名程度の企業を想定し、SCS評価制度★４の水準、第三者評価と技術検証の仕組み、取得前に実施すべき対策、Webアプリケーション診断・プラットフォーム診断・ペネトレーションテストの使い分け、費用・期間を左右する要因、支援会社の選び方まで実務に即して解説します。 この記事で分かること ・SCS評価制度★４が求める対策水準と★３との違い ・第三者評価で確認される文書・運用・証跡の考え方 ・技術検証（脆弱性診断）に備えて確認すべきIT基盤 ・Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストの位置づけ ・★４取得に向けた準備手順、費用・期間、ベンダー選定のポイント SCS評価制度★４とは SCS評価制度は、取引先ごとに異なりやすいセキュリティ要求を共通化し、サプライチェーンに参加する企業の対策状況を可視化するための制度です。経済産業省と内閣官房国家サイバー統括室が制度構築方針を公表し、IPAが制度を運営します。★３・★４は2027年3月頃の運用開始が予定されています。 ★４は、供給停止によってサプライチェーンに大きな影響を及ぼし得る企業や、漏えい時の影響が大きい機密情報等を扱う企業も念頭に、標準的に目指すべき水準として設計されています。初期侵入を防ぐだけでなく、侵入後の被害拡大防止、攻撃の検知、インシデント対応、復旧、取引先管理までを含めた対策が求められます。 出典：IPA「SCS評価制度の詳細情報」 https://www.ipa.go.jp/security/scs/details.html 出典：経済産業省「SCS評価制度」 https://www.meti.go.jp/policy/netsecurity/scs.html ★３との違いは「対策の広さ」と「評価方法」 ★３は一般的なサイバー脅威に対処する基礎的な水準で、専門家確認付き自己評価です。一方、★４では★３を包含しながら、継続的改善につながるリスク管理、取引先管理、防御・検知、インシデント対応等をより包括的に求めます。評価も自己評価だけでは完結せず、指定された評価機関による第三者評価と技術検証が必要です。 なお、★４を取得するために★３を先に取得する必要はありません。自社のサプライチェーン上の役割、取引先から要求される水準、扱う情報・業務の重要性などから、目指す段階を判断します。 SCS評価制度★４の第三者評価は何を確認するのか ★４では、取得希望組織が要求事項・評価基準に沿って自己評価を行った後、評価機関へ評価・技術検証を依頼します。IPAの制度構築方針では、★４の評価は「文書確認」「実地審査」「技術検証」で構成される考え方が示されています。評価対象は、企業が定めた適用範囲からサンプリングして確認する想定です。 出典：IPA「制度構築方針」 https://www.ipa.go.jp/security/scs/rcu1hd0000007ajp-att/20260327001-br.pdf 文書確認では自己評価の根拠が問われる 文書確認では、自己評価の記載内容に矛盾がないか、評価基準から見て必要な事項が十分に記載されているかなどが確認されます。社内規程や方針を用意するだけでなく、要求事項と実際の運用が対応していることを説明できるよう、資産台帳、ネットワーク構成図、権限管理記録、パッチ管理記録、委託先管理資料、教育記録、インシデント対応手順などを整理しておくことが重要です。 実地審査では「実際に運用されているか」が確認される 制度構築方針では、実地審査は取得希望企業へのヒアリング、規程、操作画面等の確認によって行う想定です。相対的に重要性の高い対策について、証跡を含めて評価するとされており、例として脆弱性管理体制・管理プロセス、セキュリティインシデント対応手順、事業継続要件に沿った復旧準備が挙げられています。 つまり、規程に「毎月確認する」と記載していても、実施記録がない、担当者が手順を理解していない、操作画面上では設定されていないといった場合は説明が難しくなります。★４では、文書と運用実態を一致させることが重要です。 SCS評価制度★４の技術検証とは IPAは、★４の技術検証事業者について「委託元評価機関の委託を受けて技術検証（脆弱性診断）を実施し、技術検証結果報告書を評価機関に交付する」役割としています。評価機関自身が技術検証を行う場合もあれば、指定された別の技術検証事業者へ委託する場合もあります。 出典：IPA「指定申請について（評価機関・技術検証事業者・研修事業者向け）」 https://www.ipa.go.jp/security/scs/security-experts-organization/shiteishinsei.html 技術検証は外部公開機器の脆弱性を実際に確認する 制度構築方針では、技術検証の例として、取得希望企業がインターネットに公開している機器のうち、脆弱性を悪用された場合に組織内部へ侵入されるリスクが高い機器を対象に、既知脆弱性の悪用など一般的な攻撃パターンを試行する脆弱性検査が示されています。VPN装置やルータなどが例示されています。 ここで重要なのは、評価直前に診断を受けることよりも、日常的に外部公開資産を把握し、脆弱性情報を収集し、修正期限を定め、パッチや設定変更を行うプロセスを確立することです。技術検証で問題が見つかったときに、資産の存在そのものを把握していなかった状態では、根本的な管理プロセスの見直しが必要になります。 Webアプリケーション診断・プラットフォーム診断との関係 Webアプリケーション診断は、Webアプリケーションの入力処理、認証・認可、セッション管理などを確認し、SQLインジェクション、クロスサイトスクリプティング、アクセス制御不備といった脆弱性を検出するために用います。一方、プラットフォーム診断は、サーバー、VPN、ルータ、クラウド公開資産などについて、公開ポート、ソフトウェアの既知脆弱性、設定不備などを確認する手法です。 SCS評価制度★４の技術検証は制度で指定された方法に従う必要があるため、一般の脆弱性診断を受ければ自動的に技術検証を代替できるとは限りません。ただし、取得前の準備として外部公開資産を診断し、重大な脆弱性を先に是正しておくことは有効です。制度構築方針では、直近の脆弱性検査結果など相当する証跡をもって技術検証の代替とみなす案も検討対象として示されているため、最終的な運用ルールは申請時点のIPA資料で確認する必要があります。 ペネトレーションテストは★４の技術検証と同じではない ペネトレーションテストは、攻撃者の目的やシナリオを設定し、複数の脆弱性や設定不備を組み合わせて、どこまで侵入・権限拡大・重要資産への到達が可能かを検証する手法です。★４の技術検証としてIPAが示している「脆弱性診断」と同義ではありません。 一方、重要システムや取引先データを扱う環境では、脆弱性の有無だけでなく「侵害された場合に何が起きるか」を把握することが経営判断に役立ちます。そのため、制度取得とは別のリスク管理施策としてペネトレーションテストを組み合わせる価値があります。 ★４取得に向けて実施すべき主な対策 ★４では、経営の責任、サプライチェーンの防御、IT基盤の防御という観点をまたいで、対策を継続的に運用することが重要です。以下は制度要求を実務に落とし込む際の主要な確認ポイントです。 1．経営層への報告と継続的改善の仕組みを作る セキュリティ担当者だけで改善を進めるのではなく、経営層がリスクと対策状況を定期的に把握し、不備の是正や投資判断につなげる仕組みを整えます。報告内容には、重大脆弱性、インシデント、未対応リスク、取引先からの要求、改善計画の進捗などを含めると、技術課題を経営リスクとして判断しやすくなります。 2．資産・ネットワーク・外部公開面を継続的に把握する サーバー、端末、ネットワーク機器、クラウド、SaaS、外部公開IP・ドメイン、取引先との接続を一覧化し、変更時に更新される運用を作ります。特にVPN装置、リモートアクセス基盤、クラウド管理画面、公開Webシステムなどは、攻撃者が最初に狙いやすい入口です。棚卸しを年1回のイベントにせず、構成変更や新規導入のプロセスと連動させます。 3．脆弱性管理を「発見から是正完了まで」のプロセスにする 脆弱性情報の収集、影響判定、対応期限の設定、パッチ適用、例外承認、再確認までを一連の管理プロセスとして整備します。CVSSなどの技術的深刻度だけでなく、インターネット公開の有無、攻撃コードの公開状況、業務重要度、代替策の有無も加味して優先順位を決めることが実務的です。 診断で「高危険度」と判定された項目を放置するのではなく、修正担当者、期限、暫定対策、恒久対策、再診断結果まで追跡できる台帳を用意すると、実地審査でも説明しやすくなります。 4．ID・特権権限・リモートアクセスを強化する 侵入後の被害拡大を防ぐには、一般アカウントと管理者権限の分離、多要素認証、不要アカウントの削除、権限の定期棚卸しが重要です。特に外部から利用できるVPN、クラウド管理コンソール、サーバー管理画面、委託先用アカウントなどは重点的に確認します。共有アカウントや恒久的な保守権限が残っている場合は、利用目的と必要性を見直します。 5．ログ監視と検知・初動対応を整備する ★４は初期侵入の防止だけでなく、侵入後の被害拡大防止も重視します。認証ログ、VPNログ、EDR、サーバー、クラウド、ファイアウォール等から必要なログを取得し、異常を検知した場合の確認・エスカレーション手順を定めます。SOCを自社で持たない場合でも、MDRや外部SOCの活用、重要ログの集中管理など、自社規模に合った方法を選択できます。 6．インシデント対応と事業継続・復旧を実動レベルにする 手順書を作るだけでなく、ランサムウェア感染、情報漏えい、VPN侵害など具体的なシナリオで、連絡・隔離・証拠保全・取引先通知・経営判断・復旧を訓練します。バックアップについても、取得しているだけでなく、復元可能性、保管場所、アクセス権限、ランサムウェアからの保護を確認します。 7．取引先・委託先のセキュリティ管理を強化する サプライチェーン上の重要な委託先について、接続範囲、取り扱う機密情報、再委託、事故報告、契約終了時のデータ削除などを整理します。重要度に応じて要求水準を変えることで、全取引先へ一律に過剰な対応を求めることを避けながら、リスクの高い委託先を重点的に管理できます。 ★４取得に向けた具体的な準備手順 ステップ1：適用範囲と取得目的を経営層と合意する 「取引先から求められそうだから」という理由だけで始めると、対象範囲や投資判断が曖昧になります。どの事業・拠点・IT基盤を対象にするか、どの取引を守るために★４を目指すのか、経営層と合意します。取引先から具体的な要求がある場合は、期限や対象組織も確認します。 ステップ2：要求事項・評価基準とのギャップ分析を行う IPAが公表している★４要求事項・評価基準に沿って、現状を「適合」「一部適合」「未対応」に分類します。規程の有無だけでなく、証跡、設定、運用頻度、担当者の理解まで確認します。既存のISMSやPマーク、社内監査資料がある場合は流用できる部分を整理し、二重作業を減らします。 出典：IPA「要求事項・評価基準」 https://www.ipa.go.jp/security/scs/requirements-criteria.html ステップ3：技術的な事前診断を行う 評価直前に重大脆弱性が見つかると、パッチ適用やシステム更改が間に合わない可能性があります。外部公開資産を中心にプラットフォーム診断を行い、重要なWebサービスにはWebアプリケーション診断を実施します。必要に応じてペネトレーションテストを加え、攻撃経路や被害範囲を把握します。 ステップ4：不適合・不足事項を改善し、証跡を残す 発見した問題は、事業影響と攻撃可能性を踏まえて優先順位を付けます。緊急度の高い外部公開機器の脆弱性、管理者アカウント、多要素認証、サポート切れ製品などから対策し、変更記録、承認記録、再診断結果を残します。実地審査では「改善した」という説明だけでなく、その事実を確認できる証跡が重要です。 ステップ5：模擬審査と関係部署ヒアリングを行う 情報システム部門だけでなく、総務、人事、法務、調達、事業部、経営層など、要求事項に関係する部署へ模擬ヒアリングを行います。規程上の責任者と実際の担当者が異なる、契約上の事故報告期限を現場が知らないなど、部署横断の不整合を事前に発見できます。 ステップ6：指定評価機関へ評価を依頼する IPAは2026年度の評価機関・技術検証事業者の指定申請を2026年9月18日から10月26日まで受け付け、指定機関台帳への登録・公表を2026年12月下旬に予定しています。実際に★４を申請する際は、IPAが公表する最新の指定機関台帳から評価機関を確認し、評価範囲、日程、技術検証の実施体制、見積条件などを比較します。 ★４の費用と期間を左右する要因 ★４の総コストは制度の登録料だけではありません。第三者評価費、技術検証費、取得支援費、事前診断費、改善に必要な機器・ライセンス費、社内工数などを含めて考える必要があります。費用を大きく左右するのは、対象拠点数、外部公開資産数、システム数、既存統制の成熟度、改善が必要な不適合の量、診断対象、現地審査の範囲などです。 期間も同様です。すでに資産管理・権限管理・脆弱性管理・ログ監視・インシデント対応が運用されている企業であれば証跡整理が中心になりますが、サポート切れ機器の更改やネットワーク再設計が必要な場合は数か月単位の準備が必要になる可能性があります。制度上の審査日数だけで逆算せず、改善期間を含めて計画します。 社内稟議・予算申請で説明すべきポイント ★４対応の稟議では、「認証取得費」とだけ説明すると投資の必要性が伝わりにくくなります。取引継続・新規受注への影響、重要システム停止による売上影響、顧客・取引先データ漏えい時の対応負荷、サイバー保険や監査対応、インシデント復旧費用など、経営リスクと結び付けて説明することが重要です。 予算は、①ギャップ分析・支援、②事前診断、③不足対策の導入・更改、④第三者評価・技術検証、⑤不適合是正・再確認、⑥取得後の維持運用に分けると、追加費用の発生理由を整理しやすくなります。 ★４支援会社・ベンダーを選ぶポイント 制度要求と技術対策の両方を理解しているか 規程作成だけに強い会社と、脆弱性診断だけに強い会社では、★４対応全体を一貫して整理できない場合があります。要求事項の解釈、ギャップ分析、運用整備、技術診断、是正支援まで対応できるかを確認します。 第三者評価を行う主体との役割分担が明確か ★４の第三者評価はIPAの指定を受けた評価機関が実施します。コンサルティング会社へ支援を依頼する場合、取得支援と正式な第三者評価を混同しないことが重要です。見積書やRFPでは、「取得支援」「事前診断」「正式評価」「技術検証」のどこまでを誰が担当するのかを明確にします。 RFP・見積依頼時に確認したい項目 見積依頼では、対象組織・拠点、対象システム、外部公開IP・URL、クラウド利用状況、希望取得時期、既存認証、規程・台帳の有無、診断可能時間、個人情報・機密情報の取扱い、再診断の条件、成果物の内容を伝えます。情報が不足すると追加費用や日程変更につながるため、分からない項目は「未整理」として共有し、調査工程を見積もってもらう方法が現実的です。 よくある失敗と注意点 評価直前に証跡を作り始める ★４では実地審査があるため、直前に帳票だけを整えても、継続運用の実態を説明できない可能性があります。月次・四半期・年次で実施する統制は、早めに運用を開始して記録を蓄積します。 診断結果を危険度だけで処理する 診断ツールの危険度が低くても、外部公開された管理画面や重要取引先への接続点など、事業影響が大きい場合があります。技術スコアと業務影響を合わせて優先順位を決めます。 「製品を導入すれば取得できる」と考える 経済産業省は、SCS評価制度の評価基準を達成するために特定のセキュリティ製品の導入を必須としているわけではないとしています。EDR、SIEM、多要素認証などは有効な手段ですが、要求事項を満たす運用プロセスと組み合わせて初めて効果を発揮します。 Librus株式会社が提供できる支援 Librus株式会社では、SCS評価制度★４への対応を、申請書類の準備だけでなく、経営・運用・技術を横断したセキュリティ改善プロジェクトとして支援できます。適用範囲の整理、要求事項とのギャップ分析、改善計画、規程・運用整備、証跡設計、事前診断、是正支援まで、企業ごとの環境に合わせて設計します。 技術面では、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習、SOC／CSIRT構築・運用支援、インシデントレスポンス、デジタルフォレンジックなどを組み合わせることが可能です。診断結果を列挙するだけではなく、事業影響や取引先への影響を踏まえて改善の優先順位を整理し、運用までつなげます。 また、経営層、情報システム部門、調達・法務、現場部門など複数部署にまたがる論点を整理し、稟議や予算化に必要な説明材料を作る支援も可能です。対象範囲や取得時期が決まっていない段階でも、現状把握から相談できます。 よくある質問 Q1．SCS評価制度★４はいつから取得できますか？ IPAは★３・★４について2027年3月頃の運用開始を予定しています。評価機関等の指定機関台帳は2026年12月下旬に公表予定です。最新日程は申請前にIPA公式情報を確認してください。 Q2．★４を取得する前に★３の取得は必要ですか？ 必要ありません。上位段階は下位段階の要求を包含しますが、★３を事前取得していなければ★４を申請できないという関係ではありません。 Q3．★４は自己評価だけで取得できますか？ できません。★４は自己評価を記入したうえで、指定評価機関による第三者評価と技術検証を受け、評価報告書を取得してから事務局へ登録申請する仕組みです。 Q4．技術検証では何をするのですか？ IPAの最新案では、技術検証は脆弱性診断として実施されます。制度構築方針では、インターネット公開機器のうち侵入リスクが高い機器に対し、既知脆弱性の悪用など一般的な攻撃パターンを試行する例が示されています。 Q5．ペネトレーションテストを受ければ技術検証の代わりになりますか？ ペネトレーションテストと制度上の技術検証は目的・方法が同一ではありません。正式な代替可否は、申請時点の制度ルールと評価機関の指示に従う必要があります。事前のリスク把握としてペネトレーションテストを行うことは有効です。 Q6．ISMSを取得していれば★４対応は不要ですか？ 不要とはいえません。ISMSで整備した方針・リスク管理・証跡を活用できる可能性はありますが、SCS評価制度には独自の要求事項・評価基準と評価スキームがあります。ギャップ分析が必要です。 Q7．第三者評価にはどのくらいの期間がかかりますか？ 制度構築方針では文書確認、実地審査、技術検証それぞれに想定日数が示されていますが、事前準備・報告書作成・不適合是正は別です。実際の期間は対象範囲と改善量によって大きく変わるため、準備期間を含めて計画してください。 Q8．何から始めるのが最も効率的ですか？ 最初に適用範囲を決め、★４要求事項とのギャップ分析を行うことを推奨します。その後、外部公開資産や特権権限などリスクの高い領域から技術確認・改善を進め、証跡を蓄積すると手戻りを減らせます。 まとめ｜SCS評価制度★４は「運用実態」と「技術的な有効性」まで整える SCS評価制度★４は、サプライチェーン企業が標準的に目指すべきセキュリティ水準として、組織ガバナンス、取引先管理、システム防御・検知、インシデント対応、復旧を包括的に確認する制度です。★４では、評価機関による第三者評価に加え、実地審査と技術検証が行われるため、文書だけでなく実際の運用と技術的な安全性を説明できる状態が必要です。 準備では、適用範囲を定め、要求事項とのギャップを把握し、外部公開資産や脆弱性管理、ID・権限管理、ログ監視、インシデント対応、取引先管理を重点的に改善します。Webアプリケーション診断やプラットフォーム診断を事前に実施し、必要に応じてペネトレーションテストで侵害時の影響まで確認しておくことで、評価直前の大きな手戻りを抑えやすくなります。 2027年3月頃の制度開始に向け、評価機関の指定や運用詳細は今後も更新されます。制度開始を待ってから準備するのではなく、いま公表されている要求事項・評価基準を基に、自社の不足を整理して改善を始めることが現実的です。 SCS評価制度★４への対応を、対象範囲の整理から相談できます Librus株式会社では、「★４を目指すべきか判断したい」「第三者評価に向けて何が不足しているか確認したい」「技術検証の前に外部公開資産を診断したい」といった初期段階からご相談いただけます。対象範囲や具体的な実施方法が決まっていなくても、事業・取引先・IT環境を整理し、要求事項とのギャップと優先順位を可視化することで、必要な対策、予算、スケジュールを具体化できます。 制度対応、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、改善支援、SOC／CSIRT支援まで一気通貫で検討できるため、制度取得だけで終わらず、実際のセキュリティ水準向上につなげることが可能です。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

SCS評価制度の★3取得に必要な対策とは？要求事項と準備方法を解説

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★3は、一般的なサイバー攻撃に対して、企業が最低限実装すべき基礎的な組織対策とシステム防御策を備えていることを示すための段階です。2026年10月時点では、★3・★4は2027年3月頃の運用開始が予定されています。 結論から言えば、★3取得に向けて最初に行うべきことは、セキュリティ製品を追加購入することではありません。自社のIT基盤と業務範囲を整理し、公開されている★3要求事項・評価基準とのギャップを確認し、不足する対策を実装して、その実施を説明できる証跡をそろえることが重要です。 また、★3は単なる自己チェックではありません。取得希望企業が自己評価を行い、所定の要件を満たすセキュリティ専門家による確認・助言と署名を受け、さらに経営層による自己適合宣誓を含めて申請する仕組みです。したがって、情報システム部門だけで完結させるのではなく、経営層、管理部門、現場部門を含めた準備が必要になります。 この記事で分かること ・SCS評価制度の★3が求めるセキュリティ水準 ・★3取得までの評価スキームと専門家確認の役割 ・企業が優先して整備したい組織面・技術面の対策 ・Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストの使い分け ・申請前にそろえておきたい資料・証跡と社内体制 ・準備期間や費用を左右する要因、支援会社の選び方 SCS評価制度の★3とは SCS評価制度は、取引先ごとに異なっていたセキュリティ確認を共通化し、サプライチェーンに参加する企業の対策状況を分かりやすく可視化することを目的とした制度です。制度は任意であり、取得しなければ一律に商取引が禁止されるものではありません。ただし、発注企業が契約や調達の中で、取引先に一定の★取得や同等水準の対策を求める活用が想定されています。 ★3は、広く認知された脆弱性などを悪用する一般的なサイバー攻撃への対応を想定した水準です。経済産業省は、★3を「全てのサプライチェーン企業が最低限実装すべきセキュリティ対策」と位置付け、基礎的な組織的対策とシステム防御策を中心に実施する段階と説明しています。 出典：IPA「SCS評価制度の詳細情報」https://www.ipa.go.jp/security/scs/details.html 出典：経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」https://www.meti.go.jp/policy/netsecurity/scs.html ★3は「専門家確認付き自己評価」 ★3の評価主体は取得希望企業自身です。ただし、企業が記入した自己評価について、社内外のセキュリティ専門家が内容を確認し、必要に応じて修正を含む助言を行います。最終的に専門家が提出内容を了承した場合に署名し、企業は経営層による自己適合宣誓を含めて事務局へ提出します。 ここで注意したいのは、単に「社内の情報システム担当者が確認した」だけでは足りない点です。IPAが示す専門家には、情報処理安全確保支援士、公認情報セキュリティ監査人、CISSP、CISA、CISM、ISO27001主任審査員などの資格保持に加え、制度上必要な研修・登録要件が設けられています。 ★3取得には全ての要求事項・評価基準への適合が必要 IPAのFAQでは、★3・★4の取得には、それぞれで定められた全ての要求事項・評価基準を満たす必要があると明示されています。「重要な項目だけできていればよい」「一定点数を超えれば取得できる」という考え方ではありません。 そのため、申請直前にチェックリストを埋めるよりも、まず現状を棚卸しし、不適合項目に対して担当者・期限・予算を設定した改善計画を作る方が現実的です。特に従業員100～1,000名規模では、拠点、クラウドサービス、端末、委託先、部門ごとの例外運用が増えやすく、規程だけ整っていて実運用が追いついていないケースに注意が必要です。 出典：IPA「よくある質問」https://www.ipa.go.jp/security/scs/faq.html ★3取得で企業が整備したい主な対策 ★3の具体的な判定はIPAが公開する要求事項・評価基準に沿って行う必要があります。以下は、公開されている制度方針と一般的な実務を踏まえ、企業が準備時に優先して確認したい領域を整理したものです。実際の申請では必ず最新の公式要求事項・評価基準と照合してください。 1．経営責任とセキュリティ体制を明確にする 最初に必要なのは、誰がセキュリティ対策を決定し、誰が実行し、インシデント時に誰が判断するかを明確にすることです。情報セキュリティ方針、責任者、担当部門、報告経路が曖昧な状態では、技術対策を導入していても継続的な運用につながりません。 経営層は、★3を単なるIT部門の認証取得業務として扱うのではなく、取引継続、顧客情報保護、事業停止リスクの低減に関わる経営課題として位置付ける必要があります。最終申請には経営層による自己適合宣誓が含まれるため、対策状況を経営会議等で説明できる状態にしておくことが望まれます。 2．対象となるIT資産を把握する 対策の前提は、守る対象を把握することです。PCやサーバだけではなく、クラウドサービス、ネットワーク機器、VPN、アカウント、外部公開システム、管理者端末なども含めて棚卸しします。誰が管理しているか、どの業務で使われているか、インターネットからアクセス可能かといった情報も整理すると、その後の優先順位付けがしやすくなります。 SCS評価制度は企業等のIT基盤を主な対象として設計されています。製造設備のOTシステムや、委託元へ提供する製品自体は直接の評価対象とは異なる整理が示されているため、自社の業務範囲と制度対象を混同しないことも重要です。 3．アカウントとアクセス権限を管理する サイバー攻撃では、盗まれたID・パスワードや過剰な管理者権限が侵入・被害拡大の起点になります。入社・異動・退職時のアカウント管理、管理者権限の限定、不要アカウントの削除、認証強化、リモートアクセスの制御などを確認します。 特に、退職者のアカウントが残っている、共有IDを複数人で使っている、管理者権限が日常業務用PCに付与されているといった運用は、ルールと実態の両面から見直す必要があります。規程だけではなく、アカウント一覧や棚卸し記録を残すことで、実施状況を説明しやすくなります。 4．脆弱性管理とパッチ適用を仕組み化する ★3が想定する脅威には、広く認知された脆弱性を悪用する一般的な攻撃が含まれます。そのため、OS、ミドルウェア、ネットワーク機器、VPN、Webサーバなどの脆弱性情報を収集し、影響を判断し、更新プログラムや回避策を適用する流れを定めておくことが重要です。 実務では、「重大な脆弱性が公表されたら誰が確認するか」「何日以内に対応方針を決めるか」「業務都合でパッチを当てられない場合に代替策をどう承認するか」まで決めておくと、属人的な対応を減らせます。 5．マルウェア対策、バックアップ、ログ管理を確認する ランサムウェアや不正プログラムへの備えとして、端末・サーバの防御、メールやWeb経由の感染対策、バックアップ、復旧手順を確認します。バックアップは取得しているだけでは不十分で、復元できることを定期的に確認することが重要です。 また、インシデント発生時には、いつ、どの端末から、どのアカウントで何が行われたかを追跡できるログが必要になります。すべてのログを長期間保存すればよいわけではありませんが、重要システムや管理者操作を中心に、取得対象、保管期間、確認方法を定めることが実務上有効です。 6．インシデント対応手順と連絡体制を整える セキュリティ対策は、侵入を防ぐ施策だけでは完結しません。感染や不正アクセスが疑われた場合に、初動判断、端末隔離、経営報告、取引先への連絡、外部専門家への相談をどのように行うかを事前に決めておく必要があります。 例えば、取引先から預かったデータを扱うシステムで不審な通信が発生した場合、情報システム部門だけで調査を続けると、報告判断が遅れることがあります。法務、管理、広報、経営層を含む連絡経路と、重大度に応じたエスカレーション基準を用意しておくと、事業継続と信用毀損の双方に対応しやすくなります。 7．従業員教育と委託先管理を運用に組み込む フィッシングメール、パスワードの使い回し、機密情報の誤送信など、人を起点としたリスクは技術製品だけでは抑えきれません。入社時教育だけでなく、定期的な教育、注意喚起、必要に応じた標的型メール訓練などを実施し、受講記録を残すことが有効です。 また、クラウド事業者、保守会社、業務委託先など、自社のシステムや情報へアクセスする第三者についても、契約・権限・セキュリティ条件を確認します。取引先管理を「契約書を締結したら終わり」にせず、重要度に応じて継続的に見直すことが重要です。 Webアプリケーション診断・プラットフォーム診断・ペネトレーションテストは必要か SCS評価制度は、特定のセキュリティ製品やサービスの導入を一律に義務付ける制度ではありません。そのため、すべての★3取得企業に同じ内容の脆弱性診断やペネトレーションテストが必須になる、と単純に考えるべきではありません。自社のシステム構成、公開範囲、リスク、要求事項への適合状況を踏まえて必要性を判断します。 Webアプリケーション診断 顧客向けWebサービス、会員サイト、管理画面、APIなどを公開している場合は、SQLインジェクション、クロスサイトスクリプティング、認証・認可の不備などを確認するWebアプリケーション診断が有効です。自社開発だけでなく、外部ベンダーが開発したシステムでも、運用責任を自社が負う場合は診断範囲を検討する価値があります。 プラットフォーム診断 インターネット公開サーバ、VPN装置、ファイアウォール、クラウド上の仮想マシンなどについて、不要なポート、古いソフトウェア、危険な設定、既知の脆弱性を確認するのがプラットフォーム診断です。資産棚卸しと組み合わせることで、外部から攻撃可能な箇所を効率的に把握できます。 ペネトレーションテスト ペネトレーションテストは、個別の脆弱性の有無だけでなく、複数の弱点を組み合わせた場合に実際に重要情報や管理権限まで到達できるかを検証する手法です。★3取得のために一律実施するというより、重要システムの事業リスクが高い場合や、単純な診断では把握しにくい攻撃経路を確認したい場合に適しています。 ★3取得に向けた準備手順 ステップ1：対象範囲と責任者を決める まず、対象となる組織、拠点、IT基盤、クラウド環境、委託関係を整理し、プロジェクト責任者を決めます。営業部門や製造部門が独自に利用しているクラウドサービスなど、情報システム部門が把握していないITがないかも確認します。 ステップ2：公式要求事項とのギャップ分析を行う IPAが公開する★3・★4要求事項・評価基準を用いて、現状が適合しているかを確認します。「規程あり」「運用あり」「証跡あり」を分けて評価すると、不足が明確になります。例えば、パッチ適用ルールがあっても実施記録が残っていなければ、証明可能性の面で課題が残ります。 出典：IPA「要求事項・評価基準」https://www.ipa.go.jp/security/scs/requirements-criteria.html ステップ3：不足対策をリスクベースで改善する ギャップが見つかったら、すべてを同時に実施するのではなく、外部公開システム、管理者権限、重要データ、ランサムウェア対策など、事故時の影響が大きい領域から着手します。改善内容は、担当、期限、必要予算、完了条件を設定し、経営層が進捗を確認できる形にします。 ステップ4：証跡を整備する 自己評価を説明するためには、「実施している」と口頭で説明するだけでなく、実施状況を裏付ける資料が必要です。規程、組織図、資産台帳、アカウント一覧、パッチ適用記録、バックアップ記録、教育記録、インシデント対応手順、委託先管理記録などを整理します。 証跡には個人情報や機密情報が含まれることがあります。外部専門家へ共有する場合は、NDA、アクセス制御、保存場所、削除方法を事前に確認し、必要以上の情報を渡さない運用にします。 ステップ5：セキュリティ専門家による確認を受ける 自己評価がまとまった段階で、制度要件を満たすセキュリティ専門家に確認を依頼します。申請直前に初めて依頼すると、大きな不備が見つかった際に改善期間を確保できません。早い段階でギャップ分析やプレチェックを受け、最終確認までの修正期間を確保する方法が効率的です。 ステップ6：経営層が適合状況を確認し、申請準備を行う 最終的には経営層による自己適合宣誓が必要です。経営層には、技術的な項目をそのまま説明するのではなく、未対応事項の有無、残存リスク、取引先への影響、取得・維持コスト、次年度の改善計画をまとめて説明すると判断しやすくなります。 準備期間と費用を左右する要因 ★3取得までの準備期間は、企業規模だけでは決まりません。ISMSやPマーク等を運用していて資産管理・規程・教育・委託先管理の基盤が整っている企業は、既存資料を活用できる可能性があります。一方、拠点やクラウドサービスが多い、アカウント管理が部門ごとに分かれている、脆弱性管理が属人化している場合は、改善に時間を要します。 費用も同様で、申請・登録に関する費用だけでなく、専門家確認、コンサルティング、脆弱性診断、製品・サービス導入、社内工数、規程改定などを含めて考える必要があります。最初から大規模な製品導入を予算化するのではなく、ギャップ分析を行って必要な対策だけを見極めることで、過剰投資を避けやすくなります。 社内稟議で説明すべきポイント SCS評価制度への対応を稟議に上げる際は、「認証を取るための費用」とだけ説明すると、経営上の優先度が伝わりにくくなります。取引先からのセキュリティ要求への対応、サイバー事故による事業停止や信用毀損の低減、既存統制の標準化、将来の★4取得への基盤整備といった効果を整理すると、投資目的が明確になります。 特に、主要顧客が自社のサプライチェーン管理を強化している場合は、取引先アンケートや監査対応にかかる工数削減、一定水準を客観的に説明できることも経営上のメリットになり得ます。 支援会社を選ぶときのチェックポイント 外部支援を利用する場合は、チェックリストの記入代行だけでなく、現状分析、技術対策、証跡整備、専門家確認への準備、取得後の改善まで一貫して支援できるかを確認します。 見積依頼やRFPでは、支援範囲、対象拠点・システム、成果物、打合せ回数、脆弱性診断の有無、専門家確認との関係、追加費用が発生する条件、機密情報の取扱いを明記すると比較しやすくなります。また、制度上の専門家確認を行える人材と、コンサルティングや技術診断を担当する人材の役割分担も確認しておくと安心です。 よくある失敗と注意点 製品導入から始めてしまう SCS評価制度は、特定製品の導入を必須とする制度ではありません。現状を確認せずにEDR、資産管理、ログ管理製品などを先に購入すると、既存機能との重複や運用負荷の増加につながることがあります。まず要求事項とのギャップを把握し、運用改善で対応できるものと、技術投資が必要なものを分けることが重要です。 規程だけ整えて実運用を確認しない ルール上は定期棚卸しを行うことになっていても、実際には半年以上実施されていない、といった差異は珍しくありません。専門家確認を見据えるなら、規程、実運用、証跡の3点が一致しているかを確認する必要があります。 申請直前まで専門家に相談しない 専門家確認で大きな不足が判明すると、技術対策の導入や社内ルールの変更に時間がかかります。制度開始後すぐの取得を目指す場合は、正式申請前に現状評価と改善計画を進めておく方が現実的です。 Librus株式会社が提供できるSCS評価制度★3支援 Librus株式会社では、SCS評価制度への対応を、チェックリスト作成だけで終わらせず、企業ごとの環境と事業上の重要性を踏まえて支援します。現状把握、要求事項とのギャップ分析、改善計画策定、規程・運用整備、脆弱性診断、ペネトレーションテスト、教育、SOC／CSIRT、インシデント対応体制などを必要に応じて組み合わせることが可能です。 また、経営層に必要な判断事項と、情報システム部門が実行すべき技術対策を切り分け、取得のためだけではなく、取引先から説明を求められた際にも継続的に運用できる体制づくりを重視します。既にISMSやPマーク等の仕組みがある場合は、既存の規程・証跡を活かしながら、重複作業を抑える設計を検討します。 よくある質問 Q1．★3は中小企業だけが対象ですか？ いいえ。SCS評価制度は業種や事業規模を問わず幅広い事業者を対象とする設計です。従業員100～1,000名規模の企業も対象になり得ます。 Q2．★3を取得しないと取引できなくなりますか？ 制度自体は任意です。一律に取引が禁止されるものではありません。ただし、個別の取引契約や調達条件で、発注企業が一定の★取得や同等水準の対策を求める可能性はあります。 Q3．★3は自己評価だけで取得できますか？ 自己評価だけでは完結しません。所定の要件を満たすセキュリティ専門家による確認・助言と署名、経営層による自己適合宣誓が必要です。 Q4．すべての要求事項を満たす必要がありますか？ IPAは、★3取得には★3で定められたすべての要求事項・評価基準を満たす必要があると説明しています。 Q5．EDRや資産管理ツールは必須ですか？ 特定のセキュリティ製品を一律に導入することは求められていません。自社の規模、システム構成、既存対策を踏まえ、要求事項を満たす方法を選択します。 Q6．脆弱性診断は必須ですか？ すべての企業に同一内容の診断が一律必須とは限りません。ただし、外部公開システムの脆弱性を把握し改善することは、一般的なサイバー攻撃への備えとして有効です。自社の対象範囲と要求事項に照らして必要性を判断します。 Q7．ISMSやPマークがあれば★3対応は不要ですか？ 不要とはいえません。既存認証の規程や証跡を活用できる可能性はありますが、SCS評価制度独自の要求事項・評価基準との照合が必要です。 Q8．★3を取得してからでないと★4を申請できませんか？ いいえ。IPAは、上位段階が下位段階の事項を包含するものの、★3を事前取得しなければ★4を取得できない関係ではないと説明しています。 まとめ｜★3取得は「現状把握→改善→証跡→専門家確認」の順で進める SCS評価制度の★3は、一般的なサイバー攻撃に備えるために、すべてのサプライチェーン企業が最低限実装すべきセキュリティ対策を可視化する段階です。取得には公開された要求事項・評価基準をすべて満たし、専門家確認付き自己評価と経営層の自己適合宣誓を行う必要があります。 重要なのは、申請書作成から始めるのではなく、自社のIT基盤を把握し、公式要求事項とのギャップを確認し、必要な対策と証跡を整えることです。Webアプリケーション診断やプラットフォーム診断、ペネトレーションテストも、目的と対象を明確にしたうえで活用すれば、技術的な弱点の把握と改善に役立ちます。 2027年3月頃の制度開始を見据える場合、制度開始後に初めて準備するよりも、現在の対策状況を把握し、時間を要する改善から先に進めておく方が、予算・人員・稟議の面でも進めやすくなります。 SCS評価制度★3の準備段階からご相談いただけます 「どこまでが対象になるのか分からない」「要求事項とのギャップを自社だけで判断しにくい」「既存のISMSやPマークの資料をどこまで活用できるか確認したい」といった段階でも、Librus株式会社へご相談いただけます。 Librus株式会社では、対象範囲の整理、現状評価、改善計画、規程・証跡整備、技術診断、取得に向けたプロジェクト推進まで、企業ごとの環境に合わせて支援します。最初から実施方法が決まっていなくても、必要な対策と優先順位を整理することで、過剰な投資を避けながら、取引先への説明や将来の★4対応も見据えたロードマップを検討できます。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 105-0004東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム https://librus.co.jp/contact

VIEW MORE