The operating principle
Deploy DRE into the customer's Azure environment. Stay in the customer's existing Microsoft ecosystem. Work where the customer already works.
The intended model gives the customer control of the environment in which DRE operates, including the surrounding enterprise identity, network, access, logging, security, and governance controls. DRE becomes part of the customer's existing enterprise environment rather than an external legal-data destination.
What the current Bicep actually provisions
The infrastructure foundation is declarative and repeatable, using parameters for deployment location and naming under the legalfirewall prefix. It creates four principal resources.
| Resource | Current configuration |
|---|---|
| Azure Virtual Network | Address space 10.0.0.0/16, with AppSubnet at 10.0.1.0/24. |
| Azure Key Vault | Standard SKU, empty accessPolicies array, deployment integration flags enabled. |
| Azure Cosmos DB | GlobalDocumentDB account, Standard offer type, one primary regional location. |
| Azure OpenAI | S0 Cognitive Services account, custom subdomain, publicNetworkAccess: 'Disabled'. |
The disabled public-access setting on Azure OpenAI is the strongest control actually present in the current definition. Disabling public access does not itself create a working private route — that requires private endpoints and DNS, which remain implementation work.
What remains implementation work
| Layer | Still required |
|---|---|
| Application runtime | No application-hosting resource is provisioned. Azure Container Apps is the identified direction. |
| Messaging | Azure Service Bus for buffering, exception routing, retries, and controlled processing states is not provisioned. |
| Private connectivity | Private endpoints, private DNS zones, DNS links, routing, subnet policies, and workload integration. |
| Identity | Managed identities, Microsoft Entra ID integration, and least-privilege RBAC. No identities or role assignments are declared. |
| Data layer | Database, containers, partition strategy, consistency model, backup, retention, and authorization. |
| Model serving | Model deployment, quota configuration, content-control decisions, and diagnostic settings. |
| Observability | Azure Monitor, Log Analytics, Application Insights, diagnostic settings, alerts, and dashboards. |
The six-stage build-out sequence
- Foundation — naming, network planning, resource metadata, locks, and policy baseline.
- Private Access — private endpoints and DNS; restrict unintended public access.
- Identity — managed identities and least-privilege RBAC.
- Data and Models — Cosmos DB databases and containers; approved Azure OpenAI model deployments.
- Observability — diagnostic settings, logs, alerts, audit events, and dashboards.
- Assurance — threat modelling, access review, deployment tests, recovery testing, retention validation, and documentation.
The architectural principle
The significance of this architecture does not come from any single Azure service. It comes from the combination: customer-controlled environment, deterministic application processing, controlled model access, network isolation, attributable identity, protected secrets, structured evidence storage, observability, and human authority. The current Bicep establishes the beginning of that boundary.
Provisioned does not mean hardened. Configured does not mean validated. DRE should claim only controls that have actually been implemented and tested.
