Business Impact Assessment
November 25, 2018
Document Prepared by
| Organization Name | GSA/TTS |
|---|---|
| Address Line 1 | 1800 F St |
| Address Line 2 | Suite 4100 |
| City, State Zip | Washington, DC 20405 |
| Version Number | Date | Description | Authors |
|---|---|---|---|
| 1.0 | 2019-11-25 | Initial Version | Ryan Wold, Lynnette Jackson |
1. Overview
1.1 Purpose
2. System Description
2.1 Touchpoints System Architecture Diagram
3. BIA Data Collection
3.1 Determine Process and System Criticality
3.1.1 Table - Mission/Business Process Description
3.2 Identify Outage Impacts and Estimated Downtime
3.2.1 Table - Outage Impacts
3.2.2 Table - Mission/Business Impact Category
3.3 Estimated Downtime
3.3.1 Table - Estimated Downtime
3.4 Identify Resource Requirements
3.4.1 Table - System Resource Requirements
3.5 Identify Recovery Priorities for System Resources
3.5.1 Table - RTO Priority Table
This BIA (Business Impact Analysis) is developed as part of the contingency planning process for Touchpoints.
The purpose of the BIA is to identify and prioritize system components by correlating them to the mission/business process(es) the system supports, and using this information to characterize the impact on the process(es) if the system were unavailable.
The BIA is composed of the following three steps:
- Determine mission/business processes and recovery criticality. Mission/business processes supported by the system are identified and the impact of a system disruption to those processes is determined along with outage impacts and estimated downtime. The downtime should reflect the maximum that an organization can tolerate while still maintaining the mission.
- Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the resources required to resume mission/business processes and related interdependencies as quickly as possible. Examples of resources that should be identified include facilities, personnel, equipment, software, data files, system components, and vital records.
- Identify recovery priorities for system resources. Based upon the results from the previous activities, system resources can more clearly be linked to critical mission/business processes. Priority levels can be established for sequencing recovery activities and resources.
This document is used to build the Touchpoints Information Security Contingency Plan (ISCP) and is included as a key component of the ISCP. It also may be used to support the development of other contingency plans associated with the system, including, but not limited to, a Disaster Recovery Plan or Incident Response Plan.
Touchpoints is a web application designed and created to support Customer Experience (CX) initiatives across the federal government by streamlining the customer feedback and reporting process. Touchpoints is managed and operated by the GSA’s Federal Acquisition Service (FAS) Technology Transformation Services (TTS) Office of Products and Programs (OPP) in the Data Portfolio’s Feedback Analytics Program. The current version of the Touchpoints application is live at https://touchpoints.app.cloud.gov.
Touchpoint’s architecture is represented as follows:
The Touchpoints application team collected the information in this BIA.
No client communication was needed; all pertinent information was gathered internally.
Step one of the BIA process - Working with input from users, managers, mission/business process owners, and other internal or external points of contact (POC), identify the specific mission/business processes that depend on or support the information system.
Table 3.1.1 lists the mission/business processes dependent upon Touchpoints for support.
| Mission/Business Process | Description |
|---|---|
| Public users can submit feedback | Public users provide feedback based on public services they've experienced |
| Users can manage a list of Services | Organization Managers can manage a list of Services |
| Users can manage a list of Touchpoints | Service Managers can manage a list of Touchpoints |
| Users can create Forms for customer feedback | Primary use of Touchpoints. Forms are displayed at a Touchpoint, which is a defined location within a defined digital public Service. Public users submit feedback on forms. |
| Users can review feedback Submissions | Service Managers review Submission responses in full. |
| Users can analyze feedback Submissions | Service Managers can export .CSV files for detailed analysis. |
| Users can generate CX reports of feedback Submissions | Service Managers can export .CSV files that comply with CX Service Design specification for CX CAP Goal A-11 Reporting. |
This section identifies and characterizes the types of impact categories that a system disruption is likely to create in addition to those identified by the FIPS 199 impact level, as well as the estimated downtime that the organization can tolerate for a given process. Impact categories should be created and values assigned to these categories in order to measure the level or type of impact a disruption may cause.
The following impact categories represent important areas for consideration in the event of a disruption or impact.
| Impact Category | Severe | Moderate | Minimal |
|---|---|---|---|
| Public users can submit feedback | x | ||
| Users can manage a list of Services | x | ||
| Users can manage a list of Touchpoints | x | ||
| Users can create Forms for customer feedback | x | ||
| Users can review feedback Submissions | x | ||
| Users can analyze feedback Submissions | x | ||
| Users can generate CX reports of feedback Submissions | x |
The table below summarizes the impact on each mission/business process if Touchpoints were unavailable, based on the following criteria:
| Mission/Business Process | User Satisfaction | Policy Compliance | Reputational Impact | Impact |
|---|---|---|---|---|
| Public users can submit feedback | Minimal | Moderate | Minimal | Moderate |
| Users can manage a list of Services | Minimal | Minimal | Minimal | Moderate |
| Users can manage a list of Touchpoints | Minimal | Minimal | Minimal | Minimal |
| Users can create Forms for customer feedback | Minimal | Moderate | Minimal | Moderate |
| Users can review feedback Submissions | Minimal | Moderate | Minimal | Moderate |
| Users can analyze feedback Submissions | Minimal | Moderate | Minimal | Moderate |
| Users can generate CX reports of feedback Submissions | Minimal | Moderate | Minimal | Moderate |
Working directly with mission/business process owners, departmental staff, managers, and other stakeholders, estimate the downtime factors for consideration as a result of a disruptive event.
- Maximum Tolerable Downtime (MTD). The MTD represents the total amount of time leaders/managers are willing to accept for a mission/business process outage or disruption and includes all impact considerations. Determining MTD is important because it could leave continuity planners with imprecise direction on (1) selection of an appropriate recovery method, and (2) the depth of detail which will be required when developing recovery procedures, including their scope and content.
- Recovery Time Objective (RTO). RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD. Determining the information system resource RTO is important for selecting appropriate technologies that are best suited for meeting the MTD.
- Recovery Point Objective (RPO). The RPO represents the point in time, prior to a disruption or system outage, to which mission/business process data must be recovered (given the most recent backup copy of the data) after an outage.
The table below identifies the MTD, RTO, and RPO (as applicable) for the organizational mission/business processes that rely on Touchpoints. Values for MTDs and RPOs are expected to be specific time frames, identified in hourly increments (i.e., 8 hours, 36 hours, 97 hours, etc.).
| Mission/Business Process | MTD | RTO | RPO |
|---|---|---|---|
| Public users can submit feedback | 48 hours | 24 hours | 24 hours |
| Users can manage a list of Services | 48 hours | 24 hours | 24 hours |
| Users can manage a list of Touchpoints | 48 hours | 24 hours | 24 hours |
| Users can create Forms for customer feedback | 48 hours | 24 hours | 24 hours |
| Users can review feedback Submissions | 48 hours | 24 hours | 24 hours |
| Users can analyze feedback Submissions | 48 hours | 24 hours | 24 hours |
| Users can generate CX reports of feedback Submissions | 48 hours | 24 hours | 24 hours |
The estimated downtime objectives mentioned above are performance metrics and may relate to Service Level Agreements specified in Terms of Service agreements.
Federal Agency customers can use latest downloaded .csv files to fulfill reporting obligations.
The following table identifies the resources that compose Touchpoints including hardware, software, and other resources such as data files.
Reference the Table 10-2 Software Assets in the Touchpoints LATO SSP.
A complete list of plugins, extensions, and third party libraries
can be reviewed under the Touchpoints repository on Github: https://github.com/gsa/touchpoints.
Touchpoints uses a 3rd party dependency scanning service called Snyk to identify CVEs, Versions, and for 3rd party packages and libraries.
Access to which can be granted on a need to know basis.
It is assumed that all identified resources support the mission/business processes identified in Section 3.1 unless otherwise stated.
The table below lists the order of recovery for Touchpoints resources. The table also identifies the expected time for recovering the resource following a "worst case" (complete rebuild/repair or replacement) disruption.
| Priority | System Resource/Component | Recovery Time Objective |
|---|---|---|
| 1 | Cloud.gov | 24 hours |
| 2 | Login.gov | 24 hours |
| 3 | Database | 12 hours |
| 4 | Web app 1-4 | 4 hours |
| 5 | Redis | 6 hours |
| 6 | Amazon S3 | 12 hours |
| 7 | Amazon SES | 12 hours |