[Company] Business Impact Analysis

• Version: 1.0
• Owner: CTO
• Approved by: CEO
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose and Scope

This analysis identifies the services [Company] delivers to its customers and relies on to operate, rates the harm of each being unavailable at five points in time, and sets for each a maximum tolerable period of disruption, a recovery time objective and a recovery point objective. The recovery objectives in section 7 are the targets that [Company]'s disaster recovery and business continuity plan must meet. That plan, not this analysis, says how each service is recovered.

The analysis covers each service, the systems and suppliers it depends on, and the people and data it needs. It measures the harm of a disruption and not how likely its causes are, which [Company]'s assessment of information security risk covers. The analysis is reviewed before the disaster recovery and business continuity plan is changed, so that the plan's targets come from this analysis.

This analysis was prepared from a profile of [Company]'s size, sector, systems, data and obligations, not from interviews or workshops with the people who run each service. The services listed, the impact ratings and the recovery objectives are starting points. At the first review, each service owner confirms or corrects the entries for the services they own, and the CTO raises the version number and updates the dates in the document control list.

2. Roles

• The CTO keeps this analysis, runs its reviews and carries the recovery objectives in section 7 into the disaster recovery and business continuity plan.
• The CEO approves the analysis and its recovery objectives.
• The service owners are each accountable for the entry of the services they own, confirm its ratings and objectives at each review and keep its workaround ready.
• All staff tell the CTO about a new service [Company] starts to depend on or a change to one.

3. How Impact Is Rated

[Company] rates the harm of a service being unavailable with four words, Negligible, Limited, Serious and Intolerable, at five points after the start of a disruption: 1 hour, 4 hours, 24 hours, 72 hours and 1 week, in calendar time.

3.1 Impact Ratings

A service takes the highest rating that any part of these meanings reaches.

3.2 Time Intervals

Each rating is the harm if the service has been unavailable for that long during the period when an outage would hurt [Company] most, with no help beyond the workaround in the service's entry. A service's ratings never fall as time passes. The maximum tolerable period of disruption of a service is the first interval at which its rating is Intolerable, or "More than 1 week" where no interval reaches it.

4. How Recovery Objectives Are Set

The maximum tolerable period of disruption (MTPD) is the time after which the harm of a service being unavailable becomes intolerable for [Company] (some recovery plans call it the maximum tolerable downtime). The recovery time objective (RTO) is the longest [Company] allows a service to be unavailable, measured from the start of the disruption, and is always shorter than the MTPD so that work that stopped can catch up before the harm becomes intolerable. The recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, and says nothing about how long recovery takes.

• The RTO of every service is shorter than its MTPD and leaves time after recovery for work that stopped to catch up and for data to be checked.
• RTOs are written in hours or days of calendar time, not business hours (in minutes only for a service whose MTPD is 1 hour), and RPOs in minutes, hours or days.
• For a service a supplier runs and [Company] cannot restore itself, the RTO is how long [Company] can work without it. The supplier's own recovery commitment is not [Company]'s RTO, and the service's entry says how [Company] keeps working when that time runs out.
• An RTO shorter than 72 hours can fall across a weekend, so the entry of such a service requires someone reachable outside business hours.
• An RTO shorter than 24 hours needs someone able to restore the service at any hour, and the entry of any service with an RTO that short says so.
• The RPO of a service is set by how much of its data [Company] could re-enter or do without, not by how often the data happens to be copied. A copy of the service's data must then be made at least as often as the RPO, which the service's entry requires.
• The RPO of a service that holds no data [Company] would need to recover is written as "None".

The disaster recovery and business continuity plan recovers services in tier order.

5. Review and Maintenance

• The CTO reviews the whole analysis with the service owners at least once every 12 months, and the CEO approves it at least once every 12 months.
• A service's entry is reviewed sooner when the service, the systems or suppliers it depends on, or [Company]'s commitments to customers change, after a disruption that affects it, and after a recovery test in which recovery took longer than the service's RTO or lost more data than its RPO.
• A new service takes the next unused ID, and IDs are never reused.
• A service [Company] no longer depends on is removed at the next review.
• A change to the recovery objectives in section 7 is carried into the disaster recovery and business continuity plan within 1 month.
• Previous versions of the analysis are kept for 3 years.

6. Impact Over Time

This table rates the harm to [Company] and its customers if each service has been unavailable for the time shown.

7. Recovery Objectives

This table sets the tier and the recovery objectives for each service, in the order in which the services are recovered.

8. Service Details

8.1 S-01 Customer application

• Service: The product [Company] delivers to its customers, including its API and customers' sign-in, which customers' staff use to do their own work.
• Owner: CTO
• Depends on: AWS cloud hosting; the data customers hold in the application; the CTO.
• Impact: Customers notice within the first hour and some complain. By 4 hours they cannot use the product or its API, have to be told, and the uptime commitment is missed; at 24 hours customers cannot do their work and are lost in numbers.
• Peak periods: When customers are running time-critical work in the application, or soon after a release.
• Workaround: [Company] tells affected customers about the outage by email and keeps them updated until the service is back.
• Objectives: MTPD 24 hours; RTO 8 hours; RPO 1 hour
• Recovery requirements: A copy of customers' data must be made at least every hour and kept separate from the production systems and accounts. Someone must be reachable outside business hours, and someone must be able to restore the service at any hour.

8.2 S-02 Email, calendars and files

• Service: Business email, calendars and shared files on Google Workspace, which all staff use to work with customers and run [Company].
• Owner: CTO
• Depends on: Google Workspace email and file storage; the Google Workspace identity service for staff sign-in; the CTO.
• Impact: Customers cannot be answered in writing and records cannot be reached, so work slows and then stops. At 72 hours a major contract is lost because customers cannot be answered in writing or sent documents.
• Peak periods: When a customer is waiting on a contract or an urgent reply.
• Workaround: Staff use team chat to reach each other and mobile phone to reach customers. This continues once the RTO is reached.
• Objectives: MTPD 72 hours; RTO 24 hours; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. [Company] must check whether the supplier publishes a recovery commitment, and its data export terms, and record them in this entry.

8.3 S-03 Customer support

• Service: Answering customers' questions and problems and telling them about outages, used by customers' staff. An outage means the staff who answer customers cannot work.
• Owner: CEO
• Depends on: The staff who answer customers; the CTO for technical answers.
• Impact: Only urgent problems are answered, so customers wait longer for help, first with questions and then with problems. At 24 hours customers who are waiting cannot do work they rely on and have to be told, and by 1 week customers are lost in numbers.
• Peak periods: During an outage of the customer application, or soon after a release.
• Workaround: The CTO answers customers with urgent problems directly by phone and email.
• Objectives: MTPD 1 week; RTO 2 days; RPO None
• Recovery requirements: Someone must be reachable outside business hours.

8.4 S-04 Paying staff and suppliers

• Service: Paying wages and supplier bills and keeping the records of what has been paid and what is owed.
• Owner: CEO
• Depends on: [Company]'s bank and its online banking; email (S-02); the CEO.
• Impact: Payments are delayed, first prompting complaints from staff and suppliers and then putting payment deadlines at risk. At 1 week [Company] cannot pay its staff or suppliers, which is intolerable.
• Peak periods: When a payday or a supplier payment deadline is due.
• Workaround: Urgent payments are arranged directly with the bank by mobile phone. When 3 days have passed, the CEO makes the payments that fall due by mobile phone with the bank, from [Company]'s own copy of the records.
• Objectives: MTPD 1 week; RTO 3 days; RPO 24 hours
• Recovery requirements: A copy of the records of what has been paid and what is owed must be made at least every 24 hours and kept separate from the production systems and accounts.

8.5 S-05 Building, testing and deploying software

• Service: Writing, testing and releasing changes to the customer application using GitHub, used by the people who build the product.
• Owner: CTO
• Depends on: GitHub; AWS cloud hosting for releases; the CTO.
• Impact: Changes cannot be released, which matters little at first. By 72 hours a needed fix cannot reach customers, but the harm stays tolerable for a week because the customer application (S-01) keeps running.
• Peak periods: When a fault in the customer application needs a fix or a security update must be released.
• Workaround: Non-urgent changes wait. When 2 days have passed, the CTO releases urgent fixes to AWS from a copy of the code.
• Objectives: MTPD More than 1 week; RTO 2 days; RPO 24 hours
• Recovery requirements: A copy of the code and its history must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. [Company] must check whether the supplier publishes a recovery commitment, and its data export terms, and record them in this entry.

8.6 S-06 Team communication

• Service: Team chat and video calls, which staff use to work together and to reach one another quickly.
• Owner: CTO
• Depends on: A team chat provider; a video call provider; staff's internet connections.
• Impact: Staff lose the quickest ways to coordinate and reach one another, so work slows. The harm stays tolerable for a week because email (S-02) and direct phone calls remain.
• Peak periods: During an outage of the customer application, when staff must coordinate quickly.
• Workaround: Staff use email (S-02) and individual phone calls.
• Objectives: MTPD More than 1 week; RTO 3 days; RPO None
• Recovery requirements: The contracts with the chat and video suppliers must state each supplier's recovery commitment.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Business Impact Analysis

• Version: 1.0
• Owner: Head of security
• Approved by: CEO
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose and Scope

