SCS取得までのロードマップ｜準備から登録までの全工程

サプライチェーン強化に向けたセキュリティ対策評価制度を、適用範囲の決定、自己評価、改善、専門家確認・第三者評価、登録まで時系列で解説します。 SCS評価制度の取得は、申請書を整えるだけの作業ではありません。最初に「どの組織・拠点・業務・情報システムを評価対象にするか」を決め、要求事項ごとに証拠を集め、不足を改善し、★3では登録されたセキュリティ専門家の確認、★4では指定評価機関による第三者評価と技術検証を経て、事務局へ登録を申請する流れです。 実務上の成否を分けるのは、評価直前の対症療法ではなく、適用範囲と責任者を早期に確定し、規程・設定・運用記録が一致する状態をつくることです。本稿では、従業員100～1,000名程度の企業を想定し、経営判断、社内稟議、情報システム部門の準備、Webアプリケーション診断やプラットフォーム診断、ペネトレーションテストの位置付けまで説明します。 この記事で分かること この記事を読むと、SCS評価制度の★3と★4の違い、自社に適した段階の考え方、準備から登録までの順序、各工程で必要になる資料、期間と費用を左右する要因、外部支援会社を選ぶ際の確認点が分かります。なお、IPAは★3・★4を2027年3月頃に運用開始する予定とし、申請方法や取得ガイドは2026年10月頃、申請・登録費用は今後公開予定と案内しています。以下のロードマップには、公表済みの制度要件と、企業が先行して進められる実務準備を区別して記載します。 出典：IPA「SCS評価制度の詳細情報」「よくある質問」制度詳細／FAQ SCS評価制度とは――★3と★4の違い サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、取引関係にある企業のセキュリティ対策を共通の「★」で可視化し、委託元と委託先の双方が適切な対策水準を判断しやすくする制度です。経済産業省と内閣官房国家サイバー統括室の監督のもと、IPAが運営します。 ★3は、一般的なサイバー脅威に対処し得る水準です。取得希望組織が自己評価し、SCS評価制度に登録されたセキュリティ専門家が内容を確認・助言して署名します。最後に経営層が自己適合宣誓を行い、事務局へ提出します。 ★4は、初期侵入の防御だけでなく、侵入後の被害拡大防止、取引先のデータ・システム保護、サプライチェーン上の役割に応じた強靭化までを求める水準です。指定評価機関による第三者評価と、指定技術検証事業者による技術検証が必要です。★3を先に取得しなければ★4を申請できない仕組みではありませんが、★4は★3以下の要求を包括します。 したがって、取引先から最低限の共通水準を求められる企業では★3が出発点になりやすく、重要情報や基幹業務を預かる受託事業者、広範な接続権限を持つIT事業者、事業停止時の波及が大きい企業では★4を検討する余地があります。最終判断は、取引先要求、扱う情報、接続形態、停止時の影響、投資可能額を合わせて行います。 なぜ今、取得準備が必要なのか SCS評価制度は、単なる情報システム部門の認証対応ではなく、取引継続と受注競争力に関わる経営課題になり得ます。発注者は、委託先ごとに異なる質問票を作り続けるより、共通評価を利用する方が確認負担を抑えやすくなります。委託先にとっても、複数顧客へ同じ説明を繰り返す負担を減らせる可能性があります。 一方、準備を後回しにすると、重要案件の入札や更新時に短期間で証拠提出を求められ、場当たり的な規程作成や高額な緊急対応につながります。さらに、ランサムウェアによる操業停止、委託先アカウントを踏み台にした侵入、Webアプリケーションの脆弱性を起点とする情報漏えいが起きれば、復旧費だけでなく、代替調達、顧客説明、契約上の責任、信用毀損まで影響が広がります。 今から着手すべき理由は、制度開始まで待たずとも、資産台帳、アカウント管理、バックアップ、ログ、インシデント対応、委託先管理などの基礎整備は無駄になりにくいからです。正式な様式が公開された後に差分を調整できるよう、証拠を残す運用を先行させることが合理的です。 対象となる企業・システム・場面 SCS評価制度は、特定業種だけを対象とする制度ではありません。特に検討優先度が高いのは、大手企業や公共分野のサプライチェーンに参加する企業、顧客データや設計情報を扱う企業、クラウド運用・システム保守・BPOを受託する企業、工場や物流を止めると取引先へ影響が波及する企業です。従業員100～1,000名規模では、複数拠点、子会社、SaaS、オンプレミス、外部委託が混在し、管理主体が曖昧になりやすいため、適用範囲の設計が重要です。 対象は「会社全体」と決め打ちする必要はありません。ただし、都合の悪いシステムだけを除外すると、事業や情報の流れと評価範囲が矛盾します。顧客へ提供するサービス、扱う重要情報、利用する端末・ネットワーク・クラウド、運用する部門と委託先を一本の業務フローとして捉え、境界と除外理由を説明できる状態にします。 SCS取得までのロードマップ――準備から登録まで 工程0：経営方針と目標段階を決める 最初に経営層が決めるのは、取得目的、目標段階、責任者、予算、期限です。「顧客から求められたから」だけでなく、どの取引の維持・拡大に効くのか、停止するとどの事業に損失が出るのかを明確にします。CISOや情報システム責任者だけに任せず、事業部門、法務、総務、人事、購買、内部監査を含む横断体制にすると、規程と現場運用の乖離を減らせます。 社内稟議では、制度の概要、対象取引、目標段階、適用範囲案、現状とのギャップ、概算費用、必要な社内工数、未対応時の受注・事業継続リスクを示します。制度の申請費用が未公表である点は、外部支援費・製品導入費・評価費と分け、「確定後に追加稟議」として扱うのが安全です。 工程1：適用範囲を決定する 適用範囲は、組織図だけでは決められません。対象サービス、顧客、契約、拠点、従業員、端末、ネットワーク、クラウド、アプリケーション、データ、委託先を関連付けます。たとえば顧客向けWebサービスを対象にするなら、公開Webアプリケーションだけでなく、認証基盤、運用端末、ソースコード管理、監視、バックアップ、保守委託先まで確認対象に含み得ます。 この段階で作るべき資料は、適用範囲記述書、組織図、業務フロー、ネットワーク構成図、システム・資産台帳、データフロー、クラウド／SaaS一覧、委託先一覧、責任分担表です。除外項目には「関係がない」という結論だけでなく、情報や接続が分離されている根拠を残します。 工程2：要求事項に沿って自己評価する 次に、★3または★4の要求事項・評価基準ごとに、適合・不適合・確認中を判定します。重要なのは、規程の存在だけで適合としないことです。たとえばアカウント棚卸しを年1回行う規程があっても、実施記録がなければ運用実態を説明できません。判定欄には、根拠資料名、保管場所、対象範囲、責任者、最終実施日を紐付けます。 確認資料には、情報セキュリティ方針、リスクアセスメント、アクセス権限一覧、パッチ適用記録、バックアップ・復元試験記録、ログ監視記録、教育・訓練記録、インシデント対応手順、BCP、委託先契約・評価記録などが含まれます。個人情報や機密情報を外部専門家・評価機関へ提示する場合は、秘密保持契約、閲覧権限、保存期間、返却・削除方法、再委託条件を事前に合意します。 工程3：ギャップを優先順位付けし、改善する 不適合を一律に処理すると、予算と人員が足りなくなります。優先順位は、①取得上の必須性、②攻撃される可能性、③影響の大きさ、④短期で実施できるか、⑤他の対策への波及効果で付けます。インターネット公開資産の重大な脆弱性、多要素認証がない特権アカウント、復元できるか未確認のバックアップ、連絡網のないインシデント対応は、一般に優先度が高い項目です。 改善は「製品導入」で終わりません。責任者、手順、例外承認、記録様式、確認頻度まで決め、一定期間の運用証跡を残します。経営層には、件数ではなく、重大リスクの残存状況、期限超過、追加予算、受注・停止リスクへの影響を報告します。 工程4：必要な技術検証を行う ★4では文書確認と実地審査に加え、技術検証が求められます。具体的な対象は適用範囲とリスクに応じて設計されます。公開WebサービスにはWebアプリケーション診断、サーバー・ネットワーク機器・クラウド基盤にはプラットフォーム診断が候補です。重要システムでは、攻撃者の視点で侵入可能性と到達範囲を確かめるペネトレーションテストが有効な場合があります。 脆弱性診断は既知の弱点を広く確認する手法、ペネトレーションテストは複数の弱点や設定を組み合わせ、現実にどこまで侵入・権限拡大できるかを検証する手法です。目的が異なるため、名称だけで選ばず、評価基準、資産の重要度、停止許容度に合わせます。実施前には対象IP・URL、環境、本番影響、禁止行為、実施時間、緊急連絡先、取得データの扱いを合意してください。 工程5：★3の専門家確認、または★4の第三者評価を受ける ★3では、自己評価結果をSCS評価制度の登録セキュリティ専門家が確認し、必要に応じて修正助言を行います。専門家が最終提出内容を了承した場合に署名し、経営層が自己適合宣誓を行います。支援を受けたコンサルタントが、そのまま制度上の確認者になれるとは限りません。登録要件と独立性の扱いを確認する必要があります。 ★4では、取得希望組織が指定評価機関へ検証・評価を依頼し、文書、実地、技術面の確認を受けます。評価機関から評価報告書が提供された後、取得希望組織が事務局へ登録を申請します。評価機関や技術検証事業者は公表された指定先から選定し、事前支援と正式評価の役割分担、利害関係、再評価条件を契約前に確認します。 工程6：是正、経営層の承認、登録申請を行う 確認・評価で指摘が出た場合は、原因、影響範囲、暫定措置、恒久措置、担当者、期限、再確認方法を是正計画にまとめます。単に設定を変更するだけでなく、同種システムへの横展開と手順改訂まで行うことが重要です。 ★3は、専門家署名を含む自己評価結果と経営層の自己適合宣誓を事務局へ提出します。★4は、評価機関の評価報告書を踏まえて登録を申請します。事務局は申請内容に問題がなければ台帳へ登録し、公表します。申請様式、提出方法、費用は最新のIPA公表資料で確認してください。 工程7：登録後の運用を定着させる 登録はゴールではありません。人事異動、システム更改、M&A、クラウド移行、新規委託先の追加で、評価時の状態は変わります。少なくとも、資産台帳と権限の定期見直し、脆弱性管理、バックアップ復元試験、インシデント対応訓練、委託先評価、経営報告を年間計画に組み込みます。重大な構成変更や新サービス開始時には、臨時のリスク評価と再診断を行います。 実施期間と費用を左右する要因 準備期間は一律ではありません。公的制度としての標準所要期間が公表されていない段階で、確定的な月数を示すのは適切ではありません。実務上は、限定された範囲で管理が整っている企業ほど短く、複数拠点・子会社・レガシーシステム・多数の委託先を含む企業ほど長くなります。正式評価の予約や是正期間も考慮し、取引先の期限から逆算して余裕を持たせます。 費用を左右する主な要因は、目標段階、適用範囲の広さ、拠点数、対象システム数、現状の成熟度、規程整備の量、技術検証の深さ、診断対象数、現地訪問、再評価の回数です。見積りでは、①現状評価、②改善支援、③製品・設定変更、④脆弱性診断等、⑤制度上の専門家確認または第三者評価、⑥申請・登録費用を分けると、比較しやすくなります。 支援会社・評価機関の選び方 支援会社には、SCSの要求事項を説明する力だけでなく、技術・規程・運用・経営報告をつなぐ実装力が必要です。RFPや見積依頼では、対象段階、適用範囲案、対象拠点・システム、希望時期、既存認証、成果物、会議頻度、機密情報の扱いを提示します。 確認すべき成果物は、適用範囲記述書、要求事項別ギャップ一覧、証拠台帳、改善ロードマップ、規程・手順案、技術検証報告書、是正管理表、経営報告資料です。さらに、担当者の資格・経験、診断とコンサルティングの連携、再診断条件、報告書の具体性、緊急時の対応力を確認します。★3の制度上の専門家確認、★4の正式な第三者評価については、IPAに登録・指定された主体かを必ず確認してください。 よくある失敗と注意点 適用範囲を狭くしすぎる 評価負担を減らすために範囲を狭めても、対象事業と認証基盤や運用端末がつながっていれば、説明が成立しません。最初にデータと接続の流れを可視化し、境界を技術的・契約的に裏付けます。 規程だけを短期間で作る テンプレートを整えても、アクセス権限の棚卸しや復元試験の記録がなければ、実施を証明できません。評価日から逆算して、運用記録が蓄積される期間を確保します。 診断を一度行えば十分と考える 診断は重要ですが、対象外資産、認証後の攻撃経路、運用ミス、委託先管理、初動対応までは自動的に解決しません。診断結果をリスク台帳と改善計画へ戻し、再診断と継続監視につなげます。 正式評価と取得支援を混同する 取得準備の支援者と、制度上の確認者・評価機関は役割が異なります。利益相反や独立性に関する制度規程、契約上の責任分界を確認し、誰が何を保証するのかを明文化します。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度への対応を、チェックリスト記入だけで終わらせず、適用範囲の設計、ギャップ分析、規程・体制整備、改善実装、技術検証、運用定着まで一気通貫で支援します。経営層には取引・財務・事業継続の観点で判断材料を整理し、情報システム部門には実装可能な優先順位と証拠管理の仕組みを提示します。 Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築、インシデントレスポンス、デジタルフォレンジック、教育・訓練を組み合わせられるため、評価で見つかった課題を別々の会社へ引き継ぐ負担を抑えられます。大企業から中堅・中小企業まで、既存のISMS、顧客監査、M&A、IPO準備との重複も整理し、各社の環境に合わせたロードマップを設計します。 なお、正式な★3確認や★4評価が必要な場面では、制度上の登録・指定状況と独立性要件を確認したうえで、適切な役割分担をご案内します。 SCS評価制度についてよくある質問 SCS評価制度はいつ始まりますか？ IPAは、★3・★4を2027年3月頃に運用開始する予定と公表しています。申請方法は2026年10月頃に公開予定です。最新情報はIPA公式サイトで確認してください。 ★3を取らないと★4を取得できませんか？ いいえ。IPAは、★3を事前取得しなければ★4を取得できない関係ではないと説明しています。ただし、★4は下位段階の要求を包括します。 ★3は自己評価だけで取得できますか？ 自己評価だけではなく、登録セキュリティ専門家の確認・助言と署名、経営層による自己適合宣誓、事務局への提出が必要です。 ★4では何が行われますか？ 指定評価機関による文書確認・実地審査と、指定技術検証事業者による技術検証が行われます。その後、評価報告書を踏まえて事務局へ登録申請します。 Webアプリケーション診断は必ず必要ですか？ 一律に必須と断定できません。適用範囲、評価段階、対象システムとリスクに応じて、技術検証の内容を設計します。公開Webサービスが重要資産であれば有力な検証手段です。 取得準備では何から始めるべきですか？ 取得目的と目標段階を決め、対象サービス・拠点・システム・データ・委託先を含む適用範囲を整理します。その後、要求事項別の自己評価と証拠収集へ進みます。 申請・登録費用はいくらですか？ 2026年9月4日時点で、IPAは今後公開予定としています。準備支援、製品導入、診断、正式評価、申請・登録を分けて予算化してください。 ISMSを取得済みでも追加対応は必要ですか？ 既存の規程や監査記録を活用できる可能性はありますが、SCSの適用範囲と全要求事項への適合を別途確認する必要があります。認証保有だけで自動的にSCS登録となるわけではありません。 まとめ――SCS評価制度は「範囲・証拠・改善」の順で進める サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の取得準備は、目標段階を決め、適用範囲を定義し、要求事項に沿って自己評価し、不足を改善することから始まります。★3は専門家確認付き自己評価、★4は第三者評価と技術検証を経て、事務局への登録申請へ進みます。 最も重要なのは、評価書類と実際の運用を一致させることです。資産、権限、バックアップ、ログ、インシデント対応、委託先管理の記録を継続的に残せる体制を整えれば、SCS対応は取引先説明のためだけでなく、自社の事業継続力を高める活動になります。 SCS取得準備を、対象範囲の整理から相談したい企業へ 「★3と★4のどちらを目指すべきか」「どの拠点やシステムを含めるべきか」「顧客監査やISMSの資料をどこまで流用できるか」が未確定でもご相談いただけます。Librus株式会社では、初期ヒアリングと現状資料の確認を通じて、優先課題、必要な技術検証、社内体制、予算化の考え方を整理します。早い段階で論点を可視化することで、不要な製品導入や評価直前の手戻りを抑え、現実的な取得計画を立てやすくなります。 主な公的情報・一次情報 経済産業省「SCS評価制度に関する制度構築方針」 IPA「SCS評価制度」公式サイト IPA「SCS評価制度の詳細情報」 IPA「要求事項・評価基準」 IPA「よくある質問」 IPA「制度規程・委員会」 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015https://librus.co.jp/contact/ 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。

