セキュリティチェックで条件付きOKにした後の改善要求｜委託先へ伝える内容・期限・確認方法

セキュリティチェックの結果を確認し、「現時点では未対応の項目があるが、条件を付けて取引を進める」と社内で判断した。その次に必要になるのが、委託先への改善要求です。

ここで曖昧なまま「次回までに改善をお願いします」と伝えると、数か月後に確認したときに、何をどこまで直す約束だったのか分からなくなります。逆に、対策方法まで細かく指定しすぎると、委託先の環境では実行できない要求になる場合もあります。

改善要求で決めておきたいのは、相手への言い方よりも、何が未解決で、どの状態になれば条件を満たしたと判断し、いつ・何によって確認するかです。

この記事では、セキュリティチェックで条件付きOKと判断した後に、委託先へ改善を求める内容、伝え方、期限、完了確認、期限までに改善されなかった場合の扱いまでを順に説明します。

なお、本記事でいう「条件付きOK」は、未解決事項を残したまま一定の条件の下で委託を開始・継続する自社内の判断区分を、便宜上そう呼んでいます。条件付きOKにするかどうかの判断そのものは、セキュリティチェック結果はどう判断する？で扱っています。

回答に問題が見つかったとき、すべてを「改善要求」にすると、相手へ何を求めているのか分かりにくくなります。

まず、次の3つを分けます。

対応	使う場面	相手に求めること
追加確認	回答だけでは事実が分からない	説明や根拠資料を追加してもらう
差し戻し	空欄・記載不足・回答の修正が必要	回答を修正・追記して再提出してもらう
改善要求	現状の対策では不足があるが、条件付きで進めると判断した	定めた期限までに状態を改善してもらう

たとえば、「多要素認証を利用していますか」という設問に回答がなく、実施状況が分からないのであれば、まず必要なのは追加確認や差し戻しです。

一方、「現在は未導入で、3か月後に導入予定」と回答があり、その状態を社内で条件付きで受け付けたのであれば、次に行うのが改善要求です。

返ってきた回答をどの区分で扱うかは、セキュリティチェックシートの回答をどう確認するかで詳しく説明しています。本記事は、その確認と社内判断が終わった後から始めます。

委託先へ連絡する前に、自社側で改善条件を言葉にしておきます。本記事では、次の6項目を決めてから改善要求を出す流れとします。

決めること	内容
1. 対象	どの回答・対策が未解決なのか
2. 理由	委託業務や扱う情報に対して、なぜ対応が必要なのか
3. 求める状態	何ができれば改善完了と判断するのか
4. 期限	いつまでに改善してもらうのか
5. 確認方法	完了報告、資料、画面、再回答など、何で確認するのか
6. 未達時の扱い	期限までに完了しなかった場合、誰が再判断するのか

この6項目は公式に定められたフォーマットではなく、条件付きOK後の改善要求を社内で管理できる状態にするための項目立てです。

特に重要なのは、「求める状態」と「確認方法」です。

「セキュリティを強化してください」では、完了したかどうかを確認できません。「当社の委託業務で使用する管理者権限について、利用者を個人単位で識別できる状態にする」「対象者への教育を実施し、実施記録を確認できる状態にする」といったように、完了を判断できる状態まで落とします。

期限も「次回チェックまで」のような相対表現ではなく、可能であれば日付で決めます。次回確認が半年後なのか1年後なのかによって、未対応のまま残る期間が変わるためです。

委託先へ改善を依頼するときは、指摘だけを送らず、判断に必要な情報を一つのまとまりで伝えます。

たとえば、次のような形です。

項目	記載例
対象	チェックシート設問12「管理者アカウントの管理」
現状	当社委託業務で使用する管理者アカウントを複数名で共用している
理由	操作した利用者を特定できない状態を避けるため
求める状態	当社委託業務に関わる管理者操作について、利用者を識別できる状態にする
期限	2026年10月31日
完了確認	対応完了の報告と、確認可能な範囲の設定画面または運用資料

重要なのは、「できていないので直してください」で終わらせないことです。

委託先から見ても、なぜ求められているのか、どの状態まで対応すれば終わるのか、何を提出すれば完了になるのかが分かれば、社内で対応を進めやすくなります。

