取引先から届くセキュリティチェックシートの回答実務。正直に書いて取引を守る

「取引先から『情報セキュリティチェックシート』というExcelファイルが届いたのですが、何を書けばいいのか分かりません」——ひとりで情シス・総務を兼任している担当者から、こうした相談が寄せられることが増えています。数十項目にわたる質問が並び、「暗号化の有無」「アクセス権限の管理方法」「インシデント対応体制」など、普段の業務では意識してこなかった専門的な問いが続くと、どこから手をつければよいか分からなくなるのも無理はありません。

本記事では、取引先から届いたセキュリティチェックシートに、担当者ひとりでも現実的に対応できる手順を解説します。結論を先に言うと、大切なのは「すべての項目に『できている』と答えること」ではなく、「自社の現状を正直に、根拠とともに伝えること」です。

先に、要点をまとめます。

• セキュリティチェックシートは「合否判定」ではなく「取引先によるリスクの見える化」の一環であり、正直な回答が信頼につながる
• 回答の型は「方針」「現状」「今後の改善予定」の3点をセットで書くこと
• 一度作った回答は使い回せる。最初の1枚に時間をかければ、2社目以降の負担は大きく下がる

ただし、回答の中身以前に、ひとつだけ誤解しやすいポイントがあります。それは「厳しく詰められている質問ほど、実は対応の余地が広い」という点です。この記事の後半で、具体的にどういうことか説明します。

セキュリティチェックシートとは何か。なぜ届くのか?

取引先が自社のサプライチェーン全体のセキュリティリスクを把握するために、委託先・取引先へ送る質問票がセキュリティチェックシートです。

大企業や官公庁と取引がある会社ほど、この質問票を受け取る機会が増えています。背景には、自社が直接攻撃されなくても、取引先や委託先を経由して情報が漏えいする「サプライチェーン攻撃」が増加している事情があります。取引先からすれば、契約している委託先1社1社のセキュリティ体制を個別に監査するのは現実的でないため、まず質問票で自己申告してもらい、リスクの大小を把握する、という運用が広がっています。

IPA(独立行政法人情報処理推進機構)は2026年3月27日、「中小企業の情報セキュリティ対策ガイドライン」第4.0版を公開しました。この改定では、個社だけでなくサプライチェーン全体に被害が及ぶサイバー攻撃の脅威を踏まえ、サイバーセキュリティ対策に関する記載が拡充されています。あわせて「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)」の基本的な考え方に沿った内容になっており、大企業側が委託先を評価する際の物差しとして、今後さらに普及していく可能性があります。

つまり、セキュリティチェックシートが届くこと自体は、自社が特に疑われているサインではありません。取引先が業界の標準的な運用として、委託先全体に同じ質問票を送っている、というケースがほとんどです。まずはこの前提を理解しておくと、必要以上に身構えずに対応できます。

何を聞かれるのか。よくある質問項目の分類

チェックシートの様式は取引先ごとに異なりますが、聞かれる内容は大きく分けて次の5つの領域に集約されます。

この5領域は、中小企業のセキュリティ対策、最低限やるべき10項目で扱った基本項目とほぼ重なります。チェックシートに何を書けばよいか迷ったときは、まずこの記事で自社の対策状況を横断的に確認しておくと、チェックシートの各設問にも答えやすくなります。

このうち、ひとり情シス・総務兼任の会社が特に答えづらいのが「組織体制」と「インシデント対応」です。専任のセキュリティ担当者がいない会社では、「責任者は誰か」と聞かれても、実質的に社長やIT担当者ひとりが兼務しているケースが多く、体制図を作ったことがないという声もよく聞きます。

ここで重要なのは、専任チームがないこと自体は、必ずしも大きなマイナス評価にはならないという点です。取引先が本当に知りたいのは「何かあったときに誰が動くのか」が明確になっているかどうかであり、体制の規模そのものではありません。「情報セキュリティの責任者は代表取締役、実務対応はIT担当の◯◯が兼務」のように、実態をそのまま書くことが、空欄にするより評価されます。

業種・業態によって重点項目が変わる

