※本稿は、2026年8月30日時点で公開されているIPAおよびNISTの資料に基づいています。SCS評価制度については、今後、自己評価等ガイド、要求事項・評価基準の解説書、登録申請の手引などが公表される予定です。公開時点で追加資料が公表されている場合は、最新の内容を確認してください。
※質問票への回答が契約上どのような意味を持つかは、質問票、誓約書、基本契約、個別契約などの内容によって異なります。重要な取引に関する回答は、必要に応じて契約担当者や弁護士へ確認してください。
「未対応と書くと、取引を断られるのではないか」
取引先からセキュリティ質問票が届くと、このような不安を感じることがあります。
例えば、次の質問です。
全ての管理者アカウントに多要素認証を設定していますか。
実際には、Microsoft 365の管理者には設定しているものの、古い業務システムの管理者IDには設定できていない。
それでも、「おおむね対応しているから」と考えて「はい」を選びたくなるかもしれません。
しかし、質問が「全ての管理者アカウント」を対象としているのであれば、一部に未設定のアカウントが残っている状態を、単純に「はい」と回答するのは適切ではありません。
一方、「いいえ」だけを選び、何の説明も加えなければ、全く対策をしていないように受け取られる可能性があります。
必要なのは、未対応を隠すことでも、必要以上に悪く見せることでもありません。
現在の状態、実施済みの対策、残っている課題、暫定的な代替策、完了予定日、責任者を、事実に基づいて説明することです。
IPAの調査では、発注元から情報セキュリティ対策に関する要請を受けた経験がある中小企業は1割強でした。要請への対応上の課題としては、対策費用の確保、契約内容の明確化、専門人材の確保・育成などが挙げられています。質問票が届いた時点で全ての対策が完成しているとは限らず、不足項目をどのように管理し、改善につなげるかも重要になります。
今回は、取引先から届くセキュリティ質問票について、未対応項目を正確に回答する方法を整理します。
質問票は「満点を取るための試験」ではない
セキュリティ質問票は、発注者が取引先や委託先の状況を把握し、自社の事業や情報にどのようなリスクがあるかを判断するために使われます。
IPAが2026年4月に公開したプラクティス例でも、発注者が取引先・委託先へアンケートを行い、回答内容に応じて追加質問や証跡の提出を求め、懸念事項を一覧化して経営者へ報告したうえで、組織としての対応方針を検討する流れが示されています。
質問票の目的は、回答企業を一律に落とすこととは限りません。
回答から次のことを把握し、取引上のリスクを判断することが主な目的です。
| 発注者が確認したいこと | 回答側が説明すること |
|---|---|
| どのような対策を実施しているか | 対象、方法、頻度、最新の実施状況 |
| 未対応の項目があるか | 対象となるシステムや範囲 |
| 未対応によるリスクは何か | 想定される影響と残存リスク |
| 当面の対策があるか | 代替策、監視、利用制限 |
| 今後改善する予定があるか | 担当者、期限、予算、進捗 |
| 回答内容を確認した人は誰か | 技術確認者、業務責任者、承認者 |
IPAの別のプラクティス例では、委託先の規模や体制に応じて求める対策や質問項目を調整し、直近3年以内に未達事項があっても取引を継続するという対応例も示されています。これは全ての発注者が同じ扱いをすることを意味しませんが、未達項目があることと、直ちに取引不能になることは同じではないと分かります。
未対応項目を正しく説明し、改善状況を確認できるようにすることが、取引先との信頼につながります。
過去の記事との違い
過去の記事「SCS・SECURITY ACTIONの次に作る『証跡ファイル』とは？」では、取引先へ対策状況を説明するために、規程、台帳、教育記録、バックアップ記録、アカウント確認記録などを整理する方法を取り上げました。
今回の記事では、証跡そのものではなく、証跡を確認した結果、完全には対応できていない項目が見つかったときの回答方法に重点を置きます。
最初に回答を五つの状態へ分ける
質問票の回答を「はい」「いいえ」だけで考えると、実態を正確に表しにくくなります。
社内で確認するときは、まず次の五つに分けてください。
| 状態 | 意味 |
|---|---|
| 対応済み | 質問の対象範囲全体で要求を満たし、証跡も確認できる |
| 一部対応 | 一部の部門、システム、アカウントなどでは未対応が残っている |
| 未対応 | 要求された対策を実施していない |
| 対象外 | 質問の前提となる業務、システム、データ等が存在しない |
| 確認中 | 現時点では実施状況を確定できない |
質問票の選択肢が「はい」「いいえ」しかない場合でも、社内ではこの五つへ分けてから回答します。
例えば、一部対応の状態を「はい」とするか「いいえ」とするかは、質問文と発注者の回答要領によって異なります。
回答方法が不明な場合は、推測せず、発注者へ次のように確認してください。
一部の対象では実施済みですが、一部未対応が残っています。
この場合、「いいえ」を選択したうえで備考欄へ実施状況を記載する理解でよいでしょうか。
分からないまま、自社に都合のよい解釈で回答しないことが重要です。
「導入予定」は「対応済み」ではない
次のような回答には注意が必要です。
年度内に導入予定のため、「はい」と回答しました。
将来の予定が決まっていても、回答基準日時点で導入されていなければ、現在の対策として実施済みとはいえません。
例えば、質問票の回答基準日が2026年9月30日で、多要素認証の導入予定日が2026年12月1日であれば、9月30日時点の状態は未対応または一部対応です。
次の三つを分けて記載します。
| 項目 | 記載例 |
|---|---|
| 現在の状態 | 一部対応 |
| 現在の代替策 | 接続元IPアドレス制限、利用者限定、操作ログの日次確認 |
| 恒久対応 | 2026年12月1日までに多要素認証へ移行予定 |
「予定」「検討中」「申請中」「見積取得済み」は、それぞれ進捗を示す情報にはなります。
しかし、対策が完了したことを示す情報ではありません。
質問文の範囲を確認する
セキュリティ質問票で回答を誤る原因の多くは、技術知識の不足だけではありません。
質問がどこまでを対象としているか、確認しないまま回答することです。
例えば、次の質問があったとします。
業務用端末のディスクを暗号化していますか。
この質問だけでは、次の点が分かりません。
- ノートパソコンだけが対象か
- デスクトップパソコンも含むか
- スマートフォンやタブレットを含むか
- 委託先が使用する端末を含むか
- 取引先業務に使用する端末だけが対象か
- 暗号化の状態を集中管理することまで求めているか
回答前に、少なくとも次の四つを明確にします。
対象範囲
どの会社、部門、拠点、システム、端末、アカウントを回答対象とするのかを確認します。
基準日
いつの状態について回答するのかを確認します。
用語の意味
「重要情報」「管理者」「定期的」「速やかに」などの言葉が、質問票内で定義されているかを確認します。
回答単位
全社の対策を答えるのか、今回の委託業務に関係する環境だけを答えるのかを確認します。
質問票に説明がなければ、備考欄へ自社が回答した範囲を記載します。
本回答は、貴社から受託する業務に利用する東京本社およびクラウド環境を対象としています。店舗の独立したPOS環境は本回答の対象外です。
対象範囲を明記すれば、発注者も回答の意味を判断しやすくなります。
良い回答に含めたい八つの情報
未対応や一部対応の項目には、次の八つを記載すると状況を説明しやすくなります。
| 項目 | 記載する内容 |
|---|---|
| 1．回答区分 | 対応済み、一部対応、未対応、対象外、確認中 |
| 2．対象範囲 | 対象となる部門、システム、端末、アカウント |
| 3．現在の状態 | 何が実施済みで、何が未実施か |
| 4．証跡 | 設定画面、台帳、ログ、規程、契約、作業記録 |
| 5．未対応理由 | 製品制約、予算、移行中、業務影響など |
| 6．代替策 | 現在実施している暫定的なリスク低減策 |
| 7．改善計画 | 恒久対策、担当者、完了予定日、進捗確認日 |
| 8．承認 | 残存リスクと改善計画を確認・承認した責任者 |
文章にすると、次の形になります。
一部対応です。
Microsoft 365、VPNおよびクラウド管理者アカウントには多要素認証を設定しています。
一方、旧販売管理システムの管理者アカウント2件は、製品仕様上、多要素認証へ対応していません。
当該システムは社内ネットワークからのみ利用可能とし、管理者IDを個人別に分離したうえで、操作ログを月次確認しています。
2027年1月31日までに多要素認証へ対応した後継システムへ移行する計画です。
担当者は情報システム担当、業務責任者は営業部長、残存リスクと移行計画は2026年9月25日に代表取締役が承認しています。
この回答であれば、単純な「はい」「いいえ」よりも、現在の状況と今後の予定が明確です。
代替策は「別の対策を何かしている」だけでは足りない
未対応項目に対して、別のセキュリティ製品を導入していることを説明すれば、必ず代替策になるわけではありません。
代替策は、本来の対策が減らすはずだったリスクを、別の方法でどこまで減らせるかを検討するものです。
例えば、多要素認証が未対応であることに対して、次の回答だけでは十分な説明になりません。
ウイルス対策ソフトを導入しています。
ウイルス対策ソフトは重要ですが、パスワードが漏えいした場合の不正ログインを直接防ぐ対策ではありません。
代替策を記載するときは、次の六つを確認します。
1．本来の対策が防ぐリスク
多要素認証であれば、パスワードの窃取や使い回しによる不正ログインなどです。
2．未対応の理由
「以前から使っているから」ではなく、製品仕様、業務停止の影響、ベンダーの回答、予算承認待ちなど、確認できた事実を記載します。
3．現在の代替策
接続元制限、VPN経由への限定、個人別ID、強固なパスワード、ログ監視などを記載します。
4．代替策の対象範囲
全利用者に適用しているのか、管理者だけなのか、特定の拠点だけなのかを記載します。
5．残っているリスク
代替策を実施しても、多要素認証と同じ水準にはならない場合があります。
「代替策により完全に安全」と断定せず、残存するリスクを記載します。
6．終了条件
いつまで暫定運用を続け、何が完了したら代替策を終了するのかを決めます。
代替策は、未対応を永久に正当化するための説明ではありません。
恒久対策までの期間、リスクを減らすための管理方法として位置付けます。
代替策の記載例
例1 多要素認証が一部未対応
不十分な回答
一部のシステムでは未対応ですが、セキュリティには注意しています。
改善した回答
一部対応です。
クラウドサービス、VPNおよび管理者アカウントの計43件中、41件は多要素認証を設定済みです。
旧勤怠管理システムの管理者アカウント2件は製品仕様上対応できません。
当該管理画面へのアクセスは社内固定IPアドレスからのみに制限し、個人別の管理者IDを使用しています。管理者操作ログは総務責任者が毎月確認しています。
2026年12月末までに後継製品へ移行する計画であり、移行責任者は総務部長です。残存リスクと移行計画は2026年9月20日に代表取締役が承認しました。
例2 パッチ適用期限を満たせない機器がある
不十分な回答
原則として更新しています。
改善した回答
一部対応です。
Windows端末およびインターネット公開サーバーについては、社内手順に従って更新状況を月次確認しています。
一方、製造設備に接続された制御用パソコン1台は、装置メーカーの動作保証上、最新OSへ更新できません。
当該端末は一般業務ネットワークおよびインターネットから分離し、接続可能な端末と通信先を制限しています。USB媒体の利用は禁止し、装置メーカーへ四半期ごとに対応状況を確認しています。
2027年度の設備更新時に後継環境へ移行する計画です。設備管理部長が責任者となり、情報セキュリティ責任者が半年ごとに継続可否を確認します。
例3 インシデント対応訓練を実施していない
不十分な回答
手順書があるため対応可能です。
改善した回答
未対応です。
インシデント対応手順書と社内外の連絡先一覧は作成済みですが、全社的な机上訓練はまだ実施していません。
現在は、情報システム担当者と管理部門で連絡網を四半期ごとに確認しています。
2026年11月30日までに、ランサムウェア感染を想定した机上訓練を実施します。訓練責任者は管理部長、訓練結果と改善事項の承認者は代表取締役です。
代替策や改善計画は、質問票の備考欄へ書き切れないことがあります。
その場合は、別紙として「未対応項目・改善計画一覧」を作成します。
未対応項目・改善計画一覧のひな型
| 管理番号 | 質問番号 | 現在の状態 | 未対応範囲 | 未対応理由 | 代替策 | 残存リスク | 恒久対策 | 担当者 | 承認者 | 完了期限 | 次回確認 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| SEC-001 | Q12 | 一部対応 | 旧勤怠システムの管理者2件 | 製品仕様 | IP制限、個人別ID、ログ確認 | パスワード漏えい時の不正利用 | 後継製品へ移行 | 総務担当 | 代表取締役 | 2026年12月31日 | 2026年10月31日 |
| SEC-002 | Q25 | 未対応 | 全社訓練 | 実施計画未策定 | 連絡網の四半期確認 | 初動判断の遅れ | 机上訓練を実施 | 管理部長 | 代表取締役 | 2026年11月30日 | 2026年10月15日 |
NISTでは、未解決の課題について、必要な作業、資源、途中の達成点、完了予定日を記録する「Plan of Action and Milestones」という考え方が示されています。名称をそのまま使用する必要はありませんが、予定日だけでなく、作業内容と進捗確認日まで記録する点は参考になります。
「対象外」は理由を説明する
未対応と対象外は異なります。
例えば、次の質問があるとします。
再委託先のセキュリティ対策状況を定期的に確認していますか。
自社が業務を再委託していない場合は、対象外と回答できる可能性があります。
ただし、備考欄には理由を記載します。
対象外です。
本回答の対象となる業務について、再委託は行っていません。今後再委託を行う場合は、事前承認とセキュリティ確認を実施します。
反対に、「再委託先が管理しているため、自社には関係ない」という理由で対象外にしてはいけません。
自社の委託先がさらに別の事業者へ業務を委託しているのであれば、質問の対象となる可能性があります。
「対象外」は、対応が難しい項目を回答から外すための選択肢ではありません。
質問の前提となる業務や資産が存在しない場合に使用します。
「確認中」を長期間残さない
質問票を受け取った時点で、全ての設定や運用を即座に確認できるとは限りません。
その場合は、無理に「はい」や「いいえ」を選ばず、回答期限に余裕があるなら、まず確認を進めます。
期限までに確定できない場合は、発注者へ相談し、次のように記載します。
確認中です。
対象となるクラウドサービスのログ保存期間について、現在、提供事業者へ確認しています。2026年10月5日までに回答予定です。
ただし、「確認中」のまま放置してはいけません。
次の情報を記録します。
| 項目 | 内容 |
|---|---|
| 確認事項 | 何を確認するか |
| 確認先 | 社内担当者、委託先、サービス事業者 |
| 担当者 | 誰が確認するか |
| 回答期限 | いつまでに確定するか |
| 暫定回答 | 現時点で判明している範囲 |
| 連絡状況 | 発注者へどのように説明したか |
証跡は「あるか」ではなく「回答を裏付けるか」を確認する
質問票で「対応済み」と回答する場合は、回答を裏付ける証跡を確認します。
証跡の例は次のとおりです。
| 質問 | 証跡の例 |
|---|---|
| セキュリティ方針を定めているか | 承認済みの基本方針、公開ページ |
| 従業員教育を実施しているか | 教材、受講者一覧、実施日、理解度確認 |
| アカウントを定期確認しているか | アカウント一覧、確認記録、削除記録 |
| バックアップを取得しているか | 設定画面、実行ログ、復元試験記録 |
| 多要素認証を設定しているか | 管理画面の設定状況、対象者一覧 |
| インシデント対応手順があるか | 承認済み手順書、連絡網、訓練記録 |
| 委託先を管理しているか | 委託先一覧、確認票、契約、評価記録 |
| パッチを管理しているか | 資産一覧、更新状況、例外管理表 |
ファイル名に「セキュリティ規程」と書かれていても、内容が現在の運用と一致していなければ、十分な裏付けにはなりません。
また、規程を作成しただけで、実際の教育、点検、ログ確認などを行っていなければ、「規程あり」と「運用済み」を分けて回答する必要があります。
過去の日付で記録を作らない
質問票が届いてから、過去に実施したはずの作業について、後から記録を作りたくなることがあります。
例えば、次のような処理です。
- 実施していない教育について、昨年度の受講記録を作る
- 確認していないアカウントについて、過去の日付で点検表を作る
- 復元試験をしていないのに、実施済みと記載する
- 取締役会で承認していない規程へ、過去の承認日を記載する
このような記録を作ってはいけません。
過去の実施事実を別の資料やメール等で確認できる場合は、現在の日付で次のように整理します。
2026年9月20日、2026年4月に実施した教育について、当時の案内メール、教材および出席記録を確認し、本記録を作成した。
事実を確認できない場合は、未実施または確認不能として整理し、現在から運用を始めます。
証跡を出しすぎない
質問票へ正確に回答することと、自社の機密情報を全て提出することは同じではありません。
取引先から証跡を求められた場合でも、次の情報をそのまま提出すると、別のリスクが生じる可能性があります。
- 管理者IDの一覧
- IPアドレスを含む詳細なネットワーク構成図
- ファイアウォールの全設定
- APIキーや秘密情報が映った画面
- 従業員の個人情報
- 他の顧客名を含むログ
- 脆弱性診断の詳細な未修正箇所
- インシデント対応用の個人携帯番号
証跡は、次の段階に分けて提示する方法があります。
| 段階 | 提示内容 |
|---|---|
| 第1段階 | 回答、実施概要、実施日、責任者 |
| 第2段階 | マスキングした画面、台帳の抜粋、規程の該当部分 |
| 第3段階 | 秘密保持契約や安全な共有方法を確認したうえで詳細資料 |
| 第4段階 | 必要に応じて現地確認や画面共有による確認 |
「提出しない」と一方的に拒否するのではなく、確認目的を聞いたうえで、必要な範囲で代替資料を提示できないか相談します。
回答者一人で提出しない
セキュリティ質問票は、IT担当者だけで回答できるとは限りません。
質問内容に応じて、次の役割を分けます。
| 役割 | 主な確認内容 |
|---|---|
| 回答取りまとめ担当 | 質問の割振り、期限管理、版管理 |
| 技術確認者 | 設定、ログ、システム構成、脆弱性対応 |
| 業務責任者 | 対象業務、利用方法、停止時の影響 |
| 人事・総務 | 教育、入退社、秘密保持、持出し |
| 契約担当 | 委託、再委託、事故通知、監査条項 |
| 個人情報保護担当 | 個人データの範囲、委託、事故対応 |
| 経営者・承認者 | 未対応項目、残存リスク、費用、期限の承認 |
特に、次の回答は担当者だけで決めない方が安全です。
- 取引先の要求を満たしていない
- 契約上の義務に関係する可能性がある
- 重要な個人情報や営業秘密を扱う
- 改善に大きな費用がかかる
- 完了期限を取引先へ約束する
- 取引先へ事故や脆弱性を通知する
- 残存リスクを受け入れて運用を続ける
技術担当者は、現状と選択肢を説明します。
業務責任者と経営者は、業務影響、費用、取引上の要求を踏まえて判断します。
承認者は名前だけ置かない
改善計画表へ「承認者：代表取締役」と書くだけでは不十分です。
承認者が確認すべき内容を明確にします。
| 承認事項 | 確認する内容 |
|---|---|
| 現在の状態 | 何が未対応か |
| 影響範囲 | どの業務、情報、取引先に影響するか |
| 代替策 | 現在どのようにリスクを下げているか |
| 残存リスク | 代替策後も何が残るか |
| 恒久対策 | 最終的に何を実施するか |
| 必要資源 | 費用、人員、委託先、停止時間 |
| 完了期限 | いつまでに終えるか |
| 遅延時対応 | 期限に間に合わない場合にどうするか |
| 対外説明 | 取引先へ何を伝えるか |
承認日は、質問票の提出日より前にします。
提出後に形式的に承認を取るのではなく、外部へ回答する前に、未対応項目と対処方針を確認してください。
完了期限は現実的に設定する
質問票で印象を良くするため、根拠のない短い期限を記載してはいけません。
例えば、実際には予算化、製品選定、契約、移行が必要なのに、「1か月以内に対応します」と回答すると、後から約束を守れなくなる可能性があります。
期限を決める前に、次の工程を確認します。
| 工程 | 確認すること |
|---|---|
| 方針決定 | どの方法で対応するか |
| 予算 | 費用の承認が必要か |
| 調達 | 製品、サービス、委託先を選ぶか |
| 設計 | 現在の業務やシステムへの影響 |
| 試験 | テスト環境や一部利用者で確認するか |
| 教育 | 利用者への周知や操作説明が必要か |
| 本番移行 | 停止時間、切戻し手順 |
| 完了確認 | 設定、ログ、証跡を誰が確認するか |
恒久対策の完了まで時間がかかる場合は、途中の達成点も設定します。
2026年10月31日 対象システムとアカウントの確定
2026年11月30日 製品選定と予算承認
2027年1月15日 試験環境への導入
2027年2月28日 本番環境への導入完了
このように記載すれば、最終期限まで何も進まない状態を防ぎやすくなります。
期限を変更するときは記録を残す
改善計画が予定どおり進まない場合もあります。
納期の遅れ、製品の仕様変更、業務繁忙、予算の変更などが原因です。
期限を変更する場合は、元の期限を消して新しい期限へ書き換えるだけにしないでください。
次の情報を残します。
- 当初の完了予定日
- 変更後の完了予定日
- 遅延理由
- 遅延による影響
- 代替策が現在も有効か
- 追加した対策
- 取引先への連絡要否
- 変更承認者
- 承認日
取引先へ完了予定日を伝えている場合は、期限変更をいつ、どのように伝えるかも確認します。
質問票の回答手順
中小企業では、次の手順にすると回答漏れを減らしやすくなります。
1．原本を保存する
受信した質問票、依頼メール、回答要領、提出期限を一つのフォルダへ保存します。
ファイルを直接上書きせず、回答版に日付と版番号を付けます。
2．質問の意味を確認する
対象範囲、基準日、用語、証跡の要否を確認します。
不明点は一覧にし、まとめて発注者へ質問します。
3．担当者へ割り振る
各質問について、回答者、確認者、期限を決めます。
IT担当者一人へ全てを任せないようにします。
4．証跡を確認する
「実施しているはず」ではなく、設定、記録、契約などを確認します。
5．回答状態を分類する
対応済み、一部対応、未対応、対象外、確認中へ分けます。
6．未対応項目を改善計画へ移す
質問票の中だけに残さず、社内の課題管理表へ登録します。
7．技術確認と経営承認を行う
回答内容、残存リスク、期限、対外的な約束を確認します。
8．提出版を保存する
提出したファイル、提出日、提出先、送信方法を記録します。
9．追加質問を管理する
取引先からの追加質問、回答、証跡提出の履歴を残します。
10．約束した期限を追跡する
質問票を提出した後も、改善計画の完了まで確認します。
SCS評価制度とは分けて考える
取引先の質問票で未対応項目を説明することと、SCS評価制度の適合判断は同じではありません。
SCS評価制度の基本規程では、自己適合宣言を、適用範囲内のIT基盤等が要求事項・評価基準の全てに適合していることについて、経営層が組織の責任で宣言することと定義しています。
★3では、登録希望組織が自己評価を行い、★3確認責任者が内容の妥当性を確認して署名し、その後、組織が自己適合宣言を行います。★3確認責任者には、全ての要求事項・評価基準を満たしていることを確認し、結果に虚偽等が含まれないよう最大限注意する責務があります。
また、虚偽申請や情報隠蔽等の不正行為が確認された場合、事実確認と弁明の機会を経たうえで、登録が取り消される可能性があります。
したがって、次の考え方は適切ではありません。
取引先が代替策を認めてくれたので、SCSでも適合にできる。
発注者が取引上のリスク判断として代替策を許容することと、SCS評価制度上の要求事項・評価基準へ適合することは別です。
2026年8月30日時点では、IPAの要求事項・評価基準ページで、詳細な解説書は2026年10月頃の公開予定とされています。例外的な適合判断を含む具体的な解釈については、今後公開される公式資料を確認し、自己判断で適合と扱わないことが重要です。
質問票では「一部対応」「代替策あり」と説明できる場合でも、SCSの自己評価では不適合となる可能性があります。
この二つを混同しないでください。
質問票を改善活動の入口にする
質問票への回答を、その場限りの作業にしてはいけません。
毎年、同じ質問について、担当者が一から調べ直している会社があります。
回答内容を次の社内台帳へ反映すると、次回から確認しやすくなります。
| 質問内容 | 反映する台帳・記録 |
|---|---|
| 端末、サーバー、ネットワーク機器 | IT資産台帳 |
| クラウド、SaaS | SaaS・クラウド台帳 |
| アカウント、管理者、MFA | アカウント管理台帳 |
| 委託先、再委託先 | 委託先管理台帳 |
| 脆弱性、パッチ | 脆弱性・更新管理表 |
| バックアップ | バックアップ・復元確認表 |
| 教育 | 教育計画、受講記録 |
| インシデント対応 | 連絡網、手順書、訓練記録 |
| 未対応項目 | 改善計画・リスク管理表 |
IPAのプラクティス例でも、質問票で把握した課題やリスクを一覧化し、経営者へ報告して、組織として対応方針を検討する流れが示されています。
質問票は、取引先へ説明するためだけの書類ではありません。
自社が把握していなかった課題を見つけ、改善の優先順位を決める材料になります。
15分で始める最初の確認
過去に提出したセキュリティ質問票を一つ開いてください。
次の五つを確認します。
- 「はい」と回答した項目に、現在も確認できる証跡があるか
- 一部対応なのに「はい」としている項目がないか
- 「対象外」の理由を説明できるか
- 完了予定日を回答した項目は、実際に完了しているか
- 回答を承認した責任者が分かるか
一つでも説明できない項目があれば、過去の回答を直ちに否定するのではなく、現在の状態を確認してください。
必要に応じて台帳を更新し、未対応事項には担当者、期限、承認者を設定します。
経営者が確認したい五つの質問
経営者が、質問票の全ての技術項目を確認する必要はありません。
ただし、担当者へ次の五つは確認してください。
- 一部対応や未対応の項目を、実態どおりに回答しているか
- 代替策によって、どのリスクをどこまで減らしているか
- 代替策を実施しても残るリスクは何か
- 恒久対策の責任者、費用、完了期限が決まっているか
- 取引先へ約束した改善事項の進捗を確認しているか
この五つに答えられなければ、「はい」を多く付けることよりも、未対応項目の管理を優先してください。
まとめ
セキュリティ質問票で未対応項目が見つかったとき、実態より良く見せるために「はい」と回答してはいけません。
一方、「いいえ」だけで終わらせる必要もありません。
次の内容を事実に基づいて説明します。
- 現在の回答区分
- 対象となる範囲
- 実施済みの対策
- 未対応となっている部分
- 未対応の理由
- 現在の代替策
- 代替策後も残るリスク
- 恒久対策と完了期限
- 担当者と承認者
- 回答を裏付ける証跡
重要なのは、未対応が一つもないように見せることではありません。
未対応事項を把握し、放置せず、会社として改善方針を決めていることです。
ただし、取引先が代替策を許容することと、SCS評価制度で適合となることは別です。
SCSの自己適合宣言では、適用範囲内のIT基盤等が要求事項・評価基準の全てに適合していることを、経営層が組織の責任で宣言します。
まずは、回答中の質問票について、「一部対応」「未対応」「確認中」の項目だけを抜き出してください。
そして、一項目ごとに次の一文を完成させます。
現在は〇〇の状態であり、△△の代替策を実施しています。残存リスクは□□であり、責任者は〇〇、承認者は〇〇、恒久対策の完了予定日は〇年〇月〇日です。
この一文を書けなければ、まだ取引先へ回答する段階ではありません。
ライトハウスコンサルタントでは、専任の情報システム担当者がいない中小企業を対象に、セキュリティ質問票の回答確認、証跡整理、未対応項目の改善計画、委託先管理、SCS★3を見据えたギャップ整理を支援しています。
質問票の回答を代行して見栄えを良くすることが目的ではありません。
自社の実態を確認し、説明できない部分と不足している対策を明確にして、取引先へ誠実に説明できる状態を作ることが重要です。
- 投稿タグ
- SCS★3, SCS評価制度, サプライチェーンセキュリティ, セキュリティチェックシート, セキュリティ質問票, 一部対応, 中小企業セキュリティ, 代替策, 委託先管理, 改善計画, 未対応項目, 残存リスク, 証跡
