SCC Disaster Recovery Plan

SCC Governance Security & Compliance
1

1. Purpose

The SCC Disaster Recovery Plan establishes the procedures and responsibilities required to restore SCC systems and services following a disruptive event. The plan ensures that SCC can recover hosted environments, development infrastructure, and critical services in a timely and predictable manner. This plan supports SCC’s commitment to protect the confidentiality, integrity, and availability of member data.

This is supplementary to the expectation the SCC has of all member institutions to store or perform on-site local backups of all database contents and associated digital assets.

2. Scope

This plan applies to:

  • All SCC staff and contractors

  • SCC-managed cloud infrastructure

  • SCC-managed development, staging, and testing environments

  • SCC systems used for support, monitoring, and administration

  • Backup and recovery infrastructure

  • Events that disrupt availability, integrity, or functionality of SCC services

The plan covers disasters including but not limited to system failures, data corruption, cloud provider outages, security incidents, natural disasters, and human error.

3. Objectives

The objectives of the SCC Disaster Recovery Plan are to:

  • Restore hosted services within the defined Recovery Time Objective (RTO)

  • Minimize data loss within the defined Recovery Point Objective (RPO)

  • Maintain continuity of SCC operations

  • Protect member data from loss or corruption

  • Provide clear roles, responsibilities, and communication pathways

  • Ensure predictable and repeatable recovery procedures

5. Disaster Definition

A disaster is any event that significantly disrupts SCC operations or hosted services and cannot be resolved through normal incident response procedures. Examples include:

  • Loss of access to hosting provider resources

  • Corruption of production databases

  • Widespread asset storage failure

  • Extended cloud provider outage

  • Security incident requiring full environment rebuild

  • Natural disaster affecting SCC operational capacity

6. Recovery Priorities

SCC restores services in the following order:

Core hosting infrastructure

  • VPC, subnets, security groups, IAM roles, networking.

Database services

  • MariaDB instances, database restoration, schema validation.

Asset storage

  • S3 buckets or equivalent object storage.

Application services

  • Specify 7 containers, asset server, web portals, web server.

Monitoring systems

  • Uptime monitoring and alerting.

Support systems

  • Help Desk, documentation, communication channels.

7. Backup Strategy

SCC maintains a multilayered backup strategy described in full in the Database and Asset Hosting Service Level Agreement: SCC Hosting SLA

Backups include schema, data, and essential configuration files. Backups are stored in the same region as the hosted environment. Backups include automated integrity checks.

8. Recovery Time and Recovery Point Objectives

Recovery Time Objective (RTO)

SCC staff restores normal operations within three business days during Central Time business hours. Restoration is subject to incident severity, system dependencies, and operational capacity.

Recovery Point Objective (RPO)

Data loss is limited to changes made since the last valid backup. This is typically less than 24 hours.

9. Disaster Recovery Procedures

1. Notify Stakeholders

SCC staff notifies affected member institutions with:

  • Description of the issue

  • Expected recovery timeline

  • Any required member actions

2. Stabilize the Environment

SCC staff isolates affected systems, halts automated processes, and preserves logs for forensic analysis.

3. Restore Infrastructure

SCC staff rebuilds or reconfigures:

  • VPC

  • Subnets

  • Security groups

  • IAM roles

  • Load balancers

  • Reverse proxy configuration

4. Restore Databases

  • Deploy new MariaDB instance

  • Import the most recent valid SQL backup

  • Validate schema and data integrity

  • Apply required migrations

5. Restore Assets

  • Recreate asset storage buckets

  • Restore quarterly snapshot

  • Apply weekly incremental updates

6. Restore Application Services

  • Deploy Specify 7 containers

  • Deploy asset server

  • Validate application functionality

  • Reconnect application to restored database

7. Validate System Integrity

SCC staff verify:

  • Authentication and SSO

  • CRUD operations

  • Asset retrieval

  • Reporting

  • API functionality

  • Performance and stability

8. Member Validation

Members confirm:

  • Data completeness

  • Asset availability

  • Workflow functionality

9. Finish Recovery

SCC staff confirms full restoration and provides a summary report to members.

10. Communication Plan

SCC staff communicates with members through:

  • Email notifications

  • Status updates during recovery

  • Final restoration confirmation

  • Follow up documentation if required

SCC staff maintains transparency throughout the recovery process.

11. Post Recovery Review

Following an incident, SCC staff conducts a review that includes:

  • Timeline of events

  • Root cause analysis

  • Impact assessment

  • Effectiveness of recovery procedures

  • Required improvements

  • Updates to documentation

Findings are incorporated into future planning and training.

12. Plan Maintenance

SCC staff reviews this plan annually and updates as SCC infrastructure, hosting practices, and member needs evolve.

Download this document as a pdf:
SCC Disaster Recovery Plan.pdf (103.2 KB)