取引先の業種や、自社が委託される業務の内容によって、チェックシートの重点は変わります。たとえば次のような傾向があります。

• 顧客の個人情報を扱う業務(受付代行、顧客管理システムの運用委託など): 個人情報保護法に基づく安全管理措置、データの保管場所(国内か海外か)、委託先へのさらなる再委託の有無が細かく聞かれる傾向があります
• システム開発・保守を受託する業務: ソースコードの管理方法、開発環境と本番環境の分離、開発者アカウントの権限管理が重点的に聞かれます
• クラウドサービスを提供する業務: 可用性(稼働率)、障害発生時の復旧目標時間(SLA（サービス品質保証）に相当する項目)、データセンターの所在地が聞かれることが多くなります

自社がどの業務で取引先から評価されているのかを踏まえて回答すると、的外れな回答を避けやすくなります。たとえば、個人情報を一切扱わない業務なのに、データの暗号化やアクセスログの保存期間について過剰に詳しく書く必要はありません。逆に、扱う業務の性質上、明らかに重要度が高い項目については、他の項目より厚めに、具体的な運用ルールまで書き込むとよいでしょう。

また、取引先の業種そのものによっても質問の傾向が変わります。金融機関や官公庁と取引がある会社が委託先に送るチェックシートは、監督官庁のガイドラインに準拠した詳細な項目(暗号化アルゴリズムの種類、ログの保存期間の年数指定など)を含むことがあり、一般的な事業会社が送るチェックシートより設問数が多く、専門的になる傾向があります。届いたチェックシートの分量や専門性の高さから、取引先がどの程度厳格な基準を求めているかをある程度推測できるため、回答にかける時間配分の目安にもなります。

回答の基本方針: 「方針・現状・今後」の3点セットで書く

チェックシートに向き合うときに陥りやすい失敗は、実態以上によく見せようとして「はい」を並べてしまうことです。しかし、この対応にはリスクがあります。

セキュリティチェックシートは、多くの場合、契約の前提条件として扱われます。回答内容と実際の運用に大きな乖離があると分かった場合、後から契約上の問題に発展する可能性があります。特に、インシデントが実際に発生した際に「回答していた体制が実は存在しなかった」と判明すれば、取引先との信頼関係そのものが崩れかねません。

現実的な回答の型は、次の3点をセットで書くことです。

• 方針: どういう考え方でセキュリティに取り組んでいるか(例: 「重要データは限られた担当者のみアクセス可能とする方針」)
• 現状: 今できていること、まだできていないことを具体的に(例: 「主要な業務システムには多要素認証を導入済み。一部の古いシステムは未対応で、2026年内の対応を予定」)
• 今後: できていない項目について、いつまでにどう改善する予定か

「全部できています」と背伸びして答えるのではなく、「ここまではできていて、ここから先は計画中です」と正直に書くほうが、長期的な信頼につながります。これは中小企業診断士やセキュリティコンサルタント向けの実務解説でも共通して指摘されているポイントです。

不明な項目、判断がつかない項目については、空欄のまま提出するのは避けてください。「確認中」「該当する仕組みは現在未導入」のように、何らかの意思表示をしたうえで提出することが、無回答よりも評価されます。

回答例: 具体的な文面のイメージ

抽象的な説明だけでは掴みにくいため、よくある設問への回答例を1つ示します。設問「退職者のアカウントは速やかに無効化されていますか」に対して、次のように書くイメージです。

退職が確定した時点で、退職日当日中に対象アカウントを無効化する運用としています(社内規程「アカウント管理規程」第3条に基づく)。現状、無効化の実施記録は担当者の個人メモで管理しており、台帳化はできていません。2026年内をめどに、無効化記録を専用の管理シートに一元化する予定です。

このように、「できていること(当日中の無効化)」「まだ弱い部分(記録の台帳化ができていない)」「今後の予定(台帳化の時期)」の3つが1つの回答に収まっていると、取引先も実態を正確に把握でき、かつ改善の意思が伝わります。「はい」の一言だけで済ませるのと比べて、書く分量はわずかに増えますが、後から実態との矛盾を指摘されるリスクは大きく下がります。

