Business Continuity and Disaster Recovery (BCDR) Policy

AES ETL Control Panel for Microsoft Fabric

Publisher: Assurance eServices
Workload Name: AssuranceEServices.AESETLPanel
Document Version: 1.1
Effective Date: April 28, 2026
Last Updated: April 28, 2026
Next Review Date: October 28, 2026

Executive Summary
Policy Overview
Scope and Objectives
Recovery Objectives
Architecture and Components
Business Continuity Strategy
Disaster Recovery Strategy
Backup and Data Protection
Incident Response Procedures
Testing and Maintenance
Roles and Responsibilities
Communication Plan
Compliance and Audit

Executive Summary

This Business Continuity and Disaster Recovery (BCDR) policy outlines Assurance eServices’ commitment to maintaining the availability, integrity, and security of the AES ETL Control Panel workload for Microsoft Fabric. This policy ensures minimal disruption to customer operations during unexpected events, natural disasters, or system failures.

Key Highlights:

RTO (Recovery Time Objective): 4 hours
RPO (Recovery Point Objective): 15 minutes
Service Availability SLA: 99.9%
Global Distribution: Automatic failover across Azure regions
Customer Data Protection: All pipeline configurations and business data stored in customer-controlled Microsoft Fabric OneLake
Minimal AES Data: Only 7 operational identifiers stored in AES secure databases (AES-256 encrypted)

Data Collection and Storage Transparency

Customer-Controlled Data (Your OneLake):

✅ All pipeline configurations and job definitions
✅ All business data processed by pipelines
✅ Execution logs (if enabled by customer)
✅ User preferences and settings
✅ Complete control over retention, backup, and recovery

AES Operational Data (AES Secure Databases):

AES collects and stores ONLY 7 operational identifiers for basic service operation:

Data Point	Purpose	Storage
tenantId	Identify your Fabric tenant	AES Database (AES-256)
workspaceId	Identify workspace	AES Database (AES-256)
graphqlitemId	Identify pipeline item	AES Database (AES-256)
JobCount	Track job count	AES Database (AES-256)
JobStepCount	Track job step count	AES Database (AES-256)
LastJobAuditID	Track last audit ID	AES Database (AES-256)
LastJobStepAuditID	Track last step audit ID	AES Database (AES-256)

What AES Does NOT Store:

❌ User identities, names, emails, or personal information
❌ Execution logs or detailed diagnostic data
❌ Performance metrics or telemetry
❌ Pipeline configurations or business logic
❌ Authentication credentials or tokens

See our complete Privacy Policy for details.

Policy Overview

Purpose

The purpose of this BCDR policy is to:

Ensure continuous availability of the AES ETL Control Panel workload
Minimize service disruption during unforeseen events
Protect customer data and maintain data integrity
Define recovery procedures and responsibilities
Establish testing and maintenance schedules
Comply with industry standards and regulatory requirements

Commitment

Assurance eServices is committed to:

Maintaining a robust and tested disaster recovery plan
Regular review and updates of BCDR procedures
Transparent communication with customers during incidents
Continuous improvement of resilience and recovery capabilities
Meeting or exceeding committed SLAs

Scope and Objectives

Scope

This BCDR policy covers:

Frontend Application: Azure Static Web Apps hosting infrastructure
Authentication Services: Microsoft Entra ID integration
Customer Data: Pipeline configurations, business data, and execution logs (if enabled) stored in customer’s OneLake
AES Operational Data: 7 operational identifiers stored in AES secure databases
- tenantId, workspaceId, graphqlitemId, JobCount, JobStepCount, LastJobAuditID, LastJobStepAuditID
Execution Services: Fabric Spark compute within customer capacity
Support Infrastructure: Documentation, support portals, and communication channels

Out of Scope:

Customer’s Microsoft Fabric capacity (managed by Microsoft)
Customer’s OneLake storage (managed by Microsoft)
Customer’s network infrastructure
Third-party services not controlled by Assurance eServices

Objectives

Primary Objectives:

Availability: Maintain 99.9% uptime for the workload frontend
Data Integrity: Ensure zero data loss for customer configurations
Recovery Speed: Restore full service within 4 hours of incident
Customer Communication: Notify customers within 30 minutes of service disruption
Continuous Operation: Enable customers to continue operations during regional outages

Recovery Objectives

Service Level Commitments

