なりすましによる
不正送金を、
止められていますか。

振込先の変更や請求を、届いたメールの中にある連絡先ではなく、登録済みの連絡先で確認しているか。

振込先が変わった直後や、初めての振込先への支払いを、確認が済むまで保留にしているか。

振込先を変更できる人を決めていて、変更されたとき、変えた本人以外（登録済みの担当者など）にも知らせが届くか。

変更後の最初の入金や支払いを確認する担当と期限が決まっていて、合わなければ次の送金を止められるか。

取引先ごとに、登録を変えてよい担当者の一覧があるか。

担当者の追加の申し込みに書かれたメールアドレスが、取引先のものかを確認しているか。

取引先の登録へのログインの再設定は、登録済みの連絡先にだけ送られる手順になっているか。

請求のメールのドメインが、取引先の登録済みのものと一致するかを確認しているか。

取引先や支払いの額が外から知られている前提で、手順を組んでいるか。

送金の依頼や指示を、届いたメールやチャットとは別の手段（登録済みの電話番号など）で、本人に確認する手順があるか。

新しい管理者アカウントが作られたり、アプリが自分に権限を付けたりしたとき、担当者に知らせが届くか。

使っていないアプリや入口、必要より広い権限を、定期的に見直して閉じているか。

委託先やベンダーが侵害や重大な脆弱性を公表したとき、何日以内に何を止め、どのパスワードや鍵から入れ替えるか、手順と担当が決まっているか。

外部の作業者に渡したアカウントを、疑いが出たときにすぐ止められるか。

外部の作業者が身分証の持ち主本人であることを、画像以外の方法で確認しているか。

管理画面や外部連携の入口に接続できる場所を、自社のネットワークだけに絞っているか。

本番のキーやデータベースのパスワードを、ソースコードや設定ファイルに平文で置かずに管理しているか。

開発者のキー 1 本で届くリポジトリを、必要な範囲に絞っているか。

委託先や運営会社で事故が起きたとき、自社が影響を受けたか、何人分のどの情報かを、すぐに受け取れる取り決めがあるか。

配信先のリストや委託先に渡す情報を、要る項目だけに絞っているか。

本人確認の映像が仮想カメラから来たとき、それを見分ける仕組みがあるか。

口座を開いた直後に、短期間の大きな取引など不正の兆候が出たら、本人確認をやり直す手順があるか。

2027 年 4 月の本人確認の制度の変更に向けて、写真の画像を送る方式から移る計画があるか。

振込先を変更できる人を決めていて、変更されたとき、変えた本人以外（登録済みの担当者など）にも知らせが届くか。

取引先の登録へのログインの再設定は、登録済みの連絡先にだけ送られる手順になっているか。

大量の読み出しに、件数の上限や、負荷の監視のほかにも気づいて止める手段があるか。

委託先の再委託や転売を、契約の前や事前に知り、実際に作業する人物を把握できる取り決めになっているか。

配信サービスへのログインに、フィッシングに強い多要素認証を求めているか。

社内の人や取引先を名乗る連絡でログイン情報を求められたとき、別の手段（登録済みの電話番号など）で確認する手順があるか。

組織のメールアドレスで外部のサービスにアカウントを作るときは、承認や届け出が要る決まりになっているか。

承認していないサービスへの通信を、技術的に止められているか。

新しいツールを承認するとき、情報の扱いに問題がないかの確認が要るかを、申請した本人以外も判断しているか。

組織のメールアドレスで外部のサービスにアカウントを作るときは、承認や届け出が要る決まりになっているか。

一斉の通知やメールは、作った人とは別の人の確認を経てから送られ、予定と違う宛先への一斉配信は送る前に止められるか。

自社の名義の通知を送るサービスとドメインを把握していて、偽の通知が出回ったとき、受け取った人に本物の見分け方を案内できるか。

配信サービスへのログインに、フィッシングに強い多要素認証を求めているか。

社内の人や取引先を名乗る連絡でログイン情報を求められたとき、別の手段（登録済みの電話番号など）で確認する手順があるか。

送る前に、作った本人とは別の人か別の手段が、中身や宛名を元の一覧と突き合わせているか。合わなければ止められるか。

突き合わせたことが記憶ではなく記録として残り、各行が元の一覧のどの行から作られたかを後から辿れるか。

取引先ごとに分けたファイルは、扱う場所か担当者を分けているか。

委託先が送付を行う場合、委託先の確認の手順を把握しているか。

配信先のリストや委託先に渡す情報を、要る項目だけに絞っているか。

取引先や支払いの額が外から知られている前提で、手順を組んでいるか。

送金の依頼や指示を、届いたメールやチャットとは別の手段（登録済みの電話番号など）で、本人に確認する手順があるか。

その確認は、金額や「秘密」の指定にかかわらず、省けない決まりになっているか。

担当者が指示を疑ったとき、送金を止めて相談できる相手が決まっているか。

振込の作成と承認は別の人が行い、1 人の判断だけで短い間に何度も送金できない設定になっているか。

送金はすべてシステムの支払いの流れを通り、その外で手作業の送金をする道は閉じているか。

社内の口座間の資金移動に、理由の裏付けを求めているか。

銀行から入出金の照会があったとき、口座の明細を直接見て確認する手順があるか。

振込先の変更や請求を、届いたメールの中にある連絡先ではなく、登録済みの連絡先で確認しているか。

振込先が変わった直後や、初めての振込先への支払いを、確認が済むまで保留にしているか。

請求のメールのドメインが、取引先の登録済みのものと一致するかを確認しているか。

漏れたとき、何が・何件・いつからいつまで取られたかを、相手の記録に頼らず自社の記録で言えるか。

調査に使うログは、攻撃者が消したり書き換えたりできない場所にあり、書き換えられていないことを示せるか。

大量の読み出しに、件数の上限や、負荷の監視のほかにも気づいて止める手段があるか。

委託先の「保存しない」「消した」という説明を、消去の記録や写真などで確認しているか。

委託先の再委託や転売を、契約の前や事前に知り、実際に作業する人物を把握できる取り決めになっているか。

委託先が照会するデータソースと、データが保存される場所を言えるか。

利用者の連絡先が漏れたとき、利用者にフィッシングへの注意を伝える手順があるか。

会員情報を返す API を一覧にして、それぞれ誰が何のために使うかを決めているか。

開発やテストの環境のうち、本番の顧客データを持つものを一覧で言えるか。

それらの環境に外から入れる人を決め、ID・パスワードのほかの方法でも本人を確認しているか。

目的を終えた環境が廃止されたことを、誰が確認するかが決まっているか。

フォームで集めた個人情報が、どの SaaS に、いつからいつまで残っているか。ゴミ箱やテスト送信の分も含めて言えるか。

委託先がファイルのやり取りに使う共有の場所に、自社の個人情報が置かれているか、置かれているなら誰が見られるかを把握しているか。

委託先やベンダーが侵害や重大な脆弱性を公表したとき、何日以内に何を止め、どのパスワードや鍵から入れ替えるか、手順と担当が決まっているか。

委託先や運営会社で事故が起きたとき、自社が影響を受けたか、何人分のどの情報かを、すぐに受け取れる取り決めがあるか。

配信先のリストや委託先に渡す情報を、要る項目だけに絞っているか。

廃棄を委託した機器を、1 台ずつシリアル番号で言えるか。

委託先の「保存しない」「消した」という説明を、消去の記録や写真などで確認しているか。

委託先の再委託や転売を、契約の前や事前に知り、実際に作業する人物を把握できる取り決めになっているか。