01Purpose & Scope

This document consolidates continuity and contingency protocols for the Web Development team within the Office of Information Technology. It addresses four distinct risk categories:

• Staff turnover and succession — ensuring institutional knowledge is not lost when personnel change
• System outages and disaster recovery — defining response procedures for critical platform failures
• Budget or organizational disruption — outlining response strategies for resource or structural changes
• Institutional compliance — providing documentation sufficient for HR, audit, and accreditation review

This plan covers all systems and platforms owned or operated by the Web Development team and applies to all current team members.

02Team Structure

03Systems Inventory & Criticality

Criticality Definitions

• Critical — Failure directly disrupts institutional operations or public-facing services
• High — Failure significantly degrades team productivity or cross-team coordination
• Medium — Failure affects specific workflows but does not disrupt primary operations
• Low — Failure has minimal operational impact; restoration can be scheduled

Recovery Priority Definitions

• P1 — Restore within 4 business hours; active response required immediately
• P2 — Restore within 1 business day; response begins within 4 hours

04Knowledge Concentration Risk

The following areas represent current gaps in documentation or coverage:

• DNS access — DNS is currently managed exclusively by the CIO. The Web Team has server-level access sufficient to affect site availability but no corresponding ability to resolve DNS-related outages. A defined, supervised change pathway for DNS records — even a limited one — would ensure recovery does not depend on a single point of contact during an incident.
• Vendor relationships — The Team Lead is the primary contact for Beacon (current hosting). TAM and customer success manager contacts for Beacon are not yet documented for team access. Primary contact for WPEngine/5by5 is not yet established.
• Banner integration configurations — Integration code is in the team repository (accessible to Tony Bush and Bobby Martin), but lacks adequate documentation for independent troubleshooting or hand-off.
• Slate integration configurations — Tony Bush is the primary specialist; documentation of configuration and dependencies is incomplete.
• Backup procedures — No formal backup process is documented for the una.edu MySQL database, which is used for Open Alabama reporting. Current backups exist only on the Team Lead's machine. This is a gap requiring action.
• apps.una.edu failover — No failover strategy currently exists for apps.una.edu. A failover plan is in development for the new site, which will likely be hosted on WPEngine.
• unasites.com and American Cloud services — Recovery procedures for apps.una.edu's hosting environment are not documented.
• smallbusinessadvocate.una.edu — No documented response procedure or escalation path exists for this application.

05Succession & Coverage Protocols

5.1 Planned Absence (Vacation, Leave)

Prior to any planned absence exceeding three business days, the Team Lead will:

1. Identify a temporary point of contact from the developer team
2. Brief that developer on any time-sensitive in-flight work
3. Ensure emergency credential access procedures (Section 8) are confirmed active
4. Notify the ERP Manager of the coverage arrangement

5.2 Unplanned Absence (Short-Term)

For unplanned absences expected to be fewer than five business days:

1. The available senior developer assumes day-to-day ticket and support queue management
2. Development and deployments continue normally
3. Emergency access to credentials is available via the procedure in Section 8

5.3 Academic Break & Holiday Coverage

During extended academic breaks (Spring Break, Summer, Thanksgiving, Winter Break), the team follows a structured on-call approach to ensure systems are monitored and recoverable without requiring everyone to remain available.

Pre-Break Checklist

• Confirm all monitored systems are stable; review the #alerts channel for any unresolved issues
• Verify uptime monitoring is active for apps.una.edu and smallbusinessadvocate.una.edu
• Ensure no deployments or pending updates are scheduled during the break period
• Confirm the on-call designee has access to all credentials needed for first-response recovery

On-Call Rotation

• One team member is designated as the primary on-call responder for each break period
• Responsibility rotates across the team across the academic year so no single person carries it repeatedly
• The on-call designee is not expected to be at a desk, but must be reachable and able to respond within a reasonable window

Response Expectations During Breaks

• Response times are longer than normal business hours — this is expected and acceptable
• Requires prompt attention: una.edu or apps.una.edu is down; a P1 system is unreachable
• Can wait until return: minor display issues, non-critical support requests, low-priority alerts

Escalation During Breaks

1. On-call designee attempts first-response recovery
2. If unresolved, escalate to Team Lead
3. If Team Lead is also unreachable, escalate to ERP Manager

5.4 Risk: Loss of a Developer

Immediate Response (0–30 Days)

• Redistribute ticket queue across remaining developers, prioritizing compliance-critical and production-impacting issues
• Team Lead assumes additional development capacity for active projects
• Document all in-flight work before any departure

Short-Term (30–90 Days)

• Begin posting for a replacement; leverage the UNA CS program for student worker or graduate assistant pipeline as bridge capacity
• Evaluate which active projects can be deferred versus which require external contractor engagement

Mitigation (Ongoing)

• Maintain living documentation for all active projects, integrations, and credentials
• Cross-train developers on critical systems (Slate integrations, deployment workflows)
• No single developer should be the sole owner of any production system

5.5 Extended or Permanent Departure / Loss of Team Lead

Immediate Response (0–30 Days)

• ERP Manager assumes interim oversight
• Senior developer steps into a lead capacity for daily operations and ticket triage
• Active projects should be documented and in a state where hand-off is possible within 72 hours

Short-Term (30–90 Days)

• ERP Manager initiates search for replacement or evaluates internal promotion pathway
• Team continues in maintenance mode, deferring new initiatives until leadership is stabilized
• Vendor and integration contacts documented and accessible to ERP Manager

