2026.08.30 68 人が閲覧（直近 30 日）業務システム

FISC安全対策基準とは？第14版の改訂点と金融システム開発での対応範囲

FISC安全対策基準は、公益財団法人金融情報システムセンター（FISC）が1985年12月の初版以来、改訂を重ねてきた「金融機関等コンピュータシステムの安全対策基準・解説書」を指します。2026年3月25日に第14版が公表され、AI・生成AIの安全対策と耐量子計算機暗号（PQC）への対応が新たに反映されました。この基準には法的な強制力がなく、それでも金融庁の検査で参照される事実上の標準として機能しているため、「どこまでやれば足りるのか」の線引きが発注側の悩みになります。本記事では、三本柱の構成と対象範囲、第14版の改訂点、クラウド利用時の責任分界、ベンダー選定で確認する統制項目、全項目への一律準拠を目指さない判断基準までを整理します。

まとめ｜FISC安全対策基準の位置づけと発注側が押さえる要点

FISC安全対策基準は法令ではなく、FISCという民間の財団法人が示す自主基準です。守らなくても直ちに違法にはなりません。ただし金融庁の検査ではシステムリスク管理の水準を測る物差しとして参照されるため、金融機関とその委託先にとっては実質的な要求事項として扱われています。

構成は設備基準・運用基準・技術基準の三本柱で、全体では約300項目の規模になります。ISO/IEC 27001のような第三者認証の仕組みはなく、「FISC認証を取得しました」と対外的に名乗ることはできません。自社で対応状況を判定し、その根拠を文書として残す形が実務の到達点になります。

発注側が最初に決めるべきは、全項目を一律に満たしにいくのかどうかです。結論から書くと、非金融の事業会社が金融機関向けにシステムを提供する場合を除き、一律準拠は費用対効果が合いません。取り扱うデータの性質と、障害時に社会へ与える影響の大きさで対応範囲を絞り込み、絞った理由を残す進め方を推奨します。

法令ではない実務基準という位置づけと金融庁の監督指針との関係

法的拘束力を持たない自主基準が金融検査で事実上参照される構図

FISCは金融情報システムに関する調査研究を行う公益財団法人であり、行政機関ではありません。したがって安全対策基準そのものに罰則や行政処分の根拠はなく、条文番号も存在しません。位置づけとしては業界の自主基準です。

それでも実務での重みが違います。金融庁が金融機関のシステムリスク管理態勢を検証する際の水準として参照されてきた経緯があり、金融機関側も内部規程を基準項目に紐づけて整備してきました。結果として、契約書や提案依頼書に「FISC安全対策基準に準じた対策を講じること」という条件が書かれます。法的拘束力の有無ではなく、取引条件として要求されるかどうかで判断してください。

第三者認証が存在せず準拠を宣言できない制約と代わりに残す証跡

ISMS（ISO/IEC 27001）やPCI DSSと決定的に違うのは、審査機関による認証制度が存在しない点です。FISCは基準と解説書を刊行しますが、個社のシステムを審査して合否を出す仕組みを持ちません。「FISC準拠認証取得」という表現は、制度上は成り立たない言い方になります。

では取引先にどう示すか。実務では、基準項目ごとに自社の対応状況を判定した一覧表（対応状況表）を作り、監査法人の内部統制監査やSOC 2などの外部報告書を補助資料として添える形が定着しています。対外的な説明の実体は、認証書1枚ではなく、この一覧表と根拠資料の束になります。

対象となる金融機関等の範囲と一般の事業会社が参照する実務的な場面

基準が想定する「金融機関等」は、銀行・信用金庫・証券会社・保険会社に加え、資金移動業者やクレジットカード会社など決済に関わる事業者を広く含みます。金融機関からシステム開発や運用を受託するベンダー、SaaSを提供する事業者も、委託先管理の対象として間接的に基準の要求を受けます。

金融以外の事業会社が読む理由は2つあります。1つは、金融機関へサービスを提供する際に対応状況の提示を求められるため。もう1つは、自社のセキュリティ規程を作る際の網羅的なチェックリストとして流用できるためです。後者の目的なら全項目を追う必要はなく、自社のリスクに対応する章だけを抜き出す読み方で足ります。

