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

SCS評価制度とPマーク・SOC 2・業界ガイドラインの関係

サプライチェーン強化に向けたセキュリティ対策評価制度（以下「SCS評価制度」）への準備で、PマークやSOC 2を取得済みなら、最初から仕組みを作り直す必要はありません。ただし、既存認証を持っているだけでSCS評価制度の要求を自動的に満たすわけでもありません。制度ごとに目的、対象範囲、評価方法が異なるためです。 実務上の結論は、既存の規程や証跡を制度別に管理するのではなく、「要求事項―社内統制―証跡―責任者」の対応表を一つ作り、共通利用できるものと不足部分を切り分けることです。例えば、アクセス権申請、ログ監視、インシデント対応訓練、委託先評価の記録は複数制度で活用できます。一方、Webアプリケーション診断やプラットフォーム診断、ペネトレーションテストなど、技術的な有効性を裏付ける追加検証が必要になる場合があります。 本記事では、従業員100～1,000名程度の企業を想定し、SCS評価制度とPマーク、SOC 2、金融・医療等の業界ガイドラインをどう整理し、監査・取引先回答・経営報告に使える証跡体系へまとめるかを解説します。なお、制度の詳細は今後更新され得るため、申請時点のIPA公式資料を必ず確認してください。 この記事で分かること この記事を読むと、各制度の目的と守備範囲の違い、既存認証をSCS評価制度へ流用できる範囲、証跡の共通化手順、技術検証の組み込み方、社内稟議や外部支援会社の選定で確認すべき点が分かります。特に重要なのは、「認証を何個持っているか」ではなく、「必要な統制が対象範囲で実際に機能し、その事実を再現可能な証跡で説明できるか」という視点です。 SCS評価制度とは何か SCS評価制度は、取引先を含むサプライチェーン全体のセキュリティ対策を段階別に可視化し、発注者と受注者の間で共通言語として使うことを想定した制度です。経済産業省と内閣官房国家サイバー統括室の監督のもと、IPAが運営します。委託元が取引先に適切な段階を示し、対策の実施状況を確認する利用場面が想定されています。 IPAの公表情報では、★3は一般的なサイバー脅威に対処し得る水準で、専門家確認付き自己評価です。★4は、初期侵入の防御だけでなく、被害拡大や攻撃目的の遂行を抑え、取引先のデータ・システム保護や自社の役割に応じたサプライチェーン強靱化策まで含む水準で、第三者評価と技術検証が予定されています。★5は高度な攻撃を想定したリスクマネジメントとベストプラクティスを念頭に、今後さらに具体化される位置付けです。上位段階の申請に、下位段階の事前取得が必須という関係ではありません。★3・★4は2027年3月頃の運用開始が予定されています。 出典：経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度」https://www.meti.go.jp/policy/netsecurity/scs.htmlIPA「SCS評価制度の詳細情報」https://www.ipa.go.jp/security/scs/details.htmlIPA「よくある質問」https://www.ipa.go.jp/security/scs/faq.html 評価対象は会社全体とは限らない SCS評価制度では、取得希望組織が適用範囲を決め、その中から対象をサンプリングして評価することが想定されています。したがって、最初に決めるべきなのは「全社で取るか」ではなく、どの取引、拠点、業務、システム、クラウドサービス、委託先を評価対象にするかです。重要顧客へ提供するサービスだけを狭く切り出すと準備負担は下がりますが、共通基盤や本社機能が範囲外になり、実態と説明が合わないことがあります。契約上の責任範囲、ネットワーク境界、データフロー、運用責任者を基準に決めることが重要です。 SCS評価制度とPマーク・SOC 2・業界ガイドラインの違い 複数制度は競合するものではなく、異なるリスクを異なる方法で確かめる仕組みです。Pマークを持つ企業がSCS評価制度にも対応し、クラウドサービスについてSOC 2報告書を顧客へ提示し、さらに金融・医療の業界要求を満たすことは矛盾しません。むしろ、目的の違いを理解せず、一つの認証で全要求を代替できると考えることが問題になります。 制度・基準主な目的主な対象評価・確認の特徴SCSとの関係SCS評価制度サプライチェーン上のサイバー対策を段階評価組織が定めた取引・業務・システム等★3は専門家確認付き自己評価、★4は第三者評価・技術検証を予定比較の中心。取引要請への共通言語Pマーク個人情報保護マネジメントシステムの構築・運用原則として国内事業者の法人単位JIS Q 15001に基づく運用指針への適合を審査規程、教育、委託先管理、事故対応等を部分流用SOC 2サービス組織の統制について利用者等へ保証を提供対象サービスと、その提供に関係するシステム・統制独立した監査人がTrust Services Criteriaに照らして報告アクセス管理、変更管理、ログ、可用性等の証跡を部分流用業界ガイドライン業種固有の法規制・リスクへの対応金融、医療、重要インフラ等の対象事業・システム監督指針、契約、監査等と結び付く場合があるSCSを土台に固有要求を追加する Pマークは個人情報保護が中心 プライバシーマーク制度は、JIS Q 15001に基づく個人情報保護マネジメントシステム（PMS）を整備し、実際の事業活動で個人情報を適切に取り扱う体制を評価します。付与単位は原則として法人です。個人情報の特定、リスク分析、教育、委託先管理、事故対応、内部監査、マネジメントレビュー等はSCS評価制度の準備にも役立ちます。 ただし、Pマークはサイバー攻撃への技術的耐性だけを評価する制度ではありません。脆弱性管理、境界防御、侵害拡大防止、検知・対応能力などについては、Pマークの運用証跡だけでは説明が不足する可能性があります。Pマーク取得済み企業ほど、PMS文書を無批判に転用するのではなく、情報資産の範囲を「個人情報」から「取引先の重要情報、設計情報、認証情報、業務継続に必要なシステム」へ広げる作業が必要です。 出典：プライバシーマーク制度「制度の概要」https://privacymark.jp/system/about/outline_and_purpose.html SOC 2は対象サービスの統制を説明する保証報告 SOC 2は、AICPAのTrust Services Criteriaを用いて、サービス組織のシステムに関する統制を独立した監査人が検証する枠組みです。セキュリティを共通基準とし、契約やサービス特性に応じて可用性、処理のインテグリティ、機密保持、プライバシーを扱います。Type 1は特定時点の統制設計、Type 2は一定期間にわたる運用状況を対象とする点も、単純な認証マークとは異なります。 SOC 2報告書が対象とするサービス、システム境界、除外事項、サブサービス組織、対象期間を確認しなければ、SCS評価制度への利用可否は判断できません。例えば、クラウドサービスAのSOC 2報告書は、同じ法人が運営する受託開発部門Bや国内拠点全体を当然にはカバーしません。一方で、ID管理、特権アクセス、変更管理、バックアップ、ログレビュー、インシデント管理などの統制記述と運用証跡は、有力な基礎資料になります。 出典：AICPA & CIMA「SOC 2 - SOC for Service Organizations」https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2 業界ガイドラインは業種固有の上乗せ要件 金融機関向けのFISC安全対策基準、医療情報システムの安全管理に関するガイドラインなどは、事業停止時の社会的影響、取り扱う情報の機微性、システム構成、監督上の要請を踏まえた具体性を持ちます。SCS評価制度を取得しても、業界固有の責任分界、外部委託、クラウド利用、非常時運用等の要求が消えるわけではありません。 例えば金融機関向けサービスでは、顧客の外部委託先管理やシステムリスク管理に耐える説明が必要です。医療分野では、医療機関とサービス提供者の責任分界、認証・認可、保守接続、バックアップ、証跡レビュー等を具体化します。SCS評価制度は共通基盤、業界ガイドラインは追加レイヤーと考えると整理しやすくなります。 出典：FISC「安全対策」https://www.fisc.or.jp/publication/pubcat/sm/厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版」https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html なぜ今、複数制度を一体管理すべきなのか 取引先ごとの質問票、Pマーク更新、SOC 2監査、業界別監査を別々の担当者と文書で回すと、同じアクセス権一覧や教育記録を何度も収集することになります。回答内容が制度ごとに食い違えば、統制そのものより説明の不整合が問題になります。さらに、営業が顧客へ回答した内容と、情報システム部門の実運用が一致しないまま契約上の保証となることもあります。 一体管理の目的は、監査工数の削減だけではありません。経営者が重要取引の継続条件を把握し、投資の優先順位を決められる状態をつくることです。取引先から★4を求められる可能性があるのに、翌年度予算へ技術検証やEDR、ログ保管、復旧訓練の費用を織り込んでいなければ、運用開始直前の対応は難しくなります。制度対応を営業継続、受注資格、BCPの課題として扱う必要があります。 対応しない場合に起こり得る問題 SCS評価制度への未対応が直ちに法令違反や一律の取引停止を意味するわけではありません。しかし、発注者が調達条件として一定段階を求めるようになれば、評価未取得や説明不足が新規取引、契約更新、委託範囲の判断に影響する可能性があります。特に、自社が大企業の業務システムを運用する、機密設計情報を扱う、顧客ネットワークへ接続する、再委託先を多数利用するといった場合は優先度が高まります。 攻撃面では、VPN機器や公開サーバーの脆弱性から侵入され、認証情報を窃取され、委託元環境への接続口を踏み台にされるケースが考えられます。メールアカウント侵害による取引情報の流出、ランサムウェアによる納品停止、開発環境への侵入によるソースコード改ざんも、サプライチェーン上の影響が大きい事象です。Pマークの教育記録やSOC 2報告書があっても、未修正の公開脆弱性や過大な特権が残っていれば実害は防げません。 証跡と統制を共通利用する7つの手順 1．経営が目標段階と対象取引を決める 最初に、主要顧客の調達方針、扱う情報、停止時の売上影響、代替困難性を踏まえ、目標とする★と期限を仮決定します。経営会議では、認証取得費だけでなく、改善投資、運用人員、維持費を含めて判断します。顧客要請が未確定なら、売上上位顧客、重要インフラ関連、機密情報を扱う業務から優先順位を付けます。 2．適用範囲と責任分界を図にする 組織図だけでは不十分です。業務プロセス、情報の流れ、利用SaaS、クラウド、ネットワーク、拠点、再委託先、保守会社を一枚の構成図と台帳にします。自社が実施する統制、クラウド事業者に依存する統制、顧客側の責任を分けることで、証跡の所在が明確になります。 3．制度横断のコントロールマトリクスを作る 各制度の要求をそのまま横に並べるのではなく、アクセス管理、脆弱性管理、ログ監視、インシデント対応、事業継続、委託先管理、教育などの統制テーマへ正規化します。行には統制、列にはSCS、Pマーク、SOC 2、業界ガイドラインを置き、該当要求、実施部署、頻度、証跡、保管先、不備、改善期限を記録します。これが監査回答の基礎台帳になります。 4．証跡の品質を確認する 規程が存在するだけでは、運用の有効性は説明できません。アクセス権棚卸しなら、対象者一覧、承認記録、差異、是正結果、実施日、責任者まで必要です。教育なら受講率だけでなく、未受講者への督促や理解度確認も証跡になります。ログ監視では、ログを保存している事実に加え、アラートの判断基準、対応チケット、エスカレーション記録を確認します。個人情報や顧客機密を含む証跡は、閲覧権限、提出方法、マスキング、保管期限も定めます。 5．不足をリスクで優先順位付けする 不備は件数順ではなく、取引への影響、攻撃可能性、被害規模、外部公開の有無、代替策の有効性で評価します。インターネット公開機器の重大な脆弱性、共有管理者ID、多要素認証の欠如、バックアップ復元未検証などは、文書表現の不足より先に改善すべきです。改善計画には、恒久対応、期限、責任者、予算、完了条件、暫定措置を含めます。 6．技術検証で実装の有効性を確かめる Webアプリケーション診断は、認証・認可不備や入力処理等、Web固有の脆弱性を確認します。プラットフォーム診断は、OS、ミドルウェア、ネットワーク機器、クラウド設定などを調べます。ペネトレーションテストは、攻撃者の視点で複数の弱点を組み合わせ、重要資産へ到達できるかを検証します。目的が異なるため、単に「診断実施済み」とせず、対象資産、脅威、深度に応じて選びます。 RFPや見積依頼では、対象URL・IP・クラウド環境、認証後画面、API、実施時間、停止回避条件、再診断、報告会、機密情報の取扱い、再委託、事故時連絡、報告書サンプルを確認します。成果物には、経営向け要約、技術的根拠、再現条件、影響、リスク評価、推奨対策、優先順位、対象外範囲を含めるべきです。 7．運用サイクルへ組み込む 評価取得を一度きりのプロジェクトにしないことが重要です。月次の脆弱性管理、四半期のアクセス権棚卸し、年次の教育・訓練、委託先見直し、インシデント対応演習、経営レビューなど、既存会議へ統制確認を組み込みます。組織変更、M&A、新規クラウド導入、重要な再委託、重大インシデントがあれば、定例を待たず適用範囲とリスクを再評価します。 準備資料、期間、費用を左右する要因 準備では、情報セキュリティ規程、資産台帳、ネットワーク・データフロー図、アカウント一覧、権限棚卸し記録、脆弱性・パッチ管理記録、ログ監視記録、インシデント対応計画と訓練記録、バックアップ・復旧試験、教育記録、委託先台帳・契約、過去の診断報告書、PマークやSOC 2の審査資料などを集めます。資料名より、最新版か、対象範囲が一致するか、承認と実施記録が残るかが重要です。 期間は、適用範囲、目標段階、拠点・システム数、既存認証の成熟度、証跡の蓄積期間、技術改善の量、評価機関との調整で変わります。初期ギャップ分析だけなら比較的短期間でも可能ですが、ログ運用や権限棚卸しなど一定期間の実績が必要な統制は、文書作成だけでは埋まりません。余裕を持って年度予算と人員計画へ組み込むべきです。 費用も申請・評価費だけでなく、コンサルティング、ツール導入、診断、ペネトレーションテスト、規程改定、教育、運用工数、再評価まで含めて見積もります。全社一律に高額な製品を導入するより、重要資産へ優先配分し、既存ツールの設定改善や運用統合で代替できる部分を見極める方が合理的です。 社内稟議で説明すべき内容 稟議では「認証取得のため」だけでは投資効果が伝わりません。①主要取引先と売上への影響、②求められる可能性のある段階と期限、③現状との差分、④事故時の事業停止・復旧・信用への影響、⑤既存のPマーク・SOC 2・業界対応を共通利用できる範囲、⑥初年度と維持年度の費用、⑦社内責任者と外部支援範囲、⑧取得できない場合の代替説明を示します。 特に、情報システム部門だけに責任を寄せないことが重要です。営業は顧客要求の把握、法務・購買は契約と委託先管理、人事は教育、事業部門は業務継続、経営はリスク受容と予算判断を担います。制度対応を横断プロジェクトとして位置付けることで、監査直前の資料集めから、平時の統制運用へ移行できます。 支援会社を選ぶ際の確認ポイント 支援会社には、制度文書の作成能力だけでなく、技術と経営の両面を確認します。具体的には、SCS要求事項と既存制度をマッピングできるか、適用範囲を事業・契約から設計できるか、診断やペネトレーションテストを含む技術検証に対応できるか、改善後の運用設計まで支援するかを確認してください。 見積比較では、成果物の名称だけで判断せず、ヒアリング回数、現地確認、対象拠点・システム、証跡サンプル数、規程改定、技術検証、再確認、経営報告、申請支援が含まれるかを揃えます。また、評価を担う立場と改善支援を担う立場の独立性、利益相反、機密情報の保管・削除、再委託先も確認が必要です。制度開始前の段階では、公式に登録・指定されたかのような不適切な説明がないことも重要です。 出典：経済産業省「SCS評価制度に係る不適切な勧誘に御注意ください」https://www.meti.go.jp/policy/netsecurity/20260427_scs.html よくある失敗と注意点 既存認証があれば追加対応は不要と考える 制度間で目的と範囲が違うため、認証書だけでは代替できません。報告書、適用範囲、統制記述、例外事項、証跡を要求事項単位で照合します。 規程を増やしすぎる 制度ごとに似た規程を作ると、更新漏れと矛盾が生じます。共通の基本規程と手順を中心にし、業界固有事項は付則や管理基準で補完する方が運用しやすくなります。 対象範囲を曖昧にしたまま診断を発注する 公開Webだけを診断しても、取引先接続端末やクラウド管理面が重要なら目的を満たしません。情報資産と攻撃経路を整理してから、診断対象と手法を決めます。 評価直前に証跡を作る 後から整えた記録は、継続運用の証明になりにくく、実態との不一致も起きます。日常業務から自動的に証跡が残るチケット、承認フロー、ログ保管の仕組みを設計します。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度に向けた現状分析、適用範囲の設計、Pマーク・SOC 2・業界ガイドラインとの要求事項マッピング、規程・証跡整備、改善計画、経営報告、運用定着まで一気通貫で支援します。単にチェックリストを埋めるのではなく、取引上の重要性と実際の攻撃経路を踏まえ、優先順位を設計します。 技術面では、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習、SOC／CSIRT構築・運用、インシデントレスポンス、デジタルフォレンジックを組み合わせられます。経営面では、リスクアセスメント、情報セキュリティ体制構築、教育、SBOM、M&A・IPO・取引先監査等の重要局面にも対応します。既存の認証やツールを生かしながら、企業ごとの環境、予算、期限に合わせて支援範囲を個別設計できる点が特徴です。 よくある質問 Q1．PマークがあればSCS評価制度を取得できますか？ Pマークだけで自動的に取得できるわけではありません。ただし、個人情報管理、教育、委託先管理、事故対応、内部監査等の規程と証跡は活用できます。SCS固有の対象範囲とサイバー対策との差分確認が必要です。 Q2．SOC 2 Type 2報告書はSCS評価の代わりになりますか？ 原則として別の枠組みです。対象サービス、期間、統制、例外事項がSCSの適用範囲と一致する部分は有力な証跡候補になりますが、不足要求は別途対応します。 Q3．業界ガイドラインとSCSはどちらを優先すべきですか？ 法令、監督上の要請、契約上の義務を優先しつつ、SCSを共通基盤として統合します。片方を選ぶのではなく、業界固有要求を上乗せする考え方が実務的です。 Q4．★3を取らずに★4を目指せますか？ IPAの公表情報では、★3の事前取得が★4取得の条件という関係ではありません。ただし、★4は★3相当を包含するため、現状とのギャップと準備負担を確認して目標を決めます。 Q5．どの部署が主管になるべきですか？ 情報システムまたはセキュリティ部門が事務局を担う例が多いものの、経営、営業、法務、購買、人事、事業部門を含む横断体制が必要です。取引条件とリスク受容は経営判断です。 Q6．診断とペネトレーションテストのどちらが必要ですか？ 目的で選びます。個別資産の既知の弱点を網羅的に確認するなら脆弱性診断、攻撃経路を組み合わせて重要資産への到達可能性や検知・対応を確かめるならペネトレーションテストが適します。 Q7．準備はいつ始めるべきですか？ 対象範囲の整理とギャップ分析は早期に始めるのが合理的です。運用証跡の蓄積や予算化には時間がかかるため、顧客要請が確定してからでは選択肢が狭まる場合があります。 Q8．既存の取引先質問票は使えますか？ 利用できます。ただし、質問への回答だけでなく、対応する統制、証跡、対象範囲、責任者をひも付けてください。回答の根拠が明確になり、SCSや他の監査への再利用が容易になります。 まとめ：制度別対応から統制・証跡の一体管理へ サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）、Pマーク、SOC 2、業界ガイドラインは、目的も対象範囲も評価方法も異なります。したがって、一つの認証ですべてを代替することはできません。一方、アクセス管理、教育、委託先管理、ログ監視、インシデント対応、事業継続など、共通利用できる統制と証跡は多くあります。 実務では、対象範囲を定め、制度横断のコントロールマトリクスを作り、証跡の品質を確認し、技術検証で実装の有効性を確かめます。制度取得そのものをゴールにせず、重要取引の継続と事故時の被害抑制につながる運用へ落とし込むことが、経営上の価値になります。 SCS評価制度の準備を、既存資産を生かして始めたい企業へ まず現状と不足項目を整理する PマークやSOC 2の資料をどこまで使えるか分からない場合は、既存の規程・証跡とSCS要求事項のギャップを整理するところから相談できます。Librus株式会社は、対象範囲や目標段階が未確定の段階でも、重要取引とリスクを踏まえ、優先して確認すべき項目と準備の進め方を可視化します。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F電話：03-6772-8015お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

