Azure Day-Two Operations: A Provider Responsibility Checklist

What does day-two operations mean in Azure?

Day-two operations is the ongoing ownership of the platform that begins the moment your migration project closes and never ends. Migration is a finite project. It moves workloads from one place to another, and then it stops. Day-two work has no completion date, because the platform keeps changing as new attacks arise every day it runs.

The mistake worth naming is assuming the vendor who migrated you keeps everything healthy afterward. Migration scope and operational scope are different contracts with different deliverables. If nobody formally owns operations from the day migration ends, the gap does not stay static. It compounds, because every untracked change makes the next one harder to correct.

So the fresh responsibility scope you write now is cheaper than the cleanup you would pay for later.

What should the provider own after migration

The provider should own operation of the platform layer and workload operations. Its scope should also cover governance and the controls that protect identity, security, backups, and cost. Owning something means more than doing the work. It means producing evidence that the work happened and meeting a stated SLA. Results must be reported on a schedule you agreed to in writing.

The distinction that protects you is between operating and deciding. Your provider operates the machinery. You decide business risk, and Microsoft secures the underlying cloud. The Microsoft shared responsibility model states plainly that regardless of service model, the customer stays responsible for protecting data and controlling access to workloads.

Read that carefully, because it draws the line most engagements get wrong. A provider can operate your identity system flawlessly and still leave you exposed if you assumed they owned access decisions they never agreed to own. The sections below break each responsibility area into operating and decision ownership, then state the evidence that proves it.

Who owns tenant and subscription governance?

The provider owns policy enforcement, landing zone governance, drift correction, and the ongoing evolution of your Azure architecture. You approve governance policies and organizational structure, but the provider is responsible for ensuring those decisions remain enforced across every subscription.

Governance extends beyond Azure Policy. In regulated industries and regions with strict data residency requirements, the Azure Landing Zone must also enforce data sovereignty. Your provider should ensure the Azure architecture automatically prevents regulated workloads and sensitive data from drifting across geographic boundaries, helping maintain compliance without relying on manual oversight. Management groups, Azure Policy, and landing zone controls should work together to enforce both governance standards and physical data boundaries, backed by monthly compliance reporting.

That report matters because ungoverned environments get expensive fast. EPC Group notes that organizations with 50 or more subscriptions and no landing zone spend 30 to 40 percent more on cloud operations. Drift is the quiet driver of that number, so the provider must correct compliance issues as it reports them as part of its service.

Who owns identity and privileged access?

The provider operates and monitors Microsoft Entra ID access controls, while you own joiner-mover-leaver decisions and role approvals. This is a shared responsibility. The provider enforces least privilege. You decide who deserves access in the first place.

The reason this split earns its keep sits in the data. Microsoft research shows MFA blocks more than 99.2% of account compromise attacks. A provider enforcing MFA and PIM closes almost the entire credential-theft door, but only you can stop a departed employee's access from lingering, because only you know they left.

Who owns patching, backups, and recovery tests?

The provider owns patch cadence and backup execution. It also conducts scheduled recovery tests with restore evidence and recovery point and recovery time objective (RPO/RTO) reporting, while you define retention and criticality. A tested restore is required for a backup to qualify as a deliverable.

The numbers make that blunt. Research compiled by CrashPlan found that only 61% of restores succeed completely, and just 50% of businesses test recovery plans annually. That creates what could be called Schrödinger's Backup: if your MSP can provide a backup log but not a tested restore log, your data is simultaneously safe and destroyed until a real incident proves which is true. Demand the restore log. A backup without a verified recovery test is simply expensive cloud storage pretending to be disaster recovery.

Who owns monitoring and incident response?

The provider owns Azure Monitor and Log Analytics configuration. It handles alert triage. It responds to incidents against a stated SLA and manages Microsoft escalation, while you own severity definitions and business impact context. Defender for Cloud posture management sits with the provider too, because posture requires operational discipline.

Good tooling with a good operator moves fast. A Forrester study of Microsoft Defender found mean time to acknowledge dropped from 30 minutes to 15 and mean time to resolve fell from up to 3 hours to under 1. Those gains only land if your provider defines the SLA in numbers. An incident response promise without a resolution target is a sentiment, and sentiment does not restore a downed system.

Evidence and SLA

Every responsibility area must map to a named artifact and a response and resolution SLA. It must also have a reporting cadence that establishes ownership. Accountability comes from turning each promise into something you can point at and check on a schedule.

Here is what that looks like across the areas covered above:

• Governance: a monthly compliance dashboard showing policy state and every drift correction made

• Identity: a quarterly access review with PIM activation logs and privileged role changes

• Backup and recovery: dated restore logs with actual RPO and RTO measured against target

• Security: incident tickets with acknowledgment and resolution timestamps against SLA