FISC安全対策基準の対象範囲と設備・運用・技術という三本柱の構成

設備基準・運用基準・技術基準がそれぞれ扱う対策範囲と項目の違い

設備基準が扱うのは、建物・電源・空調・入退室管理といった物理環境の対策です。データセンターの立地条件、耐震性能、無停電電源装置の冗長構成などが該当します。運用基準は組織と手続の対策で、開発から本番移行までの管理、障害対応の体制、委託先の管理、教育訓練を含みます。技術基準はシステム自体に実装する対策で、アクセス制御、暗号化、ログの取得と保全、不正検知が中心です。

3分野の合計は約300項目の規模です。項目数は改訂のたびに増減するため、版を指定せずに「何項目」と語るのは避けてください。自社が参照する版の目次で実数を確認するのが正確です。設備面をどう設計するかは、金融システムのサーバー構成と可用性・DR設計の判断基準で具体的な構成パターンを扱っています。

基準と解説書が対になる文書構成と自社の統制へ当てはめる読み方

刊行物の正式名称が「安全対策基準・解説書」となっているとおり、文書は2層構造です。基準は「何を実現すべきか」を短い要求文で示し、解説書はその背景と具体的な実装例を述べます。基準文だけを読んで対策を設計すると、抽象度が高すぎて解釈が割れます。

読み方の順序としては、まず基準文で要求の趣旨をつかみ、次に解説書で自社の構成に近い実装例を探し、最後に自社の統制へ言い換える流れが実務的です。解説書の例をそのまま導入する必要はありません。趣旨を満たす別の手段があるなら、なぜ同等と言えるのかを記録に残せば説明が通ります。

約300項目という規模感と全項目を一度に見ない優先順位の付け方

300項目を頭から順に検討する進め方は、まず破綻します。実務では対象システムの性質で絞り込みます。勘定系のように停止が社会的影響を持つシステムなら設備基準と運用基準を厚く、情報系や社内向けシステムなら技術基準の一部に絞る、という配分です。

絞り込みの前提になるのが、自社システムがどの層に属するのかの整理です。勘定系・情報系・チャネル系という区分と各層の要件差は、勘定系システムの三層構造と情報系との違いで詳しく扱っています。層が決まれば、参照すべき基準の範囲も自動的に狭まります。

第14版で反映されたAI・PQC対応と改訂版を追い続ける手順

第14版の四つの改訂点とAI・生成AI関連ガイドラインの取り込み

FISCは2026年3月25日に第14版の公表を告知しました。改訂の柱は四点です。第一にAI安全対策で、官公庁に加えて各協会・団体が公表したAI・生成AIのガイドラインやレポートを分析し、その内容を基準に反映しています。第二にサイバーセキュリティ関連ガイドラインの反映。第三が耐量子計算機暗号への対応。第四がシステム障害事例と各種ガイドラインを踏まえた基準項目・解説の見直しです。

生成AIを社内で使い始めた金融機関にとって、第一の改訂は無視できません。従来は外部委託と外部サービス利用の枠組みで語られていた論点が、AI固有の項目として基準側に入った形です。すでに検証環境を持っているなら、利用範囲と入力データの取り扱いを第14版の該当項目と突き合わせてください。

耐量子計算機暗号への移行時期と暗号更新を設計へ織り込む着眼点

PQC（Post-Quantum Cryptography）の反映は、金融庁が2024年11月に公表した「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会報告書」を受けたものです。移行に関する留意点や対応時期の考え方が基準側に取り込まれました。

今日ただちに暗号方式を差し替える話ではありません。設計上の意味は別のところにあります。暗号アルゴリズムをアプリケーションのコードに直接埋め込まず、後から差し替えられる構造にしておくこと。この「暗号アジリティ」を新規開発の要件に入れておけば、移行時期が来たときの改修規模が大きく変わります。既存システムでは、暗号方式・鍵長・利用箇所の棚卸しから着手してください。

年1回ペースの改訂を追う情報源とガイドラインサーチの使い分け

