RBNZのサイバーレジリエンス：モバイルバンキングアプリを診断しましょう。

1. 01

   RBNZ Guidance on Cyber Resilience、2021年4月、A1；Deposit Takers (Operational Resilience) Standard 2027草案、第13条および第33条

   サイバーレジリエンスを取締役会レベルで担う

   条文の内容

   取締役会はエンティティのサイバーレジリエンスの最終責任を負うべきであり、サイバーレジリエンス戦略とフレームワークの責任者となる上級役員を任命すべきです。サイバーリスク環境を理解し、サイバーリスクの許容度とアペタイトを定め、戦略とフレームワークを承認し、実施状況を監視すべきです。オペレーショナルレジリエンス基準の草案は、重要オペレーションとICTシステムの許容レベル、オペレーショナルリスク管理の枠組み、ICTシステム方針、事業継続計画の承認を取締役会の責任としています。

   出典：RBNZ Guidance on Cyber Resilience、2021年4月、A1；Deposit Takers (Operational Resilience) Standard 2027草案、第13条および第33条

   モバイルアプリにとっての意味

   ガバナンスはアプリの上位にありますが、モバイルチャネルを定期的にテストするか、結果を取締役会に届けるかを決めるのはガバナンスです。

   Ostorlabによる支援

   Ostorlabは、セキュリティチームと経営層に、リリースごとの証拠を提供します。何をテストし、何を検出し、何を修正し、何を再テストしたかが分かります。

   お客様が担うこと

   取締役会の承認、リスクアペタイト、説明責任、内部監査、テストプログラムのリソースです。

2. 02

   RBNZ Guidance on Cyber Resilience B3.7〜B3.7.2；オペレーショナルレジリエンス基準草案ガイダンス、2026年6月、第71.3項および第97.3項

   定期的かつ重大な変更の後にセキュリティテストを実施する

   条文の内容

   エンティティは、サイバー攻撃に悪用されたり、サイバーインシデントにさらされたりする弱点を検出するため、システムとネットワークのセキュリティテストを実施すべきです。テストは定期的に、また、新しいシステムや技術の導入など、脅威状況に重大な変化が生じたときにも実施し、必要に応じて社内部門と関連するサードパーティを参加させるべきです。オペレーショナルレジリエンス基準の草案ガイダンスは、セキュリティ統制の有効性テストと保証を含むICTシステムの脆弱性評価や、起こり得る攻撃シナリオに対して統制を検証するレッドチーム演習などの敵対的テストを求めています。

   出典：RBNZ Guidance on Cyber Resilience B3.7〜B3.7.2；オペレーショナルレジリエンス基準草案ガイダンス、2026年6月、第71.3項および第97.3項

   モバイルアプリにとっての意味

   モバイルのリリースは、インターネットに接続されたチャネルへの重大な変更です。アプリとそれが呼び出すAPIは、ストア更新の前と、リリース間の定期的なサイクルでテストされるべきです。

   Ostorlabによる支援

   AIエージェントのペネトレーションテストは、お客様がリリースするビルドで、ログイン後も含めてアプリとそのAPIをテストし、AIエージェントによる各検出結果に再実行できる動作するエクスプロイトを付けます。自動スキャンはCI/CDパイプラインからビルドごとに実行されます。

   お客様が担うこと

   スコープの設定、レッドチームやTLPTの実施、テスト結果をリスク管理の枠組みにどう反映するかの判断です。

3. 03

   オペレーショナルレジリエンス基準草案ガイダンス、2026年6月、表6；草案、第21条(4)

   脆弱性とパッチを文書化した期限で管理する

   条文の内容

   草案ガイダンスは、期待される情報セキュリティ統制を挙げています。新たな脆弱性や脅威が発見された場合を含め、脆弱性を適時に特定、評価、優先順位付け、対処する脆弱性管理プロセスと、ベンダー提供のコンポーネントを含むハードウェアとソフトウェア資産全体で、パッチやその他の更新を評価し、適切な場合はテストし、適時に適用するパッチ管理プロセスです。重大なICTインシデントにつながる可能性があり、適時に是正される見込みが低い重大な統制上の弱点については、草案はRBNZへの10営業日以内の通知を求めています。

   出典：オペレーショナルレジリエンス基準草案ガイダンス、2026年6月、表6；草案、第21条(4)

   モバイルアプリにとっての意味

   アプリ内のSDKとネイティブライブラリは、バージョンとパッチを持つ、お客様が提供するソフトウェアです。見えない脆弱性には、修正期限を設定できません。

   Ostorlabによる支援

   SCAは静的にコンパイルされたライブラリを識別し、リリースごとに既知の脆弱性と対応付けます。検出結果はクリティカル、高、中、低で評価され、プラットフォーム内、またはJiraやServiceNowでチケットとして追跡され、修正のリリース後に再テストされます。

   お客様が担うこと

   サーバーとインフラのパッチ適用、時期の判断、ベンダーの保守契約、リスクの受容です。