This business impact analysis identifies the services [Company] delivers to its customers and relies on to operate, and rates the harm of each being unavailable at five points in time. For each service it sets a maximum tolerable period of disruption, a recovery time objective and a recovery point objective. The recovery objectives in section 7 are the targets [Company]'s disaster recovery and business continuity plan must meet. That plan, not this analysis, says how each service is recovered.

The analysis covers each service, the systems and suppliers it depends on, and the people and data it needs. It measures the harm of a disruption, not how likely its causes are, which [Company]'s assessment of information security risk covers. It is reviewed before the disaster recovery and business continuity plan is changed, so that the plan's targets come from this analysis. Where a customer is a financial entity to which DORA applies, that customer must analyse the impact of severe disruptions to its own business and ensure that the ICT services it uses are aligned with that analysis, and section 7 gives such customers [Company]'s recovery objectives for that purpose.

This analysis was prepared from a profile of [Company]'s size, sector, systems, data and obligations, not from interviews or workshops with the people who run each service. The services listed, the impact ratings and the recovery objectives are starting points. At the first review, each service owner confirms or corrects the entries for the services they own, and the head of security raises the version number and updates the dates in the document control list.

2. Roles

• Head of security: keeps this analysis, runs its reviews and carries the recovery objectives in section 7 into the disaster recovery and business continuity plan.
• CEO: approves the analysis and its recovery objectives.
• Service owners (the head of engineering, the head of operations and the head of finance): each accountable for the entry of the services they own, confirming its ratings and objectives at each review and keeping its workaround ready.
• All staff: tell the head of security about a new service [Company] starts to depend on or a change to one.

3. How Impact Is Rated

[Company] rates the harm of a service being unavailable with four words, Negligible, Limited, Serious and Intolerable, at five points after the start of a disruption: 1 hour, 4 hours, 24 hours, 72 hours and 1 week, in calendar time.

3.1 Impact Ratings

A service takes the highest rating that any part of a meaning reaches.

3.2 Time Intervals

Each rating is the harm if the service has been unavailable for that long during the period when an outage would hurt [Company] most, with no help beyond the workaround in the service's entry. A service's ratings never fall as time passes. The maximum tolerable period of disruption of a service is the first interval at which its rating is Intolerable, or "More than 1 week" where no interval reaches it.

4. How Recovery Objectives Are Set

Every service has three recovery objectives. The maximum tolerable period of disruption (MTPD) is the time after which the harm of a service being unavailable becomes intolerable for [Company] (some recovery plans call it the maximum tolerable downtime). The recovery time objective (RTO) is the longest [Company] allows a service to be unavailable, measured from the start of the disruption, and is always shorter than the MTPD so that work that stopped can catch up before the harm becomes intolerable. The recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, and says nothing about how long recovery takes.

• The RTO of every service is shorter than its MTPD and leaves time after recovery for work that stopped to catch up and for data to be checked.
• RTOs are written in hours or days of calendar time, not business hours (in minutes only for a service whose MTPD is 1 hour), and RPOs in minutes, hours or days.
• For a service a supplier runs and [Company] cannot restore itself, the RTO is how long [Company] can work without it. The supplier's own recovery commitment is not [Company]'s RTO, and the service's entry says how [Company] keeps working when that time runs out.
• Where an RTO is shorter than 72 hours it can fall across a weekend, so the service's entry requires someone reachable outside business hours.
• The RPO of a service is set by how much of its data [Company] could re-enter or do without, not by how often the data happens to be copied. A copy of the service's data must then be made at least as often as the RPO, which the service's entry requires.
• The RPO of a service that holds no data [Company] would need to recover is written as "None".

The disaster recovery and business continuity plan recovers services in tier order.

5. Review and Maintenance

• The head of security reviews the whole analysis with the service owners at least once every 12 months, and the CEO approves it at least once every 12 months.
• A service's entry is reviewed sooner when the service, the systems or suppliers it depends on, or [Company]'s commitments to customers change, after a disruption that affects it, and after a recovery test in which recovery took longer than the service's RTO or lost more data than its RPO.
• A new service takes the next unused ID, and IDs are never reused.
• A service [Company] no longer depends on is removed at the next review.
• A change to the recovery objectives in section 7 is carried into the disaster recovery and business continuity plan within 1 month.
• Previous versions of the analysis are kept for 3 years.

6. Impact Over Time

The table rates the harm of each service being unavailable at each of the five intervals, using the ratings in section 3.1.

7. Recovery Objectives

The table gives the tier, MTPD, RTO and RPO of each service, in the order in which the disaster recovery and business continuity plan recovers them.

8. Service Details

8.1 S-01 Customer application

• Service: Delivers [Company]'s product to its customers, including its API, customers' sign-in and its AI features. Customers use it in their own work.
• Owner: Head of engineering
• Depends on: AWS, an external AI model provider and engineering staff.
• Impact: Customers cannot do work they rely on from the first hour, have to be told, and a commitment to customers is missed. By 4 hours a major contract is lost, because customers that rely on the service in their own regulated operations cannot accept a missed recovery time commitment.
• Peak periods: When a customer is running its own regulatory reporting or end-of-period processing.
• Workaround: None
• Objectives: MTPD 4 hours; RTO 2 hours; RPO 15 minutes
• Recovery requirements: A copy of the service's data must be made at least every 15 minutes and kept separate from the production systems and accounts. Someone must be reachable outside business hours to restore the service.

8.2 S-02 Customer support

• Service: Answers customers' questions and incident reports and keeps them informed during disruptions. Customers' staff use it to ask for help and report problems. An outage means the system that holds [Company]'s records of customer contacts and open cases is unavailable.
• Owner: Head of operations
• Depends on: Support staff and the system that holds [Company]'s records of customer contacts and open cases.
• Impact: Customers' problems are taken by mobile phone and email without the records of open cases, so answers slow, and by 4 hours a commitment to customers is missed. By 24 hours a major contract is lost, because customers' open problems and incidents cannot be tracked or followed up for a day.
• Peak periods: When a customer is reporting an incident that affects its own operations, or following one up.
• Workaround: Support staff take calls on mobile phones and email customers directly, using [Company]'s own copy of the customer contact list.
• Objectives: MTPD 24 hours; RTO 8 hours; RPO 4 hours
• Recovery requirements: A copy of the service's data must be made at least every 4 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours.

8.3 S-03 Single sign-on

• Service: Lets staff sign in to company systems through Okta. All staff use it to reach the systems they work in.
• Owner: Head of engineering
• Depends on: Okta and the staff who manage access to company systems.
• Impact: Staff cannot reach the systems they work in, so work is delayed across teams and customers' urgent requests go unanswered. By 72 hours customers' requests have gone unanswered for three days and a major contract is lost.
• Peak periods: While [Company] is recovering another service and staff need access to the systems to do it.
• Workaround: Staff who are already signed in carry on working, and urgent work is handled by mobile phone and email. Once the RTO is reached, the head of engineering tells the service owners which work has stopped, and urgent work continues by mobile phone.
• Objectives: MTPD 72 hours; RTO 12 hours; RPO 24 hours
• Recovery requirements: A copy of the service's data, including its users and their access, must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. The contract with Okta must state its recovery commitment and how [Company] gets its data out.

8.4 S-04 Email and files

• Service: Provides staff email, calendars and file storage. Staff use it for day-to-day work and for correspondence with customers.
• Owner: Head of engineering
• Depends on: Microsoft 365 email and file storage, and the staff who manage the accounts.
• Impact: Staff cannot send or find the messages and files they work from, and customers wait for replies. By 72 hours customers have gone three days without the notices and documents their contracts entitle them to, and a major contract is lost.
• Peak periods: While a disruption is under way and customers must be told, or when a customer is waiting for documents.
• Workaround: Staff use team chat, video calls and mobile phone to reach each other and customers, and work from [Company]'s own copy of the files. Once the RTO is reached, urgent customer notices go out by mobile phone and video call.
• Objectives: MTPD 72 hours; RTO 24 hours; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. [Company] must check whether the supplier publishes a recovery commitment, and its data export terms, and record them in this entry.

8.5 S-05 Paying staff and suppliers

• Service: Pays staff salaries and supplier invoices. Staff and suppliers depend on it.
• Owner: Head of finance
• Depends on: [Company]'s bank, the payroll and payment services it uses, and finance staff.
• Impact: Payments are delayed at first, and by 72 hours payroll and supplier payment deadlines are at risk. By 1 week [Company] is unable to pay its staff or suppliers.
• Peak periods: During a payroll run or a supplier payment deadline.
• Workaround: Finance staff prepare payments by hand from [Company]'s own copy of the payroll and supplier data, and tell the staff and suppliers affected about delays by email and mobile phone. This continues once the RTO is reached.
• Objectives: MTPD 1 week; RTO 3 days; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. The contracts with the payroll and payment services must state their recovery commitments and how [Company] gets its data out.

8.6 S-06 Team communication

• Service: Lets staff talk to each other and to customers through team chat and video calls.
• Owner: Head of engineering
• Depends on: The team chat and video call suppliers.
• Impact: Coordination slows and some customer meetings are disrupted, and by 72 hours customers are waiting for answers. The harm stays tolerable for a week because email and mobile phone carry urgent contact.
• Peak periods: While a disruption is being managed and staff must coordinate quickly.
• Workaround: Staff use email and mobile phone for urgent contact with each other and with customers.
• Objectives: MTPD More than 1 week; RTO 3 days; RPO None
• Recovery requirements: The contracts with the team chat and video call suppliers must state their recovery commitments.

