Microsoft runs the infrastructure behind Microsoft 365, so is every document, mailbox, Teams message, permission, and policy automatically recoverable whenever your business needs it? The short answer is no. Platform availability, deleted-item recovery, retention, eDiscovery, and backup solve different problems. A service can remain available while an authorized user deletes information, an attacker changes it, or a retention window expires. The more useful question is which recovery mechanism applies to each failure scenario.
Microsoft 365 backup adds fast, policy-based recovery for core collaboration workloads, yet its current boundary is specific. It protects Exchange Online, SharePoint Online, and OneDrive for Business, with Teams coverage depending on where the underlying content is stored. Recovery depth, restore destination, identity health, administrative access, and evidence requirements still determine whether a restore will meet the business need. Those details matter more than a simple yes-or-no claim that the tenant is backed up.
This guide separates Microsoft's service resiliency, native recovery, Purview controls, first-party Backup, and independent protection options. It explains what each layer can recover, where the current gaps sit, and how to test the resulting design against recovery point and recovery time objectives. Calance can support that work through its managed Microsoft 365 services, including environment assessment, governance, monitoring, and managed support. The goal is a defensible recovery operating model, not a product checklist.
Microsoft 365 combines controls that are often discussed as one feature. Treat them as four layers with distinct triggers, time horizons, and purposes. Microsoft's shared responsibility guidance makes the division clear: Microsoft operates the SaaS platform, while the customer remains responsible for its data, identities, access, and configuration choices. A sound Microsoft 365 backup design maps each recovery outcome to the layer that can deliver it, while the wider Microsoft 365 data protection program assigns ownership.
Microsoft uses redundancy, replication, monitoring, and service engineering to keep the workloads available. That protects against infrastructure faults. It does not provide a customer-selected historical state after an accepted user, administrator, application, or attacker change.
Recycle bins, version history, and deleted-item retention are the quickest response to many ordinary errors. Their windows and behavior differ, so operators must act before an item ages out or broad rollback becomes necessary.
Retention policies and labels can retain content for regulatory, records-management, or organizational requirements. eDiscovery helps authorized teams find and export relevant information. These controls center on preservation and investigation, not on returning a workload to a clean operational state after widespread corruption.
The paid first-party service introduces centralized protection policies and restore points for supported workloads. It can shorten recovery after a large deletion or ransomware event, but it does not absorb every application, identity object, configuration, or legal obligation in the tenant.
| Layer | Main purpose | Typical recovery problem | What it is not |
|---|---|---|---|
| Service resiliency | Keep Microsoft services running | Hardware, storage, or datacenter failure | A customer-selected historical restore |
| Native recovery | Reverse recent user or admin mistakes | Deleted file, old version, removed mailbox item | A uniform tenant-wide recovery system |
| Purview retention | Preserve information under policy | Records, legal hold, investigation | Operational workload rollback |
| First-party Backup | Recover supported workloads from restore points | Broad deletion, corruption, ransomware rollback | Complete protection for every tenant dependency |
Native controls should be the first runbook branch for a recent, well-scoped mistake. They are already close to the workload, usually require fewer steps, and can avoid a larger restore. Their weakness is inconsistency: each service has different clocks, object rules, and administrative paths. An Office 365 backup assessment should document these controls before evaluating paid layers, because they remain part of day-to-day recovery even after another service is added. The chosen path should be tied to incident age, affected workload, administrator authority, and the required operational outcome before teams escalate to a broader restore.
SharePoint and OneDrive provide version history, two-stage recycle bins, and Files Restore. Microsoft's native SharePoint and OneDrive recovery guidance describes a 93-day recycle-bin period and recovery to an earlier point within the previous 30 days. These controls suit recent deletion, overwrite, or file-level ransomware while the required state remains within that window. SharePoint consulting and support services can align the recovery path with governance, permissions, and operational ownership.
Exchange Online supports recovery of deleted items and, when configured, preservation through holds and retention. Microsoft's deleted-item documentation sets a 14-day default retention period that administrators can extend to 30 days. Recoverable Items behavior, inactive mailboxes, and holds introduce further paths, but they need deliberate configuration and role-based procedures.
Teams recovery follows its storage architecture. Channel files live in SharePoint; files shared in chats generally live in the sender's OneDrive; conversation and membership data follow different services and retention rules. A deleted Microsoft 365 group can usually be restored during its 30-day soft-deleted period, bringing back connected resources such as its mailbox, SharePoint site, and Team where applicable. A Team recovery runbook should identify which underlying service owns each object before an incident occurs.
Recovery timeline: Immediate mistake → version history, Undo, or the first-stage recycle bin; recent deletion → second-stage recycle bins, Recoverable Items, or soft-deleted group restoration; broad rollback → Files Restore or an available protected restore point; retention or legal preservation → Purview, holds, and eDiscovery under the applicable policy.
Current first-party coverage centers on three storage workloads. The Microsoft service overview lists Exchange Online, SharePoint Online, and OneDrive for Business. Microsoft 365 backup is a focused Microsoft 365 backup solution, rather than a tenant image. Scope depends on protection policies, billing, supported objects, and application storage.
Protection can cover selected sites, supported rule-based selections, or a broader eligible scope. Full restoration can use the original or a new URL. Granular recovery can return selected files and folders to the original location or a new folder, subject to current limits.
OneDrive protection operates at the account level, supporting full-account and granular file or folder recovery. Leavers, deleted accounts, ownership, and licensing still need runbook treatment because the destination and authorized recipient may have changed.
Exchange protection includes supported user and shared mailboxes; room and group mailboxes are unsupported. Operators can restore all supported content or selected items to the current mailbox, either in place or in recovered folders.
Teams is not one backup object. Channel files can be recovered through protected SharePoint sites, and chat-shared files through the owner's protected OneDrive. Chats, channel posts, reactions, meeting context, and other service-resident conversations remain outside the current workload list.
| Workload or data type | First-party Backup | Native recovery elsewhere | Important limitation |
|---|---|---|---|
| SharePoint sites and files | Yes | Versions, recycle bins, Files Restore | Policy scope and restore-point window apply |
| OneDrive accounts and files | Yes | Versions, recycle bins, Files Restore | User lifecycle and destination must be planned |
| User and shared mailboxes | Yes | Recoverable Items, retention, holds | Room and group mailboxes unsupported |
| Teams channel files | Yes, through protected SharePoint sites | SharePoint recovery | Team settings and conversations are separate |
| Teams chat-shared files | Potentially, through protected OneDrive | OneDrive recovery | Coverage follows the file owner's account |
| Teams chats and channel posts | No | Retention, eDiscovery, limited native paths | No operational Backup restore today |
Recovery design needs two coordinates: the age of a usable point and the narrowest restorable scope. The current Microsoft 365 backup and recovery service offers policy windows of three months, six months, one year, or two years. Review existing policies before assuming they retain two years; point density and granularity also vary by workload.
The configured protection policy sets the maximum horizon. Reducing or disabling protection can trigger a recovery grace period, which should remain a safety mechanism. Requirements must state whether the selected window covers delayed discovery.
For full SharePoint and OneDrive restores, Microsoft documents points about every ten minutes for 14 days, then weekly through day 365. Exchange has points about every ten minutes through the first year. The same table does not specify cadence for months 13 through 24, so plans should not assume one.
Microsoft's restore documentation describes generally available SharePoint and OneDrive file-and-folder recovery, with roughly daily points for 14 days and weekly points through day 365. Exchange supports all-content or selected-content restore, with current selection and item limits.
Full SharePoint and OneDrive recovery can use the original or an alternative URL; granular content can use its original location or a new folder. Exchange targets the current mailbox, in place or in recovered folders. Destinations are workload-specific.
| Recovery dimension | Exchange Online | SharePoint Online | OneDrive for Business |
|---|---|---|---|
| Recovery window | 3, 6, 12, or 24 months | 3, 6, 12, or 24 months | 3, 6, 12, or 24 months |
| Recent restore-point density | About every 10 minutes | Full: about every 10 minutes | Full: about every 10 minutes |
| Older density | First year: about every 10 minutes | Weekly, days 15–365 | Weekly, days 15–365 |
| Granular restore | Selected supported mailbox content | Files and folders | Files and folders |
| Alternative destination | Current mailbox; in place or recovered folders | Original or new site/folder | Original or new location/folder |
| Key limitation | Current selection and item limits | Granular points are less frequent | User lifecycle affects destination planning |
A written gap register makes the product boundary manageable. Office 365 backup planning should cover unsupported workloads, identity and configuration dependencies, history beyond policy, and destinations outside the source tenant. Native controls or rebuild procedures can cover some gaps; others may justify another service.
Teams chats, channel posts, reactions, and conversation context sit outside the current protected workload set. Purview may preserve and locate messages, but it does not place an entire conversation state back into the live Team.
Planner, Forms, Power Platform, Loop, Stream metadata, Viva, and application settings are not automatically protected. Content stored in supported services may inherit a control, but application behavior and relationships still need separate recovery. Application maintenance and support services can document dependencies and rebuild steps beyond stored files.
Conditional Access policies, roles, transport rules, connectors, device settings, app registrations, retention configuration, and tenant settings are outside a collaboration-data restore. Exports, supported infrastructure-as-code, change control, and runbooks fill much of this gap.
An alternative site URL is not a cross-tenant restore. Mergers, divestitures, tenant compromise, sovereignty, and migration need separate identity mapping, permissions, domains, dependencies, and chain-of-custody design.
Workload gap: The first-party service does not directly restore every conversation, application record, relationship, or metadata layer. Microsoft may still provide retention, eDiscovery, native recovery, or storage-level protection for part of the scenario. A separate process becomes relevant when the business requires a complete live restoration that those controls cannot deliver.
Identity and configuration gap: Collaboration-data recovery does not recreate every identity, policy, role, connector, or tenant setting. Microsoft may provide Entra recovery, audit history, exports, or service-specific controls for supported elements. Broader protection or a documented rebuild process becomes relevant when configuration loss or recovery time would exceed business tolerance.
Retention-window gap: The selected Backup policy defines the available operational history, while Purview can preserve information according to legal or records requirements. Another recovery layer becomes relevant only when delayed discovery could exceed the configured backup window and the organization still needs a usable historical workload state.
Recovery-destination gap: Supported alternative SharePoint or OneDrive destinations do not create a general cross-tenant recovery capability. Microsoft still provides migration and identity tools for supported scenarios. Separate migration, cross-tenant, or independently administered recovery procedures become relevant when tenant separation, sovereignty, or custody is an explicit requirement.
These controls may keep copies of similar content, but their purpose changes what an administrator can do later. Microsoft 365 backup supports restoration; a defensible Microsoft 365 data protection program also assigns owners across operations, security, legal, compliance, and records management. It prevents a retention policy from being presented as a tested disaster-recovery plan.
Backup supports recovery from a known point after deletion, corruption, or attack. The success measure is whether users and business processes can work again within agreed time and data-loss tolerances. It needs scope, restore permissions, clean-point selection, validation, and evidence from exercises.
Purview retention can preserve content despite a user's deletion or dispose of it when the policy period ends. It applies records and compliance logic. Microsoft's retention documentation should guide policy design, especially where multiple retention rules, labels, holds, and workload locations interact.
eDiscovery supports search, collection, review, and export for investigations or legal matters. It does not normally reconstruct a site, mailbox, or collaboration experience for end users. Access is intentionally controlled, and the evidentiary workflow can require preservation of context, custody, and reviewer actions.
Restore decisions must account for governance changes since the selected point. Microsoft's Backup privacy and compliance guidance notes that content existing only in backup is not searchable through current eDiscovery tooling and that retention or deletion policies do not flow into backup. Restored sensitivity labels can also return to their state at the restore point. Compliance teams should therefore review historical-state effects before broad restoration.
| Control | Main question | Best suited for |
|---|---|---|
| Backup | Can operations return to a usable earlier workload state? | Recovery after deletion, corruption, destructive change, or attack, with an approved point, destination, and validation process |
| Retention | Must information be preserved or disposed of under policy? | Regulatory, records-management, legal-hold, and organizational information-lifecycle requirements |
| eDiscovery and legal preservation | Can authorized reviewers find, preserve, collect, review, and export relevant information? | Investigations, litigation, regulatory response, and controlled evidentiary workflows rather than live workload restoration |
Data restoration depends on a working control plane. If administrators cannot authenticate, privileged roles are compromised, or the destination user no longer exists, a technically valid restore point may still be unusable. Microsoft 365 data protection therefore needs a parallel identity recovery plan with separate owners, protected credentials, and tested escalation paths.
Microsoft Entra Backup is currently documented separately and in preview. It takes daily automatic backups with a recovery window of up to seven days for supported objects and properties, including selected users, groups, applications, service principals, Conditional Access policies, named locations, authentication methods, and authorization policy settings. It requires eligible Microsoft Entra licensing.
Object support does not mean every property, relationship, or deletion state is recoverable. Microsoft documents exclusions and warns that hard-deleted objects cannot be restored. Organizations should compare the service's current object-property matrix with their real dependencies and retain configuration exports or rebuild instructions for unsupported elements.
Use emergency access accounts, phishing-resistant authentication, least privilege, time-bound elevation, separate role assignments, alerting, and multi-person approval where possible. Store runbooks and escalation contacts somewhere accessible if the tenant is impaired. Calance's Microsoft cloud consulting services can help connect identity governance, security baselines, collaboration controls, and recovery ownership across the wider Microsoft environment.
Recovery dependency chain: Confirm that protected data and restore points are healthy → restore or secure identity services and trusted authentication → establish clean privileged administrator access → recreate or recover the required Entra objects and relationships → assign an authorized backup administrator under monitored access → start the workload restore and validate permissions, ownership, and user access.
Ransomware can involve stolen credentials, malicious OAuth consent, mailbox rules, encryption, deletion, or endpoint persistence. Restoring before containment can return clean data to a hostile environment. The plan must join security response, identity control, backup administration, and business validation.
Microsoft describes protected data as append-only, so normal backup operations cannot change earlier data. The service stays inside Microsoft's trust and data boundary, and offboarding includes a recovery grace period. Administrators and policy changes still need protection and monitoring.
Separate backup roles from daily administration. Require strong authentication and managed devices, use just-in-time elevation, alert on policy or offboarding changes, and retain approvals. Managed detection and response services can connect suspicious identity or endpoint activity with containment and recovery decisions under the agreed scope.
The newest point may contain encrypted files, malicious rules, or altered permissions. Build the incident timeline from identity, endpoint, audit, and workload evidence. Choose the latest state before harmful activity, with a clear account of business changes that will be lost.
Test integrity, permissions, sharing, mailbox rules, automation, labels, access, endpoint health, and monitoring. Keep restored systems restricted until the incident commander and business owner accept the evidence.
Ransomware recovery sequence: Contain affected identities, endpoints, applications, and network paths → identify the scope and construct an incident timeline → secure identity services and privileged administrative access → select and approve the last trustworthy restore point → restore supported data into the planned destination → validate security, integrity, permissions, and business function → reopen access in controlled stages and continue monitoring.
Backup isolation question: First-party restore points stay within Microsoft's trust and data boundary. If policy requires custody under an independently administered trust boundary, record that as a separate architectural requirement. The distinction concerns control objectives and administrative separation; it is not a claim that Microsoft's boundary is inherently unsafe.
Microsoft 365 backup uses pay-as-you-go billing based on protected content, so modeling starts with eligible workload size. As of August 2026, Microsoft's pricing documentation lists $0.15 per GB per month. Capacity can include live data, archives, and retained deleted or versioned content. Restores have no separate service charge, though internal labor remains.
Baseline protected capacity by workload, then model growth, churn, archives, and policy changes. Recoverable mailbox content and site versioning can make protected capacity larger than the live-content view. Finance and IT should reconcile forecasts with billing.
Billable capacity includes qualifying versions and deleted data held for recovery. Retention choices, user behavior, migrations, and remediation can change the footprint, so cost reviews should accompany recovery tests and governance changes.
As of August 2026, Full Workload Backup is in preview. It discovers new eligible protection units on a described 24-hour check cycle. Dynamic rule-based selection is also preview functionality. Confirm status, eligibility, and licensing before treating either as a production control.
A selective Microsoft 365 backup solution may focus on executive mailboxes, regulated sites, or critical OneDrive accounts. It can control cost, but requires classification and monitoring. New sites, renamed groups, leavers, ownership changes, and projects can otherwise fall outside policy.
| Scope approach | Cost tendency | Coverage benefit | Operating risk |
|---|---|---|---|
| Broad workload protection | Higher and easier to forecast | Fewer eligibility gaps | Includes low-value content and more retained capacity |
| Selective protection | Lower if classification is accurate | Spend follows criticality | Missed or newly created objects can remain unprotected |
| Tiered policies | Balanced by business class | Window and scope follow impact | Requires dependable ownership, tagging, and review |
Organizations ask different recovery questions. A small tenant may accept native tools and rebuild steps; a regulated or acquisition-heavy enterprise may need longer history, independent administration, or cross-tenant restoration. An Office 365 backup decision should follow requirements, not a blanket product claim.
This can fit modest data volumes, rapid incident detection, adequate native windows, and tolerance for manual recovery. Document the decision, owners, and expiry clocks in the service desk runbook.
The service fits fast recovery of supported Exchange, SharePoint, and OneDrive data inside the Microsoft boundary. Its workload list, retention options, identity dependency, and destination behavior must match the scenarios.
Another Microsoft 365 backup solution may be justified for unsupported data, Teams conversations, longer history, independent administration, cross-tenant needs, exports, or external requirements. Test vendor claims through restores, contract terms, security review, and exit planning.
Some organizations use native recovery for simple mistakes, first-party Backup for core-workload rollback, Purview for governance, and another process for remaining gaps. IT infrastructure and operations services can connect backup, disaster recovery, monitoring, ownership, and support without presuming one architecture fits every environment.
| Requirement | Native recovery only | First-party Backup | Additional layer | Layered model |
|---|---|---|---|---|
| Core Exchange, SharePoint, OneDrive | Recent, item-specific recovery | Strong supported coverage | Varies by provider | Native speed plus broader rollback |
| Teams chat recovery | Limited | Not covered | May be available | Add only if required |
| Other SaaS applications | No | No | Often supported separately | Common for multi-SaaS estates |
| Long operational history | Limited | Up to selected 24-month policy | May extend further | Match history to data class |
| Fast Microsoft-native restore | Workload dependent | Primary strength | Integration dependent | First-party path for core data |
| Independent trust boundary | No | No | Possible | Use when control requires it |
| Cross-tenant recovery | Limited | Not a general target | May be supported | Design identity mapping separately |
| Cost control | Included controls | Capacity based | Contract dependent | Tier by criticality |
| Compliance and search | Retention tools required | Backup-only data has search limits | Feature dependent | Keep Purview as governance layer |
A healthy policy has not proved business recovery. Microsoft 365 data protection testing needs measurable recovery point objectives, recovery time objectives, and acceptance criteria. Include failed and partial restores because permissions, destinations, identity changes, conflicts, and application relationships can make a successful job unusable.
RPO states the maximum tolerable data loss. Compare it with restore-point density by workload and age. A ten-minute pattern for recent full restores does not imply the same granularity for older file-level recovery, and a two-year window does not promise daily points.
RTO starts before the restore button. It includes detection, authority, identity containment, clean-point selection, execution, conflict handling, validation, and reopening. A Microsoft 365 backup and recovery exercise should time the whole path, not only the restore job.
Run table-top, item, site or mailbox, and ransomware exercises. Microsoft currently limits recovery performed solely for testing to no more than twice per month per protection unit; actual incident recovery is not subject to that limit.
Capture the request, approvals, point, scope, times, errors, validation, acceptance, and lessons. Assign corrective actions an owner and due date. Structured Azure migration services can support continuity planning where Microsoft 365 depends on Azure-hosted applications, identity components, or migrated workloads.
Recovery drill checklist
Microsoft 365 backup products create restore capabilities; an operating model makes them dependable. It connects inventory, classification, policy scope, identity, security response, legal duties, testing, and ownership. It records recoverable scope, authority, destination, history, timing, and evidence.
Inventory users, shared mailboxes, sites, OneDrive accounts, Teams, groups, applications, identities, and privileged roles. Map business services to storage and upstream dependencies. Record owners, data class, obligations, tolerable loss, and the effect of restoring an old state.
Separate platform and backup administration, incident command, legal approval, privacy review, and business acceptance. Define who declares recovery, selects a point, approves an alternative destination, and reopens access. Keep emergency contacts outside the tenant.
Reconcile eligible objects with policies, billing, licenses, new sites and mailboxes, leavers, mergers, and exceptions. Alert on offboarding, policy reduction, role changes, and failures. Review preview-based scope rules until their production behavior is accepted.
Review after acquisitions, divestitures, migrations, new duties, incidents, or Microsoft feature changes. Update RPO, RTO, policy windows, sources, and drills. Check current documentation before relying on preview features or expanded granularity.
The team can assess workload coverage, map recovery requirements, review identity and administrative dependencies, design monitoring and testing, and support planning through Calance managed cybersecurity support services. The engagement depends on the tenant, business impact, compliance obligations, and service model. Microsoft 365 backup and recovery choices remain the customer's governance decision.
Recovery loop: Discover the data, workloads, identities, settings, and dependencies → classify business impact, legal duties, RPO, and RTO → protect them with the appropriate native, retention, backup, and independent controls → monitor policy health, scope changes, role changes, and billing → test technical recovery and decision-making under realistic conditions → recover through containment, clean-point approval, and the runbook → validate security, integrity, permissions, and business acceptance → review the evidence, close gaps, and update policies and training.
1. Does Microsoft 365 include backup?
Microsoft includes platform resiliency and workload-specific recovery features such as version history, recycle bins, and deleted-item retention. Microsoft 365 backup adds policy-based restore points for supported workloads. Customers still own configuration, access, recovery planning, validation, operational testing, and compliance decisions.
2. What does Microsoft 365 Backup currently protect?
The current service protects eligible Exchange Online user and shared mailboxes, SharePoint Online sites, and OneDrive for Business accounts. Teams files may be covered through SharePoint or OneDrive storage, while chats, channel posts, reactions, and other conversation data remain outside scope.
3. Does Microsoft 365 Backup protect Teams chats?
No. Current first-party protection does not restore Teams chats, channel posts, reactions, or related conversation context. Files used in Teams may be recoverable when their underlying SharePoint site or OneDrive account is protected, so administrators must distinguish file storage from message data.
4. Do I still need Office 365 backup if Microsoft has recycle bins and retention?
It depends on recovery objectives. Native controls can handle many recent mistakes, while retention preserves information for policy or legal needs. Additional backup may be justified for broader rollback, longer operational history, independent administration, unsupported workloads, or recovery destinations that native controls cannot provide.
5. How long does Microsoft 365 Backup keep restore points?
Supported protection policies can be configured for three months, six months, one year, or two years. Available restore-point frequency varies by workload, item granularity, and age. Existing policies and published service documentation should be checked before assuming a particular window or point density.
6. Can Microsoft 365 Backup restore individual files and folders?
Yes. Granular SharePoint and OneDrive file-and-folder recovery is generally available. Items can return to the original location or a new folder, subject to current constraints and restore-point density. Full site or account restoration remains useful when damage is broad or difficult to enumerate.
7. Does Microsoft 365 Backup protect shared mailboxes?
Yes, supported shared mailboxes can be protected alongside user mailboxes. Room and group mailboxes are currently unsupported protection units. Administrators should confirm mailbox type, policy inclusion, licensing and billing status, destination behavior, and permissions before relying on the service for a recovery scenario.
8. Is Purview retention the same as Microsoft 365 backup?
No. Purview retention preserves or disposes of information according to policy, and eDiscovery supports authorized search and review. Backup focuses on returning supported workload data to an earlier usable state. Organizations commonly need both governance controls and tested operational recovery procedures.
9. Does Microsoft 365 Backup protect Microsoft Entra ID?
No. Collaboration-data protection and Entra recovery are separate service areas. Microsoft Entra Backup is currently in preview with its own licensing, supported object and property list, daily capture pattern, seven-day window, and exclusions. Identity exports, emergency access, and rebuild runbooks remain important.
10. Can Microsoft 365 Backup recover from ransomware?
It can restore supported Exchange, SharePoint, and OneDrive data from an earlier point, which can help recovery. A safe ransomware response must first contain attackers, secure identities and administrators, identify a trustworthy point, then validate permissions, labels, rules, endpoints, and business function.
11. Do businesses still need a third-party Microsoft 365 backup solution?
Some do, while others can meet requirements with native controls and first-party Backup. Another layer may be reasonable for Teams conversations, other SaaS applications, longer history, independent custody, cross-tenant restoration, or different exports. Decide through documented requirements and tested restores, not a universal rule.
12. How can Calance help with Microsoft 365 backup and recovery?
Calance can assess workload coverage, map business requirements to recovery controls, review identity and administrative dependencies, design monitoring and drills, and support managed operations. Recommendations depend on the tenant, risk, compliance duties, budget, and existing tools; specific recovery outcomes require agreed scope and testing.