Synoptix Business Continuity Plan (BCP)

1. Purpose

This Business Continuity Plan (BCP) documents Synoptix’s strategy and procedures to ensure continuity of critical business functions during and after a disruptive event (natural disaster, data-center outage, cyber incident, pandemic, prolonged third-party outage, loss of key personnel, etc.). The BCP’s goals are to:

• Protect people and assets;
• Maintain or promptly resume critical services with predefined Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs);
• Minimize financial, legal, and reputational impact;
• Communicate clearly and consistently to employees, customers, partners, and regulators; and
• Return Synoptix operations to normal in a controlled, prioritized way.

This plan supplements (and must be used in coordination with) Synoptix’s Security Incident Response Program, Information Security Program, Access Control Policy, and Media Use & Handling Policy.

2. Scope

Applies to all Synoptix business units that contribute to delivering customer-facing services and critical internal operations, including:

• Production application and database services (Synoptix Cloud and any customer-hosted integrations);
• Support, Sales, and Professional Services functions required to support customers;
• Corporate functions that impact service availability (IT/Infrastructure, DevOps, DBA);
• Third-party vendors and service providers that are required for business continuity (cloud providers, data center partners, critical SaaS providers);
• Physical offices and locations where critical staff perform work.

3. Objectives & Recovery Targets

3.1 Objectives

• Restore critical customer-facing services and support operations with minimal disruption.
• Protect customer data integrity and confidentiality during recovery.
• Keep affected customers and stakeholders informed with timely and accurate communications.
• Validate system health before returning to normal operations.

3.2 RTO / RPO (Target)

These targets align with Synoptix’s InfoSec and DR plans:

Note: Exact RTO/RPO for customer-specific environments may vary by contract and hosting choice (customer-managed vs Synoptix Cloud). Always consult the customer contract/DPA.

4. Plan Activation & Authority

4.1 Activation Criteria

BCP is activated when a disruption meets one or more of the following:

• Production service unavailable or degraded beyond acceptable SLA thresholds;
• Confirmed data-center outage impacting Synoptix Cloud hosting of customer data;
• Confirmed ransomware or severe cyber intrusion affecting availability or integrity of systems;
• Office or site closure preventing key staff from performing duties for more than 8 hours;
• Loss of a key vendor critical to service delivery (e.g., primary cloud provider region down);
• Any other event declared by Executive Sponsor or IRT as materially impacting business operations.

4.2 Decision Authority

• IRT Lead / Incident Commander: Initially evaluates and recommends BCP activation (i.e., the Incident Response Team Lead or designated DevOps/Infrastructure Manager).
• Executive Sponsor (CEO): Authorizes formal activation of the BCP and public/customer notifications when required.
• On-Call Senior Management: Executes strategic decisions if Executive Sponsor unavailable.

5. Roles & Responsibilities

6. Critical Functions & Dependencies

Identify dependencies and single points of failure.

6.1 Critical Functions

• Production application/service hosting (Synoptix Cloud)
• Production databases and backups
• Customer integrations (ERP connectors)
• Support ticketing and customer communications
• Identity & access management (AD/SSO, MFA)
• Network connectivity and DNS

6.2 Key Dependencies (Third-Party)

• Primary cloud/data-center provider (hosting provider: e.g., AWS/Azure or equivalent)
• DNS provider and CDN (if used)
• Email provider and ticketing system (support portal)
• Backup & off-site storage vendor/courier for physical media
• Key third-party integrations used by customers (ERP endpoints)

7. Recovery Strategies & Playbooks

This section provides high-level runbooks for typical scenarios. Each runbook has: detection → activation → containment → recovery → validation → communication → lessons learned.

Important: When a security incident is involved (ransomware, confirmed intrusion), run this plan in close coordination with the Security Incident Response Program — prioritize containment and forensic preservation.

7.1 Data Center / Cloud Region Outage (Primary Region Failure)

Detection: Cloud provider reports region outage, or internal monitors show service unavailability.

Activation: IRT Lead recommends BCP activation; Exec Sponsor authorizes.

Immediate Actions (0–1 hour)

1. Declare Incident Commander and open War Room channel.
2. Notify Exec Sponsor and BCC.
3. Confirm the scope and affected customers/services.

Containment & Failover (1–4 hours)

4. If multi-region architecture exists: initiate failover to secondary region (DNS failover or provider failover).

5. If no automatic failover, restore the most recent clean backup to DR/staging region and bring services online.

6. Rotate/verify credentials for any restored systems.

Recovery & Validation (4–24 hours)

7. Run smoke tests against restored services; validate essential transactions and data integrity.

8. Monitor logs closely for anomalies.

Communication

9. Send initial customer notification within 4 hours (if customers impacted) and update every 4–8 hours until services restored.

10. Prepare public statement if broad customer base impacted.

Post-Recovery

11. Conduct Lessons Learned and update failover playbook; schedule any remediation (e.g., improve multi-region strategy).