8.7 S-07 Building, testing and deploying software

• Service: Lets engineers build, test and release changes to the Customer application, including fixes. Engineering staff use it.
• Owner: Head of engineering
• Depends on: The source code hosting and build services, AWS and engineering staff.
• Impact: Releases slow down, and by 72 hours contractual deadlines for fixes to faults and security problems are at risk. The harm stays tolerable for a week because the Customer application keeps running without new releases.
• Peak periods: When a security fix or a customer-requested change is due for release.
• Workaround: Engineers keep working from their local copies of the code and tell the customers affected about any delayed fix.
• Objectives: MTPD More than 1 week; RTO 3 days; RPO 24 hours
• Recovery requirements: A copy of the source code and build configuration must be made at least every 24 hours and kept separate from the production systems and accounts. The contract with the source code hosting supplier must state its recovery commitment and how [Company] gets its code out.

8.8 S-08 Invoicing customers and collecting payment

• Service: Issues invoices to customers and records the payments received. Finance staff use it, and customers receive its invoices.
• Owner: Head of finance
• Depends on: The invoicing service finance staff use, [Company]'s bank and finance staff.
• Impact: Invoices and payments are delayed, not lost. By 1 week customers' contractual invoicing deadlines are at risk. The harm stays tolerable for a week because delayed income is still collected once the service is back.
• Peak periods: At the end of a billing period, when invoices fall due.
• Workaround: Finance staff prepare invoices by hand from [Company]'s own copy of the invoicing data, send them by email and match the payments received against the bank's records.
• Objectives: MTPD More than 1 week; RTO 4 days; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. The contract with the invoicing supplier must state its recovery commitment and how [Company] gets its data out.

8.9 S-09 Financial accounting and reporting

• Service: Keeps [Company]'s financial records and produces its accounts and financial reports. Finance staff and [Company]'s management use it.
• Owner: Head of finance
• Depends on: The accounting service finance staff use, and finance staff.
• Impact: Little changes in the first days, because records can be brought up to date later. By 1 week a legal or contractual reporting deadline is at risk. The harm stays tolerable for a week because the records are brought up to date once the service is back.
• Peak periods: During a month-end close or a reporting deadline.
• Workaround: Finance staff keep records by hand from [Company]'s own copy of the accounting data and enter them once the service is back.
• Objectives: MTPD More than 1 week; RTO 5 days; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. The contract with the accounting supplier must state its recovery commitment and how [Company] gets its data out.

8.10 S-10 Public website

• Service: [Company]'s public website, where customers and prospective customers find information about [Company] and its contact details.
• Owner: Head of operations
• Depends on: A website hosting provider and the staff who publish its content.
• Impact: Visitors cannot find information and some customers notice. By 1 week customers cannot reach the published information and contact details they rely on and have to be told. The harm stays tolerable for a week because customers can still reach [Company] by email and mobile phone.
• Peak periods: When a customer is carrying out a security or due diligence review.
• Workaround: Customer support gives customers the information and contact details they need by email and mobile phone. This continues once the RTO is reached.
• Objectives: MTPD More than 1 week; RTO 5 days; RPO 7 days
• Recovery requirements: A copy of the website's content must be made at least every 7 days and kept separate from the production systems and accounts. The contract with the hosting provider must state its recovery commitment and how [Company] gets its content out.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Business Impact Analysis

• Version: 1.0
• Owner: Head of security
• Approved by: CEO
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose and Scope

This analysis identifies the services [Company] delivers to its customers and relies on to operate, rates the harm of each being unavailable at five points in time, and sets for each a maximum tolerable period of disruption, a recovery time objective and a recovery point objective. The recovery objectives in section 7 are the targets [Company]'s disaster recovery and business continuity plan must meet. That plan, not this analysis, says how each service is recovered.

The analysis covers each service, the systems and suppliers it depends on, and the people and data it needs. It measures the harm of a disruption and not how likely its causes are, which [Company]'s assessment of information security risk covers. The analysis is reviewed before the recovery plan is changed, so that the plan's targets come from this analysis. HIPAA's contingency planning requirements include assessing the relative criticality of specific applications and data, in support of the other parts of [Company]'s contingency plan, and this analysis is where [Company] records that assessment.

This analysis was prepared from a profile of [Company]'s size, sector, systems, data and obligations, not from interviews or workshops with the people who run each service. The services listed, the impact ratings and the recovery objectives are starting points. At the first review, each service owner confirms or corrects the entries for the services they own, and the head of security raises the version number and updates the dates in the document control list.

2. Roles

• The head of security keeps this analysis, runs its reviews and carries the recovery objectives in section 7 into the disaster recovery and business continuity plan.
• The CEO approves this analysis and its recovery objectives.
• Service owners are each accountable for the entry of the services they own, confirm its ratings and objectives at each review and keep its workaround ready.
• All staff tell the head of security about a new service [Company] starts to depend on or a change to one.

3. How Impact Is Rated

[Company] rates the harm of a service being unavailable with four words, Negligible, Limited, Serious and Intolerable, at five points after the start of a disruption: 1 hour, 4 hours, 24 hours, 72 hours and 1 week, in calendar time.

3.1 Impact Ratings

A service takes the highest rating that any part of a meaning reaches.

3.2 Time Intervals

Each rating is the harm if the service has been unavailable for that long during the period when an outage would hurt [Company] most, with no help beyond the workaround in the service's entry. A service's ratings never fall as time passes. The maximum tolerable period of disruption of a service is the first interval at which its rating is Intolerable, or "More than 1 week" where no interval reaches it.

4. How Recovery Objectives Are Set

The maximum tolerable period of disruption (MTPD) is the time after which the harm of a service being unavailable becomes intolerable for [Company] (some recovery plans call it the maximum tolerable downtime). The recovery time objective (RTO) is the longest [Company] allows a service to be unavailable, measured from the start of the disruption, and is always shorter than the MTPD so that work that stopped can catch up before the harm becomes intolerable. The recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, and says nothing about how long recovery takes.

• The RTO of every service is shorter than its MTPD and leaves time after recovery for work that stopped to catch up and for data to be checked.
• RTOs are written in hours or days of calendar time, not business hours (in minutes only for a service whose MTPD is 1 hour), and RPOs in minutes, hours or days.
• For a service a supplier runs and [Company] cannot restore itself, the RTO is how long [Company] can work without it. The supplier's own recovery commitment is not [Company]'s RTO, and the service's entry says how [Company] keeps working when that time runs out.
• Where an RTO is shorter than 72 hours it can fall across a weekend, so the service's entry requires someone reachable outside business hours.
• The RPO of a service is set by how much of its data [Company] could re-enter or do without, not by how often the data happens to be copied. A copy of the service's data must then be made at least as often as the RPO, which the service's entry requires.
• The RPO of a service that holds no data [Company] would need to recover is written as "None".

The disaster recovery and business continuity plan recovers services in tier order.

5. Review and Maintenance

• The head of security reviews the whole analysis with the service owners at least once every 12 months, and the CEO approves it at least once every 12 months.
• A service's entry is reviewed sooner when the service, the systems or suppliers it depends on, or [Company]'s commitments to customers change, after a disruption that affects it, and after a recovery test in which recovery took longer than the service's RTO or lost more data than its RPO.
• A new service takes the next unused ID, and IDs are never reused.
• A service [Company] no longer depends on is removed at the next review.
• A change to the recovery objectives in section 7 is carried into the disaster recovery and business continuity plan within 1 month.
• Every version of the analysis is retained for at least 6 years from the date it was created or the date it was last in effect, whichever is later.

6. Impact Over Time

The table rates the harm of each service being unavailable at each of the five points in time.

7. Recovery Objectives

The table sets the tier, MTPD, RTO and RPO of each service, in the order the disaster recovery and business continuity plan recovers them.

8. Service Details

8.1 S-01 Customer application

• Service: The application, its API, customers' sign-in and the AI features, including clinical decision support, that hospitals and health systems use in their work.
• Owner: Head of engineering
• Depends on: Microsoft Azure; an external AI model provider; the engineering team; the data customers send to the application.
• Impact: Customers lose features their clinical staff rely on and have to be told, and a missed uptime or recovery time commitment brings service credits or notice. By 4 hours clinical staff have been without decision support for long enough that patients are put at risk of harm.
• Peak periods: During a customer's busiest clinical hours or the go-live of a new customer.
• Workaround: None
• Objectives: MTPD 4 hours; RTO 2 hours; RPO 1 hour
• Recovery requirements:
  • A copy of the customer application's data must be made at least every hour and kept separate from the production systems and accounts.
  • Someone reachable outside business hours must be able to restore the service.

8.2 S-02 Sign-in to company systems