実際の回答作業: 5つのステップ

チェックシートが届いてから提出するまでの一連の流れを、実務の手順として整理します。

ステップ1: 期限と提出形式を確認する

まず、回答期限がいつまでか、Excelファイルのまま返送するのか、専用のWebフォームに入力する形式なのかを確認します。証跡(規程のコピー、設定画面のスクリーンショットなど)の添付が求められているかどうかも、この段階で把握しておくと、後工程の見積もりが立てやすくなります。

ステップ2: 設問全体にひととおり目を通す

回答を始める前に、全設問を一度読み通します。専門用語が並んでいて身構えてしまいますが、先に全体像を掴んでおくことで、「これは自社で判断できる項目」「これは開発会社や委託先に確認が必要な項目」の仕分けができます。

ステップ3: 自社の状況を棚卸しする

質問項目に沿って、自社の現状を一つずつ確認していきます。この段階で、以下のような資料があると作業が早く進みます。

• 利用しているクラウドサービス・業務システムの一覧
• アカウント管理の運用ルール(退職時の削除フロー含む)
• バックアップの取得頻度と保管場所
• 過去にインシデントが発生した際の対応記録(あれば)

これらの資料が手元にない場合、チェックシート対応をきっかけに整理してしまうのがおすすめです。一度整理しておけば、次に別の取引先から同様の質問票が届いたときの負担が大きく減ります。

ステップ4: 回答を作成する

「方針・現状・今後」の型に沿って、各設問に回答を記入します。この際、備考欄があれば積極的に活用してください。「〇〇規程第◯条に基づき実施」のように、根拠を一言添えるだけで、回答の説得力が増します。規程文書自体を持っていない場合でも、社内で決めている運用ルールを簡潔に書き添えるだけで十分です。

ステップ5: 提出前にダブルチェックする

提出前に、次の2点を確認します。

• 回答内容が、実際の運用と矛盾していないか(誇張していないか)
• 未対応の項目について、改善予定を書いたか(空欄のままになっていないか)

可能であれば、回答を作成した本人以外にもう一人、内容を確認してもらうと安心です。ひとりで担当している場合は、経営者に最終確認だけでもしてもらうと、「会社として回答した」という位置づけが明確になります。

費用感: チェックシート対応そのものにコストはかかるか

セキュリティチェックシートへの回答自体は、多くの場合、社内の人的コストのみで対応可能です。専用ツールの購入や外部業者への委託が必須というわけではありません。ただし、以下のようなケースでは、追加の検討が必要になることがあります。

多くの中小企業にとって、いきなりISMS認証を取得する必要はありません。チェックシート対応が頻発するようになった段階で、コストと工数削減の効果を比較しながら検討するのが現実的です。IPAが提供する「SECURITY ACTION」という自己宣言制度は、ISMSのような第三者認証と異なり、無料で取り組める点が中小企業にとって現実的な選択肢です。

実施記録・証跡の残し方

費用をかけずにできる工夫として、日々の運用の中で「証跡」を残しておく習慣も紹介します。証跡とは、実際にその対策を行っていることを示す記録のことです。

• 退職者のアカウントを無効化した日時をメモやチケット管理ツールに残す
• バックアップが正常に取得できているかを確認したログを月次で保存する
• 社内向けにセキュリティ研修や注意喚起を行った際の実施記録(配布資料・参加者リストなど)を保管する

これらは特別なツールを使わなくても、既存のメールやスプレッドシートで十分に代替できます。重要なのは「対策をやっている」という主張ではなく、「いつ・誰が・何をしたか」が後から確認できる状態にしておくことです。チェックシートで証跡の提出を求められた際、こうした記録があれば慌てずに対応できます。

SECURITY ACTIONの活用: チェックシート対応の負担を下げる土台

IPAが運営する「SECURITY ACTION」は、中小企業が情報セキュリティ対策に取り組むことを自己宣言する制度です。「一つ星」と「二つ星」の2段階があります。

二つ星を宣言するには、ガイドラインが提供する「5分でできる情報セキュリティ自己診断」を用いて自社の状況を把握したうえで、情報セキュリティ基本方針(ひな形あり)を策定し、外部に公開することが求められます。