4. 04

   Deposit Takers (Operational Resilience) Standard 2027草案、第20条；草案ガイダンス、第99項〜第102項

   統制が機能していること、サードパーティICTも含めて保証する

   条文の内容

   預金受入機関は、情報へのアクセスを許可された者に限定する情報セキュリティ統制と、その統制と情報共有プロセスが有効であることを確認する保証プロセスを維持する必要があります。保証は、統制が進化する脅威と脆弱性に対応していることを確認するのに十分でなければならず、他人が提供または維持するICTシステムにも及ぶ必要があります。草案ガイダンスは、保証プロセスを文書化し、定期的かつリスクベースで実施し、重大な変更やインシデントの後に繰り返すことを求めています。

   出典：Deposit Takers (Operational Resilience) Standard 2027草案、第20条；草案ガイダンス、第99項〜第102項

   モバイルアプリにとっての意味

   アプリ、そのバックエンド、背後のサービスは1つのシステムです。保証は、アプリが依存するID、不正検知、クラウドなど、他者が運用する部分にも及ぶ必要があります。

   Ostorlabによる支援

   Ostorlabは、アプリとそのAPIの統制をテストし、検出結果ごとに証拠を生成します。その結果は、統制環境全体とあわせて保証資料に活用できます。

   お客様が担うこと

   保証の枠組みそのもの、統制の設計、どの証拠が十分かの判断です。

5. 05

   RBNZ Guidance on Cyber Resilience B1.4.1、B2.5、B2.8；オペレーショナルレジリエンス基準草案ガイダンス、表6

   セキュリティを組み込み、すべての変更をテストする

   条文の内容

   エンティティは、変更管理の方針、手順、統制を備え、変更のライフサイクル全体でサイバーセキュリティを考慮すべきです。推奨プラクティスとして、設計と開発の最初の段階からレジリエンス対策を組み込む「レジリエンス・バイ・デザイン」の考え方を採用し、新しい、または更新された技術、製品、サービス、プロセスの導入前にサイバーリスク評価を行うべきです。草案ガイダンスの統制領域には、変更管理、構成管理、新機能の安全な展開とテスト環境が含まれます。

   出典：RBNZ Guidance on Cyber Resilience B1.4.1、B2.5、B2.8；オペレーショナルレジリエンス基準草案ガイダンス、表6

   モバイルアプリにとっての意味

   アプリの各リリースは、インターネット公開チャネルへの変更です。パイプラインでの自動テストがリリース前を、ストア版のスキャンがリリース後をカバーします。

   Ostorlabによる支援

   Mobile SASTはAPK、AAB、IPAを直接解析し、ソースコードなしで、組み込まれたSDK全体のテイント解析も行います。Mobile DASTはアプリを実行し、通信、スタックトレース、スクリーンショットを取得します。どちらもCI/CDパイプラインからビルドごとに実行され、ストア版は手動トリガーなしで監視されます。

   お客様が担うこと

   セキュアコーディング標準、設計レビュー、開発者トレーニング、リリース承認です。

6. 06

   RBNZ Guidance on Cyber Resilience D1.1、D2.1、D4.1、D5.1；Deposit Takers (Operational Resilience) Standard 2027草案、第12条、第22条〜第26条

   サードパーティと重要サービス提供者を評価する

   条文の内容

   エンティティは、外部委託の前に業務の重要度と機密性を評価し、契約締結前にデューデリジェンスを実施して文書化し、サードパーティ接続からの侵入を検知・防止する統制を設計・検証し、重要なサードパーティを対応計画に組み込み、そのサイバーセキュリティ能力を定期的に評価すべきです。草案では、重要サービス提供者とは重要オペレーションを提供するサードパーティです。預金受入機関は、契約前にその能力を調査し、条件を文書化・監視し、登録簿を維持し、これらの提供者を管理する方針を定める必要があります。

   出典：RBNZ Guidance on Cyber Resilience D1.1、D2.1、D4.1、D5.1；Deposit Takers (Operational Resilience) Standard 2027草案、第12条、第22条〜第26条

   モバイルアプリにとっての意味

   モバイルバンキングアプリには、自社のバックエンドと通信するサードパーティSDKが組み込まれ、不正検知やIDの提供者に依存することもあります。それらは資産目録とサードパーティリスクの視点に含めるべきです。

   Ostorlabによる支援

   Ostorlabは、各リリースのSDKとネイティブライブラリをバージョンとアプリバンドル内の位置とともに一覧化し、アプリとSDKがネットワーク上でバックエンドと何をやり取りするかを示し、提供者がアプリに公開するAPIもテストできます。

   お客様が担うこと

   契約、重要サービス提供者の登録簿、デューデリジェンスの記録、監視、退出計画です。