• Service: Lets staff sign in to the systems they use for their work and gives each person the access their role needs.
• Owner: Head of engineering
• Depends on: The Microsoft 365 identity service; the people who administer staff accounts.
• Impact: Staff lose access to the systems they need, work slows across teams, and by 24 hours customers waiting on a fix or an answer have to be told. By 72 hours customer incidents have gone unresolved for so long that a major contract is lost.
• Peak periods: While a customer incident is being handled.
• Workaround: Staff already signed in keep working, and urgent requests that need a new sign-in are handled by phone. Customers affected are told.
• Objectives: MTPD 72 hours; RTO 12 hours; RPO 24 hours
• Recovery requirements:
  • A copy of the staff account and group records must be made at least every 24 hours and kept separate from the production systems and accounts.
  • Someone reachable outside business hours must be available while the service is unavailable.
  • [Company] must check whether the supplier publishes a recovery commitment, and its data export terms, and record them in this entry.

8.3 S-03 Customer support

• Service: Answers customers' questions and faults and passes them to the teams that can fix them. Customers' staff and [Company]'s support team use it. An outage means the system that receives and records customers' requests is unavailable.
• Owner: Head of operations
• Depends on: Support staff; the system that receives and records customers' requests.
• Impact: Only urgent faults and questions are handled, and by 24 hours customers who rely on support have to be told. By 72 hours customers whose requests have waited three days have lost confidence, and a major contract is lost.
• Peak periods: During a customer incident or the go-live of a new customer.
• Workaround: Urgent requests are handled by phone and email by the people who normally answer them, and customers affected are told.
• Objectives: MTPD 72 hours; RTO 24 hours; RPO 24 hours
• Recovery requirements:
  • A copy of the support records must be made at least every 24 hours and kept separate from the production systems and accounts.
  • Someone reachable outside business hours must be available to restore the service.

8.4 S-04 Email and files

• Service: Gives staff email, calendars and shared files, which they use to work with each other and with customers.
• Owner: Head of engineering
• Depends on: Microsoft 365 email and file storage; the people who manage mailboxes and sharing.
• Impact: Messages and shared files are out of reach and delays build across teams, and by 24 hours customers waiting on replies have to be told. By 72 hours [Company] has been out of reach by email for so long that a major contract is lost.
• Peak periods: When customers are waiting on a reply or a document.
• Workaround: Urgent messages go by team chat and mobile phone, and customers affected are told. Files needed urgently are taken from [Company]'s own copy.
• Objectives: MTPD 72 hours; RTO 24 hours; RPO 24 hours
• Recovery requirements:
  • A copy of the email and file data must be made at least every 24 hours and kept separate from the production systems and accounts.
  • Someone reachable outside business hours must be available while the service is unavailable.
  • [Company] must check whether the supplier publishes a recovery commitment, and its data export terms, and record them in this entry.

8.5 S-05 Paying staff and suppliers

• Service: Pays staff their wages and suppliers what they are owed, through [Company]'s bank. Finance staff run it.
• Owner: Head of finance
• Depends on: A bank; finance staff; the payment records.
• Impact: Payments to staff and suppliers are delayed and the delay grows more serious as payments fall due. By 1 week, with the payments that are not urgent due as well, [Company] is unable to pay its staff or suppliers.
• Peak periods: During a payroll run or when supplier payments fall due.
• Workaround: Urgent payments are made through the bank directly from [Company]'s own copy of the payment records. Payments that are not urgent wait for the service to return.
• Objectives: MTPD 1 week; RTO 3 days; RPO 24 hours
• Recovery requirements:
  • A copy of the payment records must be made at least every 24 hours and kept separate from the production systems and accounts.

8.6 S-06 Team communication

• Service: Gives staff team chat and video calls to coordinate work and speak to customers.
• Owner: Head of engineering
• Depends on: The team chat provider; a video call provider; staff.
• Impact: Coordination across teams slows and incidents take longer to handle. By 1 week a commitment to customers is missed, and the harm goes no further because email carries urgent work and no major contract is lost.
• Peak periods: During an incident that needs several teams.
• Workaround: Staff use email to reach each other and customers, and customers affected are told.
• Objectives: MTPD More than 1 week; RTO 3 days; RPO None
• Recovery requirements:
  • Contact details for staff and service owners must be kept somewhere that does not depend on team communication, so that the workaround can be used.
  • The contracts with the team chat and video call providers must state their recovery commitments.

8.7 S-07 Public website

• Service: Gives prospective and current customers public information about [Company] and its product, and a way to make contact.
• Owner: Head of operations
• Depends on: A website hosting provider; the people who maintain the site content.
• Impact: Prospective customers cannot find information or make contact through the site, and current customers cannot find public information. By 1 week income from new customers is lost for the period, but no major contract is lost because current customers contact [Company] directly.
• Peak periods: During a customer evaluation or procurement review that relies on public information.
• Workaround: [Company] contacts prospects and customers directly by email and phone, and tells those affected.
• Objectives: MTPD More than 1 week; RTO 3 days; RPO 24 hours
• Recovery requirements:
  • A copy of the site content must be made at least every 24 hours and kept separate from the production systems and accounts.
  • The hosting provider's contract must state its recovery commitment and how [Company] gets its data out.

8.8 S-08 Building, testing and deploying software

• Service: Lets engineers build, test and release changes to the product, including fixes. The engineering team uses it.
• Owner: Head of engineering
• Depends on: Sign-in to company systems (S-02); the engineering team; the source code and build configuration.
• Impact: Changes cannot be built, tested or released, so a fix customers are waiting for is held up. By 72 hours customers waiting on a fix have to be told, and the harm goes no further within a week because the live customer application keeps running.
• Peak periods: When a fix for a customer-facing fault or a security issue is waiting to be released.
• Workaround: None
• Objectives: MTPD More than 1 week; RTO 3 days; RPO 24 hours
• Recovery requirements:
  • A copy of the source code, build configuration and release records must be made at least every 24 hours and kept separate from the production systems and accounts.

8.9 S-09 Invoicing customers and collecting payment

• Service: Sends invoices to customers and collects what they owe. Finance staff run it.
• Owner: Head of finance
• Depends on: The supplier of the invoicing system; finance staff; customers' contract and billing details; a bank.
• Impact: Invoices and payment collection are delayed, and customers expecting them have to be told. By 1 week a contractual invoicing deadline is at risk, and the harm goes no further because delayed invoices are still issued once the service returns.
• Peak periods: At month end or when a contract sets an invoicing deadline.
• Workaround: Invoices are prepared from [Company]'s own copy of the billing records and issued once the service returns. Payments that reach the bank are recorded by hand, and customers affected are told.
• Objectives: MTPD More than 1 week; RTO 5 days; RPO 24 hours
• Recovery requirements:
  • A copy of the billing records must be made at least every 24 hours and kept separate from the production systems and accounts.
  • The invoicing system supplier's contract must state its recovery commitment and how [Company] gets its data out.

8.10 S-10 Financial accounting and reporting

• Service: Keeps [Company]'s financial records and produces its accounts and management reports. Finance staff use it.
• Owner: Head of finance
• Depends on: The supplier of the accounting system; finance staff; the financial records.
• Impact: Records of what [Company] has paid and been paid are not updated and reporting is delayed. By 1 week a deadline for filing accounts or a contractual reporting deadline is at risk, and the harm goes no further because records kept by hand let the deadline still be met.
• Peak periods: At month end or ahead of a filing deadline.
• Workaround: Entries are recorded by hand and entered once the service returns from [Company]'s own copy of the records.
• Objectives: MTPD More than 1 week; RTO 5 days; RPO 24 hours
• Recovery requirements:
  • A copy of the financial records must be made at least every 24 hours and kept separate from the production systems and accounts.
  • The accounting system supplier's contract must state its recovery commitment and how [Company] gets its data out.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Business Impact Analysis

• Version: 1.0
• Owner: CISO
• Approved by: CEO
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose and Scope

This analysis identifies the services [Company] delivers to its customers and relies on to operate, rates the harm of each being unavailable at five points in time, and sets for each a maximum tolerable period of disruption, a recovery time objective and a recovery point objective. The recovery objectives in section 7 are the targets [Company]'s disaster recovery and business continuity plan must meet. That plan, not this analysis, says how each service is recovered.

The analysis covers each service, the systems and suppliers it depends on, and the people and data it needs. It measures the harm of a disruption and not how likely its causes are, which [Company]'s assessment of information security risk covers. The analysis is reviewed before the disaster recovery and business continuity plan is changed, so that the plan's targets come from this analysis.

This analysis was prepared from a profile of [Company]'s size, sector, systems, data and obligations, not from interviews or workshops with the people who run each service. The services listed, the impact ratings and the recovery objectives are starting points. At the first review, each service owner confirms or corrects the entries for the services they own, and the CISO raises the version number and updates the dates in the document control list.

2. Roles

• The CISO keeps this analysis, runs its reviews and carries the recovery objectives in section 7 into the disaster recovery and business continuity plan.
• The CEO approves the analysis and its recovery objectives.
• Service owners (the head of IT, the head of operations and the head of finance) are each accountable for the entry of the services they own, confirm its ratings and objectives at each review, and keep its workaround ready.
• All staff tell the CISO about a new service [Company] starts to depend on or a change to one.

3. How Impact Is Rated

[Company] rates the harm of a service being unavailable with four words, Negligible, Limited, Serious and Intolerable, at five points after the start of a disruption: 1 hour, 4 hours, 24 hours, 72 hours and 1 week, in calendar time.

3.1 Impact Ratings

A service takes the highest rating that any part of a meaning reaches.

3.2 Time Intervals