Metric	Target	Measurement
RTO (Recovery Time Objective)	4 hours	Time to restore full service functionality
RPO (Recovery Point Objective)	15 minutes	Maximum acceptable data loss window
Service Availability	99.9%	Monthly uptime percentage
Incident Response Time	30 minutes	Time to acknowledge critical incidents
Customer Notification	30 minutes	Time to notify customers of service disruption
Critical Bug Fix	48 hours	Time to deploy critical security patches

Priority Classification

Priority 1 (Critical):

Complete service outage affecting all customers
Security breach or data exposure
Authentication system failure
RTO: 4 hours | RPO: 15 minutes

Priority 2 (High):

Partial service degradation affecting multiple customers
Performance issues impacting user experience
Non-critical feature failures
RTO: 8 hours | RPO: 1 hour

Priority 3 (Medium):

Single customer impact
Minor feature issues
Documentation or UI inconsistencies
RTO: 24 hours | RPO: 4 hours

Priority 4 (Low):

Cosmetic issues
Enhancement requests
Non-urgent documentation updates
RTO: 5 business days | RPO: N/A

Architecture and Components

System Architecture

┌─────────────────────────────────────────────────────────────┐
│                    Customer's Fabric Tenant                  │
│  ┌────────────────────────────────────────────────────────┐ │
│  │              Microsoft Fabric Platform                  │ │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐ │ │
│  │  │   OneLake    │  │ Spark Compute│  │  Monitoring  │ │ │
│  │  │   Storage    │  │    Engine    │  │     Hub      │ │ │
│  │  └──────────────┘  └──────────────┘  └──────────────┘ │ │
│  └────────────────────────────────────────────────────────┘ │
│                            ▲                                 │
│                            │                                 │
└────────────────────────────┼─────────────────────────────────┘
                             │
                   ┌─────────┴──────────┐
                   │   HTTPS / API      │
                   └─────────┬──────────┘
                             │
┌────────────────────────────▼─────────────────────────────────┐
│              AES ETL Control Panel Workload                   │
│  ┌────────────────────────────────────────────────────────┐  │
│  │         Azure Static Web Apps (Global)                  │  │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │  │
│  │  │   Primary    │  │  Secondary   │  │    Backup    │  │  │
│  │  │   Region     │  │   Region     │  │   Region     │  │  │
│  │  │  (West US 2) │  │  (East US 2) │  │ (West Europe)│  │  │
│  │  └──────────────┘  └──────────────┘  └──────────────┘  │  │
│  └────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────┘
                             │
                   ┌─────────┴──────────┐
                   │  Microsoft Entra   │
                   │   Authentication   │
                   └────────────────────┘

Component Resilience

Component	Redundancy	Failover	Recovery
Frontend Application	Multi-region deployment	Automatic	< 5 minutes
Authentication (Entra)	Microsoft-managed HA	Automatic	< 1 minute
Customer Data (OneLake)	Microsoft-managed HA	Automatic	N/A (Always available)
AES Operational Data (7 identifiers)	Multi-region backups	AES-managed restore	< 30 minutes
Spark Execution	Customer capacity	N/A	Customer-controlled
Static Content (CDN)	Global edge distribution	Automatic	< 1 minute

Business Continuity Strategy

Proactive Measures

1. High Availability Architecture

Multi-region deployment across 3 Azure regions
Azure Static Web Apps with automatic load balancing
Global CDN distribution for static assets
Health monitoring with automatic failover

2. Monitoring and Alerting

Real-time health checks every 60 seconds
Automated alerting for service degradation
Performance monitoring and threshold alerts
Customer-facing status page updates

3. Redundancy and Fault Tolerance

No single point of failure in critical path
Stateless frontend architecture for horizontal scaling
Data stored in highly available OneLake storage
Graceful degradation for non-critical features

Operational Resilience

Dependency Management:

Microsoft Fabric Platform: Customer’s Fabric capacity managed by Microsoft (99.9% SLA)
Azure Static Web Apps: Multi-region hosting with automatic failover
Microsoft Entra ID: Enterprise authentication with Microsoft’s SLA
Azure CDN: Global content delivery with edge caching
OneLake Storage: Customer’s pipeline data with Microsoft’s durability guarantees
AES Databases: 7 operational identifiers with automated encrypted backups

Capacity Planning:

Automated scaling based on usage patterns
Regular capacity reviews and load testing
Performance benchmarking and optimization
Resource allocation monitoring

Disaster Recovery Strategy

Disaster Scenarios

Scenario 1: Regional Azure Outage

