2025/11/30 更新：日証協の不正アクセスガイドラインもリスト化する予定が、許可を得ないと使えないようなのでガイドラインの対応箇所のみを監督指針の表に追加。
Todo: 日証協GLのパブコメの確認。
（出典等）
金融庁ウェブサイトより、以下のリンクの資料を基に加工して作成。
– 金融商品取引業者等向けの総合的な監督指針
– 「金融商品取引業者等向けの総合的な監督指針」等の一部改正（案）に対するパブリックコメントの結果等の公表について
– コメントの概要及びコメントに対する金融庁の考え方（https://www.fsa.go.jp/news/r7/shouken/20251015/01.pdf）
– 「金融商品取引業者等向けの総合的な監督指針」の一部改正（新旧対照表）（https://www.fsa.go.jp/news/r7/shouken/20251015/02.pdf）
日本証券業協会のウェブサイトより、以下のリンクの資料を参考にした。
– インターネット取引における不正アクセス等防止に向けたガイドライン
– 「インターネット取引における不正アクセス等防止に向けたガイドライン」の改正案に関するパブリックコメントの結果について
リスト
| カテゴリ | 監督指針項番 | 監督指針の記載箇所 | 項番 | 対応項目 | 関連項目 | 関連FAQ | 日証協GL |
| 経営管理・内部管理態勢の強化 | Ⅲ－２－８－２－２（１） | インターネット等の不正アクセス・不正取引等の犯罪行為に対する対策等について、犯罪手口が高度化・巧妙化し、被害が拡大していることを踏まえ、最優先の経営課題の一つとして位置付け、取締役会等において必要な検討を行い、セキュリティ・レベルの向上に努めるとともに、利用時における留意事項等を顧客に説明する態勢が整備されているか。 | 1.1 | 不正アクセス・不正取引対策を、犯罪手口の高度化・巧妙化を踏まえ、 | GL III. | ||
| 1.1.1 | 最優先の経営課題の一つとして位置付けているか | GL III. | |||||
| 1.1.2 | 取締役会等で検討を行っているか | GL III. | |||||
| 1.1.3 | セキュリティレベル向上に努める態勢整備ができているか | GL III. | |||||
| 1.1.4 | 利用時における留意事項等を顧客に説明する態勢が整備できているか | GL III. | |||||
| インターネット取引の健全かつ適切な業務の運営を確保するため、金融商品取引業者内の各部門が的確な状況認識を共有し、金融商品取引業者全体として取り組む態勢が整備されているか。 | 1.2.1 | 金融商品取引業者内の各部門が的確な状況認識を共有しているか | GL III. | ||||
| 1.2.2 | 金融商品取引業者全体として取り組む態勢が整備されているか | GL III. | |||||
| 金融ＩＳＡＣやＪＰＣＥＲＴ／ＣＣ等の情報共有機関等を活用して、犯罪の発生状況や犯罪手口に関する情報の提供・収集を行うとともに、有効な対応策等を共有し、自らの顧客や業務の特性に応じた検討を行った上で、今後発生が懸念される犯罪手口への対応も考慮し、必要な態勢の整備に努めているか。 | 1.3.1 | 金融ＩＳＡＣやＪＰＣＥＲＴ／ＣＣ等の情報共有機関等を活用して、犯罪の発生状況や手口に関する情報の提供・収集及び有効な対応策等の共有を行っているか | GL III. | ||||
| 1.3.2 | 上記情報に基づき、自らの顧客や業務の特性に応じた検討を行った上で、今後発生が懸念される犯罪手口への対応も考慮し、必要な態勢の整備に努めているか | GL III. | |||||
| リスク分析、セキュリティ対策の策定・実施、効果の検証、対策の評価・見直しからなるいわゆるＰＤＣＡサイクルが機能しているか。 | 1.4.1 | PDCAサイクル（リスク分析→対策実施→効果検証→評価・見直し）が機能しているか | GL III. | ||||
| セキュリティ管理体制 | Ⅲ－２－８－２－２（２） | セキュリティ体制の構築時及び利用時の各段階におけるリスクを把握した上で、自らの顧客や業務の特性に応じた対策を講じているか。 | 2.1.1 | セキュリティ体制の構築時及び利用時の各段階におけるリスクを特定しているか | 1.4.1 | [10]業務の特性には取扱う商品の特性も含まれます | GL III. |
| 2.1.2 | 特定したリスクに対して自らの顧客や業務の特性に応じた対策を講じているか（RBAの際に、自らの顧客や業務の特性を考慮しているか） | 1.4.1 | [10]業務の特性には取扱う商品の特性も含まれます | GL III. | |||
| 個別の対策を場当たり的に講じるのではなく、効果的な対策を複数組み合わせることによりセキュリティ全体の向上を目指す | 2.1.3 | 個別の対策を場当たり的に講じるのではなく、効果的な対策を複数組み合わせることによりセキュリティ全体の向上を目指しているか | #N/A | ||||
| リスクの存在を十分に認識・評価した上で対策の要否・種類を決定し、迅速な対応が取られているか。 | 2.1.4 | リスクの特定及び評価を適切に行っているか | 1.4.1 | #N/A | |||
| 2.1.5 | 特定・評価したリスクに対してリスク低減措置の要否及び内容を決定しているか | 1.4.1 | #N/A | ||||
| 2.1.6 | リスク低減措置は妥当な期間内で実施されているか | 1.4.1 | #N/A | ||||
| インターネット取引に係る情報セキュリティ全般に関する方針を作成し、各種犯罪手口に対する有効性等を検証した上で、必要に応じて見直す態勢を整備しているか。 | 2.2.1 | インターネット取引に係る情報セキュリティセキュリティ方針を策定しているか | GL IV. 3. (1) | ||||
| 2.2.2 | 各種犯罪手口に対する有効性等を検証した上で、必要に応じて見直す態勢を整備しているか（PDCAサイクルの体制が整備されているか） | 1.4.1 | #N/A | ||||
| 針等に沿って個人・法人等の顧客属性を勘案しつつ、「金融分野におけるサイバーセキュリティに関するガイドライン」や日本証券業協会の「インターネット取引における不正アクセス等防止に向けたガイドライン」等も踏まえ、提供するサービスの内容に応じた適切なセキュリティ対策を講じているか。 | 2.2.3 | 顧客属性及びガイドラインが反映されたRBAを採っているか | 1.4.1 | GL IV. 2. (1) | |||
| 犯罪手口の高度化・巧妙化等（「中間者攻撃」や「マン・イン・ザ・ブラウザ攻撃」など）を考慮しているか。 | 2.2.4 | 犯罪手口の高度化・巧妙化等（「中間者攻撃」や「マン・イン・ザ・ブラウザ攻撃」など）を考慮しているか。 | #N/A | ||||
| フィッシング詐欺対策 | メールやＳＭＳ（ショートメッセージサービス）内にパスワード入力を促すページのＵＲＬやログインリンクを記載しない（法令に基づく義務を履行するために必要な場合など、その他の代替的手段を採り得ない場合を除く。） | 2.3.1 | メールやSMSにパスワード入力を促すページのURLまたはログインリンク（パブコメも参照）を記載していないか。 | [15]ログインすることが可能な画面へ遷移するページのURL についても記載すべきではない [19なお書き,20なお書き]ログインを伴わずに閲覧できる場合であっても、同じページ内にログインボタンが表示されるような状態は適切ではない [16]注意喚起やパスキー等では代替措置とならない [17]共通ショートコード等で送信元を担保しても記載は許されない | GL IV. 4. (5) | ||
| 利用者に対して正規のウェブサイトのブックマークや正規のアプリからログインすることを促す | 2.3.2 | 利用者に対して正規のウェブサイトのブックマークや正規のアプリからログインすることを促しているか。 | GL IV. 7. (2) ⑥ | ||||
| 送信ドメイン認証技術の計画的な導入 | 2.3.3 | 送信ドメイン認証技術（DMARC等）の計画的な導入を行っているか。 | [24]DMARCポリシーはrejectが望ましい | GL IV. 4. (1) | |||
| フィッシングサイトの閉鎖依頼 | 2.3.4 | フィッシングサイトの閉鎖依頼を適宜実施しているか。 | GL IV. 4. (3) | ||||
| （注）情報の収集に当たっては、金融関係団体や金融情報システムセンターの調査等、金融庁・警察当局から提供された犯罪手口に係る情報などを活用することが考えられる。 | 2.4.1 | 金融ISACやFISC、自主規制団体及び金融庁、警察当局からの情報を方針策定やRBA等に活用しているか。 | GL IV. 4 | ||||
| 認証・不正防止策 | インターネット取引を行う場合には、提供するサービスの内容に応じて、以下の不正防止策を講じているか。 | 2.5 | 2.5.1以下参照 | [29]提供するサービスの内容＝インターネット上の業務内容や商品性に応じて、必要・適切な不正防止策を講じる必要がある [38]パスキー等は、一部の事業者による任意のサービスではなく、業界全体で必須化が重要。また、顧客の被害防止のみならず、犯罪による不当な資金流出を遮断することにもつながり業界の信頼性の向上にも資する [50]ログイン後に表示される顧客情報等を全てマスキングしてもパスキー等は必要 [51]証券口座や銀行口座へのログイン時には、フィッシングに耐性のある多要素認証を導入すべきと考えます [64]ログイン後に表示される個人情報等が悪用される可能性も考えられることから、ログインそのものも重要な操作である [74]パスキー等に移行した顧客について過去に利用していたパスワード等の認証情報は削除する必要がある | #N/A | ||
| 内外の環境変化や事故・事件の発生状況を踏まえ、定期的かつ適時にリスクを認識・評価し、必要に応じて、認証方式等の見直しを行っているか。 | 2.5.1 | 定期及び随時にRBAの見直しを実施し、適切なリスク低減措置を講じているか。 | 1.4.1 | GL III. | |||
| ログイン、出金、出金先銀行口座の変更など、重要な操作時におけるフィッシングに耐性のある多要素認証（例：パスキーによる認証、ＰＫＩ（公開鍵基盤）をベースとした認証）の実装及び必須化（デフォルトとして設定） | 2.5.2 | ログイン、出金、出金先銀行口座の変更時において、パスキー認証またはPKI認証（以下、「パスキー等」とする）を必須化しているか。 | [28,30]証券会社以外の金商業者等もパスキー等の対応が必要 [45,46,47]フィッシングに耐性のある多要素認証の導入に際して、前提として、確実に本人の認証情報を登録することは重要（コメント側は認証器の初回登録時のみならず、再登録時についても言及） [49]ログイン時以外でのパスキー等の利用はログイン認証を突破された場合（セッションハイジャック等を想定か）に有効であり重要 [53]ログイン時に多要素認証を行っていた場合においても「顧客の意図しない出金がなされることはない」とは言い切れず、その他の段階においても不正な操作を阻止するために複数の対策を講じている必要があるため、重要な操作時におけるフィッシングに耐性のある多要素認証の必須化は必要 [64]取引チャネルが限定されている場合であってもそのログイン時においては「フィッシングに耐性のある多要素認証」による必要がある [65]一定期間多要素認証を省略できるといった機能は、基本的には望ましくない。デバイスの乗っ取り、セッションハイジャック等のリスクを防ぐためにも、「ログイン、出金、出金先銀行口座の変更」などの重要な操作を行う際にフィッシングに耐性のある多要素認証を必須化することが重要 | GL IV. 1. (2) ① | |||
| 2.5.3 | その他重要な操作時（パスキー認証器の追加及び削除、登録連絡先（通知先）の変更時等）にパスキー等を必須化しているか。 | [49]（2.5.2も参照） | GL IV. 1. (2) ① | ||||
| （注１）フィッシングに耐性のある多要素認証の実装及び必須化以降、顧客が設定に必要な機器（スマートフォン等）を所有していない等の理由でやむを得ずかかる多要素認証の設定を解除する場合には、代替的な多要素認証を提供するとともに、解除率の状況をフォローした上で、認証技術や規格の発展も勘案しながら、解除率が低くなるよう多要素認証の方法の見直しを検討・実施することとする。 | 2.5.4 | パスキー認証器を保有していない等やむを得ない理由以外でパスキー等を不要としているケースはないか。 | [2なお書き]フィッシングに耐性のある多要素認証の設定の解除が認められるのは、顧客が設定に必要な機器を所有していない等のやむを得ない理由がある場合のほか、システム上行うことができる操作が情報の閲覧のみであり取引を一切行うことができない場合等に限られる [39]採用する認証方式を顧客の判断に委ね、それを前提に顧客対応に差異を設けることは適切ではない [44]顧客要望による例外を認めることは、顧客がそのリスクを認識していたとしても不正アクセスの隙を与えることにつながりかねず、原則としてフィッシングに耐性のある多要素認証を必須化することが適切 [78]顧客側の物理的・技術的な理由で設定できない場合は「やむを得ずかかる多要素認証の設定を解除する場合」に該当する可能性があるが、IT リテラシーが著しく低い顧客の場合は、そもそもインターネット取引を提供することの適切性について検討する必要がある。他、（２）複数端末利用、（３）高頻度取引のための解除希望、（４）出金時のみ解除希望、は解除不可の事例である。 | GL IV. 1. (2) ① | |||
| 2.5.5 | やむを得ない理由でパスキー等を不要とするときのため、代替的な多要素認証を提供しているか。 | GL IV. 1. (2) ① | |||||
| 2.5.6 | パスキー等を不要としている顧客の割合をモニタリングし、状況を踏まえつつ有効化している顧客が増加するよう周知等の施策を検討・実施しているか。 | 3.4.1 3.4.2 | [32,33,34]本改正において各社に求める多要素認証の水準は「フィッシングに耐性のある多要素認証」である [77]解除率の状況をフォローし、解除率が低くなるような対策を講じる必要がある。サービスの利用に必要な IT リテラシーについて、顧客の意識向上に努めていくことが重要。 [79]解除率は「パスキー等を無効とした顧客/全顧客」で算出する。 | GL IV. 1. (2) ① | |||
| （注２）フィッシングに耐性のある多要素認証を実装及び必須化するまでの間は、代替的な多要素認証を提供するとともに、当該実装及び必須化に向けた具体的なスケジュールについて顧客に周知する必要がある。また、それまでの期間においても、振る舞い検知やログイン通知等の検知機能を強化する必要がある。 | 2.5.7 | パスキー等の必須化までの間、代替的な多要素認証を提供しているか。 | GL IV. 1. (2) ① | ||||
| 2.5.8 | パスキー等必須化までの具体的なスケジュールを周知しているか。 | [40]スケジュール周知期間については、顧客の安心のために、できる限り早期
に見通しを明らかにすることが重要。周知方法は問わず、顧客属性や取引形態等に関わらず、正しく理解できる内容により、確実に伝わる方法で行うことが重要 | GL IV. 1. (2) ① | ||||
| 2.5.9 | パスキー等必須化までの間、振る舞い検知やログイン通知等の検知機能を強化しているか。 | 2.5.12 | [82]ログイン履歴で提供する項目については、顧客が自身の取引かどうかを判
別できる程度の内容が求められる | GL IV. 1. (2) ① | |||
| 顧客が身に覚えのない第三者による不正なログイン・取引・出金・出金先口座変更を早期に検知するため、電子メール等により、顧客に通知を送信する機能の提供 | 2.5.10 | 少なくともリスクベースでのログイン・取引・出金・出金先口座変更通知の機能を提供しているか。 | 2.6.6 | [82]ログイン履歴で提供する項目については、顧客が自身の取引かどうかを判
別できる程度の内容が求められる | GL IV. 1. (2) ② | ||
| 認証に連続して失敗した場合、ログインを停止するアカウント・ロックの自動発動機能の実装及び必須化 | 2.5.11 | 連続ログイン失敗回数を基準とした自動アカウント・ロック機能を必須化しているか。 | GL IV. 1. (2) ③ | ||||
| 顧客のログイン時の挙動の分析による不正アクセスの検知（ログイン時の振る舞い検知）及び事後検証に資するログイン・取引時の情報の保存の実施 | 2.5.12 | ログイン時の振る舞い検知を実施しているか。 | 2.5.9 | GL IV. 5. (1) | |||
| 2.5.13 | 事後検証に資するログイン・取引時の情報を保存しているか。 | GL IV. 5. (1) | |||||
| 不正アクセスの評価に応じて追加の本人認証を実施するほか、当該不正が疑われるアクセスの適時遮断、不正アクセス元からのアクセスのブロック等の対応の実施 | 2.5.14 | リスクベースによる追加の本人認証、アクセス遮断、アクセスブロック等の対応を実施しているか。 | [86]顧客の状況に応じたリスク評価を行うことが重要であり、必ずしもログイン時の挙動だけに限るものではない | GL IV. 5. (2) | |||
| 日本証券業協会の「インターネット取引における不正アクセス等防止に向けたガイドライン」においてスタンダード（対応が必要な事項）とされた措置の実施 | 2.5.15 | 日証協GLを参照。 | GL全体 | ||||
| さらに、例えば、以下のような不正防止策を講じているか。 | 2.6 | 2.6.1以下は例示であるとともに、必須項目ではない（但し、検討を行いなぜ講じていないかを合理的かつ適切に説明可能なよう整理すべきであると考えられる）。 | #N/A | ||||
| 取引時や他の銀行口座との連携サービス提供時におけるフィッシングに耐性のある多要素認証の提供 | 2.6.1 | パスキー等による取引時の認証機能を提供しているか。 | GL IV. 1. (2) BP, GL IV. 7. (3) BP | ||||
| 2.6.2 | パスキー等による銀行口座との連携サービス提供時の認証機能を提供しているか。 | [89]投資信託等の定時定額購入における銀行口座から証券口座への定期的な入金サービスについては、設定変更等の重要な操作を除いては、他の銀行口座との連携サービスの対象外 [90]本規定の趣旨は、顧客の身に覚えのない不正な操作で資金移動が行われること及び顧客の個人情報等が漏えい（不正に閲覧）されることを防ぐもの | #N/A | ||||
| 取引金額の上限や購入可能商品の範囲を顧客が設定できる機能の提供 | 2.6.3 | 取引金額の上限設定機能を提供しているか。 | [91]銀行口座からの資金移動金額の上限設定と取引機能の上限設定は別のもの | GL IV. 1. (2) BP | |||
| 2.6.4 | 取引しない商品等を設定できるか（例えば、現物取引のみで信用取引をしない場合に信用取引口座を開設していたとしても取引をできなくする、等）。 | #N/A | |||||
| 不正なログイン・異常な取引等を検知し、速やかに利用者に連絡する体制と仕組みの整備 | 2.6.5 | 不正なログイン・異常な取引等を検知できるか。 | 2.5.12 | GL IV. 5. (1) GL IV. 5. (BP) | |||
| 2.6.6 | 検知した不正ログイン・異常取引等を利用者への速やかに連絡する体制及び仕組みは整備されているか（2.5.10は単なるログイン通知等であり、本項目は不正ログインと判断されたものの通知＝不正ログイン通知と考えられる）。 | 2.5.10 | [82]ログイン履歴で提供する項目については、顧客が自身の取引かどうかを判
別できる程度の内容が求められる | GL IV. 1. (2) ② GL IV. 6. (1) | |||
| 日本証券業協会の「インターネット取引における不正アクセス等防止に向けたガイドライン」においてベストプラクティス（対応することが望ましい事項）とされた措置の実施 | 2.6.7 | 日証協GLを参照。 | GL全体 | ||||
| 顧客対応・情報提供態勢の整備 | Ⅲ－２－８－２－２（３） | インターネット上でのＩＤ・パスワード等の個人情報の詐取の危険性、類推されやすいパスワードの使用の危険性（認証方式においてパスワードを利用している場合に限る。）、被害拡大の可能性等、様々なリスクの説明や、顧客に求められるセキュリティ対策事例の周知を含めた注意喚起等が顧客に対して十分に行われる態勢が整備されているか。 | 3.1.1 | インターネット上でのフィッシングをはじめとした個人情報詐取の危険性の周知・注意喚起を実施しているか。 | GL IV. 7. (2) ① | ||
| 3.1.2 | 類推されやすいパスワードの使用の危険性（認証方式においてパスワードを利用している場合に限る。）、被害拡大の可能性について周知・注意喚起を実施しているか。 | GL IV. 7. (2) ① | |||||
| 3.1.3 | 顧客に求められるセキュリティ対策事例の周知を含めた注意喚起等を実施しているか。 | GL IV. 7. (2) ① | |||||
| 顧客自らによる早期の被害認識を可能とするため、顧客が取引内容を適時に確認できる手段を講じているか。 | 3.2.1 | 顧客が取引内容を適時に確認できるか。 | GL IV. 1. (2) ② | ||||
| 顧客からの届出を速やかに受け付ける体制が整備されているか。 | 3.3.1 | 顧客からの被害届出を速やかに受け付ける体制を整備しているか。 | [103,104,105] | GL IV. 7. (2) ⑤ | |||
| 顧客への周知（公表を含む。）が必要な場合、速やかにかつ顧客が容易に理解できる形で周知できる体制が整備されているか。 | 3.3.2 | 顧客への周知（公表を含む。）が必要な場合、速やかにかつ顧客が容易に理解できる形で周知できる体制が整備されているか。 | GL IV. 7. (2) ③ | ||||
| 被害にあう可能性がある顧客を特定可能な場合は、可能な限り迅速に顧客に連絡するなどして被害を最小限に抑制するための措置を講じることとしているか。 | 3.3.3 | 被害にあう可能性がある顧客を特定可能な場合は、可能な限り迅速に顧客に連絡するなどして被害を最小限に抑制するための措置を講じることとしているか。 | GL IV. 6. (1) | ||||
| 不正取引を防止するための対策が利用者に普及しているかを定期的にモニタリングし、普及させるための追加的な施策を講じているか。 | 3.4.1 | 不正取引を防止するための対策が利用者に普及しているかを定期的にモニタリングしているか。 | GL IV. 1. (3) | ||||
| 3.4.2 | 不正取引を防止するための対策を普及させるための追加的な施策を講じているか。 | GL IV. 1. (3) | |||||
| 不正取引による被害があった場合には、被害状況を十分に精査し、顧客の態様やその状況等を加味したうえで、顧客の被害補償を含め、被害回復に向けて真摯な顧客対応を行う態勢が整備されているか。 | 3.4.3 | 不正取引による被害があった場合には、被害状況を十分に精査できる態勢となっているか。 | GL IV. 6. (1) | ||||
| 3.4.4 | 顧客の態様やその状況等を加味したうえで、顧客の被害補償を含め、被害回復に向けて真摯な顧客対応を行う態勢が整備されているか。 | [108,109,110,111,112,113,114] | GL IV. 6. (1) | ||||
| 不正取引に関する記録を適切に保存するとともに、顧客や捜査当局から当該資料の提供などの協力を求められたときは、これに誠実に協力することとされているか。 | 3.4.5 | 不正取引に関する記録を適切に保存しているか。 | GL IV. 5. (1) | ||||
| 3.4.6 | 顧客や捜査当局から当該資料の提供などの協力を求められたときは、これに誠実に協力することとされているか。 | GL IV. 6. (3) ② | |||||
| Ⅲ－２－８－２－２（４） | インターネット取引が非対面取引であることを踏まえた、取引時確認等の顧客管理態勢の整備が図られているか。 | 3.5.1 | インターネット取引が非対面取引であることを踏まえた、取引時確認等の顧客管理態勢の整備が図られているか。 | #N/A | |||
| インターネット取引に関し、外部委託がなされている場合、外部委託に係るリスクを検討し、必要なセキュリティ対策が講じられているか。 | 3.5.2 | インターネット取引に関し、外部委託がなされている場合、外部委託に係るリスクを検討し、必要なセキュリティ対策が講じられているか。 | GL IV. 3. (2) | ||||
| 犯罪発生時の報告 | Ⅲ－２－８－２－３（１） | インターネット取引における不正アクセス・不正取引を認識次第、速やかに「犯罪発生報告書」にて当局宛て報告を求めるものとする。 | 4.1.1 | インターネット取引における不正アクセス・不正取引を認識次第、速やかに「犯罪発生報告書」にて当局宛て報告を求めるものとする。 | [121] [125] | GL IV. 6. (3) ① | |
| Ⅲ－２－８－２－３（２） | 略 | 4.2.1 | 略 | #N/A |
監督指針にない日証協不正アクセスガイドラインの項目について
日証協の不正アクセスガイドラインには存在するものの、上記の金融庁の監督指針には存在しない項目の一覧（日証協GLが監督指針に加重して求める項目）。
| GL項目 | レベル | 概要 |
|---|---|---|
| GL IV. 1. (1) | スタンダード | 口座開設時の本人確認 |
| GL IV. 1. (2) | スタンダード | 全てのツールが対象 |
| GL IV. 1. (2) ④ | スタンダード | 情報のマスキング等 |
| GL IV. 1. (2) | ベストプラクティス | ツールの使用可否設定 |
| GL IV. 1. (3) | ベストプラクティス | フィッシング耐性のある多要素認証等の利用状況のモニタリング指標 |
| GL IV. 2. (2) ① | スタンダード | データの暗号化等 |
| GL IV. 2. (2) ② | スタンダード | 情報漏洩・管理強化 |
| GL IV. 2. (2) ③ | スタンダード | 本人確認書類の適切な廃棄 |
| GL IV. 2. (2) ④ | スタンダード | 特定個人情報管理の点検・強化 |
| GL IV. 4. (2) | スタンダード | 共通ショートコードの利用 |
| GL IV. 4. (4) | スタンダード | ドメインの管理・周知 |
| GL IV. 4. | ベストプラクティス | BIMI採用 |
| GL IV. 4. | ベストプラクティス | S/MIME採用 |
| GL IV. 6. (2) | スタンダード | 凍結解除時の再本人確認 |
| GL IV. 6. (3) ③ | スタンダード | JPX、日証協等の連携・報告 |
| GL IV. 6. (3) ④ | スタンダード | 銀行との連携・報告 |
| GL IV. 6. | ベストプラクティス | 金融ISAC、JPCERT/CCの活用 |
| GL IV. 6. | ベストプラクティス | 体制整備の強化 |
| GL IV. 7. (1) | スタンダード | 研修の強化 |
| GL IV. 7. (1) | ベストプラクティス | 演習、訓練 |
| GL IV. 7. (2) ② | スタンダード | 顧客のリテラシー強化 |
| GL IV. 7. (2) ④ | スタンダード | 確実なお知らせ等の確認必須化機能 |
コメント