Outside SLA Request Policy & Process
This document outlines the governance protocol for evaluating, approving, and deploying custom architectural configurations that fall outside the standard myDRE Service Level Agreement (SLA). This framework supports compliance mandates for change management and risk validation under ISO 27001:2023 (A.08.29 - Security Testing in Development and Acceptance, A.08.32 - Change Management) and NIS 2.
1. Scope & Architectural Impact
An Outside SLA Request is triggered whenever a project requires architectural components, networking exemptions, or deployment patterns that deviate from the standard, pre-validated myDRE service blueprint.
Common Implementation Examples
- Cross-Workspace Data Bridges: Implementing a unified Common Share accessible across separate isolated Workspaces.
- Advanced Data Analytics Tools: Provisioning Serverless SQL pools or custom database clusters.
- Custom Storage Topologies: Deploying General-Purpose Storage Accounts (v2) with non-standard replication parameters.
- Perimeter Ingress Configurations: Opening specialized inbound ports or firewall vectors to accommodate real-time data feeds.
The Compliance & Security Balance
Because non-standard changes directly modify the network topology or role assignments, they can impact core auditability, data isolation boundaries, and operational expenditure. To maintain compliance, every custom request must undergo rigorous multi-tiered verification before any deployment occurs.
2. Multi-Tiered Approval Lifecycle
To protect the platform's integrity and ensure clear accountability, every Outside SLA Request must pass through a four-stage vetting pipeline:
┌────────────────────────────────────────────────────────┐
│ STAGE 1: DOCUMENTATION │
│ Draft specialized Design Document mapping alterations │
└───────────────────────────┬────────────────────────────┘
▼
┌────────────────────────────────────────────────────────┐
│ STAGE 2: anDREa TECHNICAL REVIEW │
│ anDREa CTO conducts structural & security sanity check │
└───────────────────────────┬────────────────────────────┘
▼
┌────────────────────────────────────────────────────────┐
│ STAGE 3: TENANT SECURITY REVIEWS │
│ Tenant's Security/CISO team reviews internal threat │
└───────────────────────────┬────────────────────────────┘
▼
┌────────────────────────────────────────────────────────┐
│ STAGE 4: EXECUTIVE SIGN-OFF │
│ Department Manager (Responsible) signs off on risk │
└────────────────────────────────────────────────────────┘
- Step 1: Formal Design Documentation: A dedicated, isolated architectural Design Document is generated for the request. This technical file acts as the permanent compliance ledger detailing the explicit changes, ports, and assets involved.
- Step 2: anDREa Technical Sanity Check: The anDREa CTO conducts a technical evaluation. This assessment determines if the change threatens platform scalability, compromises system maintainability, or introduces cross-tenant vulnerabilities. This review may impose strict technical prerequisites or issue a binding NOGO decision.
- Step 3: Organizational Security Sanity Check: The Tenant organization's own Information Security Officer (ISO) or CISO reviews the design against internal corporate data handling rules and compliance criteria. This check may introduce additional local controls or issue a binding NOGO.
- Step 4: Executive Risk Sign-Off: A designated institutional stakeholder (typically a Departmental or Line Manager holding budgetary authority) must explicitly sign off on the design, formally accepting the associated security risks, financial impacts, and operational variances.
3. Administrative Information for Auditors
- Access Restrictions: The master directory containing all active and archived Outside SLA Design Documents is strictly locked. It is accessible only by authorized Local Research Support personnel and anDREa compliance engineers to prevent unverified modifications.
- Granular Accountability: A unique, standalone artifact is generated for each independent request. This ensures that the distinct individuals responsible for the technical sanity checks, corporate security approvals, and executive sign-offs are explicitly logged and audit-verifiable for the lifecycle of the study.