Impact: Primary region unavailable
Detection: Health checks fail for 2 consecutive minutes
Response: Automatic DNS failover to secondary region
Recovery Time: 5-10 minutes
Customer Impact: Minimal, transparent failover

Scenario 2: Complete Azure Service Disruption

Impact: All Azure regions affected
Detection: Cross-region health check failure
Response: Activate tertiary backup region (West Europe)
Recovery Time: 30 minutes to 2 hours
Customer Impact: Service unavailable during failover

Scenario 3: Customer Data Loss (OneLake)

Impact: Customer’s OneLake storage affected
Detection: Customer report or OneLake API errors
Response: Customer utilizes OneLake versioning and snapshots (Microsoft Fabric-managed)
Recovery Time: Customer-initiated, typically 15 minutes to 1 hour
Customer Impact: Restore from last checkpoint (OneLake versioning)
AES Role: Advisory support only; customer controls OneLake data recovery

Scenario 3b: AES Operational Data Loss

Impact: AES operational identifiers (7 data points) corrupted or lost
Detection: Service health monitoring alerts
Response: Restore from AES encrypted backups
Recovery Time: 15-30 minutes
Customer Impact: Minimal; identifiers used for basic tracking only

Scenario 4: Security Incident

Impact: Potential unauthorized access
Detection: Security monitoring alerts
Response: Immediate service isolation and investigation
Recovery Time: 4-24 hours depending on severity
Customer Impact: Temporary service suspension

Scenario 5: Application Bug or Bad Deployment

Impact: Service degradation or outage
Detection: Automated testing or customer reports
Response: Rollback to previous stable version
Recovery Time: 15-30 minutes
Customer Impact: Brief service interruption

Recovery Procedures

Automatic Recovery (No Manual Intervention):

Regional failover via Azure Traffic Manager
CDN cache refresh and distribution
Health check validation of new region
Automatic service restoration

Manual Recovery (Requires Intervention):

Detection: On-call engineer alerted via PagerDuty
Assessment: Evaluate scope and impact (15 min)
Communication: Update status page and notify customers (15 min)
Execution: Execute recovery runbook (2-3 hours)
Validation: Verify service restoration and data integrity (30 min)
Notification: Confirm resolution to customers (15 min)

Data Recovery

Customer-Controlled Data Recovery (Your OneLake):

Pipeline Configurations:

Source: Fabric item storage in customer’s OneLake
Backup Method: OneLake automatic versioning (Microsoft-managed)
Retention: Customer-controlled via OneLake policies
Recovery Method: Customer restores via Fabric UI or API
Recovery Time: Customer-initiated, typically < 5 minutes

Execution Logs (Optional, Customer-Enabled):

Source: OneLake Lakehouse tables (if enabled by customer)
Backup Method: Delta table versioning in customer’s OneLake
Retention: Customer-configurable (default 90 days)
Recovery Method: Time-travel queries on Delta tables (customer-controlled)
Recovery Time: Immediate (no recovery needed)
Note: AES does NOT store execution logs

Business Data:

Source: Customer’s OneLake storage
Backup Method: OneLake versioning and snapshots (Microsoft-managed)
Retention: Customer-controlled
Recovery Method: Customer-managed via Fabric platform
Recovery Time: Customer-controlled

AES Operational Data Recovery (AES Databases):

7 Operational Identifiers:

Source: AES secure databases
Data Points: tenantId, workspaceId, graphqlitemId, JobCount, JobStepCount, LastJobAuditID, LastJobStepAuditID
Backup Method: Automated daily backups with multi-region redundancy
Encryption: AES-256 encrypted backups
Retention: Duration of service + 90-day grace period after termination
Recovery Method: Automated restore from encrypted backups
Recovery Time: 15-30 minutes
Purpose: Basic service operation tracking only

Backup and Data Protection

Data Classification

Customer-Controlled Data (Your OneLake):

Data Type	Storage Location	Backup Method	Retention	Criticality
Pipeline Configurations	Customer’s OneLake	OneLake versioning (Microsoft-managed)	Customer-controlled	Critical
Business Data	Customer’s OneLake	OneLake versioning (Microsoft-managed)	Customer-controlled	Critical
Execution Logs (Optional)	Customer’s OneLake Lakehouse	Delta table history	Customer-configurable	Medium
User Preferences	Customer’s OneLake item properties	OneLake versioning	Customer-controlled	Low

AES-Managed Data:

Data Type	Storage Location	Backup Method	Retention	Criticality
Operational Identifiers (7)	AES secure databases	Automated daily backups (AES-256)	Active + 90 days post-termination	Medium
Application Code	GitHub repository	Git version control	Indefinite	Critical
Static Assets	Azure Static Web Apps	Deployment history	30 days	Low