7.2 Ransomware / Massive Data Corruption

Detection: Unusual file encryption events, external notification of ransom demand, or data integrity failures.

Activation: Immediate BCP + IR Program activation; include Legal.

Immediate Actions (0–1 hour)

1. Isolate infected systems (remove from network); disable backups from being overwritten.
2. Collect forensic evidence (do not power down systems if that would destroy volatility needed for analysis — follow IR playbook).
3. Notify Exec Sponsor, Legal, and external counsel as appropriate.

Containment & Eradication (1–24 hours)

4. Restore affected systems from the most recent clean backups (verify pre-compromise snapshot).

5. Rotate credentials (esp. admin keys and service accounts).

6. Apply patches and remediation to close the exploited vector.

Recovery & Validation (24–72 hours)

7. Validate data integrity and system behavior. Run extensive testing before re-enabling integrations.

8. Coordinate with customers about data exposure, remediation steps, and recommended actions (password rotations, logs review).

Communication & Reporting

9. Notify affected customers and regulators as required (within 48 hours of confirmation per Synoptix IR Program).

10. Prepare public communication only after Legal/Exec sign-off.

Post-Recovery

11. Conduct an in-depth post-mortem; update DR backup cadence and offline/immutable backups strategy.

7.3 Wide Network Outage / ISP Failure

Detection: Loss of internet connectivity for corporate office or primary network paths.

Activation: Partial BCP activation for affected worksite or service.

Immediate Actions

1. Confirm outage scope (office-only vs cloud provider vs ISP).
2. If office-only: instruct staff to work remotely via personal networks (secure VPN required). Provide mobile VPN instructions and any emergency credentials.
3. If ISP affecting hosting: follow cloud provider outage playbook.

Recovery

4. Use alternate ISP or cellular-based internet to re-establish minimal operations (hotspotting for critical staff).

5. Prioritize support and customer communications.

7.4 Loss of Key Personnel

Detection: Key employee unexpectedly unavailable (sudden resignation, illness, travel incident).

Activation: BCP team coordinates continuity; consider temporary role reassignment and knowledge transfer.

Immediate Actions

1. HR notifies IT and InfoSec (standard practice described in Offboarding).
2. Reassign essential tasks to pre-identified backups (delegation matrix).
3. Ensure credentials are not compromised; rotate if needed.

Recovery

4. Reassign projects and update schedule. Consider temporary contractor support if backlog risks continuity.

7.5 Pandemic / Widespread Office Closure

Detection: Government orders or elevated risk makes office inaccessible.

Activation: BCP for pandemic mode: prioritize remote work, critical staffing, and mental-health supports.

Immediate Actions

1. Enforce mandatory remote-work configuration: ensure MFA, VPN posture, and device posture checks.
2. Prioritize on-call rotations and critical function staffing (minimize human dependence on single individuals).
3. HR communications and welfare check-ins.

Recovery & Return to Work

4. Staged return to office based on local rules and Executive Sponsor guidance.

8. Backups & Alternate Operations

8.1 Backup Strategy

• Nightly backups for transactional databases (retained per InfoSec Program: 30 days), with longer retention for configuration/source-code (90 days).
• Off-site/offline backups stored encrypted with chain-of-custody for physical transfers.
• Use immutable snapshots or offline copies where feasible to protect against ransomware.

8.2 Alternate Sites & Remote Work

• Synoptix supports remote work as the primary alternate workspace; critical staff must have company-issued, encrypted devices and VPN access (see Access Control Policy).
• For extended on-site requirement, identify third-party co-working or secondary office space options; maintain vendor contacts and agreements in Appendix A.

8.3 DNS & Failover

• Maintain TTL values and failover procedures for DNS updates. Document DNS provider credentials in the KMS with dual control.
• Use CDN or provider-managed failover when feasible to reduce RTO for public endpoints.
‍

9. Communications Plan

9.1 Communication Principles

• Timely, transparent, factual, coordinated with Legal and Exec Sponsor.
• Use pre-approved templates for internal, customer, and public communications to ensure consistency.
• Designate a single point of contact for media inquiries.

9.2 Notification Templates (examples)

Internal — Initial Alert

Subject: [BCP] Incident Declared — [Brief Title]

Team,

An incident affecting [service/office] was detected at [time]. The Incident Commander is [name]. BCP is activated. Do not take independent actions that may interfere with recovery. Standby for further instructions via [War Room link / Slack channel].

— [Executive Sponsor / IRT Lead]

‍

Customer — Initial Notification (impacted customers only)

Subject: Synoptix Service Notification — [Service Name] outage

Hello [Customer Name],

We are investigating an incident impacting [service]. Our Incident Response and Infrastructure teams have activated our Business Continuity Plan and are working on recovery. We will provide an update within [X hours]. If you require immediate assistance, contact [support@synoptix.com / phone].

We apologize for the inconvenience and will follow up with next steps.

— Synoptix Support Team