Each rating is the harm if the service has been unavailable for that long during the period when an outage would hurt [Company] most, with no help beyond the workaround in the service's entry. A service's ratings never fall as time passes. The maximum tolerable period of disruption of a service, defined in section 4, is the first interval at which its rating is Intolerable, or "More than 1 week" where no interval reaches it.

4. How Recovery Objectives Are Set

The maximum tolerable period of disruption (MTPD) is the time after which the harm of a service being unavailable becomes intolerable for [Company] (some recovery plans call it the maximum tolerable downtime). The recovery time objective (RTO) is the longest [Company] allows a service to be unavailable, measured from the start of the disruption, and is always shorter than the MTPD so that work that stopped can catch up before the harm becomes intolerable. The recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, and says nothing about how long recovery takes.

• The RTO of every service is shorter than its MTPD and leaves time after recovery for work that stopped to catch up and for data to be checked.
• RTOs are written in hours or days of calendar time, not business hours (in minutes only for a service whose MTPD is 1 hour), and RPOs in minutes, hours or days.
• For a service a supplier runs and [Company] cannot restore itself, the RTO is how long [Company] can work without it, the supplier's own recovery commitment is not [Company]'s RTO, and the service's entry says how [Company] keeps working when that time runs out.
• Where an RTO is shorter than 72 hours it can fall across a weekend, so the service's entry requires someone reachable outside business hours.
• The RPO of a service is set by how much of its data [Company] could re-enter or do without, not by how often the data happens to be copied, and a copy of the service's data must then be made at least as often as the RPO, which the service's entry requires.
• The RPO of a service that holds no data [Company] would need to recover is written as "None".

The disaster recovery and business continuity plan recovers services in tier order.

5. Review and Maintenance

• The CISO reviews the whole analysis with the service owners at least once every 12 months, and the CEO approves it at least once every 12 months.
• A service's entry is reviewed sooner when the service, the systems or suppliers it depends on, or [Company]'s commitments to customers change, after a disruption that affects it, and after a recovery test in which recovery took longer than the service's RTO or lost more data than its RPO.
• A new service takes the next unused ID, and IDs are never reused.
• A service [Company] no longer depends on is removed at the next review.
• A change to the recovery objectives in section 7 is carried into the disaster recovery and business continuity plan within 1 month.
• Previous versions of the analysis are kept for 3 years.

6. Impact Over Time

The table shows the harm of each service being unavailable at each interval, using the ratings in section 3.

7. Recovery Objectives

The table sets the tier, MTPD, RTO and RPO of each service, in the order in which the disaster recovery and business continuity plan recovers them.

8. Service Details

8.1 S-01 Sign-in to company systems

• Service: Lets staff sign in to [Company]'s systems and applications, and so reach the customer work that depends on that access. Used by all staff.
• Owner: Head of IT
• Depends on: The Microsoft 365 identity service; the staff who administer accounts and access.
• Impact: Staff lose access to the systems they need, so customer work slows within an hour. By 4 hours the service desk and customer support work stop, recovery time commitments are missed and a major contract is lost, which is intolerable.
• Peak periods: During a customer incident or a customer's own deadline.
• Workaround: Staff already signed in keep working. When the RTO of 2 hours is reached, staff take customers' urgent requests by landline and mobile phone and tell the customers affected.
• Objectives: MTPD 4 hours; RTO 2 hours; RPO 4 hours
• Recovery requirements: A copy of the sign-in configuration and account data must be made at least every 4 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. [Company] must check whether the supplier publishes a recovery commitment, and its data export terms, and record them in this entry.

8.2 S-02 Service desk

• Service: Receives, triages and resolves IT and security requests from customers' users by phone and email. Staff use AI to triage incoming requests. An outage means the systems that log, track and triage requests are unavailable.
• Owner: Head of operations
• Depends on: The systems that log and track requests; AI-assisted triage; sign-in (S-01); service desk staff.
• Impact: Within an hour requests are taken by phone and email and tracked by hand, customers have to be told, and recovery time commitments come under pressure. By 4 hours requests tracked by hand have fallen behind, customers' own work is stopped, commitments are missed and a major contract is lost, which is intolerable.
• Peak periods: During a customer incident or when many of a customer's users are affected at once.
• Workaround: Staff take requests by landline phone, mobile phone and email and track them by hand, without AI triage.
• Objectives: MTPD 4 hours; RTO 3 hours; RPO 1 hour
• Recovery requirements: A copy of request records must be made at least every hour and kept separate from the production systems and accounts. Someone must be reachable outside business hours. Copies of controlled government information must have the same protection as the original.

8.3 S-03 On-premises systems and site

• Service: The on-premises systems and the site that houses them, covering power, hardware and the building. Used by staff and by the services that run on them.
• Owner: Head of IT
• Depends on: The power supply; the hardware; the building; the staff who maintain the systems.
• Impact: Services that run on-premises slow, then stop. By 4 hours services that run on-premises, including the controlled information environment (S-04), have stopped and the customers affected have to be told. By 24 hours customers' controlled work has stopped for a day and a major contract is lost, which is intolerable.
• Peak periods: During a customer deadline or when customers are working on controlled information.
• Workaround: None
• Objectives: MTPD 24 hours; RTO 6 hours; RPO 1 hour
• Recovery requirements: A copy of on-premises data must be made at least every hour and kept separate from the production systems and accounts. Someone must be reachable outside business hours. Copies of controlled government information must have the same protection as the original.

8.4 S-04 Controlled information environment

• Service: Holds the controlled government information [Company] handles for defense contractors and state agencies, and the systems used to work on it. Used by staff and customers.
• Owner: Head of IT
• Depends on: Azure Government; the on-premises systems (S-03); sign-in (S-01); the staff who administer the environment.
• Impact: Within the first hour customers cannot do controlled work they rely on and have to be told. By 24 hours uptime and recovery time commitments are missed and a major contract is lost, which is intolerable.
• Peak periods: During a customer's contract or reporting deadline.
• Workaround: Staff tell the customers affected, and controlled work waits until the environment is restored.
• Objectives: MTPD 24 hours; RTO 8 hours; RPO 1 hour
• Recovery requirements: A copy of the environment's data must be made at least every hour and kept separate from the production systems and accounts. Someone must be reachable outside business hours. Copies of controlled government information must have the same protection as the original. The cloud provider's contract must state its recovery commitment and how [Company] gets its data out.

8.5 S-05 Management of customer systems

• Service: Monitors, patches and manages customers' IT and security systems. Delivered by [Company]'s technical staff to customers. An outage means the systems staff use to monitor and manage customers' systems are unavailable.
• Owner: Head of operations
• Depends on: The systems staff use to monitor and manage customers' systems; sign-in (S-01); technical staff.
• Impact: Customers' systems go unmonitored and unpatched. By 4 hours customers cannot rely on [Company] to watch their systems and have to be told. By 24 hours commitments are missed, service credits fall due and customers are lost in numbers, which is intolerable.
• Peak periods: While a customer has an active incident or a scheduled maintenance window.
• Workaround: Staff handle urgent customer issues by hand, using phone and email.
• Objectives: MTPD 24 hours; RTO 12 hours; RPO 4 hours
• Recovery requirements: A copy of the configuration and records for customers' systems must be made at least every 4 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. Copies of controlled government information must have the same protection as the original.

8.6 S-06 Email and files

• Service: Email, calendars and file storage for staff, including customer correspondence and shared documents. Used by all staff.
• Owner: Head of IT
• Depends on: Microsoft 365 email and file storage; sign-in (S-01).
• Impact: Customers notice delays within 4 hours. By 24 hours work across teams stops and commitments are at risk. By 72 hours customers have gone three days without the documents [Company] sends them by email, and a major contract is lost, which is intolerable.
• Peak periods: During a customer incident or a contract renewal.
• Workaround: Staff use team chat, landline phones and mobile phones. When the RTO is reached, staff handle urgent matters by phone and tell customers by phone.
• Objectives: MTPD 72 hours; RTO 24 hours; RPO 4 hours
• Recovery requirements: A copy of email and files must be made at least every 4 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. [Company] must check whether the supplier publishes a recovery commitment, and its data export terms, and record them in this entry. Copies of controlled government information must have the same protection as the original.

8.7 S-07 Paying staff and suppliers

• Service: Pays staff salaries and supplier invoices. Used by staff and suppliers and run by the finance staff.
• Owner: Head of finance
• Depends on: The finance systems; [Company]'s bank; sign-in (S-01); email (S-06).
• Impact: A short delay is not noticed outside the finance staff. After 24 hours late payments cause complaints, and by 72 hours payment deadlines are at risk. By 1 week staff or suppliers cannot be paid, which is intolerable.
• Peak periods: During a payroll run or when a supplier payment falls due.
• Workaround: The head of finance prepares urgent payments by hand from the last copy of the payment records.
• Objectives: MTPD 1 week; RTO 48 hours; RPO 24 hours
• Recovery requirements: A copy of payment records must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours.

8.8 S-08 Team communication

• Service: Team chat, used by staff to coordinate work with each other.
• Owner: Head of IT
• Depends on: A team chat provider.
• Impact: Staff reach each other by other channels at first, but work across teams is delayed from 4 hours. By 72 hours incident coordination suffers and commitments are missed. The harm stays tolerable for a week because staff coordinate incidents by email, landline phone and mobile phone.
• Peak periods: During a customer incident when staff must coordinate quickly.
• Workaround: Staff coordinate by email, landline phone and mobile phone. When the RTO is reached, staff keep coordinating this way until team chat is restored.
• Objectives: MTPD More than 1 week; RTO 4 days; RPO None
• Recovery requirements: The team chat provider's contract must state its recovery commitment.