この基本方針の文書自体を、チェックシート回答時に根拠資料として添付できる点が実務上のメリットです。チェックシートの多くの設問は「方針が文書化されているか」を問うものであるため、SECURITY ACTIONの取り組みを一度進めておけば、以降のチェックシート対応がその分だけ楽になります。取引先によっては、SECURITY ACTIONの宣言そのものを一定の評価材料として扱う場合もあります。

比較: 都度その場しのぎで対応する場合と、テンプレートを整備する場合

セキュリティチェックシートへの向き合い方は、大きく2つに分かれます。

取引先からのチェックシート依頼が今後も続く見込みがある会社では、最初の1社への対応にやや時間をかけてでも、基本方針文書と回答テンプレートを作っておくことを推奨します。年1回程度の見直しを前提にしておけば、情報が古くなる心配もありません。

「厳しい質問」ほど対応の余地が広い理由

冒頭で触れた「厳しく詰められている質問ほど、実は対応の余地が広い」という点について説明します。

チェックシートの中には、一見すると答えにくい、踏み込んだ質問が含まれることがあります。たとえば「インシデント発生時の対応体制と過去のインシデント発生実績」や「委託先(自社がさらに外部に委託している先)のセキュリティ管理状況」といった質問です。こうした質問を見ると、「自社には体制がないから答えられない」「聞かれたくない」と身構えてしまいがちです。

しかし実際には、こうした踏み込んだ質問ほど、「これから整備する予定です」という回答の余地が広く用意されています。取引先の担当者も、すべての委託先が完璧な体制を持っているとは想定しておらず、質問の意図はむしろ「現状把握と今後の改善姿勢の確認」にあります。逆に、答えやすい表面的な質問(「パスワードポリシーはありますか」など)のほうが、実は「ある/ない」の二択に近く、誤魔化しがきかない場合もあります。

つまり、質問の難易度と、回答の柔軟性は必ずしも比例しません。難しそうに見える質問ほど、「現状はここまでで、これから改善します」という正直な言葉で受け止めてもらえる余地が大きい、と捉えておくと、身構えすぎずに向き合えます。

失敗例と回避策

チェックシート対応でよくある失敗のパターンと、その回避策を整理します。

• 失敗例1: 「はい」で埋めて後から矛盾が発覚する — 多要素認証を「導入済み」と回答したが、実際には一部のシステムにしか導入していなかった。後日、取引先からの追加ヒアリングで実態が食い違っていることが判明し、信頼を損ねた。回避策は、回答前に必ず実際の設定画面や運用記録で裏取りをすること。記憶や思い込みで「導入済み」と書かない。
• 失敗例2: 期限ギリギリまで放置し、雑な回答になる — 数十項目ある質問票を後回しにした結果、提出前日に慌てて空欄のまま提出してしまった。回避策は、届いた時点でステップ1〜2(期限確認・全体把握)だけでも先に済ませ、残りの作業量を早期に見積もっておくこと。
• 失敗例3: 情報システム部門だけで完結させようとする — バックアップの頻度や委託先の管理体制など、実は総務や経理が把握している情報を、情シス担当者だけで推測して回答してしまい、後から実態と違うと判明した。回避策は、関連する部署に一言確認してから回答を確定させること。
• 失敗例4: 一度作った回答を使い回さず、毎回ゼロから作る — テンプレート化していないため、取引先が増えるたびに同じ調査を繰り返し、本来の業務を圧迫していた。回避策は、初回の回答をベースに、汎用的な回答集(FAQ形式)を社内文書として残しておくこと。
• 失敗例5: パスワードや設定内容を、チェックシートの回答欄にそのまま書いてしまう — 「現在使用中の管理者パスワードは◯◯です」のように、機密情報そのものを回答文に記載してしまうケースがまれにあります。チェックシートは複数の担当者間でメール添付・共有フォルダ経由でやり取りされることが多く、機密情報を平文で書くこと自体がセキュリティリスクになります。回避策は、「該当の管理体制は整備済み」のように運用の有無・方針レベルで回答し、具体的な認証情報や設定値そのものは書かないこと。証跡の提出が必要な場合も、パスワードなど機密性の高い値はマスキングしたスクリーンショットを使う。日頃から社内でシャドーIT(勝手に導入されたツール)の見つけ方と対処にも目を配っておくと、チェックシートで把握しきれていないサービスの存在を指摘されるリスクも減らせます。

