ISMSにおける可用性とは？機密性・完全性との違いと確保策・ISO27001管理策を解説

ISMSにおける可用性とは、認可された利用者が必要なときに情報やシステムへ確実にアクセスできる状態を保つことを指し、機密性・完全性と並ぶ情報セキュリティの3要素（CIA）の一つです。この記事では、可用性の意味や機密性・完全性との違いをわかりやすく整理したうえで、ISO/IEC 27001:2022が求める冗長性やバックアップなどの附属書A管理策、可用性を脅かす脅威の具体例、稼働率やRTO／RPOといった指標、リスクアセスメントでの評価方法までを順に解説します。これからISMSの運用で可用性をどう確保すべきか悩む担当者が、最初に取り組むべき対策まで判断できる内容を目指しました。

ISMSにおける可用性確保の要点と最初に取り組むべき対策のまとめ

ISMSにおける可用性は、機密性・完全性とのバランスを取りながら「止まらない・止まってもすぐ復旧できる」状態を維持することが核心です。確保の柱は、冗長化やバックアップによる技術的対策、RTO／RPOを定めた事業継続の備え、稼働率などの指標による継続的な評価の3つに整理できます。ISO/IEC 27001:2022では、冗長性（A.8.14）、情報のバックアップ（A.8.13）、2022年版で新設された事業継続のためのICTの備え（A.5.30）といった管理策が可用性を直接支えています。

最初に着手すべきは、情報資産ごとに可用性の重要度を評価し、優先度の高いシステムから冗長化とバックアップの復旧テストを固めることです。数十名規模の組織であれば、自前の設備をすべて二重化するより、可用性のSLAが明示されたクラウドサービスを選ぶほうが現実的なケースもあります。可用性対策は一度作って終わりにせず、リスクアセスメントとPDCAのなかで毎年見直すことで、形だけの運用に陥らず実効性を保てます。

情報セキュリティ3要素における可用性の定義と機密性・完全性との関係

可用性は単独の概念ではなく、機密性・完全性と組み合わせて初めて情報セキュリティとして成立します。まずは3要素それぞれの目的の違いと、可用性を高める際に生じる相反関係を押さえておきましょう。

必要なときに情報を利用できる状態を保証する可用性の意味

可用性（Availability）とは、認可された利用者が必要なタイミングで情報やシステムを中断なく利用できる状態を保証する特性です。たとえばECサイトがセール時間帯にアクセス集中で落ちる、基幹システムが障害で半日止まる、といった事象はいずれも可用性が損なわれた状態にあたります。機密性や完全性が「守って隠す・正しさを保つ」方向の特性であるのに対し、可用性は「使えるようにする」方向の特性だという点が大きな違いです。情報を厳重に守っても、肝心なときに取り出せなければ事業は止まってしまうため、3要素のなかでも事業継続に最も直結する要素といえます。

認可された人だけが使える機密性と可用性の目的の違い

機密性（Confidentiality）は、許可された人だけが情報にアクセスできるよう制限する特性で、アクセス制御や暗号化がその代表的な手段です。一方の可用性は「使える人が使えること」を目的とするため、両者は目的の向きが逆になります。たとえば認証を何重にも強化して機密性を高めると、ログイン手順が複雑になり、緊急時に正規利用者がすぐにアクセスできず可用性が下がることがあります。どちらを優先するかは情報資産の性質で判断し、個人情報は機密性寄り、緊急連絡用システムは可用性寄り、といった重み付けを資産ごとに決めることが実務上のポイントになります。

改ざんを防ぐ完全性と可用性を両立させる際のトレードオフ

完全性（Integrity）は、情報が正確かつ完全で、不正な改ざんや破壊が起きていない状態を保つ特性です。完全性を厳格に保とうとして更新のたびに承認フローや検証処理を挟むと、処理待ちが増えて可用性が落ちる場合があります。逆に、可用性を優先して冗長化したデータを複数拠点で同時更新すると、整合性が崩れて完全性を損なうリスクが生じます。実務では、重要データには更新ログとチェックサムで完全性を担保しつつ、参照系はキャッシュやレプリカで可用性を確保するなど、処理の性質ごとに対策を分けてバランスを取る設計が現実的です。

真正性・責任追跡性・否認防止・信頼性を加えた情報セキュリティ7要素

従来のCIA3要素に、真正性・責任追跡性・否認防止・信頼性の4特性を加えた考え方を情報セキュリティの7要素と呼びます。真正性は利用者やデータが本物であること、責任追跡性は誰が何をしたか追跡できること、否認防止は行為を後から否定できないこと、信頼性は意図したとおりに動作することを指します。可用性と関係が深いのは信頼性で、システムが安定して期待どおり稼働し続けることは、結果として可用性の維持にもつながります。ISMSの運用では3要素を土台としつつ、扱う情報の種類に応じてこれらの拡張要素も評価対象に加えると、抜けのないリスク評価が可能になります。

ISO/IEC 27000が定義する可用性とISMSにおける位置づけ

用語規格であるISO/IEC 27000では、情報セキュリティを「情報の機密性、完全性および可用性を維持すること」と定義し、可用性を「認可されたエンティティが要求したときに、アクセスおよび使用が可能である特性」としています。ISMS（ISO/IEC 27001）はこの定義を前提に、組織がリスクアセスメントを通じて自社にとって必要な可用性のレベルを決め、管理策で維持する仕組みを求めます。つまりISMSにおける可用性は「規格が一律の停止時間を定める」ものではなく、組織自身が事業への影響から目標を設定し、それを満たす対策を選ぶという位置づけになっている点を理解しておくことが重要です。

ISO/IEC 27001:2022が求める可用性確保の附属書A管理策

ISO/IEC 27001:2022では附属書Aの管理策が114から93へ再編され、組織的・人的・物理的・技術的の4区分に整理されました。2013年版からの移行期限は2025年10月31日で、すでに経過しています。ここでは数ある管理策のうち、可用性に直接関わるものを取り上げます。

情報処理施設・設備の冗長性を求める管理策A.8.14

A.8.14「情報処理施設・設備の冗長性」は、可用性の要求事項を満たすのに十分な冗長性をもって施設・設備を導入することを求める管理策です。具体的にはサーバーの二重化、ネットワーク経路の多重化、フェイルオーバー機構の用意などが該当します。常時稼働の冗長構成にするか、緊急時に切り替える待機構成にするかは、後述するRTO（目標復旧時間）から逆算して決めます。審査では、冗長構成が実際に切り替わるかを定期的に動作確認しているかどうかが問われるため、構成を持つだけでなく切替テストの記録を残しておくことが実務上の判断基準になります。

復旧の前提となる情報のバックアップA.8.13と3-2-1ルール

A.8.13「情報のバックアップ」は、情報・ソフトウェア・システムのバックアップを取得し、合意した方針に従って定期的に検証することを求めます。可用性の観点では、障害やランサムウェア被害からデータを取り戻せるかどうかが要であり、バックアップの取得だけでなくリストア（復元）の成否が決定的に重要です。実務では、3つの複製を2種類の媒体に保管し1つは隔離した場所に置く「3-2-1ルール」や、改ざん・暗号化を防ぐイミュータブルストレージの採用が有効です。復元テストでファイルのハッシュ値が一致するところまで確認できて初めて、可用性を支えるバックアップとして機能します。

過負荷による停止を防ぐ容量・能力の管理A.8.6

A.8.6「容量・能力の管理」は、現在および将来の容量需要を監視・調整し、必要な性能を確保することを求める管理策です。可用性が損なわれる原因は障害や攻撃だけではなく、アクセス増やデータ量の増大による処理能力の枯渇も含まれます。たとえばストレージの空き容量が尽きてシステムが書き込みできずに停止する、繁忙期のトランザクション急増で応答が返らなくなる、といったケースです。CPU・メモリ・ディスク・帯域の使用率を継続的にモニタリングし、しきい値に達する前に増強する運用を定めておくことが、突発的な停止を未然に防ぐ判断材料になります。

2022年版で新設された事業継続のためのICTの備えA.5.30

A.5.30「事業継続のためのICTの備え」は、2013年版に対応する管理策がない、2022年版で新設された管理策です。事業継続の目標に基づいてICTの継続要件を定め、計画・実装・維持・テストすることを求めます。中核となるのは事業影響度分析（BIA）で、重要業務ごとに許容できる停止時間を割り出し、そこからRTOとRPOを設定します。Azure Site RecoveryやAWS Elastic Disaster RecoveryなどのDRサービスを使う場合でも、構成や復旧手順を自社の文書として整備し、年1回以上の復旧訓練で実際に切り替えられることを確認しておくことが、審査での主要な確認ポイントになります。

中断・阻害時の情報セキュリティA.5.29と適用宣言書での採否

A.5.29「中断・阻害時の情報セキュリティ」は、危機や災害といった中断時にも情報セキュリティを維持するための計画・対応を求める管理策で、A.5.30とあわせて事業継続クラスタを形成します。これらの管理策をどこまで採用するかは、リスクアセスメントの結果を踏まえて適用宣言書（SoA）に記載します。可用性のリスクが低い情報資産しか持たない組織であれば、一部の管理策を「適用除外」とし、その理由を明記することも認められています。採用・除外のいずれであっても、判断の根拠を文書に残すことが、説明責任を果たすうえでの基準となります。

可用性を脅かすシステム障害・災害・サイバー攻撃の主な脅威と被害例

適切な対策を選ぶには、まず何が可用性を損なうのかを具体的に把握する必要があります。脅威は技術的な故障から自然災害、サイバー攻撃、人的ミスまで幅広く、それぞれ被害の現れ方が異なります。

ハードウェア故障やソフトウェア不具合によるシステム停止

サーバーのディスク故障や電源ユニットの破損、OSやミドルウェアのバグ、アップデート後の不具合などは、最も頻度の高い可用性の脅威です。単一のサーバーで基幹システムを運用していると、1台の故障がそのまま全社の業務停止に直結します。たとえばRAIDを組まずに運用していたストレージが故障し、復旧に丸1日かかって受発注が止まる、といった被害が典型例です。こうした故障は完全には避けられない前提で、後述する冗長化やバックアップによって「故障しても止めない・すぐ戻す」設計に切り替えることが対策の出発点になります。

地震・台風・停電など自然災害と設備障害による業務中断

地震や台風、洪水といった自然災害は、データセンターやオフィスの物理的な被災を通じて可用性を大きく損ないます。停電や空調故障でサーバールームが高温になり機器が停止する、通信回線が切断されて社外からアクセスできなくなる、といった設備障害も同じ脅威に含まれます。東日本大震災以降、こうした災害を想定した拠点分散の重要性が広く認識されるようになりました。被災時にどの業務を、どれくらいの時間で復旧させるかをあらかじめ決めておかないと、復旧の優先順位が定まらず混乱が長期化します。災害は発生確率と影響度の両面から評価することが欠かせません。

大量アクセスでサービスを止めるDDoS攻撃の被害例

DDoS（分散型サービス拒否）攻撃は、大量のアクセスを一斉に送り込んでサーバーやネットワークを過負荷状態にし、正規利用者がサービスを使えなくする攻撃です。機密性や完全性ではなく、可用性そのものを直接狙う点に特徴があります。ECサイトが攻撃を受けて販売機会を逸する、公共サービスのサイトが長時間ダウンして問い合わせが殺到する、といった被害が報告されています。対策としては、CDNやWAFによる負荷分散・フィルタリング、攻撃トラフィックを検知して遮断するDDoS防御サービスの利用が有効で、平時から防御の発動条件を決めておくことが被害の最小化につながります。

業務とバックアップを暗号化するランサムウェアの停止リスク

ランサムウェアは、データを暗号化して使用不能にし、復号と引き換えに身代金を要求するマルウェアです。近年は業務データだけでなく、ネットワーク経由でバックアップまで暗号化し、復旧手段ごと奪う手口が増えています。感染すると基幹システムが数日から数週間にわたり停止し、製造ラインや物流が止まる深刻な被害につながった事例もあります。可用性を守る観点では、バックアップを本番環境から隔離（オフラインやイミュータブル化）し、感染時に確実に復元できる状態にしておくことが最後の砦になります。身代金を支払っても完全には復旧しない前提で、復旧計画を準備しておく判断が求められます。

設定ミス・誤操作・容量不足による人的要因の停止

外部からの攻撃や災害だけでなく、内部の人的要因による停止も無視できません。ファイアウォールやロードバランサーの設定ミス、本番サーバーでの誤ったコマンド実行、証明書の更新忘れによる通信停止などが代表例です。クラウド移行時に権限設定を誤って正規利用者が締め出される、といったケースもあります。これらは技術対策だけでは防ぎきれないため、変更作業の手順書化とダブルチェック、作業前のバックアップ取得、証明書や容量のしきい値を監視するアラート設定といった運用面の備えが、停止を未然に防ぐ判断基準になります。

冗長化・バックアップ・クラウド活用による可用性確保の具体的対策

脅威を踏まえたうえで、可用性を確保する具体策を技術・事業継続・物理の各面から整理します。重要なのは個別の対策を並べることではなく、目標とする停止時間から逆算して必要な対策を選ぶことです。

単一障害点をなくす冗長化・負荷分散・HAクラスタ構成

可用性対策の基本は、止まると全体が止まる単一障害点（SPOF）をなくすことです。サーバーを複数台に分けて負荷分散装置で振り分ける、データベースをHA（高可用性）クラスタで二重化し障害時に自動で切り替える、ネットワーク回線を別々のISPで二重化する、といった構成が代表的です。たとえばWebサーバーを2台以上にしてロードバランサー配下に置けば、1台が故障しても残りで処理を継続できます。冗長化はコストも増えるため、すべてを二重化するのではなく、停止が事業に与える影響が大きいシステムから優先的に適用する判断が現実的です。

復旧を保証するバックアップ運用と定期的なリストアテスト

冗長化が「止めない」対策なら、バックアップは「止まっても戻す」ための最後の備えです。取得頻度・保管期間・保管場所・暗号化の有無を方針として定め、本番環境から隔離した場所にも複製を保管します。重要なのは、取得したバックアップから実際に復元できるかを定期的にテストすることです。バックアップが取れているつもりでファイルが破損していた、復元手順が古く誰も実行できない、といった事態は珍しくありません。少なくとも年1回、できれば四半期ごとに復元テストを行い、所要時間と結果を記録しておくことが、いざというときに機能する運用の条件になります。

目標復旧時間RTOと目標復旧時点RPOを定める事業影響度分析

RTO（目標復旧時間）は「障害発生からどれだけの時間で復旧させるか」、RPO（目標復旧時点）は「どの時点のデータまで戻せれば許容できるか」を示す指標です。両者は事業影響度分析（BIA）で重要業務ごとに割り出します。下表のように、両指標は守るものも対策も異なります。

たとえば受注システムでRTOを4時間、RPOを15分と定めるなら、15分間隔でのデータ複製と、4時間以内に切り替え可能な待機系が必要になります。こうした目標値の決め方や事業継続全体の進め方は、BCP対策（事業継続計画）の意味と策定の進め方もあわせて参考にすると、可用性対策を事業継続の文脈で整理しやすくなります。

可用性ゾーンとSLAを活用したクラウドでの可用性設計

クラウドを活用すると、自前で設備を二重化するより低コストで高い可用性を実現できます。AWSやMicrosoft Azure、Google Cloudは、物理的に離れた複数のデータセンター群である「アベイラビリティゾーン」を提供しており、複数ゾーンにシステムを分散配置すれば、1拠点が被災しても稼働を継続できます。さらに、より広域な障害に備えてマルチリージョン構成を取る選択肢もあります。ただしクラウド事業者のSLAで保証されるのは事業者側の責務範囲に限られ、自社の設定ミスや構成不備による停止は対象外です。責任共有モデルを理解し、自社が守るべき設計を文書化しておくことが重要です。

UPS・予備電源・空調などシステムを支える物理的対策

可用性は、ソフトウェアやネットワークだけでなく、それを支える電源や空調といった物理環境にも依存します。停電時に安全にシステムを稼働・停止させるためのUPS（無停電電源装置）、長時間の停電に備える自家発電設備、サーバールームの温度を一定に保つ空調の冗長化などが該当します。ISO/IEC 27001:2022では、こうした電源・通信などの設備をサポートユーティリティとして保護する管理策（A.7.11）が定められています。クラウド中心の構成であっても、社内に残るネットワーク機器やオンプレミスのサーバーには物理的な備えが必要であり、見落とされがちな盲点になりやすい領域です。

稼働率99.9%やSLAで測る可用性の指標と目標設定の考え方

可用性は感覚ではなく数値で管理することで、対策の妥当性を判断できます。稼働率やMTBF・MTTRといった指標の意味を理解し、自社にとって過不足のない目標を設定する考え方を整理します。

稼働率99.9%が示す年間約8.8時間という許容停止時間

稼働率は、一定期間のうちシステムが正常に稼働していた時間の割合で、可用性を表す最も代表的な指標です。「9」の数で語られることが多く、99.9%は「スリーナイン」と呼ばれます。下表のとおり、9が一つ増えるごとに許容される停止時間は大幅に短くなります。

このように、99.9%でも年間で約8.8時間の停止が許容範囲に含まれます。自社のシステムに求める水準を、業務への影響と照らして具体的な数値で定めることが目標設定の出発点になります。

故障頻度を表すMTBFと復旧速度を表すMTTRの違い

稼働率を構成する要素として、MTBFとMTTRがあります。MTBF（平均故障間隔）は故障から次の故障までの平均稼働時間で、値が大きいほど壊れにくいことを示します。MTTR（平均修復時間）は故障から復旧までの平均時間で、値が小さいほど早く直せることを示します。可用性は「MTBF÷（MTBF＋MTTR）」で表され、稼働率を上げるにはMTBFを延ばすか、MTTRを縮めるかのいずれか、または両方が必要です。故障を減らす（MTBF向上）には機器の品質や冗長化、早く直す（MTTR短縮）には監視と復旧手順の整備が効きます。どちらに投資すべきかは、自社の弱点がどちらにあるかで判断します。

クラウド事業者のSLAで定める可用性保証と返金条項

SLA（サービス品質保証）は、提供事業者が保証するサービス水準を明文化したもので、可用性については月間や年間の稼働率として示されます。多くのクラウドサービスは99.9%や99.95%といった稼働率を掲げ、これを下回った場合に利用料金の一部を返金するサービスクレジット条項を設けています。注意したいのは、SLAはあくまで事業者の保証であり、返金額は実際の損害を補償するものではない点です。重要システムを預ける際は、保証される稼働率の数値だけでなく、計測の対象範囲や除外条件、補償の上限まで契約内容を確認したうえで採否を判断することが大切です。

過剰投資を避ける可用性目標とコストのバランス判断

可用性は高めるほどよいわけではなく、水準を上げるほどコストは急激に増えます。99.9%から99.99%へ引き上げるには、冗長構成の多重化や自動フェイルオーバーの精緻化が必要となり、投資額が大きく膨らみます。社内の情報共有ツールに99.99%を求めるのは過剰であり、停止が直接売上に響く決済システムにこそ高い水準を割り当てる、といったメリハリが重要です。判断基準は「停止1時間あたりの損失額」と「水準を上げる費用」の比較で、損失より対策費が上回る領域には投資しないのが合理的な考え方になります。

稼働率を継続的に把握するモニタリングと記録の実務

目標を定めても、実際の稼働状況を測っていなければ達成できているか判断できません。死活監視や性能監視のツールでシステムの稼働状態を常時計測し、停止が起きた際は発生時刻・原因・復旧時刻・影響範囲を記録します。これらのログは、稼働率の算出だけでなく、ISMSのマネジメントレビューで改善を議論する際の客観的な根拠にもなります。月次で稼働率を集計し、目標未達の月はその原因と再発防止策をセットで残しておくと、対策が後手に回らず、可用性を継続的に改善する運用の土台が整います。

リスクアセスメントでの可用性評価とISMS運用への落とし込み方

ここまでの対策や指標を、ISMSの仕組みのなかでどう位置づけるかを整理します。可用性はリスクアセスメントで評価し、適用宣言書で管理策に落とし込み、PDCAで維持・改善する流れに組み込みます。

情報資産ごとに機密性・完全性・可用性を3軸で評価する手順

ISMSのリスクアセスメントでは、情報資産を洗い出したうえで、資産ごとに機密性・完全性・可用性の3軸で重要度を評価します。手順は次のとおりです。

1. 情報資産（顧客データベース、基幹システム、文書など）を台帳に洗い出す
2. 各資産について機密性・完全性・可用性の重要度を段階評価する
3. 資産を脅かす脅威と脆弱性を特定する
4. 影響度と発生可能性からリスク値を算定する

たとえば受注システムは可用性の重要度を高く、社内研修資料は低く評価するなど、資産の性質に応じて差をつけます。3軸で評価することで、可用性だけが突出して弱い資産を漏れなく洗い出せます。

可用性のレベルを点数化して対策の優先順位を決める方法

可用性の重要度は、たとえば「3：数時間の停止も許されない」「2：1営業日程度なら許容」「1：数日止まっても影響は小さい」のように段階を定義して点数化すると、評価者による判断のばらつきを抑えられます。点数と脅威の発生可能性を掛け合わせてリスク値を出し、値の大きい資産から優先的に対策を講じます。この点数化により、限られた予算と工数を、止まると最も困るシステムに集中投下する根拠が得られます。評価基準は組織内で統一し、年1回の見直し時に同じ基準で再評価することが、経年での比較を可能にする条件になります。

適用宣言書SoAで可用性関連管理策の採否を判断する基準

リスクアセスメントの結果は、適用宣言書（SoA）に反映します。SoAは附属書Aの各管理策について、採用するか除外するかと、その理由を明記する必須文書です。可用性のリスクが高いと評価された資産があれば、冗長性（A.8.14）やバックアップ（A.8.13）、事業継続のためのICTの備え（A.5.30）を採用し、実装状況を記録します。逆に該当するリスクが小さい場合は除外でき、その判断もリスクアセスメントの結果と整合していることが審査での確認対象です。採否の根拠がリスク評価に紐づいていることが、説明責任を果たすうえでの基準になります。

PDCAと内部監査で可用性対策を形骸化させない運用

可用性対策は導入して終わりではなく、PDCAサイクルのなかで維持・改善し続けることで実効性を保てます。計画した冗長化や復旧テストが予定どおり実施されているかを内部監査で点検し、未実施や不備があれば是正します。マネジメントレビューでは、稼働率の実績やインシデントの発生状況を経営層が確認し、追加投資や方針変更を意思決定します。こうした運用全体の進め方はISMS運用の実務手順（PDCA・内部監査・リスクアセスメント）で詳しく解説しており、可用性対策を組織の運用サイクルに組み込む際の参考になります。