8.9 S-09 Customer support

• Service: Handles customers' account, contract and billing questions and escalations, apart from the technical requests that go to the service desk (S-02). Used by customers. An outage means the systems that record customer contacts are unavailable.
• Owner: Head of operations
• Depends on: The systems that record customer contacts; the staff who handle customer queries.
• Impact: Customers barely notice for the first 4 hours, then some complain. By 1 week customers whose queries go unanswered have to be told, and a renewal is at risk. The harm stays tolerable because urgent technical matters continue through the service desk.
• Peak periods: During a contract renewal or when a customer escalates a complaint.
• Workaround: Staff take customer queries by phone and email.
• Objectives: MTPD More than 1 week; RTO 5 days; RPO 24 hours
• Recovery requirements: A copy of customer contact records must be made at least every 24 hours and kept separate from the production systems and accounts.

8.10 S-10 Invoicing customers and collecting payment

• Service: Issues invoices to customers and collects payment from them. Used by the finance staff and customers.
• Owner: Head of finance
• Depends on: The finance systems; customer billing records; sign-in (S-01).
• Impact: Customers do not notice delayed invoices in the first day, then cash flow is at risk. By 72 hours a contractual invoicing deadline is at risk. The harm stays tolerable for a week because invoices can be issued late and the income is still collected.
• Peak periods: During a billing run or when a large invoice falls due.
• Workaround: Staff prepare invoices by hand from the last copy of billing records and send them by email.
• Objectives: MTPD More than 1 week; RTO 6 days; RPO 24 hours
• Recovery requirements: A copy of billing records must be made at least every 24 hours and kept separate from the production systems and accounts.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Business Impact Analysis

• Version: 1.0
• Owner: CISO
• Approved by: Board
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose and Scope

This analysis identifies the services [Company] delivers to its customers and relies on to operate, rates the harm of each being unavailable at five points in time, and sets for each a maximum tolerable period of disruption, a recovery time objective and a recovery point objective. The recovery objectives in section 7 are the targets that [Company]'s disaster recovery and business continuity plan must meet. That plan, not this analysis, says how each service is recovered.

The analysis covers each service, the systems and suppliers it depends on, and the people and data it needs. It measures the harm of a disruption and not how likely its causes are, which [Company]'s assessment of information security risk covers. The analysis is reviewed before the disaster recovery and business continuity plan is changed, so that the plan's targets come from this analysis.

This analysis was prepared from a profile of [Company]'s size, sector, systems, data and obligations, not from interviews or workshops with the people who run each service. The services listed, the impact ratings and the recovery objectives are starting points. At the first review, each service owner confirms or corrects the entries for the services they own, and the CISO raises the version number and updates the dates in the document control list.

2. Roles

• The CISO keeps the analysis, runs its reviews and carries the recovery objectives in section 7 into the disaster recovery and business continuity plan.
• The board approves the analysis and its recovery objectives.
• Service owners (the head of engineering, the head of operations, the head of finance and the head of people) are each accountable for the entry of the services they own, confirming its ratings and objectives at each review and keeping its workaround ready.
• All staff tell the CISO about a new service [Company] starts to depend on or a change to one.

3. How Impact Is Rated

[Company] rates the harm of a service being unavailable with four words, Negligible, Limited, Serious and Intolerable, at five points after the start of a disruption: 1 hour, 4 hours, 24 hours, 72 hours and 1 week, in calendar time.

3.1 Impact Ratings

A service takes the highest rating that any part of a meaning reaches.

3.2 Time Intervals

Each rating is the harm if the service has been unavailable for that long during the period when an outage would hurt [Company] most, with no help beyond the workaround in the service's entry. A service's ratings never fall as time passes. The maximum tolerable period of disruption of a service is the first interval at which its rating is Intolerable, or "More than 1 week" where no interval reaches it.

4. How Recovery Objectives Are Set

The maximum tolerable period of disruption (MTPD) is the time after which the harm of a service being unavailable becomes intolerable for [Company] (some recovery plans call it the maximum tolerable downtime). The recovery time objective (RTO) is the longest [Company] allows a service to be unavailable, measured from the start of the disruption, and is always shorter than the MTPD so that work that stopped can catch up before the harm becomes intolerable. The recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, and says nothing about how long recovery takes.

• The RTO of every service is shorter than its MTPD and leaves time after recovery for work that stopped to catch up and for data to be checked.
• RTOs are written in hours or days of calendar time, not business hours (in minutes only for a service whose MTPD is 1 hour), and RPOs in minutes, hours or days.
• For a service a supplier runs and [Company] cannot restore itself, the RTO is how long [Company] can work without it. The supplier's own recovery commitment is not [Company]'s RTO, and the service's entry says how [Company] keeps working when that time runs out.
• Where an RTO is shorter than 72 hours it can fall across a weekend, so the service's entry requires someone reachable outside business hours.
• The RPO of a service is set by how much of its data [Company] could re-enter or do without, not by how often the data happens to be copied. A copy of the service's data must then be made at least as often as the RPO, which the service's entry requires.
• The RPO of a service that holds no data [Company] would need to recover is written as "None".

The disaster recovery and business continuity plan recovers services in tier order.

5. Review and Maintenance

• The CISO reviews the whole analysis with the service owners at least once every 12 months, and the board approves it at least once every 12 months.
• A service's entry is reviewed sooner when the service, the systems or suppliers it depends on, or [Company]'s commitments to customers change, after a disruption that affects it, and after a recovery test in which recovery took longer than the service's RTO or lost more data than its RPO.
• A new service takes the next unused ID, and IDs are never reused.
• A service [Company] no longer depends on is removed at the next review.
• A change to the recovery objectives in section 7 is carried into the disaster recovery and business continuity plan within 1 month.
• Previous versions of the analysis are kept for 3 years.

6. Impact Over Time

The table shows the harm of each service being unavailable at each of the five points in time, using the ratings in section 3.

7. Recovery Objectives

The table shows the recovery objectives for each service, in the order in which the disaster recovery and business continuity plan recovers them.

8. Service Details

8.1 S-01 Customer application

• Service: The product that enterprise customers use to do their work, covering its API, customers' sign-in and its AI features.
• Owner: Head of engineering
• Depends on: The cloud hosting providers, an external AI model provider, and the engineers who run it.
• Impact: Within the first hour customers cannot do work they rely on, the uptime commitment is missed and any service credits the contracts set fall due. By 4 hours customers are lost in numbers and major contracts are lost.
• Peak periods: During a customer's own reporting deadline or a period of peak use.
• Workaround: None
• Objectives: MTPD 4 hours; RTO 2 hours; RPO 15 minutes
• Recovery requirements: A copy of the service's data must be made at least every 15 minutes and kept separate from the production systems and accounts. Someone must be reachable outside business hours to restore the service.

8.2 S-02 Single sign-on

• Service: The single sign-on service, Okta, through which all staff sign in to [Company]'s systems.
• Owner: Head of engineering
• Depends on: Okta and the people who administer it.
• Impact: Staff are slowed within the first hour and by 4 hours cannot do work they rely on. By 24 hours staff cannot reach most of the systems they work in, work for customers stalls and a major contract is lost.
• Peak periods: During an incident that needs many staff to reach systems at once.
• Workaround: Staff who are already signed in keep working, and urgent work goes ahead by phone and email. Staff affected are told by email and mobile phone. Once the RTO is reached, urgent work continues this way until Okta is restored.
• Objectives: MTPD 24 hours; RTO 8 hours; RPO 24 hours
• Recovery requirements: A copy of the sign-in configuration and the user and group records must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. Okta's contract must state its recovery commitment and how [Company] gets its data out.

8.3 S-03 Email, calendars and files

• Service: Email, calendars and shared files that staff use to work with each other, with customers and with suppliers.
• Owner: Head of engineering
• Depends on: The office suite supplier and the people who administer it.
• Impact: Staff cannot send contracts, notices or customer replies, and work stalls. By 72 hours customers have gone three days without the notices, contracts and replies they are waiting for, and a major contract is lost.
• Peak periods: During an incident that needs formal notices sent to customers, or ahead of a contract signing deadline.
• Workaround: Staff use team chat, video calls and mobile phone, and urgent notices to customers are given by phone. Once the RTO is reached, staff keep working this way until the service is restored.
• Objectives: MTPD 72 hours; RTO 12 hours; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. The supplier's contract must state its recovery commitment and how [Company] gets its data out.

8.4 S-04 Customer support

• Service: Support staff answer enterprise customers' questions and reports of problems. An outage means the customer support system is unavailable.
• Owner: Head of operations
• Depends on: A customer support system supplier and the support staff.
• Impact: Customers waiting for help have to be told, and problems stay open while requests are handled by email and mobile phone without the support system's records. By 72 hours enterprise customers whose problems have gone unresolved for three days leave and a major contract is lost.
• Peak periods: During a customer outage or ahead of a customer's own deadline.
• Workaround: Support handles urgent requests by email and mobile phone and tells affected customers about delays. Once the RTO is reached, all requests are handled this way until the service is restored.
• Objectives: MTPD 72 hours; RTO 24 hours; RPO 4 hours
• Recovery requirements: A copy of the service's data must be made at least every 4 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. The supplier's contract must state its recovery commitment and how [Company] gets its data out.

