取引先のセキュリティチェックシートに答えるための開発・運用体制

BtoBのサービスを大きな会社に導入してもらおうとすると、ほぼ確実に「セキュリティチェックシート」への回答を求められます。数十から数百の質問が並ぶ表計算ファイルを前に、どう書けば通るのかを考えがちですが、本質は書き方ではありません。チェックシートは、自社の開発と運用の実態を問うものです。実態が整っていれば回答は事実を書くだけで済み、整っていなければどれだけ表現を工夫しても、追加の質問や導入の見送りにつながります。

結論を先に言えば、やるべきことは三つです。一つ目は、典型的な質問項目を知り、開発の段階から設計に組み込んでおくこと。二つ目は、運用のルールと記録を残し、「やっている」と証明できる状態にすること。三つ目は、一度作った回答を社内の標準回答として管理し、取引先ごとに作り直さないことです。答えられない項目があっても、正直に現状と対応予定を示せば、それだけで取引が止まるとは限りません。

この記事は、BtoBのSaaSや業務システムを提供している、またはこれから提供しようとしている事業責任者・開発責任者に向けて書いています。チェックシートで問われる典型的な項目、開発段階から備えておくべき設計、運用で整えるべき体制、回答の作り方と管理のしかた、よくある失敗までを順に説明します。

セキュリティチェックシートとは：取引先が確かめたいこと

セキュリティチェックシートは、取引先が外部のサービスや委託先を使う前に、情報の扱いが自社の基準を満たしているかを確かめるための質問票です。用語の説明はセキュリティチェックシートの用語ページにまとめています。

取引先の情報システム部門やセキュリティ担当者が確かめたいのは、突き詰めると次の四つです。

• 自社のデータがどこに、どう保管されるのか：保存場所、暗号化、他社のデータとの分離、削除のされ方。
• 誰がそのデータに触れられるのか：提供会社の社員や委託先のアクセス権限、その管理と記録。
• 問題が起きたときにどうなるのか：障害や情報漏えいの際の連絡、復旧、原因調査の体制。
• 組織として継続的に管理しているのか：ルール、教育、点検、外部の認証や評価の有無。

質問の形式は会社ごとに違いますが、この四つのどれかに分類できるものがほとんどです。この構造を知っておくと、初めて見るチェックシートでも「この質問は何を確かめたいのか」が読み取れるようになり、的外れな回答を避けられます。

チェックシートの典型的な質問項目

多くのチェックシートに共通して現れる項目を、分野ごとに整理します。具体的な文言は取引先によって違いますが、問われる中身はおおむね次のとおりです。

この表の右端の列が大事です。「運用」で備える項目は、後から規程や手順書を整えれば対応できます。一方「開発」で備える項目は、システムの設計に関わるため、後から追加しようとすると大きな改修になることがあります。

開発段階から備えておくべき設計

チェックシートで後から苦労しやすいのは、システムの作りそのものに関わる項目です。最初の版を作る段階で、少なくとも次の点を設計に組み込んでおくと、後の改修を避けられます。

顧客ごとのデータ分離

複数の顧客企業が使うサービスでは、「他社のデータが見えることはないか」「どのように分離しているか」がほぼ必ず問われます。データベースを顧客ごとに分けるのか、同じデータベースの中で顧客を識別する列で分けるのかなど、方式によって説明の仕方が変わります。どの方式でも、アクセスのたびに顧客の識別を必ず確かめる仕組みを、個々の画面の実装に任せず共通の層で強制しておくことが重要です。分離方式の選び方はSaaSのマルチテナント設計で詳しく解説しています。

認証まわりの拡張性

大企業ほど、多要素認証や、自社のID管理基盤を使ったSSO（シングルサインオン）への対応を求める傾向があります。最初からすべてを実装する必要はありませんが、ログインの仕組みを後から差し替えられる構造にしておくと、要望が来たときの改修が小さく済みます。自前でパスワード管理を作り込むより、実績のある認証サービスを使う方が、説明もしやすくなります。