一方、契約、法令、自社のセキュリティ基準などで具体的な対策方法が決まっている場合は、その要件を明示します。「方法はすべて委託先に任せる」と一律に考えるものではありません。

委託先へメールで伝える場合は、次のような形にできます。

件名：セキュリティチェック結果に伴うご対応のお願い（○○項目）

○○株式会社
○○様

お世話になっております。

先日ご回答いただいたセキュリティチェックシートについて、社内で確認を行いました。

設問○○「○○○○」については、現状のままでは当社の委託業務における○○のリスクが残るため、下記の対応を条件として、本件委託を進める判断としています。

• 対象：設問○○「○○○○」
• 現在確認している状態：○○○○
• ご対応いただきたい状態：○○○○
• 対応期限：2026年○月○日
• 完了時に確認したい内容：完了のご連絡／○○が確認できる資料

対応方法について確認が必要な点や、期限までの対応が難しい事情がある場合は、○月○日までにご連絡ください。

よろしくお願いいたします。

この文面の目的は、強く要求することでも、関係を悪化させない表現を探すことでもありません。条件付きで進める社内判断と、未解決事項を閉じるための条件を同じ内容として伝えることです。

「対応をお願いします」だけ送り、社内では別の基準で完了を判断する状態は避けます。

改善に数週間、数か月かかる場合は、完了までの間も委託業務が続くことになります。

その場合は、改善完了まで何もせず待つのではなく、必要に応じて暫定的な条件を決めます。

たとえば、

• 扱う情報の範囲を限定する
• 必要な担当者だけにアクセス権限を絞る
• 一部の作業は改善完了後に開始する
• 未対応の機能や環境を委託業務では使わない
• 報告や確認の頻度を一時的に上げる

といった方法です。

どの条件が必要かは、未対応事項と委託業務への影響によって変わります。条件付きOKは「未対応でも問題ない」という意味ではなく、未対応の間に残るリスクをどう扱うかまで含めた判断として残します。

改善要求では、「目的だけ伝えて、方法は委託先に任せる」とした方がよい場面もあれば、具体的な方法まで指定すべき場面もあります。

分ける基準は、その要求の根拠です。

契約条件や法令、自社が委託先へ必須としているセキュリティ要件に具体的な方法が定められているなら、その内容を求めます。

一方、求めているのが「利用者を識別できること」「権限を必要な範囲に限定できること」といった状態であり、達成方法が複数あるなら、委託先の環境に合う方法を提案してもらう余地があります。

IPAの「サイバーセキュリティ経営ガイドライン」の指示9でも、委託先を含む対策状況の把握に加え、契約上の役割・責任範囲を明確にし、必要に応じて導入支援や共同実施などの方策を検討する考え方が示されています。

要求を出す側が「正解の製品」を決めることより、何を満たす必要があり、誰がどこまで責任を持つのかを明確にすることが先です。

条件付きOKで避けたいのは、改善要求を送った時点で対応を終えた扱いにしてしまうことです。

改善要求は、相手へ送った日ではなく、改善を確認して社内で閉じた時点で完了します。

管理表には、少なくとも次の情報を残します。

管理項目	記録する内容
委託先	対象の会社・サービス
対象項目	どの設問・対策に対する要求か
条件付き判断日	いつ条件付きで受け付けたか
社内承認者	誰が条件付き判断を承認したか
改善要求	何をどの状態まで求めたか
委託先担当者	相手側の対応窓口・責任者
期限	改善完了予定日
暫定条件	完了までの間に付けた条件
確認方法	何をもって完了とするか
確認結果	完了／未完了／期限変更など
次の対応	再確認日、上位判断など

条件付きOKというステータスだけでは、何を条件にしたのかまでは分かりません。

「条件」「期限」「完了を確認する方法」を一緒に残すことで、担当者が変わっても次に確認する内容を追える状態になります。

改善期限になったら、結果を確認します。

進み方は大きく3つです。

完了した

合意した状態になっていることを確認し、改善事項を完了にします。重要な項目で根拠資料を求めていた場合は、その資料も確認します。