8.5 S-05 Paying staff and suppliers

• Service: The finance team pays staff and suppliers on time.
• Owner: Head of finance
• Depends on: A finance system supplier, [Company]'s banks and the finance team.
• Impact: Staff and suppliers are paid late, and complaints grow as the delay lengthens. By 72 hours payment deadlines are at risk, and by 1 week [Company] is unable to pay its staff or suppliers.
• Peak periods: During a pay run or when supplier payments fall due.
• Workaround: The finance team works from [Company]'s own copy of the pay and supplier payment data and instructs the banks directly. Once the RTO is reached, urgent payments go ahead this way and the staff and suppliers affected are told.
• Objectives: MTPD 1 week; RTO 48 hours; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. The finance system supplier's contract must state its recovery commitment and how [Company] gets its data out.

8.6 S-06 Team communication

• Service: Team chat and video calls that staff use to work together and to coordinate during incidents.
• Owner: Head of engineering
• Depends on: The team chat and video call suppliers.
• Impact: Coordination slows and teams lose time. By 1 week delays across teams cost income, which stays tolerable because email and mobile phone carry urgent work and customers still get their service.
• Peak periods: During an incident that needs many staff to coordinate quickly.
• Workaround: Staff use email and mobile phone. Once the RTO is reached, staff keep working this way until the service is restored.
• Objectives: MTPD More than 1 week; RTO 3 days; RPO None
• Recovery requirements: The suppliers' contracts must state their recovery commitments.

8.7 S-07 Building, testing and deploying software

• Service: Engineers write, test and release changes and fixes to the product.
• Owner: Head of engineering
• Depends on: The cloud hosting providers, the source code repositories and the engineers.
• Impact: New features and non-urgent fixes wait while the customer application keeps running. By 1 week a fix that customers or a contract deadline depend on cannot be released, which stays tolerable because the customer application runs without it.
• Peak periods: When an urgent fix for customers is waiting to be released.
• Workaround: Engineers keep working from their local copies of the code, and releases wait until the service is restored.
• Objectives: MTPD More than 1 week; RTO 3 days; RPO 24 hours
• Recovery requirements: A copy of the source code and the build and release configuration must be made at least every 24 hours and kept separate from the production systems and accounts.

8.8 S-08 Financial accounting and reporting

• Service: The finance team keeps [Company]'s accounts and produces its financial reports for the board and for filings.
• Owner: Head of finance
• Depends on: A finance system supplier and the finance team.
• Impact: Month-end close and reporting slip, and by 72 hours a filing or reporting deadline is at risk. The harm stays tolerable for a week because filings that are due go ahead by hand from [Company]'s own copy of the data.
• Peak periods: During month-end close or ahead of a legal filing deadline.
• Workaround: The finance team records transactions by hand from [Company]'s own copy of the data and delays reporting that is not urgent. Once the RTO is reached, filings that are due go ahead this way until the service is restored.
• Objectives: MTPD More than 1 week; RTO 4 days; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. The supplier's contract must state its recovery commitment and how [Company] gets its data out.

8.9 S-09 Internal IT support

• Service: Staff raise requests for devices, access and software in ServiceNow, and IT support staff resolve them.
• Owner: Head of engineering
• Depends on: ServiceNow and the IT support staff.
• Impact: Staff wait longer for fixes and new devices, and by 72 hours staff who are locked out or without devices cannot do work they rely on. This stays tolerable for a week because most staff keep working and urgent faults are handled directly.
• Peak periods: When many staff need access or new devices at once, such as during an incident or when new staff start.
• Workaround: Staff report faults to IT support by email and mobile phone, and urgent faults are handled first. Once the RTO is reached, all requests are handled this way until the service is restored.
• Objectives: MTPD More than 1 week; RTO 4 days; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. ServiceNow's contract must state its recovery commitment and how [Company] gets its data out.

8.10 S-10 Public website

• Service: [Company]'s public website, where customers and prospective customers find information about the product.
• Owner: Head of operations
• Depends on: A website hosting provider and the people who maintain its content.
• Impact: Visitors cannot find information and new enquiries slow. By 1 week lost enquiries cost income, which stays tolerable because customers use the product and support directly.
• Peak periods: During a product launch or a marketing campaign.
• Workaround: Sales and support staff handle enquiries by email and mobile phone. Once the RTO is reached, they keep doing so and tell customers who ask that the website is unavailable.
• Objectives: MTPD More than 1 week; RTO 5 days; RPO 24 hours
• Recovery requirements: A copy of the website content must be made at least every 24 hours and kept separate from the production systems and accounts. The hosting provider's contract must state its recovery commitment and how [Company] gets its data out.

8.11 S-11 Staff records and hiring

• Service: The records of staff employment and the hiring of new staff, used by the people team and managers.
• Owner: Head of people
• Depends on: A people records system supplier and the people team.
• Impact: Changes to records and hiring pause, while existing staff carry on working. By 1 week new starters cannot be set up and an employment deadline is at risk, which stays tolerable because the harm is delay and not lost work.
• Peak periods: During a hiring drive or when many staff start or leave at once.
• Workaround: The people team works from [Company]'s own copy of the records and handles urgent changes by email. Once the RTO is reached, urgent starters and leavers are handled this way until the service is restored.
• Objectives: MTPD More than 1 week; RTO 5 days; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. The supplier's contract must state its recovery commitment and how [Company] gets its data out.

8.12 S-12 Invoicing customers and collecting payment

• Service: The finance team invoices customers and records the payments they make.
• Owner: Head of finance
• Depends on: A finance system supplier, [Company]'s banks and the finance team.
• Impact: Invoices go out and payments are recorded late, which delays income without losing it. By 1 week an invoicing deadline in a contract is at risk, which stays tolerable because the income is only delayed.
• Peak periods: During a billing run or at the end of a customer's payment period.
• Workaround: The finance team works from [Company]'s own copy of the invoice and payment data and sends urgent invoices by email. Once the RTO is reached, all invoices are handled this way until the service is restored.
• Objectives: MTPD More than 1 week; RTO 6 days; RPO 24 hours
• Recovery requirements: A copy of the service's data must be made at least every 24 hours and kept separate from the production systems and accounts. The finance system supplier's contract must state its recovery commitment and how [Company] gets its data out.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Business Impact Analysis

• Version: 1.0
• Owner: Executive director
• Approved by: Board
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose and Scope

This analysis identifies the services [Company] delivers to the people it serves and relies on to operate, rates the harm of each being unavailable at five points in time, and sets for each a maximum tolerable period of disruption, a recovery time objective and a recovery point objective. The recovery objectives in section 7 are the targets that [Company]'s disaster recovery and business continuity plan must meet. That plan, not this analysis, says how each service is recovered.

The analysis covers each service, the systems and suppliers it depends on, and the people and data it needs. It measures the harm of a disruption and not how likely its causes are, which [Company]'s assessment of information security risk covers. The analysis is reviewed before the disaster recovery and business continuity plan is changed, so that the plan's targets come from this analysis.

This analysis was prepared from a profile of [Company]'s size, sector, systems, data and obligations, not from interviews or workshops with the people who run each service. The services listed, the impact ratings and the recovery objectives are starting points. At the first review, each service owner confirms or corrects the entries for the services they own, and the executive director raises the version number and updates the dates in the document control list.

2. Roles

• The executive director keeps this analysis, runs its reviews and carries the recovery objectives in section 7 into the disaster recovery and business continuity plan.
• The board approves this analysis and its recovery objectives.
• Service owners (the executive director and the finance lead) are each accountable for the entry of the services they own, confirming its ratings and objectives at each review and keeping its workaround ready.
• All staff and volunteers tell the executive director about a new service [Company] starts to depend on or a change to one.

3. How Impact Is Rated

[Company] rates the harm of a service being unavailable with four words, Negligible, Limited, Serious and Intolerable, at five points after the start of a disruption: 1 hour, 4 hours, 24 hours, 72 hours and 1 week, in calendar time.

3.1 Impact Ratings

A service takes the highest rating that any part of a meaning reaches.

3.2 Time Intervals

Each rating is the harm if the service has been unavailable for that long during the period when an outage would hurt [Company] most, with no help beyond the workaround in the service's entry. A service's ratings never fall as time passes. The maximum tolerable period of disruption of a service is the first interval at which its rating is Intolerable, or "More than 1 week" where no interval reaches it.

4. How Recovery Objectives Are Set

The maximum tolerable period of disruption (MTPD) is the time after which the harm of a service being unavailable becomes intolerable for [Company] (some recovery plans call it the maximum tolerable downtime). The recovery time objective (RTO) is the longest [Company] allows a service to be unavailable, measured from the start of the disruption, and is always shorter than the MTPD so that work that stopped can catch up before the harm becomes intolerable. The recovery point objective (RPO) is the most data, measured in time, that [Company] can afford to lose, and says nothing about how long recovery takes.

