LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

金融機関のシステムを受託すると、他業種では見慣れない量の確認資料を求められます。背景にあるのは、監督当局が示す考え方と、業界で長く使われてきた安全対策の基準です。二つは役割が違い、片方だけを見ていると答えが揃いません。

本記事では、金融機関向けにシステムを開発・運用する立場の担当者に向けて、参照される二つの土台、委託で問われる論点、クラウド利用の考え方、そして受託側が用意すべき成果物を整理します。制度や基準は改定が続くため、実際の対応は最新の公表資料で確かめながら進めてください。

参照される二つの土台

ひとつは、監督当局が示す考え方です。金融分野のサイバーセキュリティについて、経営の関与、リスクの管理、委託先の管理、インシデントへの対応と報告といった観点が整理されています*1。「何を備えるべきか」を示す性格のもので、業態や規模に応じた対応が求められます。

もうひとつは、業界団体が整備してきた安全対策の基準です。設備、運用、技術、監査といった区分で、確認すべき項目が具体的に並んでいます*2。長く使われてきたため、金融機関の調達や監査の実務に深く根づいており、ベンダーへの質問票もこの構成に沿うことが多いところです。

両者の関係を捉えると、資料づくりが楽になります。当局の考え方は「なぜ求めるのか」を、基準は「どこを確かめるのか」を示している。したがって受託側は、基準の項目に沿って自社の対策を並べ、そこに当局の観点で意味づけを添える——という形で説明資料を作ると、双方の問いに答えられます。

委託で問われる論点

金融機関がシステムを外部に委託する場合、委託先の管理そのものが監督の対象になります。受託側から見ると、次の項目について答えを用意しておく必要があります。

とくに再委託の把握は、実務で手間のかかる部分です。開発の一部を別会社に出している、監視を外部のサービスに任せている、クラウドの機能を使っている——こうした構成をすべて洗い出し、一覧として維持する必要があります。委託先・サプライチェーンのセキュリティ管理で扱う仕組みが、そのまま使えます。

可用性の説明では、「止まらない設計」だけでなく「止まったときの動き」まで問われます。復旧の目標時間、代替の手段、顧客への案内。訓練を実施し、その記録が残っていると説得力が違います。年に一度でも実施しておきたいところです。

インシデント時の報告と、平時の準備

障害や攻撃が起きたとき、金融機関には当局や顧客への連絡が求められます。受託側は、その連絡が滞らないように動く責任を負います。実務で決めておきたいのは次の三点です。

第一に、連絡の起点と時刻です。誰が検知し、誰に何分以内に伝えるのか。夜間や休日の経路も含めて決めます。ここが曖昧だと、事象の把握より連絡の調整に時間を取られます。

第二に、伝える内容の型です。何が起きたか、影響範囲、暫定の対処、今後の見込み。この四点を最初の連絡に含める型を決めておくと、情報の粒度が揃います。続報の間隔も決めておきます。

第三に、記録の残し方です。時系列の記録は、後の報告書の骨格になります。対応中に走り書きで残しても構いませんが、置き場所と様式を先に決めておくと、後からの整理が楽になります。

平時の準備としては、机上での訓練が効きます。想定シナリオを一つ決め、連絡経路をたどってみる。それだけで抜けが見つかります。金融機関側も同様の訓練を行っているため、合同で実施できると相互の理解が深まります。

クラウド利用の論点——集中と出口

金融分野でもクラウドの利用は広がりましたが、独特の論点があります。ひとつは、同じ事業者に多くの機能が集まることによる影響の大きさ。もうひとつは、乗り換えの余地をどう残すかです。

前者については、障害が起きたときに複数の業務が同時に止まる構成になっていないかを確かめます。同じ事業者の中でも領域を分ける、重要な機能は別の経路を用意する、といった設計が検討されます。説明の際は、依存関係を図にしておくと伝わりやすくなります。

後者は、契約と設計の両面に関わります。データを標準的な形式で取り出せるか、独自機能への依存を限定できているか、移行に必要な期間と費用を見積もれるか。この観点はSaaSのベンダーロックイン脱却で扱った考え方と共通です。