• Cost: monthly spend reporting with anomaly alerts and right-sizing recommendations

The FinOps Foundation's 2025 report found 50% of practitioners rank workload optimization and waste reduction as their top priority, which makes cost anomaly alerting a baseline expectation. Write these artifacts into the contract as named deliverables. A responsibility that produces no artifact is one nobody can prove was ever performed, which means in practice nobody did it.

Where does responsibility stay with the customer

Microsoft secures the platform, and the provider operates it. You remain responsible for the business decisions that govern your data and access. Nobody hands away business risk in a managed services contract. The provider executes against the decisions you make, but the decisions stay yours.

This is where companies believe they are covered when they are not. CrowdStrike's summary of the model is direct: the cloud provider protects the cloud and its underlying infrastructure, while customers protect the data and assets they store in it. Microsoft will not classify your sensitive data for you. Your provider will not decide which workload can tolerate an hour of downtime.

The inference to carry into your negotiation is this. Any responsibility that requires knowing your business cannot be fully delegated, because a provider that has never met your customers cannot weigh the cost of losing them. You set data classification and retention rules. You also set severity definitions and access approvals. The provider enforces what you decide, and that division is the difference between an operator and a scapegoat.

Splitting cost, capacity, and AKS work

The provider owns FinOps monitoring and capacity forecasting. It also provides right-sizing recommendations and operates Azure Kubernetes Service (AKS) cluster automation, while you approve spend and architecture direction. The provider surfaces the waste and proposes the fix. You authorize the change, because rightsizing a production cluster affects performance you are accountable for.

The conclusion is bigger than monthly cost savings. According to the FinOps Foundation, roughly 21% of enterprise cloud spending is wasted. In 2026, that is not simply wasted infrastructure budget—it is lost AI capital. If your provider isn't aggressively right-sizing your Azure infrastructure, they are starving your future AI and Copilot initiatives of the compute budget they require. Every optimization report should therefore track both realized savings and the capacity those savings free for strategic innovation.

Recommendations alone do not reduce a bill. Insist that every optimization report tracks the savings actually realized from last month's recommendations, so the FinOps function proves its own value.

What changes in a hybrid cloud setup

In a hybrid setup, the provider must own connectivity and identity synchronization across both environments. It must provide consistent monitoring, with explicitly defined handoff points where on-premises responsibility begins. If you kept local infrastructure instead of a full lift and shift, the seam between Azure and on-premises is where accountability quietly disappears.

This is a common arrangement. Research from Dataintelo reports that more than 72% of large enterprises ran hybrid cloud as their primary IT strategy in 2025, up from about 58% in 2022. Azure Arc extends governance and monitoring across on-premises and edge, but the tool only works if someone is contractually named to operate it on both sides of the line.

What this means for your scope is specific. Ask exactly where the provider's responsibility for a workload stops when a request crosses from Azure into your data center. An undefined handoff leaves responsibility unowned, and unowned seams are precisely where hybrid incidents live longest before anyone claims them.

How should you run the governance meeting

Run a recurring governance meeting to keep the provider accountable against everything above, on a monthly cadence with a quarterly strategic review. This is the mechanism that turns a written scope into sustained performance, because a contract nobody reviews decays into a contract nobody follows.

Use this standing agenda:

1. SLA performance against target for the period

2. Security posture and Defender for Cloud findings

3. Cost trend, anomalies, and realized optimization savings

4. Open incidents and their current status

5. Recovery test results with measured RPO and RTO

6. Upcoming changes and policy approvals needing your sign-off

On attendance, the FinOps Foundation notes that mature cost practices depend on shared accountability across the organization. Send your operations lead and someone who can approve spend. The provider should bring the engineer who does the work alongside an account manager.

The point most engagements miss is that this meeting is where decision rights get exercised. If you attend without anyone empowered to approve changes, the provider's recommendations stall and the backlog grows between sessions, which defeats the reason you booked the meeting at all.

Turn your Azure operations into BenefIT

If you now know what to demand but need a partner who can deliver against it, that is the gap ABS Technologies fills. ABS Technologies is an Armenia-based Managed IT Services Provider whose offerings map directly to the day-two responsibilities in this checklist, from governance enforcement through tested recovery and security monitoring.

What sets the engagement apart is a vendor-independent stance, which means procurement advice you can trust because it is not steering you toward a product ABS needs to sell. The work follows a structured model that begins with assessment and agreement. Benchmarking guides ongoing support, so the scope you sign is measured against a baseline and reviewed over time.

Bring this checklist to a first conversation and use it as the frame. Define a clear post-migration operations scope with ABS Technologies, with named evidence and SLAs against each area, so you hold your platform accountable to a written contract instead of a hopeful assumption.