VIEW MORE

SCS評価制度★4取得実務｜第三者評価・技術検証の備え方

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★4取得では、規程を整えるだけでは足りません。評価機関による第三者評価に加え、実地審査と技術検証を通じて、定めた対策が現場とシステムで実際に機能していることを示す必要があります。準備の要点は、①適用範囲を経営判断として確定する、②要求事項と証跡を対応付ける、③サンプリングされても説明できる運用を全社に定着させる、④Webアプリケーション診断やプラットフォーム診断等を是正・再確認まで完結させる、の4点です。 本稿は2026年9月4日時点の公表情報を基にしています。IPAによれば、★3・★4は2027年3月頃の運用開始予定です。申請方法、解説書、取得ガイド、申請・登録費用など、公表前または更新予定の事項があります。実際の申請時には必ず最新版の制度文書をご確認ください。 この記事で分かること ★4の評価スキーム、実地審査で確認され得る内容、サンプリングへの備え、技術検証の対象範囲、指摘後の是正対応を一連の実務として理解できます。また、従業員100～1,000名規模の企業が、どの部署を巻き込み、どの資料を揃え、どのように予算とスケジュールを組むべきかを整理します。 SCS評価制度と★4の位置付け SCS評価制度は、委託元が委託先の対策状況を把握しにくいこと、委託先が取引先ごとに異なる質問票へ回答する負担が大きいことを背景として、サプライチェーンに必要な対策水準を段階別に示す制度です。IPAは、取引契約等において委託元が委託先に適切な段階を提示し、その実施状況を確認する利用場面を想定しています。制度の対象はサプライチェーンを構成する企業全般です。 ★4は、一般的なサイバー脅威への対処を水準とする★3より一段深く、初期侵入後の被害拡大防止、攻撃目的の遂行リスク低減、取引先データ・システムの保護、自社の役割に応じたサプライチェーン強靭化を求める水準です。★3を先に取得しなければ★4を申請できない、という順序関係ではありません。 ★4は「書類審査＋現場確認＋技術的な確認」 IPAの公表スキームでは、取得希望組織が自己評価を行い、指定された評価機関に検証・評価を依頼します。評価機関は第三者評価を行い、技術検証は評価機関自身または委託を受けた指定技術検証事業者が実施します。評価報告書を受領後、取得希望組織が事務局へ登録申請し、問題がなければ台帳に登録・公開されます。★4では文書確認だけでなく実地審査と技術検証が行われ、適用範囲内から対象をサンプリングする想定です。 なぜ今、★4取得の準備が必要なのか 制度開始後に要求事項を読み始めても、日々の運用実績は短期間では作れません。アクセス権の棚卸し、脆弱性対応、バックアップ復旧試験、教育、インシデント訓練などは、規程の制定日ではなく実施記録によって有効性を説明します。取引先から取得予定や対応状況を尋ねられたとき、ギャップ、責任者、改善期限、予算を示せる状態にしておくことが重要です。 経営上も、★4対応は単なる認証費用ではありません。取引継続条件、入札・調達要件、秘密情報の取扱条件に影響する可能性があり、対応の遅れは営業機会の損失や個別監査の増加につながり得ます。他方、制度マークだけを目的に過剰投資をすると、維持できない仕組みが残ります。守るべき取引、情報、サービス停止時の損失を起点に優先順位を決めるべきです。 対応しなかった場合に起こり得る問題 第一は、取引先への説明力の低下です。委託元から対策水準を求められた際、計画も証跡もなければ、追加質問票、個別監査、契約条件の厳格化を招く可能性があります。第二は、攻撃を受けた際の被害拡大です。例えば、VPN機器の未修正脆弱性から侵入され、共通の管理者権限を使ってファイルサーバやバックアップ領域まで暗号化されるケースでは、境界防御だけでは事業停止を抑えられません。 第三は、委託先を経由した信用毀損です。開発環境の認証情報が漏えいし、顧客環境への接続に悪用されれば、自社の復旧費用だけでなく、顧客調査、契約上の報告、損害対応が発生します。★4の準備では、こうした連鎖を想定し、権限分離、ログ監視、インシデント対応、再委託先管理を一つの仕組みとして確認します。 対象範囲はどう決めるか 適用範囲は「審査を通りやすい最小範囲」ではなく、取引先へ約束したい業務と、その業務を支える人・拠点・システム・委託先から逆算します。たとえば顧客向けSaaSを対象とするなら、本番環境だけでなく、開発・保守端末、ソースコード管理、ID基盤、監視、バックアップ、クラウド運用、外部委託を含めるべきかを判断します。除外する対象には、業務上の依存関係がないかを確認し、理由を文書化します。 経営層が決める事項 経営層は、対象とする事業・契約、許容する停止時間と情報漏えいリスク、改善投資の上限、責任役員を決めます。情報システム部門だけに任せると、営業が締結した顧客契約、開発部門の例外運用、総務が管理する入退室、購買部門の再委託先管理が評価範囲から漏れやすくなります。 情報システム部門が準備する事項 情報システム部門は、ネットワーク構成図、資産台帳、アカウント・権限一覧、脆弱性管理台帳、ログ管理方針、バックアップ構成、インシデント対応手順を現状と一致させます。台帳上は廃止済みでも実機が稼働している、退職者アカウントが残っている、規程とクラウド設定が異なる、といった差異は技術検証で表面化しやすい点です。 ★4取得に向けた具体的な実施手順 1．経営目的と適用範囲を確定する まず、主要顧客から求められる水準、売上への影響、守る情報、重要サービスを整理します。適用範囲記述書には、法人・部門、拠点、業務、システム、ネットワーク、クラウド、委託・再委託、除外理由を記載します。評価中に範囲が変わると、証跡収集や技術検証のやり直しが生じるため、経営会議等で合意を得ておくことが有効です。 2．要求事項と現状のギャップを評価する IPAが公開する★3・★4要求事項・評価基準を基準に、適合、部分適合、不適合、対象外を判定します。自己評価の点数を埋めることよりも、判定根拠を一行で説明できることが重要です。各項目に、統制責任者、規程、実施手順、証跡、対象システム、残課題、是正期限を紐付けます。IPA FAQでは、★4取得には定められたすべての要求事項・評価基準を満たす必要があるとされています。 3．規程と実運用を一致させる 規程は現場で守れる粒度にします。「定期的に確認する」では、頻度、実施者、承認者、記録先が分かりません。「四半期ごとにシステム責任者が特権IDを棚卸しし、部門長が承認、結果をチケットに保存する」まで具体化すると、運用と証跡が結び付きます。既存のISMS文書があっても、対象範囲や実態が異なる場合は流用だけで済ませないことが肝要です。 4．証跡パッケージを作る 実施前には、組織図、責任分担表、適用範囲、情報資産・システム台帳、ネットワーク図、リスクアセスメント、各種規程、教育記録、アクセスレビュー、パッチ適用記録、脆弱性診断報告書、インシデント訓練・復旧試験結果、委託先評価、例外承認記録などを準備します。文書名を並べるだけでなく、要求事項ごとに参照ページと証跡保管場所を示す索引を用意すると、評価対応を効率化できます。 5．実地審査とサンプリングに備える 実地審査では、責任者へのインタビュー、管理画面や設定の確認、記録の突合、拠点の物理的対策の確認などが想定されます。サンプリングは、適用範囲内の一部の拠点、端末、アカウント、変更記録、教育記録等を選んで運用状況を確かめる考え方です。どのサンプルが選ばれるかを予測して一部だけ整えるのではなく、母集団を明確にし、同じ手順が全件に適用されていることを示します。 有効な事前演習は、評価者役が無作為に「直近3件の入社者」「管理者ID5件」「重大パッチ3件」「委託先2社」などを選び、申請内容、承認、設定、記録が一貫しているかを追跡することです。説明担当者だけでなく、実際の運用担当者が自分の業務を説明できる状態を目指します。 6．技術検証を実施する 技術検証の具体的方法と範囲は、最新の制度文書および評価機関との調整に従う必要があります。実務上は、インターネット公開資産、Webアプリケーション、サーバ・ネットワーク機器、クラウド設定、端末、認証・権限、ネットワーク分離、ログ等について、要求事項への適合を裏付ける検証計画を作ります。無断で本番環境を試験せず、対象、時間帯、試験元IP、禁止事項、停止判断、連絡網、データ取扱いを事前合意します。 Webアプリケーション診断は、SQLインジェクション、認証・認可不備、セッション管理、設定不備等を確認します。プラットフォーム診断は、OS、ミドルウェア、ネットワーク機器の既知脆弱性や不要サービス、暗号・設定の問題を確認します。ペネトレーションテストは、複数の弱点を組み合わせて重要資産へ到達できるかを、合意したシナリオと安全管理の下で検証するものです。自動スキャンだけでは、権限設計や業務ロジック、侵入後の横展開まで十分に確認できない場合があります。 7．指摘を是正し、再確認する 指摘はCVSS等の技術的深刻度だけでなく、悪用可能性、公開範囲、保有情報、権限、事業停止影響、代替統制を合わせて優先順位付けします。重大な認証回避や外部公開機器の既知脆弱性は迅速に封じ込め、恒久対応へ移行します。一方、直ちに改修できない基幹システムは、アクセス制限、監視強化、ネットワーク分離などの代替策を経営が期限付きで承認します。 是正管理票には、指摘、根本原因、影響範囲、暫定対応、恒久対応、責任者、期限、完了証跡、残余リスク、再確認結果を残します。設定変更の画面だけでなく、同種資産への横展開確認と、運用手順の修正まで完了させることが再発防止につながります。 成果物・報告書に含めるべき内容 社内準備の成果物には、適用範囲記述書、要求事項別ギャップ一覧、証跡索引、技術検証計画、診断報告書、是正管理票、経営報告資料を含めます。診断報告書には、対象・除外、実施日時、手法、制約、発見事項、再現条件、影響、リスク評価、推奨対策を記載し、経営向け要約と技術担当者向け詳細を分けると活用しやすくなります。 経営報告では、未解決件数だけでなく、重要事業への影響、必要投資、期限、リスク受容の要否を示します。評価報告書を取得すること自体ではなく、その後も統制を維持できる責任分担と予算を承認することが経営層の役割です。 期間と費用を左右する要因 IPAが示す申請・登録費用は2026年9月4日時点で公表待ちです。したがって、総費用は「制度上の申請・登録費用」と「評価機関・技術検証の費用」と「不足対策の改修費」を分けて見積もる必要があります。期間も一律ではなく、適用範囲、拠点数、システム数、クラウド数、文書整備度、既存認証の活用可否、技術検証の深さ、重大指摘の件数、繁忙期や変更凍結期間で変わります。 準備計画は、短期間の書類作成ではなく、予備診断、是正、運用実績の蓄積、模擬審査、本評価を逆算して組みます。予算稟議では、取得目的、対象取引、適用範囲、制度関連費、診断費、改修予備費、社内工数、取得後の維持費を分けて示すと、追加費用の理由を説明しやすくなります。 評価・支援ベンダーの選び方 評価機関と技術検証事業者は、制度上の指定状況を必ず確認します。取得支援を依頼する場合は、制度要求の解釈だけでなく、Web、プラットフォーム、クラウド、認証基盤の技術検証から是正支援、運用設計まで対応できるかが重要です。第三者評価とコンサルティングを同一法人が行う場合の中立性・公平性要件は制度文書で確認し、役割分離を契約と体制図で明確にします。 RFP・見積依頼で確認したい項目 見積依頼では、対象組織・拠点・システム、希望時期、既存認証、技術検証の対象と方式、報告書言語、再診断回数、出張、緊急連絡、機密情報の保管・削除、再委託、賠償・責任分界を明記します。価格だけでなく、前提条件と除外事項、追加費用が発生する条件を比較してください。診断データには構成情報、アカウント、脆弱性など機密性の高い情報が含まれるため、暗号化、アクセス制御、保管地域、保持期間、廃棄証明も確認します。 よくある失敗と注意点 よくある失敗は、①申請直前に規程だけ作る、②適用範囲と資産台帳が一致しない、③一部の模範的な拠点・端末だけ整える、④自動スキャン結果を技術検証の全てと考える、⑤診断指摘を修正したが再確認しない、⑥情報システム部門だけで対応する、⑦制度上の確定事項と支援会社の推奨事項を混同する、というものです。 また、診断のために本番データを複製した結果、管理外の環境へ個人情報が残る事態も避けなければなりません。テストデータの匿名化、最小権限の試験アカウント、ログ取得、データ削除の確認を計画に含めます。制度文書は更新されるため、申請時点の版番号と参照日も証跡に残してください。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度の要求事項整理から適用範囲設計、ギャップ分析、規程・運用整備、証跡作成、模擬審査、技術検証に向けた準備、是正計画、継続運用まで一気通貫で支援します。Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習、SOC／CSIRT構築、インシデントレスポンス、教育を組み合わせ、企業ごとの事業・IT環境・予算に合わせて設計します。 特徴は、診断結果を渡して終わらず、経営リスクと技術課題を接続し、改善の実行と運用定着まで伴走する点です。経営層には取引・事業継続・投資判断の言葉で、情報システム部門には設定・手順・証跡の言葉で、現場部門には日常業務の変更点として説明し、社内の橋渡しを行います。 よくある質問 Q1．★3を取得してからでないと★4を取得できませんか。 いいえ。IPAは、上位段階が下位段階の事項を包括するものの、★3の事前取得を★4取得の条件とはしていません。自社の取引要件とリスクに応じて選択します。 Q2．★4は自己評価だけで取得できますか。 できません。★4は評価機関による第三者評価と技術検証が必要で、文書確認に加えて実地審査が行われる想定です。 Q3．サンプリング対策として何をすべきですか。 母集団を明確にし、全件に同じ統制が適用されている状態を作ります。アカウント、端末、拠点、変更記録等を無作為に選ぶ模擬確認が有効です。 Q4．脆弱性診断とペネトレーションテストは同じですか。 目的が異なります。脆弱性診断は個々の弱点を網羅的に確認するのに適し、ペネトレーションテストは弱点を組み合わせて重要資産へ到達できるかを攻撃シナリオに沿って確認します。必要性は対象とリスクに基づいて決めます。 Q5．既にISMSを取得していれば準備は不要ですか。 既存の管理体系や証跡は活用できますが、自動的に★4適合になるわけではありません。SCS評価制度の要求事項、適用範囲、技術検証に照らした差分確認が必要です。 Q6．申請費用はいくらですか。 2026年9月4日時点で、IPAは★3・★4の申請・登録費用を今後公開予定としています。評価、技術検証、改修等の費用は別に見込み、範囲を明確にして見積もります。 Q7．準備にはどれくらいかかりますか。 一律の期間はありません。対象規模、現状の成熟度、技術的な不備、運用記録の有無に左右されます。制度開始や顧客期限から逆算し、予備診断と是正期間を確保してください。 Q8．対象範囲がまだ決まっていなくても相談できますか。 可能です。主要取引、重要情報、業務依存関係を整理する初期段階から支援を受けることで、過不足のある範囲設定や見積もりの手戻りを減らせます。 まとめ｜★4は「説明できる運用」と「技術的な裏付け」で備える サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★4取得準備では、要求事項を満たす規程、実際の運用、客観的な証跡、技術検証の結果が一貫していなければなりません。実地審査やサンプリングを直前対策として捉えず、どの拠点・端末・担当者が選ばれても同じ仕組みを説明できる状態を作ることが本質です。 まずは、取引と事業継続の観点から適用範囲を決め、ギャップ評価、予備診断、是正、模擬審査を進めてください。制度の最新情報を追いながら、未公表事項を仮定で埋めず、変更に対応できる計画を持つことが重要です。 SCS評価制度★4の準備を、現状整理から相談したい企業様へ Librus株式会社では、対象範囲や実施方法が決まっていない段階でもご相談いただけます。主要取引、重要システム、既存規程・診断の状況を整理し、取得に向けた課題、優先順位、必要な技術検証、概算スケジュールを可視化します。社内稟議に必要な論点も整理できるため、まず何から着手すべきかを明確にしたい企業様に適しています。 参考情報 IPA「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 IPA「SCS評価制度の詳細情報」 IPA「要求事項・評価基準」 IPA「よくある質問」 経済産業省「SCS評価制度」特設サイト ※制度の名称、評価方法、日程、費用等は今後変更・更新される可能性があります。申請・契約時はIPAおよび経済産業省の最新版をご確認ください。 監修者 鎌田光一郎：⻘山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

