取引先から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

SCS対応を一過性にしない――取得後の継続運用モデル

SOC・CSIRT・脆弱性管理・教育・内部点検・更新管理を実務で回す方法 サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）への対応で重要なのは、マーク取得をゴールにしないことです。取得時に整えた規程や証跡が、その後の組織変更、クラウド移行、新規取引、脆弱性の発見に追随しなければ、実際の防御力は低下します。 結論から言えば、SCS対応を継続させる鍵は、要求事項を「担当者が保管する審査資料」ではなく、「月次・四半期・年次で回る業務」に変換することです。SOCによる監視、CSIRTによる事故対応、脆弱性管理、従業員教育、内部点検、更新管理を一つの運用台帳と経営報告に接続すれば、更新前の慌ただしい再整備を避けやすくなります。 この記事で分かること SCS評価制度の取得後に必要となる継続運用の全体像 SOC・CSIRT・脆弱性管理・教育・内部点検を連動させる方法 ★3・★4の有効期間と、変更時に再評価を検討すべき場面 年間計画、証跡管理、経営報告、予算化の実務ポイント 継続運用を支援する会社を選ぶ際の確認事項 SCS評価制度は「取得時点の確認」であり、将来の安全を保証するものではない SCS評価制度は、サプライチェーンにおける企業の立ち位置や想定リスクに応じて必要な対策水準を示し、対応状況を可視化する制度です。経済産業省と内閣官房国家サイバー統括室が2026年3月に制度構築方針を公表し、IPAが運営します。★3・★4は2027年3月頃の運用開始が予定されています。 出典：IPA「SCS評価制度の詳細情報」、IPA「よくある質問」 ★3と★4では、評価方法と有効期間が異なる 制度構築方針では、★3は一般的なサイバー脅威に対処できる水準とされ、セキュリティ専門家の確認を伴う自己評価が想定されています。有効期間は1年です。★4は、侵入防御だけでなく、被害拡大防止、インシデント対応、事業継続、取引先管理まで含む標準的・包括的な水準で、第三者評価と技術検証を伴います。有効期間は3年ですが、期間中も毎年の自己評価と評価機関への提出が想定されています。 また、取得時の適用範囲や基準の達成に大きな影響を与える変更があった場合は、有効期限前でも専門家または評価機関による確認・評価が必要になる想定です。大規模な端末・サーバ更改、クラウドへの大規模移行、ネットワーク構成の顕著な変更、規程や運用方法の大幅変更などが例示されています。 出典：経済産業省・国家サイバー統括室「SCS評価制度に関する制度構築方針」 継続運用が必要な理由 攻撃者は審査日程に合わせて待ってはくれません。公開サーバの既知脆弱性、盗まれた認証情報、取引先を装うメール、クラウド設定ミスは、日々発生します。例えばVPN装置の脆弱性が公表されたのに資産台帳が古く、対象機器の有無を判断できなければ、パッチ適用の意思決定が遅れます。退職者アカウントが残ったままなら、取得時にアクセス管理規程が整っていても実効性はありません。 制度上の更新だけを目的にすると、現場には「年に一度、証跡を集める仕事」と映ります。これを避けるには、通常業務の成果物がそのまま評価の証跡になる仕組みが必要です。 取得後に起こり得る問題――形骸化は取引と事業継続にも影響する 規程と実態がずれる 取得後に組織再編やシステム変更が進む一方、責任者一覧、ネットワーク図、クラウド利用台帳、委託先一覧が更新されないケースがあります。事故時の連絡先が旧担当者のままでは、初動が止まりかねません。更新審査では、文書の有無だけでなく、定めた手順が実際に運用されていることを説明する必要があります。 脆弱性対応が担当者の勘に依存する 脆弱性情報を受け取っても、対象資産、事業影響、悪用状況、代替策を結び付ける仕組みがなければ優先順位が定まりません。CVSSの点数だけで判断すると、外部公開された重要システムの脆弱性と、隔離された検証端末の脆弱性を同列に扱うおそれがあります。結果として、本当に急ぐべき対応が後回しになります。 取引先への説明力が低下する 委託元から「直近の教育実施率」「重大脆弱性の是正状況」「インシデント時の通知期限」を尋ねられた際、資料を即時に提示できなければ、対策自体を行っていても信頼を得にくくなります。SCS評価制度は取引契約等で委託元が委託先に段階を提示し、実施状況を確認する利用が想定されています。継続運用は、営業・調達・法務にとっても取引継続の基盤です。 経営判断が遅れる セキュリティ情報が情報システム部門内に閉じると、経営層は予算の必要性を判断できません。技術的な指摘件数だけでなく、停止し得る事業、影響する顧客、復旧時間、契約上の通知義務まで翻訳する必要があります。経済産業省の「サイバーセキュリティ経営ガイドライン Ver3.0」も、経営者のリーダーシップと継続的な改善を重視しています。 出典：経済産業省「サイバーセキュリティ経営ガイドラインと支援ツール」 SCS取得後の継続運用モデル――6つの機能を一つの管理サイクルにする 従業員100～1,000名規模の企業では、専任の大組織を新設するより、既存の情報システム、総務・人事、法務、事業部門、経営会議の役割を明確にし、不足部分を外部サービスで補う設計が現実的です。以下の6機能を別々に導入せず、共通のリスク台帳、改善計画、証跡保管ルールでつなぎます。 1．SOC：監視結果を改善につなげる SOC（Security Operation Center）は、ログやアラートを監視し、不審な挙動を検知・分析する機能です。導入後は、検知件数だけでなく、重大度、初動時間、誤検知率、同種アラートの再発、ログ未取得資産を月次で確認します。監視対象に入っていないクラウドや拠点があれば、リスク台帳に登録し、追加時期を決めます。 SOCを外部委託する場合も、社内の判断責任は残ります。「誰が遮断を承認するか」「夜間に誰へ連絡するか」「取引先への通知を誰が決めるか」を事前に定め、半年に一度は連絡テストを行うと実効性を確認できます。 2．CSIRT：事故対応手順を訓練で検証する CSIRT（Computer Security Incident Response Team）は、インシデント発生時の対応を統括する体制です。常設の専任部署でなくても、情報システム、法務、広報、人事、事業責任者、経営層から役割を指定できます。 年1回の机上訓練では、ランサムウェアで受発注システムが停止した、委託先から情報漏えいの連絡が来た、管理者アカウントが乗っ取られた、といった自社固有のシナリオを使います。連絡網、証拠保全、復旧優先順位、顧客・委託元への報告、経営判断を時系列で試し、訓練後に手順書を改訂します。 3．脆弱性管理：資産把握から是正確認まで閉じる 脆弱性管理は、単発の診断ではなく、①資産把握、②情報収集、③影響判定、④優先順位付け、⑤修正または緩和策、⑥再確認、⑦例外承認の一連のプロセスです。インターネット公開資産は継続的に把握し、重大な脆弱性は期限と責任者を設定します。期限内に修正できない場合は、アクセス制限、WAF、監視強化などの代替策と、残余リスクを承認者が記録します。 Webアプリケーション診断は、認証、入力処理、権限管理などアプリ固有の問題を確認します。プラットフォーム診断は、OS、ミドルウェア、ネットワーク機器などの設定や既知脆弱性を確認します。ペネトレーションテストは、複数の弱点を組み合わせて実際にどこまで侵入・権限拡大・情報到達が可能かを検証します。目的に応じて使い分け、重大改修や公開前、定期点検のタイミングに組み込みます。 4．教育：受講率ではなく行動変容を測る 全社員向け教育は、パスワード、フィッシング、情報持ち出し、事故報告を基本とし、入社時と年次で実施します。ただし受講率100％だけでは不十分です。標的型メール訓練の報告率、誤送信の再発、端末放置、委託先データの扱いなど、実際の行動指標を確認します。 管理者、開発者、営業、人事、調達には役割別教育が必要です。例えば開発者にはセキュアコーディングと依存ライブラリ管理、調達担当には委託先評価と契約条項、経営層には重大事故時の判断訓練を行います。 5．内部点検：証跡の有無と運用実態を確認する 内部点検では、要求事項ごとに規程、実施記録、システム設定、担当者ヒアリングを突き合わせます。「規程がある」だけで適合とせず、例えばアカウント棚卸しなら、対象一覧、実施日、差異、削除結果、承認記録まで確認します。点検担当者は可能な範囲で実施担当者と分け、自己確認の盲点を減らします。 指摘事項は、重大度、事業影響、期限、責任者、是正方法、再確認結果を一つの改善台帳で管理します。更新直前に資料を集めるのではなく、月次の運用記録を所定の場所へ保管するルールが有効です。 6．更新管理：変更をトリガーに再評価する 更新管理は、毎年のカレンダーだけでは不十分です。M&A、事業譲渡、新拠点、クラウド移行、基幹システム刷新、大規模なネットワーク変更、重要な委託先の変更、重大インシデントを「臨時評価のトリガー」として定義します。経営企画や購買部門から情報システム部門へ変更情報が届くワークフローを設けます。 ★3は1年ごとの更新、★4は毎年の自己評価と3年ごとの第三者評価が想定されています。正式な申請方法、費用、解説書などは公表予定の情報を必ず確認し、制度の具体化に応じて計画を更新してください。 月次・四半期・年次で回す実務スケジュール 月次：変化と未対応を把握する 月次では、重大アラート、インシデント、外部公開資産、重大脆弱性、パッチ未適用、入退社アカウント、バックアップ失敗、改善課題の期限超過を確認します。会議は60分程度でも構いません。件数の報告だけで終わらず、事業影響が大きい上位課題について、担当者と期限を決めます。 四半期：部門横断でリスクを見直す 四半期ごとに、システム変更、委託先変更、教育結果、アクセス権棚卸し、復旧テスト、SOCの検知ルール、例外承認の期限をレビューします。経営層には、重大リスクの残高、是正遅延、必要予算、取引への影響を簡潔に報告します。 年次：要求事項全体と経営方針を再確認する 年次では、適用範囲、資産・データ・取引先、規程、リスク評価、教育、訓練、診断、内部点検、経営者レビューを一巡させます。★3または★4の手続きに必要な自己評価へ接続し、前年との差分と未解決事項を明示します。年度予算の編成前にギャップを洗い出せば、診断費、監視費、ツール更改、人材育成費を稟議に載せやすくなります。 実施前に準備すべき資料と、成果物に含めるべき項目 継続運用の設計時には、情報セキュリティ規程、組織図、責任分担表、IT資産・クラウド・外部公開資産の一覧、ネットワーク図、データ分類、委託先一覧、契約上のセキュリティ条項、インシデント記録、教育記録、診断報告書、改善台帳、バックアップ・復旧記録を準備します。すべてが揃っていなくても、欠落自体を課題として管理すれば着手できます。 成果物には、適用範囲、現状評価、要求事項とのギャップ、リスク評価、優先順位、改善ロードマップ、責任者、期限、概算費用、代替策、残余リスク、必要な証跡、更新・臨時評価の条件を含めるべきです。技術部門向けの詳細版と、経営判断向けの要約版を分けると、稟議と実行の双方に使えます。 期間と費用を左右する要因 継続運用モデルの立ち上げ期間は、対象範囲、拠点数、システム数、既存規程の成熟度、委託先数、★3・★4のどちらを目指すかによって変わります。現状調査から運用開始まで数か月単位で設計し、重大な技術課題は別途改修計画を置くのが現実的です。制度申請そのものの費用は、2026年9月時点で今後公表予定とされています。 費用を左右する主な要因は、支援範囲、現地確認の要否、Webアプリケーション診断・プラットフォーム診断の対象数、ペネトレーションテストの範囲、SOCの監視対象と時間帯、ログ量、CSIRT訓練の複雑さ、文書作成支援の程度です。見積もりでは「適合支援」「技術対策」「運用代行」「評価・申請関連」を分けると比較しやすくなります。 社内稟議で説明すべき内容 稟議では、マーク取得だけを目的にすると投資対効果が伝わりにくくなります。対象となる重要取引、停止時の売上・顧客影響、機密情報の種類、既存契約上の義務、現状の不足、取得後の維持費、担当工数を示します。さらに、診断・監視・訓練で得られる成果を「更新対応」「事故低減」「取引先への説明」「復旧力向上」に分けて説明します。 経営層が判断すべきなのは、目標段階、適用範囲、許容する残余リスク、優先する事業、予算、責任者です。情報システム部門だけに取得責任を負わせず、経営企画、人事、法務、調達、現場部門の協力を経営判断として明確にすることが重要です。 支援会社の選び方とRFP・見積依頼時の確認事項 支援会社は、制度文書を作る能力だけでなく、技術検証と日常運用をつなげられるかで選びます。RFPや見積依頼では、制度の最新情報への追随方法、★3・★4ごとの経験・支援方針、ギャップ評価の手法、成果物、担当体制、秘密情報の保管・削除、再委託、事故時の連絡、診断後の再確認、SOC・CSIRT支援、更新時の支援範囲を確認してください。 評価とコンサルティングを同一法人が提供する場合の中立性・公平性に関する要件は、今後詳細化される予定です。評価機関の指定状況や利益相反管理を確認し、取得支援と正式評価の役割を契約上も明確にする必要があります。 よくある失敗と注意点 適用範囲を狭くしすぎる 審査負担を下げるために範囲を狭くすると、重要な受発注システム、クラウド、拠点、委託先が外れ、取引先が期待する説明と一致しない場合があります。法人単位だけでなく、部門、拠点、システム、データ、取引関係を図示して決めます。 ツール導入を対策完了と考える EDRやSIEMを導入しても、アラートを確認する人、遮断判断、例外管理、障害時の代替手順がなければ運用されません。製品の導入記録ではなく、検知から是正までの実績を確認します。 診断結果を放置する 診断報告書を受領しても、改修責任者と期限が決まらなければリスクは残ります。事業影響と悪用可能性で優先順位を付け、修正後は再診断または設定確認を行います。受容する課題は、理由と期限を経営または権限者が承認します。 証跡に個人情報や機密情報を残しすぎる 評価用証跡には、従業員情報、構成情報、脆弱性、ログなどの機密情報が含まれます。提出目的に必要な範囲へ限定し、マスキング、暗号化、アクセス制限、保管期限、削除確認を定めます。支援会社との秘密保持、再委託、国外保管の有無も確認が必要です。 Librus株式会社が提供できる支援 Librus株式会社は、サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）への対応を、現状把握から取得準備、技術対策、取得後の運用まで一気通貫で支援します。制度要求と現場の実装を分断せず、経営・財務・事業継続・取引先対応の観点を含めて設計します。 具体的には、適用範囲の整理、ギャップ評価、規程・手順の整備、改善ロードマップ、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築・運用、インシデントレスポンス、デジタルフォレンジック、教育・訓練、SBOM導入・運用、内部点検、更新支援に対応可能です。企業ごとの環境や予算に合わせ、優先順位を付けて段階的に進めます。 よくある質問 Q1．SCS評価制度はいつ始まりますか。 IPAのFAQでは、★3・★4は2027年3月頃の運用開始予定です。申請方法や取得ガイドは2026年10月頃、評価機関は2026年12月末頃、セキュリティ専門家は2027年1月以降の公開予定とされています。最新情報はIPA公式サイトで確認してください。 Q2．★3を取得してからでないと★4を取得できませんか。 いいえ。IPAの制度説明では、上位段階は下位段階の事項を含みますが、★3の事前取得が★4取得の条件になる関係ではありません。自社の取引上の要請とリスクに応じて目標を選びます。 Q3．取得後は毎年何を行いますか。 ★3は有効期間1年で、年次点検と専門家の確認・助言を経た自己評価更新が想定されています。★4は有効期間3年ですが、毎年自己評価を実施し、評価機関へ提出する想定です。日常的には月次の監視・脆弱性管理と、四半期の横断レビューを行うと年次評価へ接続しやすくなります。 Q4．取得後にクラウド移行した場合、更新まで待ってよいですか。 大規模なクラウド移行やネットワーク変更など、適用範囲や基準達成に大きく影響する変更では、再度の確認・評価が必要になる想定です。変更計画の段階で影響評価を行い、専門家または評価機関へ確認してください。 Q5．SOCを必ず内製する必要がありますか。 内製に限定する必要はありません。外部SOCを活用する場合は、監視範囲、対応時間、重大度基準、連絡先、初動権限、ログ保管、再委託、サービス終了時のデータ返却を明確にします。社内には事業判断と連携を担う責任者が必要です。 Q6．脆弱性診断は毎年一度で十分ですか。 システムの重要性と変更頻度によります。重大な改修、公開範囲の変更、新機能追加、基盤更改があれば、その都度の診断を検討します。定期診断の間も資産把握、脆弱性情報収集、パッチ管理、外部公開面の監視を継続します。 Q7．ISMSを取得済みでもSCS対応は必要ですか。 制度構築方針ではSCSとISMSは相互補完的な位置付けです。ISMSの規程、リスク評価、内部監査などは活用できますが、SCS固有の要求事項、適用範囲、取引先管理、技術検証との差分を確認する必要があります。 Q8．何から相談すればよいですか。 目標段階や対象範囲が決まっていなくても、重要な取引、システム、データ、委託先、現状の対策を整理するところから始められます。最初に簡易ギャップ評価を行うと、必要な施策と予算の優先順位が見えやすくなります。 まとめ――SCS評価制度を経営と現場の改善サイクルに変える サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、取得時点の対策状況を可視化する仕組みです。取得後も安全が自動的に維持されるわけではありません。SOC、CSIRT、脆弱性管理、教育、内部点検、更新管理を月次・四半期・年次の業務へ落とし込み、システムや事業の変更時には臨時評価を行うことが重要です。 継続運用によって、更新準備の負担を抑えるだけでなく、事故の早期検知、復旧力、取引先への説明力、予算判断の質を高められます。規程と技術、経営と現場をつなぎ、通常業務の記録がそのまま適合の証跡になる状態を目指してください。 SCS取得後の運用設計から相談できます 「取得後に誰が運用を担うか決まっていない」「既存のISMSや社内規程を生かしたい」「診断、SOC、教育をどの順番で進めるべきか分からない」といった段階でもご相談いただけます。Librus株式会社は、対象範囲と現状の対策を整理し、事業影響と予算に応じた優先順位、年間運用計画、必要な証跡、技術的な改善策まで具体化します。取得準備だけでなく、その後も無理なく維持できる体制を設計することで、取引先への説明と実際のリスク低減を両立しやすくなります。 監修者 鎌田光一郎：青山学院大学法学部卒業。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評価制度で規程だけでは足りない理由 ログ、台帳、申請記録、教育記録、議事録を証跡として成立させる条件 ★3と★4を見据えた準備の違いと、証跡台帳の作り方 Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストを証跡につなげる方法 準備期間・費用を左右する要因と、支援会社を選ぶ際の確認事項 SCS評価制度と「証跡」の基本 SCS評価制度は何を評価する制度か SCS評価制度は、サプライチェーンを構成する企業のセキュリティ対策を共通の基準で評価・可視化し、委託元と委託先の双方が適切な対策水準を判断しやすくする制度です。IPAの公式説明では、委託先への攻撃に起因する事業・サービスの提供途絶、機密情報の漏えい・改ざん、委託先を踏み台とした不正侵入などのリスクを対象にしています。全てのサプライチェーン企業が対象とされ、特にリソースの限られる中小企業での活用効果が想定されています。 2026年9月時点の公表情報では、★3は一般的なサイバー脅威に対処できる水準、★4は初期侵入の防御だけでなく、被害拡大の防止や取引先のデータ・システム保護、サプライチェーン上の役割に応じた強靱化策まで含む水準です。★3はセキュリティ専門家の確認を伴う自己評価、★4は評価機関による第三者評価と技術検証が予定されています。★3・★4の運用開始は2027年3月頃の予定です。今後公開される解説書や申請要領によって実務詳細が更新される可能性があるため、申請前には最新版を確認してください。 出典：IPA「SCS評価制度」 出典：IPA「SCS評価制度の詳細情報」 出典：IPA「要求事項・評価基準」 証跡とは、運用の事実を再現できる記録 ここでいう証跡とは、ルールに沿った行為やシステム処理が、いつ、誰によって、何を対象に、どのような結果で行われたかを確認できる記録です。文書、システムログ、チケット、メール、ワークフロー履歴、診断報告書など形式は問いません。ただし、単にファイルが存在するだけでは弱く、対象範囲、期間、責任者、承認、結果、例外処理が読み取れることが重要です。 たとえば「退職者のアカウントは速やかに削除する」と規程に書いてあっても、退職者一覧とアカウント削除チケット、実施日時、確認者が結び付かなければ、運用実績を十分に説明できません。反対に、入退社ワークフローからID管理システムへ連携され、削除完了ログと月次照合記録が残るなら、ルールが継続的に機能していることを示しやすくなります。 なぜ規程だけでは足りないのか 規程は設計図であり、運用実績そのものではない 規程は統制の出発点です。しかし、審査対象は規程の文章力ではありません。担当者がルールを認識し、対象システムに対策を実装し、定期的に確認し、問題があれば是正しているかが焦点となります。規程の最終改定日が古い、実際のクラウド利用と記載内容が一致しない、例外承認の手続が形骸化しているといった状態では、文書と実態の不整合が生じます。 ★3では専門家が作成書類を確認し、★4では文書確認に加えて実地審査と技術検証が想定されています。また、適用範囲から対象をサンプリングして評価する考え方が示されています。つまり、代表的な一件だけを整えるのではなく、どの拠点・部署・システムが選ばれても、一定品質の証跡が提示できる状態が必要です。 証跡が弱いと、実効性と説明責任の両方が崩れる 証跡不足は審査対応の遅れだけでなく、実際のインシデント対応にも影響します。ログの保存期間が不明なら侵入経路を追えず、資産台帳が古ければ脆弱な機器の所在を特定できません。申請記録がなければ過剰権限の付与理由を検証できず、教育記録がなければ対象者の未受講を把握できません。議事録が残っていなければ、経営層がどのリスクを認識し、どの対策を承認したかを説明しにくくなります。 取引先から短期間でSCS評価制度への対応を求められた場合、証跡が分散している企業は収集と整合確認に時間を取られます。回答の遅れや説明のばらつきは、セキュリティ部門だけの問題にとどまらず、入札、契約更新、新規受注、事業継続にも影響し得ます。経営層はSCS対応を「認証の取得費」ではなく、取引維持と説明責任のための経営基盤整備として捉えることが重要です。 SCS審査に備えて整理すべき主な証跡 ログ：取得しているだけでなく、確認と対応まで示す 認証ログ、管理者操作ログ、EDRやアンチウイルスの検知ログ、ファイアウォール・VPNログ、クラウド監査ログ、バックアップジョブログなどは、技術対策の稼働状況を示す基礎資料です。ただし、ログが保存されているだけでは、異常を検知して対応する運用までは証明できません。監視ルール、アラートのトリアージ記録、インシデントチケット、月次レビュー結果まで関連付けておくと、検知から対応までを説明できます。 証跡としては、対象システム名、ログ種別、取得元、保存先、保存期間、時刻同期、閲覧権限、レビュー頻度、異常時の連絡先を一覧化します。スクリーンショットだけに依存すると改ざん防止や網羅性を説明しにくいため、可能であれば管理画面からのエクスポート、設定ファイル、チケット番号など原記録へたどれる情報を残します。機密情報や個人情報を含むログは、提出用にマスキングした写しと、原本の保管場所・閲覧手順を分けて管理します。 台帳：資産・アカウント・委託先を同じ範囲で管理する 資産台帳は、端末やサーバの一覧だけではありません。クラウドサービス、ネットワーク機器、業務アプリケーション、外部公開資産、ソフトウェア、重要データ、管理者アカウント、委託先との接続点まで含めて考えます。台帳の更新責任者と頻度を定め、購買・入社・異動・退職・廃棄などの業務イベントと連動させることが重要です。 審査で説明しやすい台帳には、識別子、所有部門、管理責任者、用途、重要度、設置・利用場所、OSやバージョン、サポート期限、外部公開の有無、バックアップ、最終確認日を持たせます。すべてを一つの台帳に詰め込む必要はありません。CMDB、端末管理、SaaS管理、契約管理など複数の仕組みを使う場合は、どれを正本とするか、相互の照合方法は何かを明確にします。 申請・承認記録：権限付与と例外の妥当性を示す アカウント発行、特権付与、外部接続、ソフトウェア導入、USBメモリ利用、データ持出し、設定変更などは、申請者、承認者、対象、理由、期限、実施者、完了確認が追跡できる記録を残します。特に期限付きの特権や例外は、失効処理までを一つの案件として管理する必要があります。 ありがちな失敗は、メールで承認を得た後に担当者の受信箱だけへ残るケースです。共有ワークフローやチケットへ集約し、検索可能な案件番号を付けます。緊急変更は事前承認が難しいこともあるため、事後承認の期限、影響確認、ロールバック結果を定めておくと、現実の運用と規程を両立できます。 教育記録：受講率だけでなく、対象と改善を説明する 教育記録では、教材名、実施日、対象者、受講結果、未受講者への督促、理解度テスト、追加教育、教材改定履歴を残します。全社員向け研修だけでなく、管理者、開発者、情報システム担当者、インシデント対応要員など役割別教育も整理すると、職務に応じた力量管理を示せます。 標的型メール訓練では、開封率など単一の数字を競うより、報告手順が機能したか、再教育が必要な部門はどこか、次回の改善策は何かを記録する方が実務的です。個人を責める運用にすると報告が遅れるため、教育の目的と個人データの利用範囲を明確にしてください。 議事録：経営判断と改善サイクルを残す 経営会議、リスク委員会、情報セキュリティ委員会、インシデント振り返り会議などの議事録は、セキュリティが経営課題として管理されていることを示します。日時と出席者だけでなく、報告されたリスク、判断の根拠、決定事項、予算、責任者、期限、継続課題を記載します。 経営層が判断すべき事項は、取得を目指す段階、適用範囲、受容する残余リスク、重大インシデント時の権限、改善予算、取引先への要求水準です。議事録とリスク台帳、改善計画、次回会議のフォロー結果がつながれば、PDCAが動いていることを説明できます。 証跡を審査で使える状態にする6つの手順 1．目標段階と適用範囲を決める 最初に★3または★4のどちらを目指すか、対象とする法人、拠点、部門、業務、システム、委託先を決めます。取引先のデータやシステムへのアクセス、サービス停止時の影響、機密情報の取扱いを基準に境界を引きます。範囲を狭めること自体が目的になると、実際のリスクや取引要件とずれるため、除外理由も記録します。 2．要求事項と証跡を対応付ける 要求事項ごとに、関連規程、実施部門、利用システム、証跡名、保存場所、対象期間、責任者、不足点を整理した証跡台帳を作ります。一つの証跡が複数要件を支える場合も、逆に一つの要件に複数証跡が必要な場合もあります。ファイル名の羅列ではなく、何を証明する資料かを一文で記載します。 3．サンプルで一連の流れを再現する 入社者のアカウント発行、重大脆弱性の対応、インシデント訓練など代表的な案件を選び、起点から完了確認まで追跡します。規程、申請、承認、システム反映、レビューの間に欠落があれば、証跡収集ではなく業務プロセスを修正します。 4．証跡の品質を確認する 良い証跡は、真正性、完全性、追跡可能性、期間整合性、再現性を備えます。作成者や日時が分からない、対象範囲が曖昧、編集可能なファイルだけ、別資料との数字が不一致といった問題を点検します。原本、提出用写し、機密情報のマスキングルールも定めます。 5．技術検証で実装を確かめる ★4を見据える場合、文書の整合だけでなく技術的な有効性も確認します。Webアプリケーション診断では認証・認可や入力処理、プラットフォーム診断ではOS・ミドルウェア・ネットワーク機器の設定や既知脆弱性を検証します。ペネトレーションテストでは、現実的な攻撃経路を用いて複数の弱点が連鎖した場合の到達可能性や影響を確認します。対象、前提、実施日、検出事項、リスク評価、是正責任者、再確認結果を報告書と改善台帳へ反映します。 6．定例運用へ組み込む 証跡は審査直前の特別作業にしないことが重要です。月次のアカウント棚卸し、四半期の資産照合、年次教育、変更時のリスク評価など、頻度とトリガーを業務カレンダーへ組み込みます。証跡台帳の更新状況をKPIとして確認し、未完了や例外を会議で扱います。 審査準備の期間と費用を左右する要因 準備期間は、従業員数だけでは決まりません。適用範囲の拠点・システム数、クラウドとオンプレミスの混在、委託先数、既存のISMS等の運用状況、台帳の精度、ログ保存期間、規程と実態の差、技術検証の範囲、是正に必要なシステム改修によって変わります。既に運用が定着していても、証跡の保管場所が部門ごとに分散していると収集に時間がかかります。反対に、規程が未整備でも対象範囲が限定され、意思決定が速ければ段階的に進められる場合があります。 実務では、現状把握、ギャップ分析、改善計画、規程・手順改定、ツール設定、運用実績の蓄積、模擬審査の順で進めます。短い準備期間では、設備投資だけを先行させず、取引上の重要度とリスクに基づいて優先順位を付けるべきです。緊急度の高い外部公開資産、多要素認証、特権管理、バックアップ復旧、脆弱性対応、インシデント連絡体制などから着手し、中長期項目は責任者と期限を伴う改善計画にします。 社内稟議では、制度対応そのものに加え、対象となる主要取引、未対応時に想定される契約・入札上の影響、対象範囲、現状ギャップ、必要な社内工数、外部費用、運用開始後の維持費、成果物を説明します。認証・登録取得だけを目的にすると、更新時に再び証跡が不足します。平時の運用品質向上と取引先への説明時間短縮も投資効果に含めると、経営判断につながりやすくなります。 支援会社の選び方とRFPで確認すべきこと SCS評価制度への対応支援会社を選ぶ際は、規程雛形の提供だけでなく、現場の実装、証跡設計、技術検証、改善運用まで支援できるかを確認します。制度要求をそのままチェックリスト化するだけでは、実態とのずれや過剰投資が生じやすいためです。経営層、情報システム部門、総務・人事、開発、営業、購買など複数部門の役割を整理し、現行の稟議やワークフローへ落とし込める会社が適しています。 見積依頼時には、目標段階、対象法人・拠点・システム、重要取引、既存認証、希望時期を共有します。そのうえで、ギャップ分析の方法、成果物、証跡台帳の有無、技術検証の範囲、是正支援、模擬審査、再確認、機密情報の取扱い、再委託、データ保存場所、削除方法、制度更新への対応を確認してください。支援と評価を同じ法人が担う場合の中立性・公平性については今後の制度詳細も確認する必要があります。 成果物には、適用範囲定義書、要求事項別ギャップ一覧、証跡台帳、規程・手順の改定案、技術検証報告書、リスク別の改善計画、経営報告資料、審査時の説明要領を含めると実務で使いやすくなります。報告書は問題点の列挙ではなく、事業影響、悪用可能性、対応難易度、依存関係を踏まえて優先順位を示すことが重要です。 よくある失敗と注意点 審査直前にスクリーンショットを集める 画面証跡は一時点の状態しか示さず、継続運用や母集団全体を説明できないことがあります。設定値のエクスポート、チケット履歴、定期レビュー記録などと組み合わせ、取得日と対象を明記してください。 規程と現場で使う手順が別物になっている 規程では情報システム部門の承認が必要でも、現場が独自にSaaSを契約していると、シャドーITが台帳から漏れます。購買・経費精算・SSOの情報を照合し、現実の業務フローに合わせて統制を設計します。 証跡の量を品質と取り違える 大量の資料は、かえって矛盾を生みます。要求事項ごとに主証跡と補助証跡を定め、審査者が短時間で結論へ到達できる索引を用意します。最新版、承認済み、対象期間内の資料を優先します。 診断を実施して終わる Webアプリケーション診断やプラットフォーム診断で問題を発見しても、改修、リスク受容、代替統制、再診断の記録がなければ改善サイクルを説明できません。診断結果をチケット化し、責任者と期限を割り当て、残課題を経営層へ報告します。 個人情報・機密情報を過剰に提出する 審査用証跡には従業員情報、顧客情報、IPアドレス、認証情報などが含まれ得ます。必要最小限の範囲に絞り、マスキング、暗号化、アクセス制御、受渡し方法、保管期限、返却・削除を事前に合意してください。秘密保持契約だけでなく、実際の取扱手順を確認することが大切です。 Librus株式会社が提供できるSCS評価制度対応支援 Librus株式会社は、サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）に向けた現状評価から、適用範囲の設計、要求事項とのギャップ分析、規程・手順整備、証跡台帳の構築、改善計画、模擬確認まで一気通貫で支援します。企業ごとのシステム構成、組織体制、取引先要求、予算策定と稟議プロセスを踏まえ、過不足のない進め方を個別に設計します。 特徴は、文書整備だけで終わらない点です。Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築・運用支援、インシデントレスポンス、デジタルフォレンジック、教育・訓練などを組み合わせ、規程と技術実装、日常運用の整合を確認できます。経営上のリスクを整理しながら、情報システム部門と現場部門の実務へ落とし込むことが可能です。 大企業との取引継続、取引先監査、M&A、IPOなど重要局面では、限られた期間で優先順位を明確にする必要があります。Librus株式会社は、グローバルスタンダードを踏まえつつ、日本企業の意思決定や現場運用に合わせ、取得準備後の改善・継続運用まで見据えて支援します。 よくある質問 SCS評価制度では、規程があれば証跡として認められますか。 規程は重要な証跡の一つですが、それだけで運用実績を示すことは困難です。申請・承認記録、ログ、台帳、点検結果、是正記録などを組み合わせ、規程どおりに実施していることを説明します。 証跡は何か月分用意すればよいですか。 必要期間は要求事項、運用頻度、今後の申請要領によって異なります。現時点で一律の期間を断定せず、月次・四半期・年次など各統制が少なくとも一度は実施されたことを示せるよう、早めに記録を蓄積してください。 Excelの台帳でも問題ありませんか。 形式より、正確性、更新責任、変更履歴、アクセス制御、他の記録との整合性が重要です。Excelを使う場合も、正本の保存場所、更新者、承認方法、バックアップを明確にします。 ★3と★4では証跡準備がどう違いますか。 ★3は専門家確認付き自己評価、★4は第三者評価と技術検証が想定されています。★4では文書の整合に加え、実地での運用確認や技術的な有効性を説明できる準備がより重要です。 ISMSを取得していればSCS対応は不要ですか。 既存のマネジメントシステムや証跡は活用できますが、SCS評価制度の適用範囲と要求事項に照らした確認が必要です。自動的に代替できると決めつけず、差分を整理してください。 脆弱性診断は必ず必要ですか。 必要な技術検証は目標段階、対象範囲、システムの性質、最新の制度文書によって判断します。ただし、外部公開Webや基盤の弱点を客観的に把握し、是正まで追跡することは、実効性の説明に役立ちます。 証跡が不足している場合、申請を諦めるべきですか。 まず不足を要求事項別に整理し、短期で補える記録と、運用実績の蓄積が必要な項目を分けます。優先度、責任者、期限を設定すれば、段階的に準備できます。 対象範囲がまだ決まっていなくても相談できますか。 可能です。主要取引、扱う情報、停止時の影響、外部接続、委託関係を整理し、事業上合理的な範囲を設計するところから進められます。 まとめ：SCS評価制度対応は「残す運用」から始める サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）で重要なのは、規程を増やすことではなく、決めた対策が現場で実施され、その事実と改善結果を追跡できる状態をつくることです。ログ、台帳、申請記録、教育記録、議事録を要求事項と結び付け、規程・実施・結果・改善の連鎖を示せるようにします。 まずは目標段階と適用範囲を定め、代表的な業務を一件たどってください。途中で承認、実装、確認、是正の記録が途切れるなら、そこが改善の出発点です。制度の最新文書を確認しながら、審査のためだけではなく、取引先への説明、インシデント対応、事業継続に役立つ証跡管理を整えることが、持続的なセキュリティ向上につながります。 SCS評価制度の準備状況を、証跡から確認しませんか 「どの範囲を対象にすべきか分からない」「規程はあるが、どの記録を証跡として示せるか不安」「★3と★4のどちらを目指すべきか整理したい」といった段階でも相談可能です。Librus株式会社では、制度要求と現場運用の両面から現状を確認し、既存資料を活かせる部分、追加対策が必要な部分、優先順位を整理します。準備範囲や実施方法が固まっていなくても、主要取引やシステム構成を伺い、社内で判断しやすい進め方をご提案します。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム

VIEW MORE