第12版が2024年、第13版が2025年、第14版が2026年と、直近は年1回ペースで改訂が続いています。追跡の起点はFISC公式サイトのトピックスと刊行物ページで、新版の公表と同時に告知が出ます。PDF版は有償で、第14版の一般価格は3,000円（税込）です。

あわせて、FISCが提供するガイドラインサーチという検索サービスがあります。第14版と「金融機関等におけるセキュリティポリシー策定のための手引書」（第3版）、「金融機関等のシステムリスク管理の解説書」は、2026年3月31日にこのサーチへ収録されました。項目を横断して探すならサーチ、通読するならPDF版という使い分けです。改訂の確認は四半期ごとに公式トピックスを見る運用で間に合います。

クラウド利用時のリファレンス参照と責任共有モデルでの分界点整理

AWS FISC安全対策基準対応リファレンスが埋める説明責任の空白

設備基準の多くは、クラウド利用者が自ら確認できません。データセンターの入退室記録も、電源設備の冗長構成も、利用者は現地を見に行けないからです。この空白を埋めるために作られたのが「金融機関向けAWS FISC安全対策基準対応リファレンス」で、FISC対応APNコンソーシアムの参画メンバー10社による共同著作物として、金融機関へ無償で提供されています。

この文書は、AWSが自らの責任範囲でどう対応しているかと、利用者側に実施してほしい対策を基準項目に対応づけて示します。監査では事業者側の対策を説明する根拠資料になります。同種の参考文書は他のクラウド事業者からも出ているため、採用先を決めた段階で文書の有無と対象バージョンを確認してください。

責任共有モデルで分かれる事業者側の対策と利用者側に残る対策項目

責任共有モデルの下では、クラウド事業者はクラウド「の」セキュリティを、利用者はクラウド「内」のセキュリティを負います。物理設備・ハイパーバイザ・基盤ネットワークは事業者側、OS以上の構成・アクセス制御・データの暗号化・ログの保全は利用者側という切り分けが基本です。

誤解が起きやすいのは運用基準の領域です。事業者が高い可用性を提供していても、障害時の連絡体制、影響範囲の特定手順、当局への報告判断は利用者側に残ります。マネージドサービスを使うほど技術基準の負担は軽くなり、運用基準の負担はほとんど変わらない。この非対称性を見落とすと、移行後に運用設計が追いつきません。

クラウド事業者の第三者評価報告書を確認する際に見るべき範囲と限界

SOC 2 Type IIやISMAP登録の有無は、事業者側の統制を確認する材料です。ただし報告書には対象期間と対象サービスの範囲が明記され、その外側は保証されません。利用予定のサービスが報告書の対象に含まれているか、報告書の対象期間が現在から見て古すぎないかを確認してください。

もう1つの限界は、報告書が事業者の統制を示すだけで、自社の設定不備を保証しない点です。ストレージの公開設定を誤れば、事業者の統制がどれだけ整っていても情報は漏れます。第三者評価は分界点の事業者側を埋める材料であり、利用者側の証跡は別途自社で作る必要があります。

監査・当局対応で求められる証跡とチェックリストの作り込み手順

基準項目を自社の統制へ読み替えるマッピング表の作り方と粒度の決め方

マッピング表は、基準項目番号・要求の要旨・自社での対応内容・根拠資料の所在・判定区分・最終確認日の6列を基本形にしてください。列を増やしすぎると更新されなくなります。

粒度の決め方には原則があります。基準項目1つに対して自社の統制を1つ以上対応づけ、逆向きの多対一（複数の基準項目を1つの統制でまとめて満たしたことにする）は、根拠資料が同一である場合に限って許容する。この線を引いておけば、後から「この項目の根拠はどれか」と問われたときに答えられます。着手時期は、対象システムの構成が固まった設計フェーズの終盤が現実的です。

対応・非対応・非該当という判定区分と非該当を選ぶ根拠の残し方

判定は3区分で運用します。対応は要求を満たしている状態、非対応は満たしていない状態、非該当は自社の構成上その要求が適用されない状態です。監査で問題になるのは、ほぼ例外なく非該当の扱いです。

