SCC Incident Response Plan

SCC Governance Security & Compliance
1

1. Purpose

This Incident Response Plan establishes the processes the Specify Collections Consortium (SCC) uses to identify, analyze, contain, mitigate, and recover from security incidents affecting SCC systems or member data.

It ensures SCC protects the confidentiality, integrity, and availability of all systems and services, including Specify Cloud hosting, development infrastructure, and support systems.

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

Incidents covered include unauthorized access, data breaches, malware, vulnerability exploitation, data corruption, misconfigurations, insider misuse, denial-of-service, cloud provider outages, and credential compromise.

3. Incident Response Lifecycle

SCC follows a six‑phase lifecycle aligned with industry best practices.

3.1. Phase 1 — Preparation

SCC maintains readiness through:

Staff Training

Bi-annual training on secure coding and best practices

Technical Controls

  • Private subnets for databases

  • IAM least‑privilege roles

  • Dockerized, immutable deployments

  • Bitwarden for credential management

  • Automated monitoring of server availability

  • Nginx and Django access logs

  • Alerts routed to SCC staff during business hours

Backup & Recovery Readiness

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

Vulnerability Management

  • Quarterly milestone-based vulnerability review

  • GitHub security alerts

  • Immediate patching of critical vulnerabilities

  • Public release notes for patched vulnerabilities

3.2 Phase 2 — Identification

Detection Sources

Incidents may be detected through:

  • Monitoring alerts

  • Member reports via the Help Desk

  • GitHub vulnerability alerts

  • Unexpected downtime

Initial Triage

SCC staff determine:

  • Affected systems

  • Member data involvement

  • Stopped or ongoing status of incident

  • Necessity of immediate containment

3.3 Phase 3 — Containment

Containment actions may include:

Technical Containment

  • Isolate affected servers or containers

  • Block suspicious IP addresses

  • Revoke compromised credentials

  • Disable compromised services

  • Restrict access to backups

  • Temporarily disable automated processes

Communication During Containment

SCC staff informs members of:

  • containment actions

  • estimated timelines

  • recommended member actions

3.4 Phase 4 — Eradication

After containment, SCC eliminates the root cause:

Technical Remediation

  • Applies patches

  • Removes malicious files or processes

  • Rebuilds compromised containers

  • Updates configurations

  • Rotates credentials

  • Reviews IAM permissions

Vulnerability Remediation

If the incident involves a software flaw:

  • A GitHub issue is created

  • Severity is assigned

  • Fix is added to the current milestone

  • Patch is reviewed and tested

  • Fix is documented in release notes

Verification

  • Confirm that the vulnerability is fully resolved

  • Confirm that no additional systems are affected

3.5 Phase 5 — Recovery

System Restoration

  • Restore from backups

  • Validate system integrity

  • Re-enable services

  • Monitor for recurrence

Member Coordination & Data Validation

  • SCC staff notifies members when systems are restored

  • Members validate database completeness and asset integrity

  • SCC staff checks logs for anomalies after restoration

  • SCC staff provides a summary of recovery actions

3.6 Phase 6 — Post‑Incident Review

The SCC staff conducts a formal review including:

Documentation

  • Timeline of events

  • Root cause analysis

  • Impact assessment

  • Actions taken

  • Communication summary

  • Recommendations for improvement

SCC Policy & Process Reviews

  • Software Development Lifecycle documentation

  • Patch Management priorities

  • Monitoring thresholds

  • Access controls

  • Internal training

Member Summary Report

SCC staff shares a summary with the affected member institution.

4. Communication Protocols

Notification to Members

SCC staff notifies members of data incidents and confirmed breaches. Notifications include:

  • Summary of the incident

  • Systems affected

  • Data potentially involved

  • Containment actions

  • Next steps

External Communication

Members control external notifications unless legally required otherwise.

5. Integration with Other SCC Policies

This IRP integrates with:

6. Continuous Improvement

SCC improves incident response with:

  • Monitoring tools

  • Enhanced logging

  • Incident reviews

  • Documentation updates

  • Member feedback

7. Policy Review

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

Download this document as a pdf:
SCC Incident Response Plan.pdf (125.2 KB)