anDREa Service Level Agreement (SLA)
This Service Level Agreement (SLA) defines the operational performance benchmarks, incident classification boundaries, and response time metrics for the myDRE platform. Grounded within the mydre CIA-AA Classification, this document aligns with ISO 27001:2023 (A.05.20 - Supplier Agreements) and NIS 2 requirements to guarantee infrastructure resilience and continuous performance monitoring.
anDREa reserves the right to modify this SLA and the associated End User License Agreement (EULA) at its sole discretion. Revisions become legally binding immediately upon publication on mydre.org or through explicit client notifications. Continued platform utilization constitutes ongoing consent to updated SLA terms.
1. Core Service Performance Metrics
Target Key Performance Indicators (KPIs)
Platform performance is calculated monthly on an aggregate hourly scale based on critical platform accessibility metrics:
Service Availability = 3-Month Average of Total Prio1 Down Time / Total Operational Time in the Month * 100%
Prio1 downtime: One or more core functionalities are not working, other core functionalities still might work.
- Target KPI Performance: >99.0% availability threshold per 3-month rolling average (< 21.6 hours of total downtime within a standard 90-day / 2160-hour operational month).
- KPI Measurement Boundary: Appraised strictly against system anomalies, software bugs, or infrastructure disruptions for which anDREa is directly responsible.
- Total Performance Metric: Calculated as the combined total of anDREa's baseline KPI performance aggregated with the live, upstream Microsoft Azure SLA Performance.
- Maximum Acceptable Outage (MAO): Permanently capped at 3 business days, in strict compliance with the platform core disaster recovery metrics.
2. Ticket Prioritization Framework
Incoming support escalations and operational incidents are categorized into three distinct layers to ensure targeted triage:
-
Priority 1 (Critical Impact):
- Total platform or core system unavailability affecting > 20% of active users or Workspaces.
- Any confirmed or highly suspected Security Breach, Data Leak, or Privacy Compromise.
-
Priority 2 (High Impact):
- Failure of default Workspace functionality impacting one or more active researchers (preventing normal computational work).
- System disruptions originating from pre-approved, active Outside SLA Requests.
-
Priority 3 (Standard Impact):
- General usability inquiries, minor layout discrepancies, functional optimization queries, and any other non-disruptive platform questions.
3. Mandatory Support Response Matrix
To maintain seamless multi-tenant operational continuity, responsibilities are divided between decentralized Local Research Support teams and centralized anDREa engineering functions.
Support Tier Response Windows
| Supporting Body | Operational Activity / Ticket Tier | Mandatory Response Boundary |
|---|---|---|
| Local Research Support (Frontline Tenant Boundary) | Workspace Architecture Creation | < 8 Working Hours |
| New Identity Ingestion / User Enrollment | < 8 Working Hours | |
| Priority 1 Tickets (Critical / Security Event) | < 2 Working Hours | |
| Priority 2 Tickets (Functional Impairment) | < 8 Working Hours | |
| Priority 3 Tickets (General Inquiries) | < 3 Working Days | |
| anDREa Support Team (Central Platform Plane) | Structural Account Approval / Validation | < 8 Working Hours |
| Priority 1 Tickets (Platform-wide / Security) | < 2 Working Hours | |
| Priority 2 Tickets (Core Function Fault) | < 8 Working Hours | |
| Priority 3 Tickets (Standard Administration) | < 3 Working Days | |
| Local Research Support Ticket Escalations | < 4 Working Hours | |
| Provisioning a New Azure Subscription Target | < 3 Working Days |
SLA Escalation Shift: If a required administrative action falls outside the technical permissions assigned to the Local Support Team, the operational SLA target automatically transfers to the corresponding anDREa Support Team window.
4. SLA Exclusions & Boundaries
The technical performance metrics and availability targets defined within this agreement explicitly exclude any operational downtime or system disruption caused by the following six external dependencies:
- Planned Maintenance Windows: Scheduled maintenance that is approved in advance, communicated to affected users beforehand, and performed within the published maintenance window, including patching, security updates, platform hardening, and routine infrastructure maintenance. Any maintenance activity that exceeds the announced window will be classified as unplanned downtime for SLA purposes.
- Upstream Public Cloud Outages: Structural failures originating from the Microsoft Azure infrastructure core or federated identity providers (including Microsoft Entra ID authentication and Microsoft Authenticator MFA anomalies). These are governed independently via the Microsoft Azure Service Level Agreement and monitored via the Azure Status Dashboard.
- Tenant Perimeter Defenses: Network disruptions caused by on-premises firewall configurations, local volume license servers, legacy corporate storage arrays, or localized proxy tools blocking outgoing HTTPS or RDP connections.
- Secondary Tooling Outages: Availability anomalies tracking the Zoho Desk support ticketing system (
support.mydre.org), which is independently managed under the Zoho Desk Classic Support Plan. - User-Induced Operating System Errors: Outages caused directly by researcher mismanagement, including letting Virtual Machine operating system disks run completely out of free storage volume space.
- Unauthorized Configuration Alterations: System crashes resulting from researchers attempting to bypass automated controls, modify low-level network topologies, or manually override standard platform authentication hooks.