中小企業が限られた予算で最初に着手すべき可用性対策

予算や人員が限られる組織では、すべての対策を一度に整えるのは現実的ではありません。優先すべきは、止まると事業が成り立たない少数の重要システムを特定し、そこにバックアップの復元テストと最小限の冗長化を集中させることです。自前で設備を二重化するより、可用性のSLAが明示されたクラウドサービスへ移すほうが、低コストで高い可用性を得られる場合があります。文書も方針・規程・手順の最小構成に絞り、まず回せる範囲で運用を始めて、実績を見ながら段階的に広げていく進め方が、形骸化を避けつつ着実に可用性を高める現実解になります。

よくある質問

ISMSにおける可用性について、検索されることの多い疑問に簡潔にお答えします。基本的な意味から、機密性・完全性との関係、BCPとの違いまでを確認しておきましょう。

情報セキュリティにおける可用性とは何ですか？

可用性とは、認可された利用者が必要なときに情報やシステムへ中断なくアクセスし、利用できる状態を保証する特性です。機密性・完全性と並ぶ情報セキュリティの3要素（CIA）の一つで、システムの停止や応答不能を防ぐことを目的とします。たとえば災害やサイバー攻撃でサービスが止まらないよう、冗長化やバックアップで備えることが可用性の確保にあたります。情報を守るだけでなく「使えること」を保証する点に特徴があります。

機密性・完全性・可用性（CIA）の覚え方はありますか？

3要素は英語の頭文字を取って「CIA」と覚えるのが定番です。Confidentiality（機密性）、Integrity（完全性）、Availability（可用性）の頭文字で、米国の情報機関と同じ綴りになるため記憶に残りやすいといえます。意味は「隠す（機密性）・正しく保つ（完全性）・使えるようにする（可用性）」と動作でセットにすると、それぞれの目的の違いを取り違えにくくなります。3つはどれか一つでも欠けると情報セキュリティが成立しない関係にあります。

可用性は英語で何といいますか？

可用性は英語で「Availability（アベイラビリティ）」といいます。CIAの「A」にあたる要素です。関連する用語として、高い可用性を意味する「High Availability（HA、高可用性）」、稼働率を示す「Availability rate」、サービス水準を定める「SLA（Service Level Agreement）」などがあり、クラウドサービスやシステム設計の文脈で頻繁に登場します。ISO/IEC 27000でも可用性はAvailabilityとして定義されています。

可用性が低いとどのような被害が起きますか？

可用性が低いと、必要なときにシステムや情報を使えず、事業に直接的な損害が生じます。具体的には、ECサイトの停止による販売機会の損失、基幹システム障害による受発注や生産の停止、ランサムウェア感染による数日間の業務停止などです。さらに、サービス停止が長引けば顧客や取引先からの信頼低下にもつながります。停止の影響は時間に比例して大きくなるため、早期復旧の備えが被害の抑制に直結します。

ISMSの可用性とBCP（事業継続計画）はどう違いますか？

可用性はISMSが守る情報セキュリティ3要素の一つで、主に情報とシステムを「使える状態」に保つことを指します。一方BCPは、災害や事故を含むあらゆる事態で事業そのものを止めないための計画で、人員・拠点・業務プロセスまで対象が広がります。両者は重なる部分があり、ISO/IEC 27001:2022の事業継続のためのICTの備え（A.5.30）は、ISMSの可用性とBCPをつなぐ管理策といえます。可用性は技術寄り、BCPは事業全体寄りと捉えると整理しやすくなります。

関連記事

• BCP（事業継続計画）とは何か：可用性確保の土台となる事業継続計画の全体像と備えるべきポイントを解説しています。