社内の体制別: 誰が何を確認すればよいか

ひとり情シス・総務兼任の会社では、チェックシートの全項目をひとりで抱え込みがちですが、実際には社内の他部署が答えを持っている項目も少なくありません。回答作業を始める前に、次のように役割を意識して声をかけておくと、手戻りを減らせます。

特に、開発会社に業務システムの開発・保守を委託している場合、バックアップの取得頻度やアクセス権限の設計といった技術的な項目は、自社側で正確に把握しきれていないことがあります。この場合は、委託先に直接確認したうえで回答するのが確実です。チェックシート対応をきっかけに、普段は聞きにくい委託先の運用体制を確認する機会として活用するのも一つの方法です。

自社が「送る側」になる場合の視点

ここまでは、自社が取引先からチェックシートを「受け取る側」である前提で解説してきました。しかし、事業が成長し、自社がさらに別の会社へ業務を委託するようになると、今度は自社が「送る側」に回ることもあります。委託先管理の観点から、この視点も簡単に触れておきます。

自社が委託先(たとえば、業務システムの開発・保守を依頼している開発会社や、クラウドサービスの提供元)を評価する際も、基本的な考え方は同じです。委託先が「すべて完璧です」と答えるより、「ここまではできていて、ここは今後改善予定です」と具体的に答えてくれるほうが、実際にはリスクを正確に把握しやすく、信頼できる相手だと判断できます。

逆に言えば、自社が受け取る側として正直に回答する経験を積んでおくと、将来自社が送る側になったときにも、委託先の回答をどう読み解けばよいかの勘所が身につきます。「はい」ばかりが並んだ回答よりも、具体的な現状と改善予定が書かれた回答のほうが信頼度が高い、という判断軸は、送る側・受け取る側のどちらの立場でも共通しています。

システム開発を外部に委託している場合、開発会社側のセキュリティ管理体制(ソースコードの管理方法、開発環境のアクセス権限、担当者退職時の引き継ぎ体制など)は、自社が受け取るチェックシートの回答内容にも直結します。委託先の体制が不透明なままだと、自社が取引先へ正確に回答できなくなるため、開発会社との関係を見直す際は、セキュリティ面の確認も含めて検討するとよいでしょう。

この記事で持ち帰れること

ここまでの内容を踏まえると、次の2点が判断できるようになっているはずです。

• セキュリティチェックシートに何を書けばよいか迷ったときの型(方針・現状・今後の3点セット)と、避けるべき対応(誇張・空欄放置)
• 自社が「都度その場しのぎ」で十分な段階なのか、「基本方針・テンプレート整備」に投資すべき段階なのかの見極め方

セキュリティチェックシートは、一見すると面倒な事務作業に見えますが、実際には自社のセキュリティ状況を可視化するよい機会でもあります。この記事の手順に沿って一度きちんと棚卸しをしておけば、次に届く質問票への対応は、確実に楽になります。

まずは今回届いたチェックシートの設問リストだけを、ステップ2の要領でひととおり眺めてみてください。「自社で即答できる項目」と「確認が必要な項目」に仕分けるだけでも、対応の見通しがかなり明るくなります。まだチェックシートが届いていない会社でも、この記事の5領域(組織体制・アクセス管理・データの取り扱い・インシデント対応・委託先管理)に沿って、自社の現状をひとつだけ棚卸ししてみると、いざ届いたときの負担がぐっと軽くなります。

ここから先、自社の体制を根本的に見直したい、あるいは委託先(開発会社)側のセキュリティ管理体制まで含めて整理したいという場合は、社内だけで抱え込まず、外部の情シス部門的な立場で相談できる相手を持っておくという選択肢もあります。