Quick Overview
- This standard sets the specific requirements for how SFA keeps critical systems and services running (business continuity) and gets them back after a disruption or disaster (disaster recovery).
- It carries out the goals in the SFA 06-107.2 Information Security Technology Policy.
- Most requirements are carried out by system owners and IT and security teams, not by general users.
- It covers planning, alternate sites and capacity, impact analysis, and backups.
- These requirements are the minimum baseline SFA must meet; the university may choose to do more.
- Meeting this standard is mandatory unless a formal exception is granted.
Things go wrong: hardware fails, storms hit, systems get attacked, and buildings lose power. This standard spells out
what SFA must do to be ready. It requires written plans for keeping essential functions going and recovering the ones that
stop, backup and alternate locations so data and services are not lost if the main site goes down, a clear understanding of
how long each critical function can be offline, and reliable, protected backups that can actually be restored. The goal is
simple: when something disrupts SFA, the university can keep operating and bounce back quickly without losing important data.
|
i
|
Policy vs. Standard
The matching policy (06-107.2) says what SFA wants to achieve. This standard says how, the concrete requirements. Day-to-day steps live in procedures.
|
Who This Applies To
This standard applies to all SFA employees, users, third-party service providers, research partners, and other authorized users
of SFA information resources, including authorized vendors, visitors, and contingent workers who work within SFA IT facilities.
In practice, the requirements below are carried out mostly by the people who own and run SFA's systems: system and application
owners, IT and facility teams, the CISO, the Office of Information Security, and business continuity and disaster recovery teams.
|
i
|
Baseline, not a ceiling
Everything here is the minimum SFA must do. Departments may add stricter requirements, but never anything weaker. See the SFA 06-107 Controls Crosswalk for higher control tiers.
|
Who Is Responsible
Key roles & responsibilities
⌄
A note on names: At SFA, the senior information security role is the Chief Information Security Officer (CISO). There is no separate "Information Security Officer" position. The abbreviation ISO at SFA refers to the Office of Information Security (the office that supports the CISO), not to a person.
- CISO and the Office of Information Security: Develop, implement, enforce, review, and update business continuity and disaster recovery plans, working with resource owners, Privacy Officers, and compliance and risk teams.
- Privacy Officers (PO): Make sure plans keep meeting privacy and regulatory obligations and coordinate communication with stakeholders when data privacy is affected. (Some Privacy Officers may also hold legal or compliance roles; the title is meant to be flexible.)
- Information Resource / Application / Asset Owners (IRO): Identify critical assets, set recovery objectives, build backups and alternate sites, assign an owner for each backup, and test and validate recovery.
- Incident Response Teams: Notify and coordinate with continuity and recovery teams when an incident calls for activating a plan.
- Business Continuity & Disaster Recovery Teams: Coordinate response and recovery during and after a disruption, and update plans based on lessons learned and changing risks.
- Compliance / Risk Management Teams: Review and test plans to keep risk at tolerable levels.
- Security Training Leads: Build and run continuity and recovery training with learning and development teams.
Full role definitions
Complete responsibilities for each role are in the attached standard PDF.
What This Standard Requires
The requirements are grouped into four areas. Expand any area for a plain-language summary of what it requires.
The official requirement numbers (like 06-107.2.4.1.1) are shown so you can match them to the attached PDF.
1 Business Continuity & Disaster Recovery Planning
Write the plan, test it, train on it
⌄
SFA must write, protect, test, and keep up to date the plans that keep essential functions running and restore the ones that stop.
- Develop and document business continuity and disaster recovery plans that identify essential functions and recovery requirements, set recovery objectives and priorities, name responsible people with contact details, restore systems without weakening controls, cover sharing of contingency information, keep an offsite copy, and are reviewed and approved; give plan access only to those with a need to know; and review and update the plans at least every 12 months or sooner when the organization, systems, or environment change, or when problems come up in testing (06-107.2.4.1.1).
- Identify, document, and coordinate with the specific people and groups who must be involved in planning, implementing, and testing the plans (06-107.2.4.1.2).
- Test the plans using a risk-based approach at least every 12 months (covering all critical functions at a minimum), then review results, fix issues, and fold in lessons learned, with clear objectives for what each test is meant to verify (06-107.2.4.1.3).
- Provide continuity and recovery training to the right people at least every 12 months, using hands-on drills and/or discussion-based exercises like tabletops; an actual plan activation can count as training (06-107.2.4.1.4).
- Use automated tools where feasible to test contingency plans more thoroughly and evaluate recovery capabilities (06-107.2.4.1.5).
- Define failure conditions for mission-critical and high-risk systems and set up automatic fail-safe procedures so systems fail into a known, secure state that protects the confidentiality, integrity, and availability of data (06-107.2.4.1.6).
2 Capacity Management / Alternate Sites
A backup place to run and store things
⌄
SFA must set up and maintain alternate locations and communication methods so work can continue if the primary site is unavailable.
- Establish alternate storage sites sized to the plans' capacity needs, with controls and access protections equal to those at the primary site (06-107.2.4.2.1).
- Build a strategy for maintaining alternate processing sites, storage sites, and telecommunications that supports the defined recovery requirements (06-107.2.4.2.2).
- Build a strategy for testing those alternate sites and telecommunications at a frequency the institution sets (06-107.2.4.2.3).
- Maintain alternate communication methods (for example mass-notification systems, instant messaging, conference bridges, email, or radio) for use when normal channels are down (06-107.2.4.2.4).
- Configure the alternate storage site so information and systems can be recovered within the recovery time objectives (RTO, how fast) and recovery point objectives (RPO, how recent) set by the impact analysis (06-107.2.4.2.5).
- Require primary and alternate telecom providers for mission-critical functions to keep contingency plans, review those plans where possible, and confirm they meet SFA's continuity requirements (06-107.2.4.2.6).
3 Impact Analysis
How long can each function be down?
⌄
SFA must understand and record how much downtime and data loss each critical function can tolerate.
- Identify and record in asset inventories the continuity objectives for mission and business functions, including acceptable interruption length, maximum tolerable outage, recovery time objective (RTO), and recovery point objective (RPO) after a plan is activated, at a minimum for all critical functions (06-107.2.4.3.1).
4 Backup Methods
Reliable, protected, restorable copies
⌄
SFA must back up critical data and systems in a protected way and be able to restore them cleanly after a problem.
- Work with asset and application owners to back up critical resources in line with the defined RTOs and RPOs, using unmodifiable or offline backups with encryption and multi-factor authentication where feasible, at appropriate frequencies, and with protections for the backups' confidentiality, integrity, and availability (06-107.2.4.4.1).
- Recover or restore all critical systems to their previous known-good state after an incident, disruption, compromise, or failure, using the defined processes and RTOs and RPOs (06-107.2.4.4.2).
- Define and implement protections for all critical system components used for recovery and reconstitution (06-107.2.4.4.3).
- For mission-critical systems, keep backups on a redundant secondary system that is not in the same location as the primary and can be activated without losing data, sized to the resource's risk and value (06-107.2.4.4.4).
- Implement transaction recovery for transaction-based systems (such as databases) so in-process transactions can be restored to a consistent state after a disruption, failure, or compromise (06-107.2.4.4.5).
Conformance & Exceptions
Meeting this standard is mandatory and effective as of the standard's publication, unless a written contract says otherwise
or a formal exception has been granted. If a requirement genuinely can't be met and there's no feasible remediation, follow the exception
process in the SFA 06-107.2 Information Security Technology Policy; requests go to the SFA Chief Information Security Officer (CISO).
|
!
|
Important
Violations of SFA 06-107 may lead to disciplinary action, up to and including involuntary separation from employment.
|
Compliance Mapping (Reference)
For auditors and security staff. Everyday users can skip this section.
Frameworks & control references
⌄
Each requirement in this standard maps to one or more of these authoritative sources:
- NIST 800-53 Rev 5.1.1, mainly the CP (Contingency Planning) family, plus SC-36, SI-13, and SI-17.
- TAC 202, for example 202.74 and 202.76.
- Texas DIR Security Controls Catalog, for example CP-2, CP-4, CP-6, CP-8, CP-9, CP-10, CP-11, SC-36, SI-17.
- UTS 165 (for example 6.1, 6.2, 17.1, 19.5, 22.4, 22.5).
- NIST CSF and NIST 800-171, and privacy and financial frameworks (HIPAA, GLBA) where relevant.
The full requirement-by-requirement control mapping is in the attached standard PDF and the SFA 06-107 Controls Crosswalk.
Related Policies & Standards
Supporting policy: SFA 06-107.2 Information Security Technology Policy
Related standards:
Other references:
- UTS 172 Emergency Management Policy
- SFA 06-107 Controls Crosswalk Reference
Responsible office: Office of Information Security ·
Contact: itsecurity@sfasu.edu
|
📎
|
Official document
The complete, official standard is attached to this article as a PDF, including its full requirement text, role definitions, and control mappings. This article summarizes that standard in plain language. If anything in this article conflicts with the attached PDF, the PDF is the official version and takes precedence.
|
Need Help?
Contact the IT Help Desk at
(936) 468-4357 (HELP) or submit a ticket at
help.sfasu.edu.
For questions about this standard, contact the Office of Information Security at
itsecurity@sfasu.edu.