発注企業が構築すべき「取引先SCS管理」の実務 | 重要度分類・★取得要請・進捗管理・未達企業支援を一気通貫で設計する

SCS評価制度の取引先管理は「対象・期限・支援」の設計から始める 結論から言えば、発注企業が構築すべき「取引先SCS管理」は、全取引先に同じ星を一律要求する仕組みではありません。自社事業への影響を基準に取引先を分類し、必要な★（段階）と期限を定め、証跡を確認し、未達先には改善支援またはリスク低減策を講じる継続的な管理プロセスです。 サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、委託元が委託先に適切な段階を提示し、対策を促し、実施状況を確認する利用を想定しています。したがって、発注企業に必要なのは「取得してください」という通知文だけではありません。誰を対象とし、どの水準を、いつまでに、誰が確認し、未達をどう扱うかを、調達・情報システム・法務・事業部の共通ルールとして定める必要があります。 この記事で分かること 取引先を事業影響で分類し、★3・★4の要請水準を決める方法 依頼、回答、証跡、期限、例外を管理する台帳と会議体の設計 未達企業を直ちに排除せず、改善計画と代替統制で支援する方法 Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストを使い分ける考え方 予算、期間、稟議、RFP、ベンダー選定で押さえる実務ポイント SCS評価制度とは何か SCS評価制度は、取引先へのサイバー攻撃を起点とする情報漏えい、改ざん、サービス停止、踏み台化などのリスクに対し、必要な対策水準を段階別に示し、マーク取得を通じて対策状況を可視化する制度です。経済産業省と内閣官房国家サイバー統括室の監督のもと、IPAが運営します。 制度上、★3は一般的なサイバー脅威に対処し得る水準で、セキュリティ専門家の確認を経た自己評価が基本となります。★4は、初期侵入の防御だけでなく、被害拡大防止や取引先データ・システムの保護、サプライチェーン上の役割に応じた強靱化を求め、第三者評価と技術検証を伴います。★5は高度な攻撃への対応を想定するが、2026年9月時点では今後の具体化事項が残っています。上位段階は下位段階を包含するが、★4取得の前提として★3取得が必須という関係ではありません。 一次情報：IPA「SCS評価制度」／制度の詳細情報／要求事項・評価基準 なぜ今、発注企業に取引先SCS管理が必要なのか チェックシート配布だけでは、残存リスクが分からない 従来の取引先調査では、自社独自の質問票を年1回送付し、回答が返れば完了とする運用が少なくありません。しかし、回答が自己申告のまま検証されない、重要な取引先と軽微な取引先が同じ設問になる、再委託先が管理対象から漏れる、といった弱点があります。SCS評価制度は共通水準を利用できるため、発注企業ごとの質問のばらつきを減らし、取引先との会話を「回答したか」から「必要水準を満たしたか」へ移しやすくなります。 サイバーリスクは財務・供給・信用の問題でもある 取引先のVPN機器やクラウド管理者アカウントが侵害されれば、攻撃者が発注企業の接続環境へ侵入するおそれがあります。受発注システムや生産管理システムを担う委託先がランサムウェア被害を受ければ、納品停止や代替調達費用が発生する可能性もあります。個人情報や設計情報を預ける先で漏えいが生じた場合、顧客説明や規制対応は委託先だけの問題では済みません。経営層は、SCS対応を情報システム部門の認証取得施策ではなく、事業継続と取引信用を守る施策として判断すべきです。 参考：経済産業省「サイバーセキュリティ経営ガイドライン Ver 3.0」、IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」 対応しない場合に起こり得る問題 制度対応を先送りしただけで直ちに違法になるとは限りません。しかし、取引先管理が弱いままでは、事故後に「なぜ重要委託先を把握していなかったのか」「なぜ契約上の報告期限がなかったのか」「なぜ既知の未達を放置したのか」を説明できません。さらに、顧客や親会社からSCSマークを取引条件として求められた際、対象先の棚卸しから始めることになり、更新契約や新規案件に間に合わない可能性があります。 一方、要求水準を過度に高く設定すると、取引先の費用負担が増え、代替困難な技術・部材の供給者との関係を損なう可能性があります。重要なのは、事故ゼロを約束することではなく、リスクに比例した要求と、未達時の意思決定記録を残すことです。 対象となる取引先・システム・場面 管理対象は、ITベンダーだけに限定しません。個人情報・営業秘密・設計情報を扱う業務委託先、基幹システムやクラウドを運用する事業者、自社ネットワークに接続する保守会社、工場設備の遠隔保守先、物流・決済・コールセンターなど停止時の影響が大きい先が中心となります。再委託先や海外拠点を含めるかも、データフローと契約関係から判断します。 取引先SCS管理を構築する8つの手順 1. 経営方針と責任者を決める 取引先リスクの受容水準、★3・★4を求める基本方針、例外を承認できる役職を経営会議等で決めます。実務責任者は情報セキュリティ部門が担っても、取引継続の最終判断は事業責任者・調達責任者と共有します。 2. 取引先と委託内容を棚卸しする 契約台帳、支払先一覧、システム構成図、データフロー、外部接続一覧を照合します。取引先名だけでなく、提供サービス、委託データ、接続方式、再委託、代替可能性、契約更新月、インシデント連絡先を記録します。 3. 重要度を分類する 「機密性」「完全性」「可用性」「接続性」「代替困難性」の各観点で影響を評価します。取引金額が小さくても、管理者権限を持つ保守会社や単一供給源は高重要度となる可能性があります。 4. 必要な★と期限を設定する 一般的な脅威への基礎的対応を求める先には★3、高い事業影響、重要データ、特権接続、停止許容時間の短い先には★4を検討します。ただし制度文書、業界要請、契約責任を確認し、自社判断の基準として明文化します。 5. 取引先へ要請し、相談窓口を設ける 通知には、要請理由、対象範囲、求める★、期限、提出物、機密情報の送付方法、質問先、未達時の協議手順を記載します。一方的な通告では、誤解や形式対応を招きやすくなります。 6. 証跡と進捗を管理する ステータスは「未案内、説明済、ギャップ分析中、改善中、申請中、取得済、例外承認、再評価予定」程度に統一します。担当者の主観的な「対応中」だけでなく、次の行動、期限、責任者、根拠資料を残します。 7. 未達企業を支援し、残存リスクを扱う 不足対策を重大度と実現難度で分け、短期是正、中期計画、代替統制に整理します。例えば多要素認証の即時導入が難しい場合、接続元制限、権限縮小、監視強化、利用時間制限を暫定策として検討します。 8. 年次更新と変更時レビューを行う マーク取得だけで終了せず、契約更新、システム変更、再委託開始、M&A、重大インシデントの発生時に再評価します。取引先台帳とSCS台帳を分離すると更新漏れが起こるため、調達・契約のワークフローと連動させます。 重要度分類と★取得要請の判断基準 区分典型例基本方針追加確認重要度A基幹・生産・決済、特権接続、重要データ、大規模停止影響★4を軸に個別に判断します。取得までの移行計画を設定第三者評価、技術検証、BCP、事故連絡、再委託重要度B業務SaaS、個人情報取扱、重要業務の一部委託★3を基本に、影響が高ければ★4適用範囲、改善計画、脆弱性管理、バックアップ重要度C機密情報や接続が限定的で代替可能★要請の要否をリスクに基づき判断最低限の契約条項、連絡先、定期見直し ※上表はLibrus株式会社による実務上の分類例であり、制度が全取引先に一律の★を指定するものではありません。自社の業種、規制、顧客要求、事業影響に合わせて調整します。 進捗管理台帳に必要な項目 最低限、取引先ID、契約・サービス名、事業オーナー、重要度、要求する★、現在の取得状況、適用範囲、有効性を確認した日、証跡の保管先、ギャップ、改善責任者、期限、暫定措置、残存リスク、例外承認者、次回レビュー日を記録します。証跡には機密情報が含まれる可能性があるため、閲覧権限、保存期間、暗号化、外部共有方法も決めます。 月次会議では、取得率だけをKPIにはしません。重要度Aの未達件数、期限超過、重大ギャップの平均滞留日数、暫定措置未実施件数、インシデント連絡先の確認率など、リスクが減ったかを示す指標を用います。 未達企業への支援方法 「排除」か「放置」かの二択にしない 未達先が代替困難である場合、取引停止は自社の供給リスクを高めます。まず、要求事項との差分を確認し、経営承認が必要な規程・体制、ツール導入が必要な技術対策、運用定着が必要な教育・訓練に分解します。そのうえで90日、180日などの改善計画を合意し、重大項目から是正します。期限内に取得できない場合は、対象データの削減、接続分離、権限の最小化、監視強化、バックアップ確認などで残存リスクを下げます。 診断・テストを目的に応じて使い分ける Webアプリケーション診断は、取引先が提供するWebシステムの入力処理、認証、セッション、アクセス制御などを確認します。プラットフォーム診断は、サーバー、OS、ミドルウェア、ネットワーク機器の既知脆弱性や設定不備を確認します。ペネトレーションテストは、攻撃者の視点で複数の弱点を組み合わせ、重要資産へ到達できるかを検証します。SCSの証跡作成だけを目的に機械的に実施するのではなく、★4の技術検証や重大ギャップの有効性確認など、確認したいリスクから手法を選びます。 実施期間と費用を左右する要因 取引先管理の構築は、対象が数十社で台帳が整っていれば2〜3か月程度で初期設計できる場合があります。一方、数百社を超え、契約・システム・データの所在が分散している場合は、優先対象から段階導入する方が現実的です。制度側の審査期間や評価機関の稼働は別途考慮する必要があり、固定的な取得期間を約束することは適切ではありません。 費用は、対象取引先数、棚卸し精度、重要度評価の粒度、説明会や個別支援の回数、ギャップ分析の深さ、規程・契約改定、技術検証の範囲、複数拠点・海外対応、進捗管理ツール連携によって変わります。見積依頼では「SCS対応一式」ではなく、設計、展開、個社支援、診断、運用の各工程を分けると比較しやすくなります。 社内稟議とRFPで説明・確認すべき事項 稟議では事業損失と取引要請を起点にする 制度の概要だけでは予算判断につながりにくい傾向があります。重要委託先の停止許容時間、預託データ、外部接続、代替調達日数、顧客からの要求状況を示し、「どのリスクを、どの順番で、どこまで下げるか」を説明します。初年度に全社一斉導入せず、重要度Aから開始するロードマップも有効です。 RFP・見積依頼時の確認項目 制度文書と要求事項・評価基準を踏まえた支援範囲 発注企業側の取引先分類・管理プロセス設計の経験 ★3の専門家確認、★4の第三者評価・技術検証との役割分担 診断結果を改善計画と運用へ接続できる体制 機密情報・個人情報の保管場所、再委託、削除方法 成果物、会議体、レビュー回数、追加費用条件 制度変更時の更新支援と、取得後の継続管理 サービス提供会社の選び方 重要なのは、制度説明ができることだけではありません。発注企業側の調達管理、取得企業側のギャップ改善、技術診断の三つをつなげられるかを確認します。成果物のサンプルでは、台帳や規程の体裁より、重要度の根拠、未達時の判断、改善後の検証まで追えるかを確認します。経営層向け報告と現場向け是正指示を分けて作成できることも重要です。 よくある失敗と注意点 全社一律で★4を要求する リスクに比べ要求が過大となり、取引先の反発や形式対応を招きます。重要度分類と例外ルールを先に作ります。 取得マークだけで安全と判断する 評価には適用範囲があります。自社との取引に関係する拠点、システム、サービスが範囲内か確認します。 調達部門だけで運用する 技術的妥当性を判断できず、情シスだけでは取引継続を決められません。部門横断の責任分担が必要です。 未達先へ期限だけ通知する 原因が予算、人材、規程、技術のどこにあるか把握できず、改善が進みません。個社別のギャップと支援メニューを用意します。 診断を一度実施して終了する システム変更や新たな脆弱性で状態は変わります。再診断、継続監視、教育、インシデント演習へつなげます。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度に関する現状把握、適用範囲の整理、取引先重要度分類、★取得要請方針、管理台帳・会議体・例外承認の設計、個社説明、ギャップ分析、改善ロードマップまで一気通貫で支援します。制度対応だけでなく、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築、インシデントレスポンス、教育・訓練を組み合わせ、発見した課題を改善・運用までつなげます。 経営上の事業継続・取引信用と、現場のアクセス制御・脆弱性管理を同じリスク軸で整理できる点が特長です。大企業の統制要件と、中堅・中小取引先の人員・予算制約の双方を踏まえ、過不足のない個別設計を行います。 よくある質問 Q1. すべての取引先にSCSマーク取得を求めるべきですか？ 一律要請は推奨しません。委託情報、外部接続、事業停止影響、代替可能性などで重要度を分類し、対象と水準を決めます。 Q2. ★3と★4はどう使い分けますか？ ★3は一般的な脅威への対応水準、★4は被害拡大防止や第三者評価・技術検証まで含みます。重要データ、特権接続、停止影響が大きい取引先では★4を検討します。 Q3. 取引先が期限までに取得できない場合は？ 未達理由と重大ギャップを確認し、改善期限、暫定措置、責任者を合意します。例外は期限付きで承認し、残存リスクと再評価日を記録します。 Q4. ISO 27001を取得済みならSCS確認は不要ですか？ 制度や適用範囲、評価観点が同一とは限りません。既存認証を証跡として活用しつつ、自社取引に必要な範囲とSCS要求との差分を確認します。 Q5. Web診断やペネトレーションテストは必須ですか？ 対象となる段階、評価・技術検証の具体的な要件、およびリスクによって異なります。診断を先に決めず、守る資産と確認目的から手法を選びます。 Q6. 管理の主管部門はどこが適切ですか？ セキュリティ部門または情報システム部門が制度・技術を統括し、調達が契約・台帳、事業部が重要度と継続判断、法務が条項と事故対応を担う形が現実的です。 Q7. どの程度の期間を見込むべきですか？ 対象数と台帳整備状況に左右されます。重要先の選定、基準設計、試行、展開の順で進め、制度側の審査・評価期間は別に見込みます。 Q8. 制度の詳細が更新された場合はどうしますか？ IPAの公式ページ、基本規程、要求事項・評価基準を定期確認し、契約条項、社内基準、取引先案内を版管理します。 まとめ｜SCS評価制度を「取引先の継続管理」に変える サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）を実務で機能させる鍵は、★取得率ではなく、重要な取引先の残存リスクを把握し、改善を継続できることにあります。発注企業は、①棚卸し、②重要度分類、③★と期限の設定、④証跡・進捗管理、⑤未達支援、⑥例外承認、⑦定期見直しを一つの業務フローとして設計すべきです。 制度の詳細は今後も更新される可能性があります。最新の公式文書を確認しながら、最初から全取引先を完璧に管理しようとせず、事業影響の大きい委託先から段階的に始めることが、現実的かつ説明可能な進め方となります。 制度対応と技術対策を一体で進めたい企業へ SCS評価制度への対応に加え、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストなどの実施範囲が決まっていない場合もご相談いただけます。制度上の要求と実際の攻撃リスクを結び付けることで、過不足の少ない対策計画と予算化につなげることが可能となります。 主な参考資料 IPA「サプライチェーン強化に向けたセキュリティ対策評価制度」 IPA「SCS評価制度の詳細情報」 IPA「要求事項・評価基準」 IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」 経済産業省「サイバーセキュリティ経営ガイドライン」 監修者 鎌田光一郎：青山学院大学法学部を卒業しました。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍しました。金融機関に対するコンサルティング業務に従事しました。その後、Librus株式会社を設立、代表取締役に就任しました。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム

VIEW MORE