非該当を選ぶときは、「自社にはATMが存在しないため該当しない」のように、構成上の事実で説明できる根拠を必ず併記してください。「対応が難しいため非該当とした」という記述は、実質的な非対応の言い換えと見なされます。非対応であること自体は必ずしも問題になりません。リスクを認識したうえで、代替統制と是正計画を示せていれば説明は通ります。隠すと説明が通らなくなる、というだけの話です。

システム障害の当局報告と平時から揃えておく運用記録の対応づけ

第14版ではシステム障害事例を踏まえた見直しが入っています。障害発生時に求められるのは、事象の検知時刻、影響範囲、復旧までの経過、原因と再発防止策を、時系列で示せる記録です。これらは障害が起きてから集めるものではなく、平時の監視ログ・変更履歴・運用手順書から自動的に積み上がる形にしておく性質のものになります。

24時間365日の監視体制や夜間バッチの運行管理をどこまで内製し、どこから委託するかは、記録の残り方にも直結します。委託範囲の決め方は金融システムの運用と委託範囲の決め方で扱っているので、運用基準への対応を設計する段階で突き合わせてください。

開発ベンダーの選定時に確認する統制項目と契約で押さえる責任範囲

提案段階で確認しておく開発体制と変更管理・障害対応の統制項目

提案書の記載を鵜呑みにせず、次の4点は具体的な運用として確認してください。第一に本番環境と開発環境の分離、および本番データを開発に持ち込まない手続。第二に変更管理で、リリース承認の権限者と、緊急変更を後追いで承認する例外手順の有無。第三に障害対応で、一次受けの体制と、重大障害の判定基準。第四にアクセス権限の棚卸し頻度です。

いずれも運用基準に対応する部分で、金融機関との取引実績を持つベンダーなら文書化されているはずの内容です。文書が出てこない場合、対応状況表の根拠資料を発注側が肩代わりして作ることになり、工数見積りに響きます。

委託先管理で求められる再委託先の把握と監査権を確保する契約条項

委託先管理では、再委託の有無と再委託先の所在まで把握することが求められます。オフショア開発を含む場合、データの保管国と、その国の法制度によるデータ開示リスクまで説明できる状態にしておいてください。

契約面では、再委託の事前承認、監査権（自社または第三者による監査の受け入れ義務）、セキュリティ事故発生時の報告期限、契約終了時のデータ返還・消去の4条項を最低限として交渉します。監査権は形式的に入れるだけでは意味がなく、実施の頻度と方法まで合意しておくと、監査の局面で使える条項になります。

見積り比較で見落としやすい基準対応の作業量とコストの内訳の差

相見積りで金額差が大きく開く場合、基準対応の作業をどこまで見込んでいるかが原因であることが少なくありません。対応状況表の作成支援、証跡の整備、監査時の質疑対応は、いずれも開発そのものとは別の工数です。見積書でこれらが明示されていないベンダーには、内訳を出してもらってください。

金融機関向けのシステム開発では、この基準対応の工数が全体の1〜2割を占めることもあります。開発費だけを比較すると判断を誤りかねません。要件定義の段階から対応範囲を整理して進めたい場合は、金融システム開発の相談窓口で、対象システムの層と必要な統制水準を含めて設計段階から詰める進め方もあります。

全項目への一律準拠を目指さない判断基準と過剰対応になる場面の線引き

事業規模と取扱データの性質から対応範囲を絞り込む三つの判断軸

軸は3つです。第一に、そのシステムの停止が資金決済に直接影響するか。影響するなら設備基準と運用基準を厚く見ます。第二に、口座情報・与信情報・本人確認記録といった、漏えい時に個人の経済的損害へ直結するデータを扱うか。扱うなら技術基準のアクセス制御と暗号化を優先します。第三に、金融機関から対応状況の提示を契約上求められているか。求められているなら、要求された項目群が対応範囲の下限になります。

3つのいずれにも当たらないシステム、例えば社内向けの経費精算や情報共有基盤なら、FISC安全対策基準を起点にする必要はなく、自社の情報セキュリティ規程で足ります。

過剰対応になりやすい非金融の事業会社で見送ってよい対策項目の例

