Responsibilities: What You Take Care of Yourself, and What Not¶
Short version¶
| The platform team takes care of… | You take care of… |
|---|---|
| The hub: firewall, Virtual WAN, DNS, gateways, App Gateway, Bastion | Everything you deploy in your spoke |
| Setting up and changing your spoke's baseline (network, groups, PIM, SPN, Key Vault, storage, Log Analytics) | Patching, backups, lifecycle and continuity of your workload |
| Policies at platform level, and keeping the platform up to date | Fixing policy violations on your resources |
| Central monitoring of the platform | Monitoring and alerting of your application |
| The deployment pipelines of the platform | Your own application pipelines (using your spoke SPN) |
| Implementing firewall rules you request | Requesting the rules you need, and knowing why you need them |
| Cost management of the platform subscriptions | The cost of your subscription |
In detail¶
| Area | Platform team | Your team |
|---|---|---|
| Network: firewall, hub, gateways, DNS, App Gateway | Responsible and accountable | Informed |
| Firewall rule content (which traffic is allowed) | Implements; security officer approves | Requests rules, with a rationale |
| IP plan | Allocates and implements | States how many addresses it needs |
| Spoke VNet, NSGs, route tables | Implements through code | Accountable for what it asks for |
| Azure Policy compliance | Accountable at platform scope | Accountable for its own resources |
| Cost and budgets | Platform subscriptions | Its own subscription |
| Logs and alerts | Platform | Its own workspace and alerts |
| Defender for Cloud and Advisor recommendations | Platform subscriptions | Its own subscription |
| RBAC and PIM | Spoke groups and PIM settings | Members of its own team group |
| Entra ID users, Conditional Access, SOC | Customer identity/security teams | – |
| Pipelines and runners | Platform pipelines | Its own application pipelines |
| Tags on the subscription | Applies them | Supplies the values and keeps them current |
| Application security, data classification, authorization inside the app | – | Fully |
| Incidents | Platform components, during the agreed support hours | Its own application, under its own SLA |
Responsibilities by domain (RACI)¶
A more detailed view, for a platform in which the platform team provides the baseline and the workload owner (you) provides the workload. R = responsible (does it), A = accountable (owns the result), C = consulted (advises and sets standards).
| Domain | Platform team | Workload owner |
|---|---|---|
| Virtual infrastructure (landing zone, baseline, shared network) | C + A | R: deploys VMs, storage, resources |
| Network security (firewall policy, NSG standards, routing) | C + A | R: security rules, subnets, endpoints, access |
| OS management (images, hardening policy, agents) | C | A + R: OS configuration, antivirus, troubleshooting |
| Monitoring and logging | C: standards, platform alerts, retention | A + R: application logging, alerts, dashboards, incident follow-up |
| Backup and disaster recovery | C + A: backup policy and DR approach where provided | R: backups, restores, retention, restore tests |
| Business continuity / high availability | C: HA architecture advice | A + R: redundant apps, failover tests, continuity plans |
| Resource governance (policies, tags, cost) | C: dashboards, policies, tag policy | A + R: tag resources, report usage, optimise, reservations |
| Identity and access (RBAC, PIM, groups) | C: baseline policies, onboarding | A + R: team groups, MFA, authorisation groups |
| Data protection and encryption | C + A: encryption policy, key lifecycle advice | A + R: encryption choices, key rotation, Key Vault management |
| Compliance and auditing | C: control advice, audit support | A + R: self-assessment, evidence, audit trail |
| Data retention and deletion | C: advice, lifecycle tooling | A + R: set retention, delete data, prove deletion |
| Incident management and data-breach reporting | C: process, runbooks, forensic support | A + R: detect incidents, report data breaches, communicate |
| IAM policy enforcement | C: writes baseline policies, approves changes | A + R: own policies, exception requests, grant and remove access |
| Application security | C: oversight of test results | A + R: patching, code audits, penetration tests, app configuration |
| Configuration management | C + A: baseline policies, templates | R: create resources, comply with policy, tags, settings |
| Update management | C + A: patch cadence, tooling for platform components | R: application and OS updates, patching, rollback (see Updates and patching if you use managed VMs) |
| Vulnerability management | C: scanning tools, reports, advice | A + R: patch, assess risk, mitigate, retest |
| Ownership and accountability | C: roles, change control, owners | A + R: name the data and application owner, decide on assets, escalate |
Your organisation decides the details
This matrix is a reference. Who is "the platform team" depends on your operating model (XMMS under a managed-service contract, or your own platform team). Security and compliance frameworks that organisations map it to include ISO 27001, NEN 7510 and NIS2. Ask your platform team which domains your contract or internal agreement changes.
Reading the RASCI matrices
The operating side of the split, with more activities and the meaning of the letters, is in Operating responsibilities.
Accountability in the managed model
In a managed service, accountability can stay with the customer organisation while the platform team does the work. Then read an A in the platform team column as "accountable for the platform team's own scope". Your contract states which applies. A task has exactly one A and at least one R. See Operating models.
Roles in your team¶
A workload normally has these technical roles. Name the people and keep the list current.
| Role | Responsibility |
|---|---|
| Owner | Owns the workload and is accountable for everything in it, including current tags and contacts |
| Approver | Approves changes and elevated access to production, for example PIM requests |
| Engineer | Builds and oversees the implementation |
| Reader | Looks, for guests and supporting engineers or architects |
How these map to the groups of your spoke is in Access, groups and PIM and Identity and access model. Roles inside your application (for example business users and their administrators) are always yours.
Managed spoke¶
If you chose a managed spoke (Service types, Managed spokes), the platform team also builds, deploys, maintains and monitors the Azure resources of your workload, within the scope of a separate agreement. What does not change:
- you stay accountable for the workload, its data and its security classification,
- you decide the requirements and accept the changes,
- you keep your own application logic, application-level roles and incident handling for your users.
Ask for the scope and the service window in the agreement.
What we expect from you¶
- Work within the policies and standards of the platform.
- Organize operations and lifecycle management of your workload.
- Name a product owner and a technical contact, and keep them current.
- Keep the subscription tags correct.
- Report platform problems through the agreed support channel, with the subscription name and what you tried.
- Follow the guardrails for workload teams: no manual production changes, four-eyes review, private connectivity, and secrets in a vault.