Backup Strategy

Customer Data Backups (Customer’s OneLake):

Responsibility: Microsoft Fabric platform (customer-controlled policies)
Mechanism: OneLake automatic versioning and snapshots
Frequency: Real-time with every save
Retention: Customer-configurable via OneLake policies
Recovery: Customer restores via Fabric UI, API, or OneLake tools
Encryption: AES-256 (Microsoft-managed)
Data Includes: Pipeline configurations, job definitions, business data, execution logs (if enabled)

AES Operational Data Backups (AES Databases):

Responsibility: Assurance eServices
Data: 7 operational identifiers (tenantId, workspaceId, graphqlitemId, JobCount, JobStepCount, LastJobAuditID, LastJobStepAuditID)
Mechanism: Automated database backups with multi-region redundancy
Frequency: Daily automated backups
Retention: Duration of active service + 90-day grace period post-termination
Recovery: AES-managed automated restore
Encryption: AES-256 encrypted backups
Purpose: Service restoration and basic operational tracking

Application Code:

Repository: GitHub with branch protection
Backup Frequency: Real-time commits
Retention: Indefinite
Recovery: Git clone and redeploy

Data Protection Measures

Customer Data Protection (Your OneLake):

Encryption at Rest: AES-256 for all OneLake data (Microsoft-managed)
Encryption in Transit: TLS 1.2+ for all API communication
Key Management: Microsoft-managed encryption keys
Access Control: Fabric RBAC (Role-Based Access Control)
Authentication: Microsoft Entra ID with MFA support
Audit Logging: Optional customer-controlled logging to OneLake
Data Residency: Remains in customer’s selected Fabric capacity region
No Data Transfer: Zero customer data transfer to AES or third parties

AES Operational Data Protection (7 Identifiers):

Encryption at Rest: AES-256 for database storage
Encryption in Transit: TLS 1.2+ for all communication
Key Management: AES-managed encryption keys
Access Control: Strict internal access controls (least privilege)
Audit Logging: All access to operational data logged
Data Minimization: Only 7 identifiers collected (no personal data)
Retention: Active service + 90-day grace period
Deletion: Automatic deletion after grace period, or immediate upon request

Separation of Concerns:

Customer pipeline data and business information: 100% customer-controlled in OneLake
AES operational identifiers: Minimal tracking data in AES secure databases
No overlap: AES cannot access customer’s OneLake data
Customer cannot access AES operational databases

Incident Response Procedures

Incident Classification

Critical (P1):

Complete service outage
Security breach or data exposure
Response: Immediate escalation, 24/7 response

High (P2):

Partial service degradation
Performance issues affecting multiple customers
Response: Within 1 hour, business hours priority

Medium (P3):

Single customer impact
Non-critical feature failures
Response: Within 4 hours, business hours

Low (P4):

Cosmetic issues
Enhancement requests
Response: Next business day

Incident Response Workflow

Phase 1: Detection (0-5 minutes)

Automated monitoring alerts triggered
PagerDuty notification to on-call engineer
Initial triage and classification

Phase 2: Assessment (5-20 minutes)

Verify incident scope and customer impact
Classify incident priority (P1-P4)
Assemble response team if needed
Begin incident log documentation

Phase 3: Communication (20-30 minutes)

Update status page: https://status.assuranceeservices.com
Send email notifications to affected customers
Post updates to support portal
Establish communication cadence (every 30 min for P1)

Phase 4: Mitigation (30 minutes – 4 hours)

Execute recovery runbook
Apply immediate workarounds if available
Escalate to engineering team if needed
Monitor recovery progress
Validate service restoration

Phase 5: Resolution (Varies)

Confirm full service restoration
Verify data integrity
Conduct smoke testing
Update status page to “Resolved”
Send resolution notification to customers

Phase 6: Post-Incident Review (Within 5 days)

Document incident timeline
Conduct root cause analysis
Identify preventive measures
Update runbooks and documentation
Publish post-mortem (for P1 incidents)

Escalation Matrix

Level	Role	Contact Method	Response Time
Level 1	On-Call Engineer	PagerDuty	Immediate
Level 2	Engineering Lead	Phone + Email	15 minutes
Level 3	Engineering Director	Phone	30 minutes
Level 4	CTO	Phone	1 hour
Level 5	CEO	Phone	2 hours

Communication Templates