7. 07

   RBNZ Cyber resilience for regulated entities、データ収集、2026年5月6日更新；Material Cyber Incident Notification FAQs；Deposit Takers (Operational Resilience) Standard 2027草案、第21条

   重大なインシデントを報告し、定期的に自己評価する

   条文の内容

   重大なサイバーインシデントは、可能な限り速やかに、検知から72時間以内に、FMAにも使用できるテンプレートでRBNZに報告する必要があります。すべてのサイバーインシデントの定期報告は、2026年5月時点で停止しています。エンティティはまた、Guidance on Cyber Resilienceに対する自己評価を報告します。大規模エンティティは毎年、その他は2年ごとです。草案は、重大なICTシステムインシデントを認識してから72時間以内に、深刻度、影響、実行可能な解決策とともにRBNZへ通知する義務を追加しています。

   出典：RBNZ Cyber resilience for regulated entities、データ収集、2026年5月6日更新；Material Cyber Incident Notification FAQs；Deposit Takers (Operational Resilience) Standard 2027草案、第21条

   モバイルアプリにとっての意味

   時計はインシデントの検知から動きます。アプリとAPIに関するトリアージ情報を再構成できる必要があり、アプリやAPIの問題が引き金になることもあります。

   Ostorlabによる支援

   Ostorlabはインシデント対応や報告の提出を行いません。再現手順、影響を受けたバージョン、リクエストとレスポンスの証拠を含むアプリとAPIの検出結果を提供し、調査中にお客様のチームが活用できるようにして、修正を再テストします。

   お客様が担うこと

   検知、トリアージ、RBNZとFMAへの通知、インシデント対応、自己評価の内容です。

8. 08

   Deposit Takers (Operational Resilience) Standard 2027草案、第8条、第27条、第29条

   事業継続計画をテストする

   条文の内容

   預金受入機関は、重要オペレーションのための文書化された事業継続計画を持ち、定期的にレビューし、定期的にテストする必要があります。テストプログラムは、登録簿のすべての重要オペレーションを対象とし、預金受入機関が直面する重要なリスクに焦点を当て、深刻だが起こり得る一連のシナリオで計画の有効性をテストする必要があります。テストは12か月に1回以上実施する必要があります。レビューとテストは文書化し、弱点は適時に解消する必要があります。

   出典：Deposit Takers (Operational Resilience) Standard 2027草案、第8条、第27条、第29条

   モバイルアプリにとっての意味

   登録簿に載る支払、預金、決済はモバイルチャネルを通ります。アプリやAPIが停止したときに顧客をどう支えるかは計画が決めます。

   Ostorlabによる支援

   Ostorlabは事業継続のツールではありません。演習の合間も、計画のアプリとAPIの部分をテスト済みに保ち、シナリオが依拠できる検出結果、チケット、再テスト結果を提供します。

   お客様が担うこと

   計画そのもの、シナリオ設計、テストの実施、取締役会への保証、計画発動時のRBNZへの報告です。

9. 09

   Privacy Act 2020、第22条IPP 5および12、第6部；Office of the Privacy Commissioner、Principle 5；Privacy Amendment Act 2025

   個人情報を保護し、重大な漏えいを通知する

   条文の内容

   Privacy Act 2020では、個人情報を保有する機関は、状況に応じて合理的な安全対策により、紛失、不正なアクセス、利用、変更、開示、その他の誤用から情報を保護する必要があります。ニュージーランド国外への開示は、受領者が同法の適用を受ける場合、同等の保護措置の適用を受ける場合、または保護が異なる可能性を伝えたうえで本人が開示を承認した場合にのみ可能です。重大な害を生じさせる可能性が高い漏えいは、可能な限り速やかにプライバシーコミッショナーと影響を受ける個人に通知する必要があり、コミッショナーは72時間以内の通知を期待しています。Privacy Amendment Act 2025は、間接収集に関するIPP 3Aを追加し、2026年5月1日から施行されています。

   出典：Privacy Act 2020、第22条IPP 5および12、第6部；Office of the Privacy Commissioner、Principle 5；Privacy Amendment Act 2025

   モバイルアプリにとっての意味

   口座番号、本人確認データ、セッショントークンは、端末上で保護されずに残ったり、保護されずにバックエンドへ送られたりすべきではありません。海外での処理には同等の保護措置の確認が必要です。

   Ostorlabによる支援

   Ostorlabは、ローカルストレージ、キャッシュ、ログ、スクリーンショットにセッショントークンや個人データがないか探し、通信の保護を確認し、アプリがどのサードパーティサービスや場所にデータを送信するかを示します。

   お客様が担うこと

   プライバシー影響評価、通知と同意、海外提供者との契約、漏えい通知です。

ニュージーランドの公開文書の要約です（2026年9月27日時点で確認）。Deposit Takers (Operational Resilience) Standard 2027は、2026年6月18日から9月11日まで協議された公開草案であり、発行および2028年12月1日の施行前に変更される可能性があります。RBNZのGuidance on Cyber Resilienceは規則ではなくガイダンスです。本ページは法的助言ではありません。