取引先のセキュリティチェックシート回答方法：回答例と証跡の整理

新しい取引や契約の更新の際に、取引先から「セキュリティチェックシート」や「セキュリティ質問票」が届くことがあります。委託する業務や預ける情報を安全に扱えるかを、取引先が確認するための書類です。質問は、多要素認証（MFA）、バックアップ、従業員教育、アクセス権限、委託先の管理など幅広く、営業や総務の担当者だけでは答えられない項目も含まれます。

回答を書き始める前に、次の4点を確認します。

• 提出期限と書式：提出期限、質問票の版、記入要領、回答の形式（「はい / いいえ」の選択、自由記述、資料の添付など）。
• 対象の範囲：質問が会社全体についてか、特定の委託業務と、そこで扱う情報・使うシステムについてか。会社全体の状況と特定の業務の状況を混同すると、実態と違う回答になります。
• 社内の担当：取引先との窓口、技術的な内容を確認する人（社内の情シスや、運用を委託しているベンダーなど）、回答内容と開示する資料を承認する人。
• 共有してよい範囲：質問票や回答を、委託先のベンダーや支援会社などの社外へ共有してよいか、どの範囲までか。

質問の意味や対象の範囲が分からない項目は、推測で答えず、提出先に確認します。確認したい点を一覧にしておくと、まとめて問い合わせられます。ベンダーや支援会社へ相談する場合も、最初から質問票の原本、ログ、パスワードなどの認証情報を送る必要はありません。必要な資料と受け渡しの方法は、相談の内容が決まってから確認します。

回答は、次の5つの段階で進めます。

1. 質問の整理：質問ごとに、求められている内容と対象の範囲を確認し、社内の担当者を決める。
2. 現状と根拠の照合：規程や手順書、システムの設定、運用の記録（作業記録、ログ、受講記録など）を確認する。
3. 回答案と不足の整理：確認できた事実をもとに回答案を書き、確認できなかった点や未対応の点を別に記録する。
4. 社内承認：回答の内容と、提出する資料の範囲を承認者が確認する。
5. 提出と保管：提出した版と根拠の資料を保管し、取引先からの追加の質問に備える。

回答の根拠を「証跡」と呼ぶことがあります。証跡とは、回答の根拠になる設定や運用の記録のことです。たとえば「管理者のアカウントに多要素認証を設定している」と答えるなら、その設定を確認した管理画面や設定の一覧と、確認した日付が根拠になります。

質問ごとに、次のような項目を社内で記録しておくと、回答と根拠の対応が分かります。

この表は社内で整理するためのもので、提出先の書式はそのまま使います。書式に列や欄を加えず、必要な回答と補足だけを転記します。以前に別の取引先へ提出した回答を使う場合も、そのまま写さず、現在の設定と記録で確認し直します。回答の版と確認した日付を残しておくと、次の更新や追加の質問に対応しやすくなります。

提出したことと、取引先が回答を受け入れたことは別です。社内では、社内の承認、提出、取引先の受領、取引先の判断を分けて記録します。IPAのプラクティス集でも、質問票を送った企業が、回答の内容に応じて証跡の依頼を含む追加の質問を行い、対策状況を総合的に評価する事例が紹介されています（IPA：プラクティス集 第4版 p.74〜75）。

質問によっては、「はい」とも「いいえ」とも言い切れないことがあります。社内では、まず次の5つの状態に分けて整理します。これは事実を整理するための社内の区分で、取引先の評価基準や、すべての質問票に共通する採点の基準ではありません。提出するときは、質問票の定義と回答の形式に合わせます。

未確認の項目を実施済み、一部だけの実施を全体で実施済み、計画中のものを実施済みとして答えないことが基本です。回答の形式が「はい / いいえ」だけで実態を表せない場合は、社内で事実を整理したうえで、備考欄での補足や、提出先への回答方法の確認を検討します。分からない項目を、独自の判断で「はい」や「いいえ」に埋めることは避けます。

「対象外」とする場合は、理由と範囲を記録します。在宅勤務、クラウドサービスの利用、外部への委託があることだけを理由に、端末の管理、物理的な管理、運用の管理を一律に対象外にはできません。業務で使う端末やデータがあれば、その管理は対象になり得ます。

期限までに改善が間に合わない項目は、現在の状況、不足している点、当面の対策（暫定策）、改善の予定を分けて記録します。改善の予定日は、担当者と実行の見込みを社内で確認してから示し、期限や回答の方法を提出先に相談します。代わりの対策や期限の延長を認めるかどうかは、取引先が判断します。