• The RTO of every service is shorter than its MTPD and leaves time after recovery for work that stopped to catch up and for data to be checked.
• RTOs are written in hours or days of calendar time, not business hours (in minutes only for a service whose MTPD is 1 hour), and RPOs in minutes, hours or days.
• For a service a supplier runs and [Company] cannot restore itself, the RTO is how long [Company] can work without it. The supplier's own recovery commitment is not [Company]'s RTO, and the service's entry says how [Company] keeps working when that time runs out.
• Where an RTO is shorter than 72 hours it can fall across a weekend, so the service's entry requires someone reachable outside business hours.
• The RPO of a service is set by how much of its data [Company] could re-enter or do without, not by how often the data happens to be copied. A copy of the service's data must then be made at least as often as the RPO, which the service's entry requires.
• The RPO of a service that holds no data [Company] would need to recover is written as "None".

The disaster recovery and business continuity plan recovers services in tier order.

5. Review and Maintenance

• The executive director reviews the whole analysis with the service owners at least once every 12 months, and the board approves it at least once every 12 months.
• A service's entry is reviewed sooner when the service, the systems or suppliers it depends on, or [Company]'s commitments to donors and beneficiaries change, after a disruption that affects it, and after a recovery test in which recovery took longer than the service's RTO or lost more data than its RPO.
• A new service takes the next unused ID, and IDs are never reused.
• A service [Company] no longer depends on is removed at the next review.
• A change to the recovery objectives in section 7 is carried into the disaster recovery and business continuity plan within 1 month.
• Previous versions of the analysis are kept for 3 years.

6. Impact Over Time

The table shows the harm of each service being unavailable at each interval, rated as described in section 3.

7. Recovery Objectives

The table sets the tier, MTPD, RTO and RPO of each service, sorted by tier, then MTPD, then RTO, and these are the targets the disaster recovery and business continuity plan must meet.

8. Service Details

8.1 S-01 Contact with donors and beneficiaries

• Service: How [Company] keeps in touch with donors and with the vulnerable beneficiaries it serves: answering enquiries, giving support and thanking donors. Staff and volunteers do this work. An outage means the video calls and records staff and volunteers use for this work are unavailable.
• Owner: Executive director
• Depends on: A video calling provider, donor and beneficiary records (S-02), staff and volunteers.
• Impact: Donors and beneficiaries notice within the first hour and some complain. By 4 hours beneficiaries wait for support they rely on and have to be told, and by 24 hours vulnerable beneficiaries whose details staff do not already hold are put at risk of harm, which is intolerable.
• Peak periods: When a beneficiary needs urgent support, or during a fundraising appeal.
• Workaround: Staff and volunteers reach donors and beneficiaries by email, mobile phone and WhatsApp, working from the details they already hold. When 8 hours pass, staff phone the beneficiaries who need urgent support directly.
• Objectives: MTPD 24 hours; RTO 8 hours; RPO None
• Recovery requirements: Someone must be reachable outside business hours. The contract with the video calling provider must state its recovery commitment.

8.2 S-02 Donor and beneficiary records

• Service: The records of donors and of the beneficiaries [Company] supports, including personal and sensitive details. Staff and volunteers use them to give support and manage donor relationships.
• Owner: Executive director
• Depends on: The supplier-run system that holds the records, the supplier that runs it, staff and volunteers who update the records.
• Impact: Staff cannot see who needs support or who has given, so support is slowed and some donors notice. By 24 hours vulnerable beneficiaries are put at risk of harm because staff cannot see who needs support, which is intolerable.
• Peak periods: When a beneficiary needs urgent support, or during a fundraising appeal.
• Workaround: Staff work from the most recent separate copy of the records. When 8 hours pass, the executive director decides which beneficiaries are contacted first by mobile phone.
• Objectives: MTPD 24 hours; RTO 8 hours; RPO 24 hours
• Recovery requirements: A copy of the records must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. The supplier's contract must state its recovery commitment and how [Company] gets its data out.

8.3 S-03 Programs for beneficiaries

• Service: The support, activities and help [Company] provides to the vulnerable beneficiaries it serves, delivered by staff and volunteers. An outage means staff and volunteers cannot reach beneficiaries through contact with donors and beneficiaries (S-01) or see their records (S-02).
• Owner: Executive director
• Depends on: Staff and volunteers, contact with donors and beneficiaries (S-01), donor and beneficiary records (S-02).
• Impact: Beneficiaries notice delays quickly. By 4 hours support they rely on is delayed and they have to be told, and by 24 hours vulnerable beneficiaries whose details staff and volunteers do not already hold are put at risk of harm, which is intolerable.
• Peak periods: When a beneficiary has an urgent need, or during a scheduled session or event.
• Workaround: Staff and volunteers deliver support by mobile phone and WhatsApp, working from the details they already hold.
• Objectives: MTPD 24 hours; RTO 12 hours; RPO None
• Recovery requirements: Someone must be reachable outside business hours to start the workaround and to decide which beneficiaries are supported first.

8.4 S-04 Email and files

• Service: Microsoft 365 email and file storage that staff and volunteers use to write to donors, beneficiaries and suppliers and to keep working documents.
• Owner: Executive director
• Depends on: Microsoft 365 email and file storage, the Microsoft 365 identity service, staff and volunteers.
• Impact: Teams cannot exchange documents and some donors and beneficiaries notice by 4 hours. A legal or contractual deadline is at risk by 24 hours. By 72 hours a major donor or a grant is lost because the reports and replies they are waiting for cannot be sent, which is intolerable.
• Peak periods: When a legal or contractual deadline is near, or during a fundraising appeal.
• Workaround: Staff use mobile phone and WhatsApp for urgent contact and video calls for meetings. When 24 hours pass, staff handle urgent matters by mobile phone and WhatsApp, and the executive director decides which come first.
• Objectives: MTPD 72 hours; RTO 24 hours; RPO 24 hours
• Recovery requirements: A copy of the email and files must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. [Company] must check whether the supplier publishes a recovery commitment, and its data export terms, and record them in this entry.

8.5 S-05 Paying staff and suppliers

• Service: Paying salaries, expenses and supplier invoices. The finance lead runs it and staff and suppliers depend on it.
• Owner: Finance lead
• Depends on: The bank, the supplier that holds payment and payroll records.
• Impact: There is little effect in the first hours. By 24 hours a payroll or supplier deadline is at risk. By 1 week staff or suppliers cannot be paid, which is intolerable.
• Peak periods: On payday, or when supplier payments fall due.
• Workaround: The finance lead tells staff and suppliers about any delay by email and mobile phone. When 48 hours pass, the executive director and the finance lead agree which payments are made first directly through the bank.
• Objectives: MTPD 1 week; RTO 48 hours; RPO 24 hours
• Recovery requirements: A copy of the payment and payroll records must be made at least every 24 hours and kept separate from the production systems and accounts. Someone must be reachable outside business hours. The supplier's contract must state its recovery commitment and how [Company] gets its data out.

8.6 S-06 Team communication

• Service: The video calls that staff and volunteers use to coordinate day to day work.
• Owner: Executive director
• Depends on: A video calling provider.
• Impact: Meetings are disrupted within hours. By 72 hours staff and volunteers coordinate programs more slowly and the donors and beneficiaries affected have to be told. The harm stays tolerable for a week because staff and volunteers can still coordinate by mobile phone, WhatsApp and email.
• Peak periods: During a program event or fundraising appeal when many volunteers must coordinate.
• Workaround: Staff and volunteers hold meetings by mobile phone and coordinate by WhatsApp and email. When 3 days pass, the executive director coordinates the day by mobile phone calls.
• Objectives: MTPD More than 1 week; RTO 3 days; RPO None
• Recovery requirements: The contract with the video calling provider must state its recovery commitment.

8.7 S-07 Taking online donations

• Service: Takes online donations by card from donors through a payment provider. Donors give through it, and the finance lead uses it to reconcile gifts.
• Owner: Finance lead
• Depends on: A payment provider, donor and beneficiary records (S-02).
• Impact: Donors cannot give and have to be told, and some do not return. The harm stays tolerable for a week because donors can give again once the service returns and major donors can be contacted directly.
• Peak periods: During a fundraising appeal or a giving day.
• Workaround: Staff tell donors by email and WhatsApp when giving will resume and ask them to return then. When 3 days pass, staff phone major donors directly.
• Objectives: MTPD More than 1 week; RTO 3 days; RPO 24 hours
• Recovery requirements: A copy of the donation records must be made at least every 24 hours and kept separate from the production systems and accounts. The supplier's contract must state its recovery commitment and how [Company] gets its data out.

8.8 S-08 Public website

• Service: [Company]'s website, where donors, beneficiaries and the public learn about its work and find out how to give or get support. Staff maintain its content.
• Owner: Executive director
• Depends on: The supplier that hosts the website, staff who maintain its content.
• Impact: Visitors do not notice in the first hours, and some donors and beneficiaries complain by 24 hours. By 1 week some donations are lost and visitors lose trust, but the harm stays tolerable because donors and beneficiaries can still reach [Company] by email and mobile phone.
• Peak periods: During a fundraising appeal, or when people look for urgent information.
• Workaround: Staff answer enquiries by email and mobile phone. When 5 days pass, staff contact major donors directly by email.
• Objectives: MTPD More than 1 week; RTO 5 days; RPO 7 days
• Recovery requirements: A copy of the website content must be made at least every 7 days and kept separate from the production systems and accounts. The supplier's contract must state its recovery commitment and how [Company] gets its data out.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.