セキュリティ設計そのものについては、クラウド移行のセキュリティ設計・対策の内容が土台になります。金融分野では、そこに「説明できる形にしておく」という要求が上乗せされる、と捉えるとよいでしょう。

業態による違いと、見積りへの影響

ひとくちに金融分野といっても、業態によって重みの置き方が変わります。受託側としては、この違いを見積りに織り込めるかが利益を左右します。

銀行や信用金庫のような預金を扱う業態では、勘定系に近い部分の可用性と、二重化・切り替えの手順が厚く問われます。停止が社会的な影響を持つため、変更の手続きも慎重です。テスト環境の用意や作業時間帯の制約が、工数に直接跳ね返ります。

保険では、契約や支払に関わる計算の正確さと、長期にわたる記録の保持が中心になります。証券や資金移動を扱う業態では、取引の記録と時刻の正確さ、不正の検知が重く見られます。同じ「セキュリティ要件」という言葉でも、確認される項目の重心が違うのです。

また、フィンテック系の事業者と既存の金融機関では、求められる資料の形が異なることもあります。前者は自社で整えた説明資料が中心、後者は業界の基準に沿った様式が中心。どちらに向けた案件なのかで、準備の順番を変えるのが実務的でしょう。

見積りの段階では、これらの確認作業に必要な工数を「開発とは別枠」で置いておくことをおすすめします。質問票への回答、資料の更新、監査への立ち会い。開発工数に埋め込むと、後半で赤字になりがちな部分です。

受託側が用意すべき成果物と進め方

案件を通して求められる資料は、ある程度決まっています。先に型を作っておけば、案件ごとの負担が下がります。

• 対応表：基準の項目に対する自社の対策と、証跡の在りか
• 構成図：システム構成、データの流れ、依存する外部サービス
• 権限一覧：誰がどの環境に触れられるのか、承認の経路
• 手順書：変更、障害対応、インシデント時の連絡
• 記録：点検、訓練、権限棚卸しの実施記録

これらを整えておくと、第三者による保証報告書の枠組みと相性がよくなります。海外の取引先や大手事業者から求められる場面では、SOC 2報告書の形で示すことも選択肢に入ります。国内の枠組みと海外の枠組みで、同じ土台を使い回せるのが望ましい形です。

進め方としては、案件の初期に「どの基準のどの項目に、誰が答えるのか」を決めるのが定石です。金融機関側の担当者と早い段階で突き合わせておけば、後半で資料づくりに追われることが減ります。ISMS認証取得の進め方で扱う土台がある企業なら、差分は思ったより小さいはずです。

体制面では、資料を作れる人と、システムを分かっている人を同じ場に置くことが肝心です。分担すると、実態と資料がずれていきます。運用の記録が自動的に残る仕組みを作り、その出力を資料として使う——この形にできれば、更新の手間も抑えられます。

まとめ：金融のシステム委託で押さえる3つの視点

金融分野のシステム委託では、監督当局が示す考え方と、業界団体が整備してきた安全対策の基準という二つの土台が参照されます。押さえたい視点は三つです。第一に、当局の考え方は「何を備えるべきか」、基準は「どこを確かめるか」を示すもので、受託側は基準の項目に沿って対策を並べ、当局の観点で意味づけを添えると双方の問いに答えられること。第二に、委託では体制と責任、再委託の把握、可用性、権限と操作の記録、インシデント時の報告が中心に問われるため、資料を先に型として用意しておくと案件ごとの負担が下がること。第三に、クラウド利用では特定事業者への集中と乗り換えの余地が独特の論点になり、依存関係を図にして説明できる状態が求められることです。まずは対応表と構成図を整え、記録が自動的に残る仕組みづくりから始めてみてください。

よくある質問

出典

1. *1　参考：金融庁「金融分野におけるサイバーセキュリティ」（https://www.fsa.go.jp/policy/cybersecurity/index.html）。監督当局が示すサイバーセキュリティの考え方と、委託先管理・インシデント対応の観点の参考として（2026年8月確認）
2. *2　参考：公益財団法人 金融情報システムセンター（FISC）（https://www.fisc.or.jp/）。金融機関等のシステムに関する安全対策基準の位置づけと、公表資料の参考として（2026年8月確認）

Tweet