Initial Notification:

Subject: [INCIDENT] AES ETL Control Panel - Service Disruption

We are currently experiencing an issue with the AES ETL Control Panel 
workload affecting [scope]. Our team is actively investigating.

Status: Investigating
Impact: [Description]
Started: [Timestamp]
Next Update: [Timestamp]

Updates: https://status.assuranceeservices.com
Support: support@assuranceeservices.com

Resolution Notification:

Subject: [RESOLVED] AES ETL Control Panel - Service Restored

The issue affecting the AES ETL Control Panel workload has been 
resolved. All services are now operating normally.

Resolution Time: [Timestamp]
Duration: [Duration]
Root Cause: [Brief description]

A detailed post-incident review will be published within 5 business days.

Thank you for your patience.

Testing and Maintenance

Testing Schedule

Test Type	Frequency	Scope	Duration
DR Failover Test	Quarterly	Full regional failover	4 hours
Backup Restoration	Monthly	Sample data recovery	2 hours
Incident Response Drill	Quarterly	Team response simulation	3 hours
Security Testing	Annually	Penetration testing	1 week
Load Testing	Monthly	Performance validation	4 hours
Runbook Validation	Quarterly	Procedure verification	2 hours

DR Testing Procedures

Quarterly Failover Test:

Pre-Test Planning (1 week before):
- Schedule testing window
- Notify customers via email
- Assemble testing team
- Review runbooks
Test Execution:
- Simulate primary region failure
- Trigger failover to secondary region
- Validate service availability
- Test data access and integrity
- Measure actual RTO/RPO
Post-Test Activities:
- Document test results
- Compare against targets
- Identify improvement areas
- Update runbooks
- Report to stakeholders

Maintenance Windows

Scheduled Maintenance:

Frequency: Monthly (first Sunday of each month)
Window: 2:00 AM – 6:00 AM UTC
Notification: 7 days advance notice
Impact: Minimal, rolling updates when possible

Emergency Maintenance:

Trigger: Critical security patches
Notification: 4 hours advance notice (when possible)
Approval: CTO authorization required

Review and Updates

Policy Review:

Frequency: Semi-annually (January and July)
Participants: Engineering, Operations, Security, Legal
Deliverables: Updated policy document, change log

Runbook Updates:

Frequency: After each incident or test
Process: Document lessons learned, update procedures
Approval: Engineering Lead review

Roles and Responsibilities

BCDR Team Structure

Incident Commander (IC)

Role: Overall incident coordination
Responsibilities:
- Declare and classify incidents
- Coordinate response team
- Make executive decisions
- Customer communication oversight
Contact: Available 24/7 via PagerDuty

Operations Lead

Role: Technical recovery execution
Responsibilities:
- Execute recovery procedures
- Coordinate with Azure support
- System health validation
- Technical status updates
Contact: On-call engineer rotation

Communications Lead

Role: Customer and stakeholder communication
Responsibilities:
- Status page updates
- Customer email notifications
- Support ticket management
- Executive briefings
Contact: Support team manager

Data Recovery Specialist

Role: Data restoration and validation
Responsibilities:
- AES operational data (7 identifiers) recovery from encrypted backups
- Assist customers with OneLake data recovery guidance
- Data integrity verification for AES operational databases
- Backup validation and testing
- Coordination with Microsoft Fabric support for OneLake issues
Contact: Senior engineer on-call

Security Lead

Role: Security incident response
Responsibilities:
- Security threat assessment
- Breach investigation
- Compliance coordination
- Forensics preservation
Contact: Security team lead

Customer Responsibilities

Customer’s Role in BCDR:

OneLake Data Management:
- Configure appropriate retention policies for your OneLake data
- Enable and validate OneLake versioning for critical pipeline configurations
- Test data recovery procedures using OneLake restore capabilities
- Manage execution log retention (if enabled)
- Control backup policies for business data
Capacity Management:
- Maintain adequate Fabric capacity for normal operations and recovery
- Monitor capacity utilization and plan for growth
- Ensure sufficient capacity for disaster recovery scenarios
Access Management:
- Maintain current contact information for incident notifications
- Designate backup administrators for continuity
- Review and update Fabric workspace permissions regularly
- Manage Microsoft Entra ID access policies
Testing Participation:
- Participate in scheduled DR tests (optional but recommended)
- Validate your OneLake data recovery procedures
- Test pipeline restoration from OneLake backups
- Report service issues promptly
Data Ownership:
- Understand that all pipeline configurations and business data remain in your OneLake
- AES stores only 7 operational identifiers for basic service tracking
- You control all aspects of your data lifecycle (retention, deletion, recovery)