非金融の事業会社が基準をそのまま適用しようとすると、設備基準で真っ先に無理が出ます。自社でデータセンターを保有していない以上、建物構造や電源設備に関する項目は自社の統制として書きようがありません。ここは非該当としてクラウド事業者の第三者評価報告書に委ね、自社の労力は技術基準と運用基準へ寄せてください。電子契約サービスのような外部SaaSへ基準を当てる範囲の絞り方は、金融業界の電子契約システムとは？保険業法・金商法の電磁的方法とeKYC要件【2026年時点】でも扱っています。

もう1つ見送ってよいのは、対外接続の専用線要件のように、勘定系の相互接続を前提とした項目です。インターネット経由でSaaSを提供する事業者には構成上当てはまりません。判断に迷ったら、その項目が守ろうとしているリスクが自社に存在するかを問い直す。存在しないなら非該当で構いません。

準拠の証明を目的化してリリースが遅れる失敗パターンと回避の手順

失敗の典型は、開発の終盤で対応状況表を作り始め、根拠資料が揃わないと分かって証跡を作り直し、本番リリースが数か月ずれる進め方です。設計時点では誰も表を見ておらず、監査の直前に初めて300項目と向き合うため、非該当の根拠すら整理されていません。

回避の手順は単純です。要件定義の段階で対応範囲を確定させ、設計フェーズの終盤でマッピング表の骨格を作り、開発中に生まれる設計書・試験記録・運用手順書をその都度、根拠資料として紐づけていく。この順序で進めれば、リリース前にやることは最終確認だけになります。基準対応は後工程ではなく、要件定義の一部として扱ってください。

よくある質問

FISC安全対策基準の検討でよく寄せられる質問を5つ取り上げます。

FISC安全対策基準の最新版はどれですか？

2026年8月時点の最新版は第14版です。FISCは2026年3月25日に「金融機関等コンピュータシステムの安全対策基準・解説書」（第14版）のPDF版公表を告知しており、刊行は2026年3月、PDF版の一般価格は3,000円（税込）です。直近は第12版が2024年、第13版が2025年と年1回ペースの改訂が続くため、参照時は公式サイトの刊行物ページで最新版を確認してください。

FISC安全対策基準に法的な強制力はありますか？

ありません。FISCは公益財団法人であり行政機関ではないため、基準に違反しても罰則や行政処分の直接の根拠にはなりません。ただし金融機関のシステムリスク管理態勢を検証する際の実務上の水準として参照されてきた経緯があり、金融機関との契約で「本基準に準じた対策」を条件として求められる場面があります。取引条件として要求されるかどうかで判断してください。

FISC準拠の認証を取得することはできますか？

できません。ISO/IEC 27001（ISMS）やPCI DSSと異なり、FISCは個社のシステムを審査して合否を出す第三者認証制度を設けていないためです。対外的な説明では、基準項目ごとに自社の対応状況を判定した一覧表と、その根拠資料を示す形が実務の標準になります。認証書に相当するものは存在しないので、「FISC認証取得」という表現は使わないでください。

クラウドサービスを使う場合も基準の対象になりますか？

対象になります。ただし責任共有モデルにより、物理設備や基盤ネットワークに関する項目はクラウド事業者側の責任範囲となり、利用者はOS以上の構成・アクセス制御・データ保護・ログ保全を担う形です。事業者側の対応は「金融機関向けAWS FISC安全対策基準対応リファレンス」のような参考文書や、SOC 2などの第三者評価報告書で説明します。利用者側の証跡は自社で別途整備してください。

第14版で新しく加わった論点は何ですか？

四点あります。AI・生成AIに関するガイドラインやレポートの内容を反映したAI安全対策、サイバーセキュリティ関連ガイドラインの反映、金融庁が2024年11月に公表した「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会報告書」を踏まえた耐量子計算機暗号（PQC）への対応、そしてシステム障害事例と各種ガイドラインを分析した基準項目・解説の見直しです。生成AIを社内で使い始めた組織は、利用範囲と入力データの扱いを該当項目と突き合わせておくのが先決になります。