Of the three properties of information security, availability is the one treated most lightly in practice. Open a typical risk register and confidentiality dominates; availability is two lines — "cloud outage" and "disaster."
Yet for a healthcare company, availability is the risk closest to the business. If the EMR stops, the clinic stops, patients wait, and claims are delayed. Nothing has leaked, and the customer's operations have still failed. The length of the outage translates directly into contractual exposure and reputation.
Meanwhile, many companies have a BCP written by general affairs as "disaster preparedness," entirely disconnected from the ISMS documentation. That split produces a specific failure: an outage caused by a cyberattack — the most likely scenario of all — appears in neither plan.
This article covers connecting ISMS availability requirements to continuity planning, setting RTO and RPO, the relationship between an ISMS-scoped plan and the company-wide BCP, and exercise records. See Clause 8: Operation, Organisational Controls and What Is an ISMS (ISO/IEC 27001)?.
Disclaimer: This article is general information. The standard and the publications of accreditation and certification bodies are authoritative.
Why This Is Where People Get Stuck
Availability risk described too coarsely
"The service stops because of a cloud outage" yields no controls. Real causes differ sharply: platform failure, application defects, database corruption, DDoS, ransomware, expired certificates, failed configuration changes, supplier outages. Recovery method and duration differ per cause, so the plan cannot be written until they are separated.
RTO and RPO set by feel
"Recovery time objective: four hours" with no basis. Can you technically restore in four? Is four contractual? Did anyone estimate the loss from four hours down? An RTO without a basis cannot be explained when it is missed.
Two BCPs that do not agree
A company-wide BCP about earthquakes and pandemics, and a system recovery runbook, existing as separate documents with no cross-reference — separate call trees, separate escalation. In a real event, nobody knows which to open.
Exercises that stop at the restore test
Technical restore tests matter, but they are one part. Who declares the outage, who calls the customer hospitals, who declares recovery — without rehearsing those decisions, you lose time when it counts.
Not knowing the customer's fallback
If you do not know how the hospital continues care when your service is down — paper, and re-entry afterwards — you will get the recovery priorities wrong.
What You Decide
Start with a business impact analysis
The starting point is which functions, down for how long, cause what. Skip it and the RTO is a number without a reason.
| Function | Impact on the customer | Tolerable outage | Basis for the judgement |
|---|---|---|---|
| Viewing clinical records | Past records unavailable; affects quality and safety of care directly | Very short | Bears on care itself |
| Entering clinical records | Paper substitutes, but re-entry follows | Short | Substitutable at a cost |
| Booking and reception | Front desk disrupted, waits lengthen | Short | Substitutable but disruptive |
| Claims and billing | Limited impact if restored before the cut-off | Medium | Counted back from the cut-off date |
| Analytics and reporting | Little immediate operational impact | Long | Can be done later |
The rightmost column matters most. Without it, the RTO cannot be defended.
Setting RTO and RPO
| Metric | Meaning | How to set it |
|---|---|---|
| RTO | Target time from outage to service resumption | Take the tolerable outage from the BIA and reconcile it with the SLA and what is technically achievable |
| RPO | The point in time to which data can be recovered | Agree with the business how much data may be lost; drives backup frequency |
| RLO | The level of service restored | Whether all functions return at once, or read-only first |
These are not numbers for the technical team alone. Whether RPO is one hour or twenty-four is a judgement by whoever bears the cost of re-entering lost data — and a shorter RPO raises infrastructure cost. Structure the trade-off as a management decision, recorded in Management Review.
Do not write targets you cannot meet. "RTO one hour" on an architecture that takes six hours to restore is meaningless to auditors and useless in an outage. Record the gap as an improvement item with a deadline — that is both honest and better received.
ISMS-scoped continuity vs the company-wide BCP
| Company-wide BCP | Continuity within the ISMS | |
|---|---|---|
| Purpose | Continuity of the organisation's critical business | Maintaining availability and preserving information security during disruption |
| Scenarios | Earthquake, flood, fire, pandemic, supply chain | System outage, cyberattack, data loss, supplier failure |
| Scope | The whole company, including HR, finance, logistics, sites | The ISMS scope |
| Owner | Corporate planning / general affairs | ISMS secretariat / IT |
| Standard | ISO 22301 and similar (optional) | ISO/IEC 27001 controls (continuity, ICT readiness, backup, redundancy) |
The ISMS does not require you to write a company-wide BCP. It requires that information security be maintained during disruption, and that ICT be prepared to meet continuity requirements. Misreading this produces a large new document that nobody operates.
The practical resolution:
- If a company-wide BCP exists, reference it as the parent document and state the ISMS's role within it
- If none exists, do not force one. Build continuity plans for the critical systems in ISMS scope, with per-system recovery procedures and RTO/RPO
- Unify the call tree either way. Opening different contact lists for an earthquake and a cyberattack is unrealistic
- Put cyberattack explicitly in both — this is exactly where the split occurs
"Maintain information security during disruption" is easy to overlook and important. Under recovery pressure, organisations really do grant sweeping admin rights, use personal devices, and move data over unencrypted paths. Decide in advance what is permitted in an emergency and what will be verified afterwards.
The Practice
1. Enumerate causes of outage
| Category | Examples | Nature of recovery |
|---|---|---|
| Platform failure | Cloud region outage, network failure | You cannot fix it. The work is the failover decision and customer communication |
| Application defect | Release-induced failure, data inconsistency | Mostly a rollback decision |
| Data damage | Accidental deletion, database corruption | Restore from backup — RPO governs |
| Cyberattack | Ransomware, DDoS, intrusion | Containment and investigation precede recovery; RTO stretches |
| Supplier or external service outage | Identity, payments, external APIs | Hinges on whether a fallback exists |
| Physical and environmental | Site damage, power, comms | Personnel safety comes first |
| People | Key staff unavailable, mass absence | Reducing key-person dependency is the pre-emptive control |
Do not file ransomware alongside the rest. Unlike ordinary failures, the backups themselves may be encrypted, and the extent of compromise must be established before restoring. It is the one scenario that breaks the assumption "we have backups, so we can recover," which makes isolated backups — offline, or immutable — the core control. See Ransomware Countermeasures for Hospitals and Backup Design: the 3-2-1 Rule.
2. Design the controls
| Control | Effect | Cost driver |
|---|---|---|
| Backup (generations, offsite, offline) | Recovery from data loss; sets RPO | Frequency and retention |
| Redundancy (multi-AZ, multi-region) | Continuity through platform failure; shortens RTO | Complexity raises operational load |
| Designed degraded mode | Avoids total outage (e.g. read-only service) | Often high value at low cost |
| Documented and automated recovery | Removes key-person dependency, shortens recovery | Ongoing maintenance of runbooks |
| Alternate communication channel | Contact when your own mail and chat are down | Cheap, and frequently absent |
| Cross-trained staff | Continuity when a key person is unavailable | Needs training and access design together |
Degraded mode is the most overlooked high-value option. If writes are impossible but reads still work, hospitals can continue seeing patients against past records — far less damaging than waiting for full restoration.
3. Write runbooks for use under pressure
- Open with a decision table — which situation leads to which procedure
- Give each step an expected duration (the gap against actuals is improvement material)
- Mark the decision points and name the role that decides
- Point to where credentials live (never the values themselves)
- State assumed dependencies ("this assumes DNS is working")
4. Build customer notification into the procedure
This step is specific to healthcare. The outage notice must go out before the recovery estimate exists, because hospitals must decide early whether to wait or switch to paper.
| Element | How to write it |
|---|---|
| What is affected | Which functions are unavailable, specifically |
| Time of onset | As far as known |
| Scope | All customers or some; if some, on what condition |
| Current outlook | "Under investigation" is acceptable — but always give the time of the next update |
| Recommended interim operation | Paper records, read-only use, and so on |
| Contact | An outage-specific contact, distinct from normal support |
Few providers can offer a recommended interim operation, and it is exactly what hospitals need most. Draft one per major outage scenario in peacetime.
Route availability incidents through the same reporting channel as everything else — see Building an Incident Response Procedure.
5. Exercise, and record it
| Exercise type | Content | Frequency |
|---|---|---|
| Restore test | Actually restore from backup and verify integrity | Quarterly to half-yearly. An untested backup does not exist |
| Tabletop | Staged scenario; rehearse decisions and communication | At least annually |
| Runbook walkthrough | Read through and confirm executability | On revision |
| Failover drill | Actually switch to the redundant configuration | Annually where feasible |
| Communication drill | Test the call tree and alternate channels | Once or twice a year |
What the record must contain — auditors check this:
| Element | Content |
|---|---|
| Date, place, format | Tabletop / live / online |
| Participants | Names and roles, including who did not attend and why |
| Scenario | The event and its assumptions |
| Measured values | Duration per step; whether RTO/RPO were met |
| What did not work | Gaps in the runbook, hesitation, delayed contact |
| Improvements | Corrective action reference, owner, deadline |
| Runbook revision | Version and date if revised |
A record with no "what did not work" is not merely low value; it draws suspicion. A run of flawless annual exercises reads as a formality. Track findings on the form in Writing a Corrective Action Report.
Where It Goes Wrong
Backups taken, never restored
The most common and most dangerous failure. A successful backup job says nothing about whether you can get back to a usable state. Corrupted generations, unknown procedures, no target environment, five times the expected duration — all surface only on a real attempt. Fix restore tests as a recurring task.
Backups inside the same privilege domain as production
This is why ransomware damage spreads. If production admin is taken, everything reachable with it is deleted, backups included. Always hold a separate authentication domain, immutable storage, or an offline copy.
One RTO and RPO for the whole system
Tolerable downtime differs by function; a uniform target means over- or under-investment. Set them per function.
Supplier and external service outages omitted
Your systems may be fine while identity or payments are down. List external dependencies with the impact and fallback for each, and put availability requirements into contracts — see Supplier Security Management.
A call tree that depends on your own mail and chat
When your platform is the thing that is down, you cannot use it to coordinate. Maintain alternate channels and test them annually, with due care for personal data.
No criteria for declaring recovery
Telling customers you are back and then failing again costs a great deal of trust. Define recovery criteria in advance — functional checks, a period of stable operation, confirmation of no reinfection — and name who declares it.
Exercises confined to the technical team
Outage decisions, customer contact and executive communication involve sales, support and management. Run at least one exercise a year including non-technical functions.
Healthcare Examples
A healthcare SaaS provider
The distinctive constraint is clinical hours. For ordinary B2B SaaS, "maintenance overnight" suffices; hospitals differ by facility, and some run weekend and emergency services. Knowing each customer's clinical hours in peacetime directly shapes how recovery work is scheduled.
The second is reconciliation after recovery. Care recorded on paper during the outage must be entered afterwards. Designing that support — bulk import, treatment of entry deadlines, how it appears in the audit trail — changes the customer's burden materially. See also Security by Design for Medical Systems.
A PHR operator
Assess the impact of users being unable to reach their own data. Usually less urgent than clinical use — unless the data is shown to a clinician at an appointment, in which case it bears on care directly. Assess per use case.
A clinical trial systems company
Integrity and continuity of the audit trail can outrank RTO. How operations during the outage are recorded, and how traceability is assured afterwards, may justify a slower recovery. Make integrity an explicit factor in recovery priority.
A SaMD developer
Add an assessment of whether an outage could harm a patient. Where the function bears on diagnosis or treatment decisions, an outage is a safety matter and ISMS continuity alone is insufficient. Connect it to product risk management (ISO 14971) and, if needed, design product-level fallbacks (offline operation, fail-safe). See SaMD, ISMS and ISO 13485.
Relationship to the customer's own BCP
Your recovery plan functions as part of the hospital's BCP. When customers build their cyber BCP they need your recovery targets, fallbacks and escalation paths. Preparing that pack in peacetime helps their planning and differentiates you commercially. See Cyber BCP for Hospitals, Writing SLAs and Responsibility Boundaries and Drawing the Responsibility Boundary.
Conclusion
- Availability is the risk closest to the business for a healthcare company; separate it by cause rather than compressing it into two register rows
- Derive RTO and RPO from the BIA. Unsupported numbers cannot be explained when missed; record the decision as a management judgement
- The ISMS asks for security maintained during disruption and ICT readiness, not a new company-wide BCP; reference an existing one as the parent
- Treat ransomware separately. It is the one scenario in which the backups themselves are lost; isolated storage is the core control
- The first customer notice must always carry the time of the next update and a recommended interim operation
- Exercise records need measured values and what did not work; a run of flawless records reads as formality
For the internal flow see Building an Incident Response Procedure; for external dependencies, Supplier Security Management; for remediating exercise findings, Writing a Corrective Action Report. Record RTO/RPO investment decisions in Management Review.
Pottech supports ISMS certification and operation with a focus on healthcare. Continuity design that starts from what an outage does to a customer's clinical work cannot be assembled from a generic BCP template. See ISMS Certification Support or contact us.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- ISO 22301 Security and resilience — Business continuity management systems | ISO
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Information-technology Promotion Agency, Japan (IPA)
- Cabinet Office, Disaster Management
Note: interpretation of requirements and the handling of accreditation and certification are governed by the standard itself and by the publications of the accreditation and certification bodies, and may change with revisions.