ISO 27001 · the business continuity plan
The business continuity plan, written from a few answers
A disruption is the one day the company cannot write a plan, so the auditor asks for the one written before it: how long the product may be down, how much data may be lost, who declares the disruption and on which channel, how security holds while everyone is restoring, and when the plan was last exercised; this page writes that plan from a few answers, with the service list and the fallback channel staying on the page.
The plan
Eleven sections in the order a disruption unfolds; an empty entry is written as a gap to fill, not skipped.
# Business continuity plan: [company] Plan owner: [the plan owner] · Approved by: [top management] Written on with the free page on getstandardos.com against the Annex A controls of ISO/IEC 27001:2022 on information security during disruption, ICT readiness for business continuity, information backup and redundancy of information processing facilities. The wording is StandardOS's own. ## 1. Purpose and scope This plan says what [company] does when a service it depends on stops, so that the company keeps its commitments to customers, keeps its information secure while it recovers, and is back within the time it has decided it can afford. It covers the services named below, the people who run them, the data they hold and the suppliers they rest on. The services covered: [to be completed, the products and internal systems the company cannot do without]. ## 2. Recovery objectives Recovery time: each covered service is restored within 24 hours of the disruption being declared. Recovery point: no more than 24 hours of data is lost for any covered service. The two figures are the company's decision, not the provider's promise; a covered service whose provider cannot meet them is listed with the gap and the measure that closes it, or the figures are changed by the approver. ## 3. Roles [the plan owner] owns this plan, keeps it current and runs the exercise. [the disruption lead] leads a disruption: declares it, decides the order of recovery, approves any departure from the security rules, and declares the return to normal. Deputy lead: [to be completed]. Whoever reaches the fallback channel first when the lead cannot be reached within thirty minutes acts as lead until the lead or the deputy takes over. ## 4. The scenarios the plan covers The plan is written for five ways a service stops; a disruption that fits none of them is handled with the same roles, channel and objectives. - the cloud provider or region that runs the product is unavailable; - the data is encrypted, deleted or corrupted, by ransomware, by an error or by a bad deployment; - the office, its network or the people who work there are unavailable; - a critical supplier stops delivering, is breached or ends the contract without notice; - the identity provider or the administrator accounts are lost or locked. ## 5. Declaring a disruption and the first hour Anyone who sees a covered service down beyond a normal incident tells [the disruption lead], who declares the disruption, names the scenario, and opens a log with the time of the declaration. From that moment this plan applies and the incident response plan continues alongside it for the security side. The channel used when the usual tools are down: [the fallback channel, to be completed]. Its contact details are kept where they can be read without the company's systems, and checked at every exercise. In the first hour the lead confirms who is available, confirms which services are affected, tells customers through the status channel that the company is aware and when the next update comes, and starts the recovery in the order the next sections set. ## 6. Security during the disruption The access rules, the multi-factor authentication and the logging stay in force during a disruption. A departure from them, such as an emergency account, a shared credential or a restore into a new environment without the usual review, is approved by [the disruption lead], written in the log with the reason, and reversed as soon as the service is back. Backups and copies made during the recovery are protected like the originals, and every restore is done from a copy that cannot be changed by the same event that caused the disruption. ## 7. Backups, redundancy and the order of recovery Every covered service is backed up at least every 24 hours, to a location the service's own credentials cannot delete, and a restore from the backup is tested at every exercise. The product runs in one cloud region. Recovery within 24 hours rests on the provider's redundancy inside that region and on the ability to rebuild the service in another region from the backups and the infrastructure code, which is what the exercise tests. The order of recovery: identities and access first, so that people can work; then the services customers pay for; then the internal services; then everything else. A service is restored to the last backup within the recovery point, and the data between that backup and the disruption is re-entered or recovered from the customers' side where it can be. ## 8. Suppliers, customers and authorities For every critical supplier the supplier register records its continuity commitment and the contact used during a disruption; a supplier that is itself the disruption is handled by the exit rules of the supplier security policy. Customers are told through the status channel at the declaration, at every change and at the return to normal, in plain words and without speculation about the cause. Where the disruption is also a security incident, the notification clocks of the incident response plan apply, and the lead and the incident plan's lead decide together what is sent to whom. ## 9. Return to normal and the review after [the disruption lead] declares the return to normal when every covered service is back within its objectives and the departures from the security rules are reversed. Within ten working days the lead holds a review with the people involved, reads the log, records what worked, what did not and what changes, and the changes go into this plan, the incident response plan or the risk register. ## 10. Exercising the plan The plan is exercised once a year, run by [the plan owner]: one scenario is walked through with the people who would act, one restore is done from a backup, the fallback channel is used, and the time each step took is written down against the objectives. An exercise that misses an objective is not a failure of the exercise; it is the finding the plan exists to produce, and it becomes an action with an owner and a date. ## 11. Records This plan, the exercise records, the disruption logs, the reviews after each disruption and the restore tests are kept as the company's evidence that it is ready, and are what the internal audit and the certification audit read. Approved by [top management] on [date]; owned by [the plan owner]; reviewed at least once a year, after every exercise and after every disruption. This plan is written from the answers given. It is not certification advice; the certification body reads the plan for its objectives and roles and then asks for the exercise and the restore test that prove them, and the record it accepts is the one the company keeps.
In StandardOS the exercise is on the calendar
StandardOS keeps the plan as a record with its owner and review date, puts the exercise on the calendar at the cadence this plan sets, and holds each exercise's record beside the plan for the auditor.
The incident response planThe supplier security policyNIS2, which asks for continuity tooThe Annex A controls