次の表は、記入の仕方を示すための例です。特定の企業の回答や実施結果ではありません。実際の回答は、取引先の質問の文言と回答の形式に合わせ、自社の設定と記録で確認してから作成します。

3つの例に共通するのは、確認できた範囲と、確認できていない範囲を分けて書くことです。

• 多要素認証：確認したシステムと対象者を明記し、ゲストや例外のアカウントは別に確認します。多要素認証の機能を契約していることや、製品が対応していることだけでは、すべての対象に適用されていることの根拠になりません。
• バックアップ：取得の設定やバックアップの成功と、復元テストの実施・結果は、別のこととして扱います。取得していることだけで「復元できる」とは答えません。また、記録が見つからないことだけで未実施と決めず、担当者や委託先に確認します。
• 従業員教育：資料や計画があることと、対象者に実施した記録があることを分けます。

確認や改善の予定を回答に書く場合も、予定を書いたことで実施済みや、要求を満たしたことにはなりません。予定の内容と期限をどう扱うかは、取引先が判断します。回答の過程で見つかった不足を改善するときの、管理者と従業員の具体的な対策は、管理者と従業員のランサムウェア対策で扱っています。

証跡は、質問の内容に合わせて選びます。規程や手順書に加えて、システムの設定、運用の記録、実施の結果などを、それぞれの回答に対応させます。後から確認できるよう、資料ごとに資料IDまたは資料名、確認した日、確認の方法、確認した範囲、例外を記録しておきます。

根拠を確認するときは、次の違いを区別します。

• 聞き取りと設定の確認：担当者から聞いた内容と、管理画面や設定の一覧で確かめた内容は、根拠としての確かさが異なります。
• 設定の存在と運用の継続：設定があることと、その設定が対象に適用され、運用が続いていることは別です。運用は記録で確認します。
• 一部の確認と全件の確認：代表的な対象だけを確認した場合は、その範囲を記録し、全体を確認したとは書きません。

製品の資料や、利用しているクラウドサービスの提供者が取得している認証は、そのサービス側の管理を示すもので、自社の設定や運用の全体を証明するものではありません。また、ISMS認証（ISO/IEC 27001）を取得している場合に回答を省略できるかは、取引先の条件によります。一律に免除されるとも、一切省略できないとも言えないため、提出先に確認します。管理の仕組みづくりと認証への取り組みは、ISMS（ISO/IEC 27001）導入ロードマップで扱っています。

証跡を開示する前に、資料に含まれる認証情報（パスワード、APIキーなど）、他社の情報、個人情報などを取り除きます。取り除いた後も、対象・日時・範囲など、判断に必要な情報が残っているかを確認します。開示先、共有の方法、開示を承認する人も決めておきます。機密を含む資料は、公開されている問い合わせフォームや、入力内容の扱いを確認していない生成AIサービスへ、そのまま入力しないようにします。

IPAの「中小企業の情報セキュリティ対策ガイドライン」には、情報セキュリティ基本方針や関連規程のサンプル、資産管理台帳のサンプル、「5分でできる！情報セキュリティ自社診断」などの付録があります（IPA：中小企業の情報セキュリティ対策ガイドライン）。対策や確認する項目を考える参考になりますが、個別の取引先の質問票の代わりや、そのまま使える回答集ではありません。

現状と根拠を社内で確認できるなら、担当者と承認者を決めて社内で進められます。外部の支援を使わなくても構いません。

次のような場合は、外部の支援を使う方法もあります。

• 技術的な項目の確認に、複数の部署や委託先のベンダーへの問い合わせが必要
• 規程に書かれている内容と、実際の設定や運用が一致していない
• 未対応の項目や例外の説明、改善の優先順位を整理しきれない

外部に依頼する場合も、回答の内容と開示の範囲を承認して提出するのは自社で、回答を受け入れるかは取引先が判断します。依頼する前に、対象の質問票と資料、確認の方法と深さ、成果物、修正の回数、設定変更などの実作業を含むかを決めておくと、依頼の範囲がはっきりします。取引先からSCS評価制度の★3・★4への対応を求められた場合は、求められた段階と対象範囲、期限を確認します。制度に沿った準備の進め方は、SCS評価制度の記事で扱っています。

Malakeでは、外部IT責任者・IT顧問の支援の一つとして、質問票を対象に現状と根拠を確認し、回答案と根拠の対応表、追加で確認する事項と提出先への質問の一覧、未確認・改善事項の担当と期限を整理します。初回相談（無料）では課題と対象を確認し、有料の支援は対象と成果物、確認の方法などを合意したうえで個別にお見積もりします。

提出の前に、次の項目を確認します。すべての項目を確認できても、それで安全であることや、取引先の審査を通ることを示すものではありません。