操作ログと監査ログ

「誰が、いつ、どのデータに、何をしたか」を記録しているかは、よく問われる項目です。ログは後から遡って取得できないため、最初の版から記録しておく必要があります。少なくとも、ログイン・ログアウト、権限の変更、データの出力や一括削除のような重要な操作は記録対象にしておきます。何をどう記録するかは監査ログの用語ページも参考にしてください。

暗号化と秘密情報の管理

通信の暗号化は今では前提です。それに加えて、保存データの暗号化、パスワードの安全な保存、APIキーやデータベースのパスワードなどの秘密情報をソースコードに直接書かないこと、が問われます。クラウドの標準機能を使えば対応しやすい部分なので、初期の設計で方針を決めておきます。

バックアップと復旧

バックアップの頻度、保管場所、保存期間に加え、実際に復元できることを確かめているかが問われます。どこまで遡って復旧できればよいか、どれくらいの時間で復旧すべきかという目標を決めておくと、回答の根拠になります。この二つの目標は、障害の際に取引先へ説明する内容そのものになります。

開発のプロセスそのもの

見落とされがちですが、「どう作っているか」もよく問われます。コードの変更を本番に反映する前に別の人が確認しているか、本番と検証の環境が分かれているか、本番のデータを開発用の環境に持ち出していないか、といった項目です。少人数の開発でも、変更内容をレビューしてから反映する、検証環境で動作を確かめてから本番に出す、本番データは匿名化してから開発に使う、という流れを最初から習慣にしておけば、そのまま回答の根拠になります。

運用で整えるべき体制とルール

設計が整っていても、運用のルールと記録がなければ「やっている」ことを示せません。少人数の会社でも、次のものは早い段階で整えておくと、チェックシートへの回答がぐっと楽になります。

• 情報セキュリティの基本方針と規程：長い文書である必要はありません。アクセス権限の付与と削除、パスワードと端末の管理、外部サービスの利用、事故の際の連絡を定めた数ページの規程で始められます。
• アクセス権限の棚卸し：本番環境やデータベースに誰がアクセスできるかを一覧にし、定期的に見直した記録を残します。退職者や契約終了した委託先の権限が残っていないかを確認します。
• 脆弱性への対応の記録：使っている部品の更新をいつ行ったか、脆弱性診断を行ったならその結果と対応を記録します。
• インシデント対応の手順：事故が起きたとき、誰が判断し、顧客にいつ、どう連絡するかを決めておきます。実際に起きる前に、一度机上で手順を確認しておくと安心です。
• 委託先と外部サービスの一覧：開発や運用を委託している会社、データを預けている外部サービスの一覧と、その管理方法を整理します。
• 従業員への教育の記録：年に一度でも、セキュリティの基本を確認する機会を設け、実施した記録を残します。

外部の認証制度（情報セキュリティマネジメントシステムの認証や、個人情報の取り扱いに関する認証など）を取得しているかを問われることもあります。取得には相応の準備と費用がかかるため、取引先の要求度合いや事業の段階に応じて判断するのが現実的です。制度の要件は変わることがあるため、最新の情報は認証機関などの公的な情報で確認してください。

回答の作り方：手順と管理のしかた

チェックシートを受け取ったら、次の手順で回答を作ります。