Communication Plan

Stakeholders

Internal Stakeholders:

Engineering team
Support team
Executive leadership
Sales and customer success

External Stakeholders:

Customers (tenant administrators)
Microsoft Fabric support team
Azure support team
Compliance auditors

Communication Channels

Status Page: https://status.assuranceeservices.com

Real-time service status
Incident history
Scheduled maintenance calendar
Subscribe for email/SMS alerts

Email Notifications:

Incident alerts to tenant administrators
Maintenance window announcements
Post-incident summaries

Support Portal: https://assuranceeservices.com/support

Submit support tickets
Access knowledge base
View open incidents

Emergency Contact:

Email: support@assuranceeservices.com
Phone: +1 (XXX) XXX-XXXX (24/7 for P1 incidents)

Communication Frequency

During Active Incident:

P1 (Critical): Every 30 minutes
P2 (High): Every 2 hours
P3 (Medium): Every 4 hours
P4 (Low): Daily update

Scheduled Maintenance:

Initial Notice: 7 days before
Reminder: 24 hours before
Start: At maintenance window start
Completion: Upon completion

Compliance and Audit

Regulatory Compliance

Standards Adherence:

SOC 2 Type II: Annual audit
ISO 27001: Information security management
GDPR: European data protection
CCPA: California consumer privacy
HIPAA: Healthcare data protection (when applicable)

Audit Requirements

BCDR Audit Activities:

Quarterly DR Test Results Review
Annual Penetration Testing Report
Incident Response Log Review
RTO/RPO Compliance Measurement
Backup Validation Records
Access Control Audit Logs

Documentation Retention

Retention Periods:

Incident Logs: 7 years
DR Test Results: 5 years
Backup Logs: 3 years
Communication Records: 3 years
Policy Revisions: Indefinite

Compliance Reporting

Monthly Reports:

Service availability metrics
Incident summary
RTO/RPO compliance

Quarterly Reports:

DR test results
BCDR policy compliance
Improvement initiatives

Annual Reports:

Comprehensive BCDR review
Audit findings and remediation
Strategic improvements

Data Retention After Service Termination

Customer Data (Your OneLake)

Immediate Access:

All pipeline configurations, business data, and execution logs remain in your OneLake under your complete control
AES does not and cannot delete your OneLake data
You manage retention and deletion based on your requirements
Zero impact from AES service termination

AES Operational Data (7 Identifiers)

Post-Termination Retention:

Grace Period: 90 days after service termination
Purpose: Allow service restoration if customer renews
Data: Only the 7 operational identifiers (tenantId, workspaceId, graphqlitemId, JobCount, JobStepCount, LastJobAuditID, LastJobStepAuditID)
Automatic Deletion: Automatically and permanently deleted after 90-day grace period
Immediate Deletion Option: Request immediate deletion by contacting privacy@assuranceeservices.com

No Data Transfer:

AES never transfers customer OneLake data to any location
No backup of customer business data by AES at any time
No retention of customer pipeline configurations by AES
Only 7 minimal identifiers retained during grace period

See our complete Privacy Policy for details on data handling practices.

Document Control

Version History

Version	Date	Author	Changes
1.0	April 27, 2026	AES BCDR Team	Initial publication
1.1	April 28, 2026	AES BCDR Team	Updated data storage, backup, and recovery sections to align with Privacy Policy

Document Approval

Role	Name	Signature	Date
CTO	[Name]	[Signature]	April 28, 2026
Engineering Director	[Name]	[Signature]	April 28, 2026
Legal Counsel	[Name]	[Signature]	April 28, 2026

Document Distribution

Internal: All engineering and operations staff
External: Published at https://assuranceeservices.com/bcdr-policy
Customers: Available via support portal

Contact Information

BCDR Inquiries:

Email: bcdr@assuranceeservices.com
Support Portal: https://assuranceeservices.com/support

Emergency Response (24/7):

Email: support@assuranceeservices.com
Phone: +1 (469) 664-5313

Policy Questions:

Email: compliance@assuranceeservices.com

Document Classification: Public
Next Review: October 27, 2026
Policy Owner: Chief Technology Officer
Document Location: https://assuranceeservices.com/bcdr-policy

This document represents Assurance eServices’ commitment to business continuity and disaster recovery for the AES ETL Control Panel workload. Regular reviews and updates ensure this policy remains current and effective.