Mitigation (Ongoing)

• Maintain a Team Lead operational runbook covering system architecture, vendor contacts, and active project statuses
• Ensure secondary 1Password admin (Lee) has documented access to all critical credentials

06Budget Cuts or Organizational Restructuring

Scenario A: One Position Eliminated

• Consolidate to two developers; Team Lead increases direct development contribution
• Defer new application development; focus on WCAG compliance, una.edu maintenance, and existing platform obligations
• Engage UNA CS department for paid student worker support as a cost-effective bridge

Scenario B: Team Dissolved or Merged

• Document all institutional knowledge: system credentials, integrations (Banner, Slate, Microsoft Entra), deployment environments, and active contracts
• Advocate to ERP Manager for retaining at minimum one technical FTE to manage una.edu and contractual obligations

Scenario C: Budget Freeze, No Reductions

• Pause discretionary tool and platform spend
• Prioritize: WCAG compliance (regulatory/legal exposure) and production stability
• Defer: new application development and non-critical redesign work

Mitigation (Ongoing)

• Maintain clear ROI documentation for team initiatives (cost avoidance, compliance risk reduction, enrollment-facing impact)
• Tie team value to institutional strategic priorities: enrollment, compliance, and operational efficiency

07Incident Response & Disaster Recovery

7.1 una.edu Outage

una.edu runs on Cascade CMS. Bobby Martin and Tony Bush have access via 1Password.

7.2 apps.una.edu Outage

apps.una.edu is a WordPress site hosted via CloudPanel on unasites.com, running on American Cloud infrastructure. Credentials for American Cloud and CloudPanel are in 1Password.

Note: No failover strategy currently exists for apps.una.edu. A failover plan is in development for the new site, which will likely be hosted on WPEngine.

When the una.edu redesign launches, WPEngine (with 5by5 support) will serve as the hosting provider for all WordPress sites and response procedures will be updated accordingly.

7.3 smallbusinessadvocate.una.edu Outage

smallbusinessadvocate.una.edu is a third-party hosted application. Uptime monitoring is active; alerts are delivered to the #alerts Slack channel.

7.4 Monitoring

Uptime monitoring is active for the following systems; alerts are delivered to the #alerts Slack channel:

• apps.una.edu
• smallbusinessadvocate.una.edu

7.5 SSO / Microsoft Entra Outage

Mitigation

• Document all registered applications and their redirect URIs
• Maintain break-glass accounts for critical systems where technically feasible

7.6 Data Loss Event

1. Immediately suspend write access to the affected system to prevent further data corruption
2. Notify ERP Manager within 1 hour of confirmed data loss
3. Engage backup restoration process; assess scope of loss against last clean backup

Mitigation Targets

• Backup retention policy (target): daily for 30 days, weekly for 6 months
• Backups tested quarterly via restoration drill
• No production data stored exclusively in a single environment

08Credential & Access Management

8.1 Credential Coverage Matrix

8.2 1Password Administration

The Team Lead holds primary admin access. Lee holds secondary admin access. The following steps are required to complete coverage:

• Configure 1Password Emergency Kit and store a physical copy in a secure, institutionally-controlled location (e.g., ERP Manager's office)
• Confirm the ERP Manager has documented knowledge of the emergency access procedure

8.3 Credential Hygiene Standards

• All team credentials are managed exclusively through 1Password — no credentials stored in email, Slack, or personal password managers
• When any team member departs, credentials they had individual access to are rotated
• To minimize rotation scope on departure, access should be scoped appropriately — not all team members require access to all platforms; restrict access to what each role actually needs
• Shared credentials are documented with purpose and scope in 1Password notes

09Vendor Relationships

10Knowledge Transfer Plan

Phase 1 — Immediate (0–30 Days)

• Establish a documented backup process for una.edu database and apps.una.edu WordPress; move backups off Team Lead's local machine to an off-site or institutionally managed location
• Document apps.una.edu infrastructure: CloudPanel configuration, American Cloud environment, and SSO/Entra setup
• Document Beacon TAM and customer success manager contacts
• Document response procedure for smallbusinessadvocate.una.edu outages, including third-party contact and escalation path
• Add Tony Bush and Bobby Martin to Claude access
• Record a walkthrough video of critical systems for team reference

Phase 2 — Near-Term (30–90 Days)

• Cross-train at least one developer on WordPress database backup and restoration
• Document all active Banner integration configurations (code is accessible in GitHub; prose documentation does not exist)
• Document all active Slate integration configurations
• Draft runbooks for the five most common support scenarios
• Document response procedure for SSO/Entra failure on apps.una.edu

Phase 3 — Ongoing

• All new systems must be documented before going into production
• Knowledge transfer is a standing agenda item in team check-ins
• This plan is reviewed and updated quarterly

11Plan Maintenance

This plan should be treated as a living document. Any significant change to team structure, systems, or platforms triggers an immediate update to the relevant sections.

ADefinitions

• RTO (Recovery Time Objective) — The maximum acceptable time to restore a system after failure
• Runbook — A documented, step-by-step procedure for a specific operational task
• Entra — Microsoft Entra ID, used for SSO across internally developed applications
• CloudPanel — Server management panel used to host apps.una.edu on American Cloud infrastructure
• 1Password — Team credential and secrets management platform
• Open Alabama — State reporting platform; the una.edu database is used primarily to support Open Alabama reporting