SCS評価制度★3取得実務自己評価から専門家確認まで

SCS評価制度★3取得は「証跡を先に設計する」と進めやすい サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★3を目指す企業は、自己評価票に回答して終わりではありません。先に適用範囲を定め、要求事項ごとに実施状況を確認できる証跡をそろえ、不足を是正し、セキュリティ専門家の確認・助言・署名を受けます。そのうえで、経営層が自己適合を宣誓し、事務局へ申請するのが基本の流れです。 最も重要なのは、規程の有無ではなく、決めた対策が現場で継続運用されていることを説明できる状態にすることです。たとえば「多要素認証を導入している」という回答だけでは、対象アカウント、例外、設定状況、定期点検の記録が分かりません。自己評価票と証跡の対応関係を最初から台帳化すると、専門家確認での手戻りを減らせます。 この記事で分かること ★3の評価方式と、自己評価・専門家確認・経営層宣誓の関係 100～1,000名規模の企業が社内で組むべき体制と実務手順 自己評価票にひも付ける証跡、技術確認、是正計画の作り方 期間・費用を左右する要因と、支援会社への見積依頼項目 申請を目的化せず、取引継続と事業継続につなげる方法 SCS評価制度と★3の位置づけ 取引先の対策水準を共通の尺度で確認する制度 SCS評価制度は、委託元と委託先の間でセキュリティ対策水準を可視化し、サプライチェーン全体の底上げを図る制度です。IPAは、委託元にとっては委託先の対策が見えにくいこと、委託先にとっては発注者ごとに異なるチェックリストへの対応が負担になっていることを背景として挙げています。取引契約等において、委託元が委託先に適切な段階を提示し、対策の実施状況を確認する利用が想定されています。出典：IPA「SCS評価制度」https://www.ipa.go.jp/security/scs/index.html ★3は、一般的なサイバー脅威に対処し得る水準です。★4は初期侵入の防御に加え、侵入後の被害拡大防止やサプライチェーン上の役割に応じた強靭化まで求め、第三者評価と技術検証を伴います。上位段階が下位段階を包含する設計であり、★3を先に取得しなければ★4に進めないわけではありません。出典：IPA「SCS評価制度の詳細情報」https://www.ipa.go.jp/security/scs/details.html ★3は専門家確認付き自己評価 ★3では、取得希望組織が要求事項・評価基準に基づく自己評価を作成します。登録された社内外のセキュリティ専門家が内容を確認し、必要に応じて修正を含む助言を行い、提出内容を了承した場合に署名します。その後、取得希望組織は経営層の自己適合宣誓を含む評価結果を事務局へ提出し、申請内容に問題がなければ台帳に登録・公開されます。これは★4の第三者評価とは異なりますが、単なる無確認の自己宣言でもありません。 IPAによると、SCS評価制度のセキュリティ専門家は、所定の資格のいずれかを保有し、制度研修を受講したうえで事務局登録が必要です。資格保有者であれば誰でも直ちに署名できるとは限らない点に注意が必要です。出典：IPA「SCS評価制度の詳細情報」https://www.ipa.go.jp/security/scs/details.html なぜ今、★3取得の準備が必要なのか 制度対応の本質は、マークの取得よりも取引先に説明可能な統制を整えることです。製造、物流、IT、業務委託などの現場では、発注元の機密情報や接続権限を委託先が保有します。委託先のVPN装置が未更新で侵入される、保守アカウントの認証情報が窃取される、クラウド共有設定の誤りで設計資料が外部公開される、といった事態は、1社の問題にとどまりません。納品停止、顧客対応、調査費用、契約上の報告、信用毀損へ連鎖します。 特に従業員100～1,000名の企業では、IT環境が十分に複雑である一方、専任のセキュリティ人員が少ないことがあります。情報システム部門がツール運用を担い、総務が規程を管理し、各事業部がSaaSを契約し、開発部門がWebサービスを運用する構造では、全社としての証拠が一か所に集まりません。★3対応は、この分散を可視化し、責任者、対象、頻度、記録を結び直す機会になります。 対応しない場合に起こり得る問題 SCS評価制度が直ちにすべての企業へ法的義務を課すという意味ではありません。しかし、発注企業が調達条件や契約更新条件として一定段階を求める運用が広がれば、未対応は営業・調達上の説明負担につながります。個別質問票への回答が続く、商談時に改善計画の提出を求められる、重要業務への参画範囲が限定される、といった影響が考えられます。 より直接的な問題は、統制の空白が残ることです。退職者アカウントが停止されていない、バックアップから復旧できるか試していない、インシデント時の連絡先が更新されていない、外部公開資産を把握していない状態は、感染や侵入が発生したときの被害を大きくします。★3の自己評価を、取引のための書類作成ではなく、事業継続上の弱点を発見する仕組みとして使うべきです。 ★3の対象範囲はどう決めるか 最初に決めるべき事項は適用範囲です。法人全体を無条件に対象とすると、海外拠点、工場、子会社、レガシー環境まで確認が広がり、証跡収集が止まることがあります。一方、都合のよい一部システムだけに狭めると、取引先が期待する事業や情報処理を含まず、説明価値が下がります。対象となる契約、提供サービス、拠点、組織、情報資産、IT基盤、外部委託先を、サプライチェーン上の役割から逆算してください。 たとえば、大手メーカー向けに保守サービスを提供し、顧客環境へリモート接続する企業なら、当該サービス部門だけでなく、接続端末、ID基盤、VPN、ログ、端末管理、委託保守先、インシデント対応体制まで対象に含める必要があります。EC事業者なら、Webアプリケーション、クラウド基盤、決済・物流連携、顧客データ管理、開発委託先が重要です。 確認軸対象範囲の決め方残す資料事業取得目的となる取引・製品・サービスを特定契約、業務フロー、サービス一覧組織・拠点運用、開発、営業、管理部門と拠点をひも付け組織図、責任分担表、拠点一覧情報・システム扱う機密情報と処理するIT基盤を洗い出す資産台帳、データフロー、構成図外部委託再委託、クラウド、保守、開発先を含める委託先台帳、契約、評価記録 SCS評価制度★3取得の実務手順 1. 経営目的と責任者を決める 経営層は、取得理由を『取引先から言われたため』だけにせず、守るべき事業、許容できない停止時間、機密情報、予算枠、リスク受容者を決めます。プロジェクト責任者は情報システム部門に置く場合でも、経営企画、総務・法務、人事、調達、開発、営業を巻き込む必要があります。経営層の宣誓が最後にあるため、開始時と申請前の2回だけではなく、主要な不足事項が判明した時点で判断会議を設けると円滑です。 社内稟議では、制度概要、取得目的、対象範囲、予定時期、担当工数、外部費用、未達項目の改修費、専門家の役割、申請後の維持運用を説明します。診断費だけを予算化し、規程改定や設定変更、端末更新の費用が漏れるケースを避けてください。 2. 資料を収集し、現状を可視化する 自己評価の前に、規程、台帳、構成図、運用記録を集めます。規程が古い場合でも捨てず、現場との差分を確認する材料にします。準備資料の例は、情報セキュリティ方針、組織図、資産・アカウント・委託先台帳、ネットワーク構成図、アクセス権レビュー記録、パッチ適用記録、バックアップ・復旧試験記録、ログ監視記録、教育履歴、インシデント対応手順と訓練記録です。 この段階で証跡台帳を作ります。列には要求事項番号、評価結果、根拠文書、ファイルの保存先、対象範囲、責任部門、確認日、不足、是正担当、期限、専門家コメントを置きます。ファイル名だけでなく、規程の章番号や管理画面の確認箇所まで書くとレビューが速くなります。 3. 自己評価票を作成する 自己評価は、担当者の印象ではなく評価基準と証跡に基づいて行います。『実施済み』と判断する前に、①対象範囲全体へ適用されているか、②責任者と頻度が決まっているか、③例外が管理されているか、④実施記録が残っているか、⑤問題発生時に改善されるかを確認します。部分導入なら、その事実と残余リスクを明記し、適合を先取りしません。 複数部門の回答が食い違った場合は、文書上のルールではなく実運用を確認します。たとえば退職者IDを即日停止する規程があっても、SaaSごとに人事情報が連携されず手作業で漏れているなら、運用証跡と改善が必要です。自己評価票の文章は、第三者が読んでも『何を、誰が、どの範囲で、どの頻度で実施したか』を追えるようにします。 4. 不足事項をリスク順に是正する 不足を同じ優先度で並べると、規程の体裁調整に時間を使い、侵入につながる穴が残ります。優先順位は、インターネットからの悪用可能性、顧客情報・重要業務への影響、攻撃の起こりやすさ、代替策の有無、要求事項への影響、改修所要時間で決めます。外部公開VPNの重大な脆弱性、管理者IDの多要素認証未導入、公開サーバの不要ポート、復旧不能なバックアップは、早期対応候補です。 Webサービスを提供する企業では、Webアプリケーション診断によりSQLインジェクション、認可不備、セッション管理などを確認します。プラットフォーム診断ではOS、ミドルウェア、ネットワーク機器、クラウド設定の脆弱性を調べます。さらに、複数の弱点を組み合わせて重要資産へ到達できるかを検証する必要があれば、合意した範囲でペネトレーションテストを実施します。これらは★3申請のために機械的に全部行うのではなく、対象範囲とリスクに応じて選びます。診断結果は、深刻度だけでなく、事業影響、悪用条件、改修責任者、期限、代替策、再確認結果まで管理してください。 5. 証跡を整え、模擬レビューを行う 証跡は『存在する資料』ではなく『評価結果を裏付ける資料』です。規程は設計、設定画面は実装、ログやチケットは運用を示します。三者を組み合わせると説明力が上がります。スクリーンショットには取得日、対象システム、取得者を付け、機密情報や個人情報を必要以上に含めません。外部へ共有する前にマスキング、アクセス制御、保存期限、削除方法を合意します。 正式な専門家確認の前に、要求事項ごとに自己評価票から証跡をたどる模擬レビューを行います。リンク切れ、古い日付、対象範囲の不一致、責任者未承認、サンプル不足を洗い出します。専門家への提出パッケージは、適用範囲説明書、自己評価票、証跡台帳、主要証跡、不足事項と是正結果、未解消リスクの扱いで構成すると確認しやすくなります。 6. セキュリティ専門家の確認・助言を受ける 専門家は、自己評価の記載と証跡が評価基準に照らして妥当かを確認し、必要に応じて修正を助言します。署名だけを依頼するのではなく、範囲設定、判断根拠、例外、サンプリング、是正結果まで説明できるレビュー工程を確保してください。社内の専門家を起用する場合も、制度上の登録要件を満たすか、評価対象の運用に関与しすぎて確認の客観性を損なわないかを検討します。 初回打合せでは、専門家の登録状況、対応実績、確認方法、必要資料、レビュー回数、追加費用、機密情報の扱い、成果物、署名条件を確認します。専門家が問題を指摘した場合は、自己評価票を修正し、是正またはリスク判断を行い、差し替えた証跡を再提示します。 7. 経営層が自己適合を宣誓し、申請する 経営層の宣誓は、現場が作った回答への形式的な押印ではありません。経営層は、適用範囲、主要なリスク、未解消事項、例外、必要予算、維持体制を確認し、提出内容に責任を持てるか判断します。申請前の経営報告は、要求事項を一つずつ読み上げるより、重要リスク、是正完了状況、残余リスク、取引への影響、次年度の維持費を中心にまとめると判断しやすくなります。 事務局への提出内容、申請方法、公開項目は最新規程に従います。公開台帳に載ることを前提に、対象範囲の表現が取引先に誤解を与えないかも確認してください。基本規程等はIPAの制度ページから確認できます。出典：IPA「制度規程・委員会」https://www.ipa.go.jp/security/scs/regulation-advisory-committeess.html 期間と費用を左右する要因 公的資料で一律の取得期間や総費用が保証されているわけではありません。実務上は、現状把握、自己評価、是正、専門家確認、経営承認、申請準備を逆算します。規程と運用記録がそろう企業は短く、資産台帳がない、拠点が多い、ID管理が分散している、レガシー機器が残る、委託先管理が未整備といった企業は長くなります。数週間で書類を整える前提ではなく、技術改修や運用実績を作る期間を含めて計画してください。 費用は、対象範囲、拠点・システム数、自己評価の初期成熟度、規程整備量、診断の要否、是正支援、専門家確認の回数、現地確認、再レビュー、申請後の運用支援で変動します。見積では『コンサルティング一式』ではなく、ギャップ分析、文書作成、証跡整備、診断、是正支援、専門家確認、申請支援を分けて確認すると比較しやすくなります。制度上の申請費用等はIPAの最新案内で確認が必要です。 支援会社・専門家を選ぶ際のチェックポイント SCS評価制度の説明ができるだけでなく、規程、IT運用、技術検証、経営報告を横断できるかを確認します。自己評価票を埋める支援だけでは、脆弱性や運用不備の是正まで進みません。一方、診断だけでは経営層宣誓や委託先管理の仕組みを整えられません。★3の取得工程全体と、その後の運用を一貫して設計できることが重要です。 SCS評価制度の最新文書と評価基準を参照しているか 専門家確認を担う者の資格・研修・登録状況を明示できるか 自己評価の代筆ではなく、根拠と判断過程を残すか Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストをリスクに応じて提案できるか 機密情報の取扱い、再委託、保存場所、削除、事故時報告が契約で明確か 是正計画、再診断、教育、継続監視まで支援範囲を選べるか RFPまたは見積依頼には、取得目標、希望時期、対象事業・拠点・システム、従業員数、既存認証、利用クラウド、外部公開システム、過去の診断、希望成果物を記載します。成果物として、ギャップ分析報告書、自己評価票、証跡台帳、適用範囲説明書、是正計画、専門家コメント・署名、経営報告資料、申請書類一覧を確認すると、納品後に何が残るか明確になります。 よくある失敗と注意点 規程を作っただけで適合と判断する 規程は必要ですが、運用記録がなければ実効性を示せません。アクセス権棚卸し、教育、バックアップ復旧試験、脆弱性対応など、定期実施が必要な対策は早めに回し、記録を残します。 適用範囲を後から変える 自己評価の途中で対象システムが増えると、証跡や診断範囲が連鎖して変わります。営業が説明したい取引範囲と、情シスが管理できるIT範囲を開始時にすり合わせてください。 専門家を最後に探す 制度登録された専門家の確保やレビュー日程がボトルネックになり得ます。初期段階で候補を決め、正式確認の前に証跡の粒度や進め方を合意することが有効です。ただし、助言者と最終確認者の関係や客観性については制度規程に従います。 診断結果を申請資料から切り離す 技術診断を実施しても、発見事項の是正記録が自己評価票と結び付いていなければ説明が弱くなります。チケット番号、改修日、再診断結果、例外承認を証跡台帳に戻します。 取得後の維持担当を決めない 組織変更、システム追加、委託先変更、重大インシデントがあれば、評価時点の状態は変わります。月次の運用確認、四半期の証跡更新、年次の自己評価、教育、診断、経営報告を年間計画に組み込みます。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度★3に向けた現状分析から、適用範囲の設計、自己評価票、証跡台帳、規程・運用の整備、技術的な確認、是正計画、経営層向け説明、専門家との連携、申請準備まで一気通貫で支援します。企業ごとのIT環境、取引構造、予算、社内稟議を踏まえ、過剰な対策を一律に導入するのではなく、リスクと要求事項の双方から優先順位を整理します。 必要に応じて、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築、インシデントレスポンス、教育・訓練まで接続できます。診断結果を報告して終わらず、改善担当と期限を定め、再確認と継続運用までつなげることが特長です。経営層には取引・財務・事業継続の言葉で、情報システム部門には設定・運用・証跡の言葉で説明し、社内合意形成を支援します。 よくある質問 Q1. ★3は自己評価だけで取得できますか。 いいえ。取得希望組織が自己評価を作成しますが、セキュリティ専門家の確認・助言・署名と、経営層による自己適合宣誓を含む申請が必要です。 Q2. 社内の有資格者が専門家確認を担当できますか。 社内外の専門家が想定されていますが、所定資格の保有、制度研修、事務局登録などの要件があります。実際の起用時は登録状況と最新規程を確認してください。 Q3. ISMSを取得済みなら、そのまま★3を取得できますか。 既存の方針、リスク管理、監査記録は有力な証跡になり得ます。ただし、SCS評価制度の適用範囲と要求事項に照らした自己評価および所定手続は別途必要です。 Q4. 脆弱性診断やペネトレーションテストは必須ですか。 すべての企業に同じ検査を機械的に実施するものではありません。評価基準、対象システム、リスク、既存証跡に応じて必要性と範囲を判断します。 Q5. どの部門が主管すべきですか。 情報システム部門が実務主管となる例は多いものの、経営企画、総務・法務、人事、調達、開発、事業部門の参加が必要です。経営層は範囲、予算、残余リスクを判断します。 Q6. どのくらい前から準備すべきですか。 台帳、規程、ログ、復旧試験等がそろっているかで変わります。運用実績や技術改修が必要なら時間を要するため、希望申請日から逆算して早期にギャップ分析を始めるのが安全です。 Q7. ★3取得後は何をすべきですか。 証跡の更新、アカウント・資産・委託先の見直し、教育、脆弱性対応、訓練、経営報告を定常化します。対象事業のリスクが高い場合は★4も検討します。 Q8. 対象範囲が決まっていなくても相談できますか。 可能です。取引先からの要求、扱う情報、接続権限、重要業務を整理し、説明価値と実行可能性の両面から範囲を設計します。 まとめ：★3は書類作成ではなく、説明可能な運用を作る取り組み サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★3取得では、対象範囲を定め、要求事項に沿って自己評価し、規程・設定・運用記録を証跡としてそろえます。不足をリスク順に是正した後、登録されたセキュリティ専門家の確認・助言・署名を受け、経営層の自己適合宣誓を含めて申請します。 成功の鍵は、自己評価票を先に埋めることではなく、経営目的、適用範囲、証跡台帳、是正責任、維持運用を一つの計画にすることです。これにより、申請時の手戻りを抑えるだけでなく、取引先への説明、事故時の初動、事業継続の実効性も高められます。 取得後も機能するセキュリティ体制を作りたい企業へ SCS評価制度への対応を、取引条件を満たすための一度きりの作業で終わらせたくない企業には、改善・運用まで含む支援が適しています。Librus株式会社は、診断、ペネトレーションテスト、SOC／CSIRT、教育、インシデント対応を必要に応じて組み合わせます。対象範囲や実施方法が固まっていない段階から、事業リスクと予算に合うロードマップをご一緒に設計します。 監修者 鎌田光一郎：⻘山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE