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

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