1. 質問を分野ごとに振り分ける：前述の表の分野に沿って、組織、認証、データ保護、ログ、脆弱性、可用性、インシデント、契約に分けます。
2. 担当者を決める：設計に関わる質問は開発責任者、規程や体制に関わる質問は経営者や管理部門、契約に関わる質問は営業や法務が回答の下書きを作ります。開発を外部に委託している場合は、委託先にも確認します。
3. 事実だけを書く：「対応しています」だけでなく、何をどうしているかを具体的に書きます。「通信はTLSで暗号化、保存データはクラウドの標準機能で暗号化」のように、確認できる事実で答えます。
4. できていない項目は、現状と予定を書く：「未対応」とだけ書かず、代わりに取っている対策と、対応の予定時期を書きます。予定時期は守れる範囲で書きます。
5. 社内で読み合わせる：回答に矛盾がないか（ある質問ではログを保存していると答え、別の質問では保存期間を決めていないと答える、など）を確認します。
6. 標準回答として保存する：取引先に提出した回答を、社内の標準回答集として保存します。次のチェックシートでは、ここから引用して作ります。
7. 定期的に更新する：システムや体制が変わったら、標準回答も更新します。古い回答を使い回すと、事実と違う回答を出してしまう危険があります。

標準回答集が育ってくると、新しいチェックシートの多くの質問は引用で埋まり、取引先ごとに違う部分だけを考えればよくなります。営業の段階で、標準的なセキュリティの説明資料を先に渡しておけば、チェックシートの回答自体を簡略にしてもらえることもあります。

答えられない項目への向き合い方

小さな会社や立ち上げ間もないサービスでは、すべての項目を満たせないのが普通です。大切なのは、取り繕わないことです。事実と違う回答は、後で発覚したときに契約上の問題になり、信頼を大きく損ないます。満たせない項目は、代わりの対策（たとえば、多要素認証が未対応なら、IPアドレスによる接続制限で補う）と、対応の見込みを示します。取引先にとって重要な項目であれば、導入の条件として対応時期を相談する、という形で前に進むことも少なくありません。

具体例：架空のBtoB SaaSが初めて大手企業の審査を受ける場面

架空の例として、従業員向けの研修管理サービスを提供する小さな会社が、初めて大手企業から百を超える質問のチェックシートを受け取った場面を考えます。

担当者が分野ごとに振り分けてみると、組織・体制の質問の多くに答えられないことが分かりました。規程は存在せず、本番環境へのアクセス権限は開発者全員が持っていて、権限の一覧もありませんでした。一方で、通信と保存データの暗号化、毎日のバックアップは、クラウドの標準機能によってすでに実現できていました。顧客ごとのデータ分離も、設計段階で顧客を識別する仕組みを共通化していたため、具体的に説明できました。

この会社は、まず数ページの情報セキュリティ規程を作り、本番環境へのアクセス権限を必要な人だけに絞って一覧化しました。操作ログについては、ログインと権限変更は記録していたものの、データの一括出力が記録対象になっていなかったため、これを追加する改修を行いました。シングルサインオンは未対応でしたが、ログインの仕組みに外部の認証サービスを使っていたため、対応の見込みと時期を具体的に書くことができました。

回答の提出後、取引先からはいくつかの追加質問がありましたが、未対応項目については対応予定を条件に導入の検討が進みました。そしてこの回答は社内の標準回答集の最初の版になり、次に別の会社からチェックシートを受け取ったときには、作成の手間が大きく減りました。

よくある失敗とその避け方

• 「対応済み」とだけ書く：具体性がないと、追加の質問が増えるだけです。何を、どの仕組みで、どの頻度で行っているかを書きます。
• 実態と違う回答をする：通したい気持ちから、予定を実施済みのように書くのは厳禁です。発覚すれば契約の解除や損害の問題になりかねません。
• 開発会社任せにする：委託先にすべて答えてもらおうとすると、組織や契約に関する質問が埋まりません。設計に関わる部分は委託先と協力しつつ、回答の責任は自社が持ちます。開発を委託する際に指定すべき項目は外注開発のセキュリティ要件で整理しています。
• 後回しにしてから慌てる：大手との商談が進んでから初めて設計上の不足に気づくと、改修が間に合わず導入が遅れます。最初の版の段階で、典型的な項目を確認しておきます。初期段階の考え方は大企業向けMVPのセキュリティ審査も参考になります。
• 回答を使い捨てにする：毎回ゼロから作ると時間がかかるうえ、回答ごとに内容がぶれます。標準回答集として管理します。