‍

Public — If required

Short factual description, status, expected next update, contact/email.

(Legal reviews all external statements before publication.)

9.3 Update Cadence

• Initial notification within 4 hours for service-impacting incidents; follow-up updates every 4–8 hours until restored (or as agreed with Exec Sponsor).
• Use customer portal, email, and account managers for targeted communication.

10. Testing, Exercises & Maintenance

10.1 Testing Schedule

• Quarterly: DR technical tests for restoring backups to staging (DBA team).
• Semi-Annual: Tabletop exercises for War Room and communications (BCP team with Exec Sponsor).
• Annual: Full DR test simulating provider region failure and failover; include support communications and customer-notification simulation.

10.2 Test Objectives

• Validate RTO/RPO targets and procedure accuracy.
• Verify backups are recoverable and data integrity holds.
• Exercise communication procedures and escalation matrices.
• Identify staffing gaps and single-person dependencies.

10.3 Metrics & Reporting

• Document test outcomes and capture metrics: time-to-restore, missed steps, communication latency.
• Remediate findings with ownership and due dates; track until closed. Report quarterly to Executive Leadership.

10.4 Plan Maintenance

• BCP owner (BCC) reviews and updates the plan annually or after any major incident, organizational change, or failed drill.
• Update contact lists, vendor agreements, and vendor SLAs at least annually.

11. Recovery & Return-to-Normal Procedures

1. Validate: Confirm services meet functional and performance criteria; run acceptance tests.
2. Stabilize: Keep increased monitoring and log review for at least 72 hours post-recovery.
3. Communicate: Send a final “service restored” notification to customers and internal staff with summary of root cause and remediation timeline.
4. Remediate: Complete any outstanding remediation tasks (patching, configuration changes).
5. Post-Mortem: Within 10 business days, hold Lessons-Learned meeting (IR & BCP teams) and produce a Post-Incident Report with action items and owners.‍
6. Close: Confirm actions completed and formally close incident with Executive Sponsor sign-off.

12. Appendices

Appendix A — Contacts & Vendor Escalation (TEMPLATE)

(Populate with real contacts and keep in KMS / secure internal wiki)

• Executive Sponsor (CEO): David Andersen | 801-815-2877 | dandersen@synoptixsoftware.com
• Incident Commander / IRT Lead: Dan Weatbrook | 801-918-1676 | dweatbrook@synoptixsoftware.com
• Business Continuity Coordinator: Robby Hilder | 801-554-1416 | rhilder@synoptixsoftware.com
• Support Lead: Pete Alberico | 801-201-3202 | support@synoptixsoftware.com
• Infrastructure/DBA Lead: Denver Campbell | 801-608-4880 | dcampbell@synoptixsoftware.com
• Legal: Mike Black | 801-898-0341 | mblack@mbmlawyers.com
• Primary Cloud Provider (Account Rep): company | rep  | phone |  | emergency contact
• DNS Provider / Registrar: name | phone |  email | account admin
• Backup Vendor / Off-site Storage:  | phone | email | chain-of-custody contact

Appendix B — Quick Activation Checklist (for Incident Commander)

• Confirm detection & classify incident severity.
• Notify Executive Sponsor and BCC.
• Open War Room channel and incident ticket.
• Assign primary recovery leads: Infra/DBA, DevOps, Support, Communications.
• Implement immediate containment steps per scenario playbook.
• Initiate backup restore or failover (if required).
• Send initial customer notification (if impacted).
• Track all actions/times in the incident ticket.
• Schedule hourly updates for Exec Sponsor; 4-hour updates for customers.

Appendix C — Recovery Checklist (Technical)

• Validate last clean backup timestamp; confirm integrity.
• Provision DR infrastructure (cloud region/standby servers).
• Restore DB to DR environment; run DB consistency checks.
• Reconfigure application endpoints and credentials.
• Update DNS records and TTLs if required for failover.
• Run smoke tests of critical flows (login, data read/write, integrations).
• Validate monitoring & logging are active and collecting data.

Appendix D — Test Plan Template

• Objectives, Scope, Pretest checklist, Roles, Test steps, Success criteria, Rollback plan, Post-test report.

Appendix E — Communications Templates

• Include internal initial alert, customer initial/follow-up/final messages, press statement template, social media guidance (Legal to approve).

13. Related Documents

• Security Incident Response Program (V1.1) — tie to forensic & containment steps.
• Information Security Program (V1.0) — policies on encryption, backups, access control.
• Access Control Policy (V1.0) — identity & access procedures during recovery.
• Media Use & Handling Policy (V1.0) — handling of backup media and secure disposal.
• Customer-specific DPAs and SLAs — check contractual notification requirements.

14. Training & Awareness

• New hires get BCP overview during onboarding.
• Annual company-wide BCP refresher.
• Semi-annual tabletop exercise for managers and critical teams.
• Documented lessons from exercise and incident are distributed.

15. Revision History