公開日： ｜更新日：
FISCという略称を見ても、何を指すのかすぐには分からないという方は少なくありません。本記事では、FISCの役割や安全対策基準の中身、金融庁・法律との違い、対応が求められる企業の範囲まで、専門知識がない方にも伝わる言葉で分かりやすく整理していきます。
FISCの正式名称は公益財団法人金融情報システムセンター、英語ではThe Center for Financial Industry Information Systemsと表記されます。1984年11月に財団法人として設立され、2011年4月には公益財団法人へと移行しました。設立には銀行や保険会社、証券会社、コンピュータメーカー、情報処理会社など、幅広い業種が関わっています。
掲げている目的は、金融情報システムに関する調査研究と基準・指針の策定を通じて、システムの安全性・信頼性・効率性を高め、利用者の安心や利便性につなげることです。ただし、FISCは法令を制定する権限や行政処分を行う権限を持つ組織ではなく、業界向けの基準づくりと普及を担う専門機関という位置づけです。
FISCは、安全対策基準を中心に複数の文書を策定しています。システムの安全対策を扱う安全対策基準・解説書、監査の視点をまとめたシステム監査基準、緊急時対応を扱うコンティンジェンシープラン策定手引書、社内規程づくりを支えるセキュリティポリシー策定手引書、リスク管理の全体像を解説するシステムリスク管理解説書のほか、TLPT実施手引書、API接続チェックリスト解説書、クラウド導入・運用解説書、IT人材確保・育成手引書なども公開されています。
FISC安全対策基準は法律や金融庁の監督指針そのものではなく、それ単独で一律の法的義務を課すものではありません。一方、FISCは金融庁の監督指針やサイバーセキュリティガイドライン、関連法令などを踏まえて基準を改訂しています。そのため、金融機関がシステムリスク管理や安全対策を具体化する際の実務的な参考資料として広く活用されています。
法令、金融庁の監督指針、業界団体の自主規制、FISC安全対策基準、ISO/IEC 27001などの規格は、それぞれ役割が異なります。法令や監督指針を前提としつつ、FISC基準で金融システム固有の対策を具体化し、ISO規格などで組織全体の管理体制を整えるなど、複数の基準を組み合わせて対応するのが一般的です。
FISC安全対策基準・解説書は、金融機関が情報システムを開発・導入・運用する際に必要とされる安全対策を、具体例とともにまとめた文書です。初版は1985年に発行され、その後も技術の変化や事故事例を踏まえて改訂が重ねられてきました。
最新版は2026年3月公表の第14版で、AIや生成AI、サイバーセキュリティ、耐量子計算機暗号といった新しいテーマまで扱う内容へと広がっています。法律そのものではありませんが、金融庁が監督資料の中で参照しているため、実務上は重みのある基準として扱われています。
安全対策基準は1985年12月に初版が発行されて以来、ITの進展や実際に起きたシステム障害の事例を踏まえて改訂が重ねられてきました。近年ではクラウド利用、サイバー攻撃、経済安全保障、AIの活用など、対応すべきテーマが年々広がっています。第13版では金融庁のサイバーガイドラインやオペレーショナル・レジリエンスへの対応が反映され、第14版では耐量子計算機暗号への対応が新たに加わりました。
対象となるのは、顧客向けオンラインサービス、金融機関同士の決済業務、顧客データを扱うシステムなど、事業運営に使われる情報システム全般です。重要度に応じて「特定システム」と「通常システム」に分類され、対策の適用範囲が決まる仕組みになっています。
適用範囲は自社システムだけでなく、クラウド環境や外部委託先にも及びます。
銀行や信用金庫では、まず対象システムの範囲を明確にし、重要度に応じた分類を行うことが出発点になります。インターネットバンキングや決済系システム、共同センター、ATM、顧客データを扱うシステムなど、幅広い領域でリスク管理体制を整える必要があります。
あわせて、クラウドや委託先との契約では役割分担や監査権限、報告義務を明記しておくことも欠かせません。BCPや大規模障害を想定した訓練の結果は、経営層や取締役会へ定期的に報告し、継続的な見直しにつなげていく姿勢が求められます。
保険会社や証券会社も、金融庁のサイバーガイドラインが対象とする業態に含まれています。証券分野では日本証券業協会のインターネット取引ガイドラインが不正アクセス対策の具体化を進めており、FISCの内容とあわせて実装する場面が増えています。保険分野では外部委託先の選定や監査権限、モニタリング体制が着眼点となり、決済・資金移動の分野ではAPI接続先の安全性確認と継続的な監視が課題となります。
FinTech企業やクラウド・SaaS事業者が金融機関とAPI接続を行う際は、API接続チェックリストを用いて、接続前の確認だけでなく接続後のやり取りも続けることが想定されています。クラウドやSaaSを提供する側は、責任分担の範囲、監視体制、データの返却・消去、脆弱性対応、ログの提供方法などを契約・運用のなかで明確にしておく必要があります。金融機関にとって、これらの事業者は重要な委託先候補です。
金融機関から業務を受託するベンダーには、契約の中でセキュリティ要件や監査の受け入れ、再委託時の承認手続き、インシデント発生時の報告、データの返却・廃棄方法などを明文化しておくことが求められます。
社内でも、アクセス管理やログ管理、脆弱性対応、変更管理といった項目を、金融機関が求める水準に合わせて記録に残しておく必要があります。委託内容によっては、第三者保証報告書の提示を求められる場合もあります。
FISC安全対策基準では、金融システムの安全性を支えるいくつかの観点が確認対象になります。代表的なものが、権限管理や多要素認証といったアクセス管理、不正の早期発見につながるログ管理、情報の重要度に応じた暗号化やデータ保護です。加えて、脆弱性への対応や定期的な診断、障害発生時に備えたBCP・DR体制、委託先やクラウド事業者を含めたサードパーティ管理、内部監査による有効性の確認なども重要な要素として位置づけられています。
これらは個別に完結するものではなく、互いに関連し合いながら金融システム全体の安全性を支える仕組みとして機能しています。
以下は、FISC安全対策基準や金融庁のサイバーセキュリティガイドラインなどで重視される代表的な観点を、一般向けに整理したものです。実際に必要となる対策は、業態、システムの重要度、取り扱う情報、委託内容などによって異なります。
| 項目 | 主な内容 |
|---|---|
| アクセス管理・認証 | 権限の最小化、特権IDの管理、多要素認証の導入 |
| ログ管理・監査証跡 | ログの取得・保管方法、改ざん防止、定期的なレビュー |
| データ保護・暗号化 | 重要度に応じた暗号化、鍵の管理、媒体・データの廃棄手順 |
| 脆弱性管理 | 脆弱性情報の収集、影響度の評価、是正対応の期限管理 |
| 脆弱性診断・ペネトレーションテスト | 定期的な診断の実施、重要システムでの実戦的な検証 |
| 運用手順・監視 | 規程の定期的な見直し、変更管理、クラウド環境の監視 |
| BCP・DR体制 | 目標復旧時間・水準の設定、復旧訓練、バックアップ体制 |
| 委託先・サードパーティ管理 | 委託先の台帳整備、契約条項、モニタリング体制 |
| 内部監査・報告 | 独立した監査体制の確保、経営層・取締役会への報告 |
| 物理セキュリティ・設備 | データセンターの入退室管理、災害・障害への備え |
アカウントと生産性を守る
Withコロナ時代の
情報セキュリティ必須概念
クラウドサービスの普及やワークスタイルの変化によって、これからの情報セキュリティはシステマチックな運用が求められます。
アカウントのセキュリティを高めながら、運用者と利用者双方の利便性を高めるためには「統合認証基盤(統合認証システム)」の概念を理解しておかなければなりません。