開発・運用体制のチェックリスト

• 顧客ごとのデータ分離の方式を説明でき、共通の仕組みで強制している
• ログインの仕組みを差し替えられる構造になっており、多要素認証やSSOへの対応方針がある
• ログイン、権限変更、データ出力などの重要な操作をログに記録し、保存期間を決めている
• 通信と保存データが暗号化され、秘密情報がソースコードに書かれていない
• バックアップの頻度・保管場所・保存期間を決め、復元を試したことがある
• 本番環境へのアクセス権限の一覧があり、定期的に見直した記録がある
• 情報セキュリティの基本方針と規程があり、従業員に周知している
• 事故の際の連絡体制と、顧客への連絡の手順が決まっている
• 委託先と利用している外部サービスの一覧がある
• 過去の回答を標準回答集として保存し、更新している

よくある質問

Q. 立ち上げたばかりで規程も認証もありません。チェックシートを出されたら諦めるべきですか？

諦める必要はありません。取引先も、立ち上げ期のサービスがすべてを満たしているとは考えていないことが多いです。満たせている項目を具体的に示し、満たせない項目は代わりの対策と対応予定を誠実に書けば、検討を続けてもらえる可能性は十分にあります。そのうえで、規程の整備など短期間でできることから着手してください。

Q. 開発を外部に委託しています。回答は誰が作るべきですか？

回答の責任は、サービスを提供している自社にあります。設計や運用の技術的な部分は委託先に下書きや確認を依頼し、組織・体制・契約の部分は自社で作るのが現実的です。委託先が回答に協力できる体制かどうかは、委託先を選ぶ段階で確認しておくと安心です。

Q. 脆弱性診断は必ず受けるべきですか？

取引先によっては、第三者による脆弱性診断の実施を求められることがあります。費用がかかるため、すべての段階で必須とは限りませんが、大企業との取引が増える段階では検討の価値があります。少なくとも、使っている部品を定期的に更新し、開発時にセキュリティの観点でコードを確認する運用は、早い段階から取り入れておくべきです。

Q. 一度作った回答は、別の取引先にもそのまま使えますか？

内容の多くは使い回せますが、質問の文言や求める粒度は取引先ごとに違います。標準回答を下敷きにしつつ、質問の意図に合わせて調整してください。また、提出時点の事実と合っているかを毎回確認することが大切です。

Otsumuに相談できること

すでに開発・運用の体制が整っていて、規程や記録もある程度そろっている場合は、この記事の手順に沿って質問を振り分け、事実を具体的に書き、標準回答集として管理するところまで、自社で十分に進められます。最初の一回は時間がかかりますが、二回目以降はぐっと楽になります。

一方で、これから大手企業向けにサービスを広げようとしているのに、設計の段階でデータ分離やログ、認証の拡張性をどこまで作り込むべきか判断できない場合や、チェックシートを受け取ってから設計上の不足が見つかり、改修の範囲と優先順位を決められない場合は、作り手の視点を入れた方が早く進みます。後から変えにくい部分を見極めることが、費用と期間の両方に効くからです。

Otsumuは、BtoBサービスの設計段階からチェックシートで問われやすい項目を織り込み、必要な機能に絞って短期間で開発する進め方を取っています。事業者向けのクラウドサービスを作る場合はSaaS開発、既存システムの改修や体制の見直しを含む場合はシステム開発をご覧ください。大企業向けの最初の版を短期間で作りたい場合は新規事業の爆速MVPシステム開発もご用意しています。

受け取ったチェックシートを見ながら、「設計で対応すべき項目」と「運用で整えればよい項目」を切り分けるところからご一緒できます。まずは30分の無料相談でお気軽にご相談ください。

この記事のテーマに最も近い支援は、開発会社選定・発注者支援です。

• RFPと比較表で、見積もりをそろえる
• 準委任・請負など契約形態の違いを整理
• 外注から内製への引き継ぎまで見据える

まずは30分の無料相談で、状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01