期限までに完了していないが、新しい計画が示された

担当者だけで期限を延長せず、当初の条件付き判断をした権限者または社内ルールで定めた権限者が、延長してよいかを再判断します。延長する場合は、新しい期限、理由、完了までの暫定条件を更新します。

改善されず、完了見込みも確認できない

条件付きで進めた前提が成立しているかを再評価します。扱う情報や委託範囲の変更、業務開始の延期、契約上の対応、取引継続の再判断など、必要な判断へ上げます。

「一度条件付きOKにしたから、そのまま取引を続ける」と固定しないことが重要です。改善要求の期限は、再判断する日でもあります。

改善が完了したという連絡だけで閉じるか、根拠資料まで確認するかは、項目の重要度によって変えます。

たとえば、

• 運用ルールを変更した → 改定後の規程や手順
• 教育を実施した → 実施記録
• アカウント管理を変更した → 対象範囲が分かる設定情報
• 契約上の条件を変更した → 契約書・覚書等

などが確認材料になります。

ただし、すべての改善事項に同じ重さの証跡を求める必要はありません。どの回答まで証跡を求めるかという確認の深さは、セキュリティチェックは自己申告だけでいい？で扱っています。

マモリスでは、回答内容を確認し、修正や追記が必要な場合はコメントを付けて差し戻しできます。条件付きで受け付ける場合は、確認コメントに条件や再確認予定を残し、回答・確認・差し戻しの履歴とあわせて後から確認できます。

ただし、マモリスの確認コメントへ改善期限を書いたこと自体が、その期限を自動で通知するわけではありません。委託先と合意した新しい期限や、延長・再評価といった判断は、システムの状態表示だけでは表せないため、社内の予定管理や管理表などと組み合わせて残します。

この記事で扱っているのは、改善要求を自動で追跡することではありません。誰に何を求め、どの回答をもとに判断し、その後どのような確認をしたのかを、同じ流れの中で残すことです。

Q1. 「NO」の回答があれば、すべて改善要求を出すべきですか？

一律に改善要求へ進める必要はありません。まず、その回答が委託業務に関係するか、事実確認が足りているか、現状を許容できるかを確認します。情報が足りない場合は追加確認、回答自体の修正が必要なら差し戻し、未対応の状態を条件付きで受け付けた場合に改善要求へ進みます。

Q2. 改善要求では、具体的な製品や設定方法まで指定した方がよいですか？

契約や法令、自社の必須要件で方法が定められている場合は、その要件を示します。達成方法が複数ある場合は、必要な状態と確認基準を示し、具体的な実装方法は委託先と調整する方法もあります。

Q3. 改善期限はどのくらいに設定すればよいですか？

一律の日数はありません。未対応による影響、対応に必要な作業、完了までの暫定措置を踏まえて決めます。重要なのは「次回チェックまで」だけで終わらせず、再確認する日を明確にすることです。

Q4. 委託先から期限延長を求められたら、そのまま認めてよいですか？

担当者だけで自動的に延長するのではなく、延長しても残るリスクを許容できるかを社内の判断権限に従って確認します。認める場合は、新しい期限、延長理由、暫定条件を記録します。

Q5. 改善完了の報告だけで確認済みにしてよいですか？

項目によります。影響が小さい項目では完了報告で足りる場合がありますが、重要な対策では規程、実施記録、設定情報などの根拠を確認する方法があります。改善要求を出す時点で、何をもって完了とするかを決めておくと再確認しやすくなります。

条件付きOKにした後の改善要求は、「直してください」と伝えて終わる作業ではありません。

対象となる未解決事項を明確にし、なぜ必要なのか、どの状態まで改善するのか、いつまでか、何を見て完了とするのかを決めて委託先へ伝えます。改善まで時間がかかる場合は、その間の条件も決めます。

そして、期限が来たら完了を確認する。終わっていなければ、期限延長を認めるのか、条件を変更するのか、取引判断を見直すのかを再び社内で決めます。

条件付きOKは、判断を先送りするための区分ではありません。未解決事項を期限と確認方法付きで管理し、最終的に閉じるための運用として扱うことが重要です。