Microsoft 365 is an essential part of day-to-day operations for many organisations. Employees communicate through Outlook and Teams, collaborate in SharePoint and store documents in OneDrive. Because these services are generally readily available, it is easy to assume that the data is adequately protected too. Yet the availability of a service does not establish whether important information can be recovered in the right way after loss or corruption.
Microsoft provides several features for data protection and recovery. The relevant question is whether the capabilities your organisation has actually put in place meet its business needs. What information must be recovered, how much data loss is acceptable and when must employees be able to resume work? These questions are the starting point for a recovery strategy, even when the data is held in the cloud.
A reliable cloud service is only part of a recovery strategy
In a traditional IT environment, the distinction between production data and backups is often visible: data is held on a server and copied to a separate backup system. In Microsoft 365, availability, version history, retention policies and recovery are more closely integrated into the services themselves. This offers valuable capabilities, but it can also make it harder to assess exactly what a particular feature addresses and where additional measures are needed.
Availability concerns access to a service, for example when the underlying infrastructure fails. Retention concerns keeping information according to defined rules, while version history helps users find earlier versions of files. Backup and recovery must ensure that data can be made available in a usable form after loss or corruption. These functions can complement one another, but they serve different purposes. A retained document, for example, is not necessarily easy to restore within the wider context in which employees need it.
A feature that allows a user to retrieve a deleted file therefore does not establish whether the organisation can recover thousands of files, several mailboxes or an entire business process after a serious incident. A sound approach starts with the required outcome. Only then should the available features, settings and procedures be assessed to establish whether they are sufficient.
What the built-in features do and do not demonstrate
SharePoint and OneDrive provide ways to retrieve earlier file versions and deleted files. Exchange Online includes features for recovering deleted messages; retention policies and legal holds may also help preserve information. Which options are usable depends on the service, its configuration and the applicable terms. The presence of a feature therefore does not mean that it protects all the data you need or provides every recovery point you might require.
Microsoft also offers additional backup functionality through Microsoft 365 Backup. This requires its own assessment and configuration; using Microsoft 365 does not in itself mean that this protection is active. Equally, retention and legal holds are not automatically a substitute for operational recovery at scale. It is therefore important to establish which provisions are actually enabled, what information they cover and how recovery is carried out. Current capabilities and terms are set out in the Microsoft 365 Backup documentation.
For everyday incidents, restoring a file or message may be enough. Widespread data loss presents a different challenge: establishing what has been affected, choosing a trustworthy recovery point and restoring the data in the right context. A synchronisation error can propagate unwanted changes, while ransomware can encrypt files whose changes are then synchronised to the cloud. Earlier versions are valuable in such circumstances, but the feasibility and speed of the complete recovery process require a separate assessment.
A compromised account reveals the recovery challenge
A security incident often affects more than one file or device. An attacker who takes over a user account can use its existing permissions to modify or delete information. The impact therefore depends in part on the access that account holds. Restricting further access is necessary, but it does not undo earlier changes. Investigation of the incident's scope and recovery of the data need to be coordinated.
When a user account puts project information at risk
An employee at a professional services firm has access to several SharePoint sites containing project documents, contracts and shared files. The account is compromised. The attacker uses its existing permissions to modify and delete large numbers of files; synchronisation also makes the effects visible on colleagues' devices.
Once the incident is discovered, IT restricts further access and the team investigates which data has been affected and when changes became untrustworthy. Meanwhile, employees want to resume their projects. An earlier version is sufficient for some documents, whereas the loss of recent changes elsewhere could lead to incorrect agreements or incomplete records.
The organisation may have several recovery options, but it first needs to establish which combination is appropriate. The team must restore the right files without overwriting legitimate changes, check access and prevent the attacker from making further changes. Simply reporting that files have been restored does not assure employees that they are once again working with trustworthy information.
This fictional example shows that recovery capability depends on more than a technical provision. Understanding the affected data, managing access, determining the recovery sequence and making decisions also shape whether work can safely resume.
Business-critical information determines recovery objectives
Not all information in Microsoft 365 has the same significance for business operations. A temporary working document is generally easier to reconstruct than a contract file, a collection of project records or a mailbox containing customer agreements. Teams and SharePoint may also have become part of processes previously handled in separate business applications. The assessment should therefore start with the work that depends on the information, rather than solely with the volume of stored data.
For each important process, establish where the information is held, who uses it and what loss or prolonged unavailability would mean. Then determine how much data loss is acceptable and how quickly the process must be operational again. These limits are referred to as RPO and RTO. An archive that changes infrequently may need different objectives from a project environment where employees continuously record new agreements and documents. The ability to reconstruct missing information, and the errors that may arise in doing so, also matter.
Always distinguish between technical recovery and the resumption of work. A restored document library has limited value if employees cannot access it or essential integrations are missing. Allow time for investigation, checks and a safe return to use as well. This produces a recovery objective that applies to the business process and can subsequently be tested in practice.
Assess additional backup for coverage and security
Additional backup can be worthwhile when existing recovery capabilities do not adequately address the risks and recovery objectives. An organisation may need different retention options, more manageable recovery at scale, central reporting or protection that is less dependent on the primary environment. This does not make additional backup an automatic choice for every organisation. The assessment starts with the gap that needs to be addressed and the costs that are proportionate to it.
Assess both Microsoft's additional services and any solutions from other providers against their actual coverage. Support for Exchange Online, SharePoint, OneDrive and elements of Teams varies between solutions. Protecting files used through Teams, for example, does not automatically mean that conversations, settings and all other elements can also be restored. Establish which data and metadata are included, which recovery points are available and whether individual items or larger collections can be restored. Check what happens to protection when accounts, sites or settings change too.
Backup storage and administration deserve the same attention. If the same administrator accounts can affect both production data and recovery provisions, a single compromised account can put both at risk. Strong authentication, limited administrative privileges, separation of responsibilities and protection against unwanted deletion help reduce this risk. How independent a provision really is depends on the configuration of access, storage and deletion controls; the label 'backup' alone does not establish this.
Finally, document who may initiate recovery, which checks are required and how recovery actions are recorded. An additional provision delivers value when it protects the required data, is adequately secured itself and supports a workable recovery process. A successful daily backup job demonstrates only part of that.
Recovery tests put assumptions to the test
A report showing successful backup jobs confirms that certain tasks have been completed. Whether complete, trustworthy data can be recovered within an acceptable time becomes clear only through recovery testing. Start with a defined scenario, such as a deleted document, and extend testing where necessary to a SharePoint library, several mailboxes or the information required for an entire business process. The scope of the test should reflect the risk and the recovery objectives.
Check not only whether data becomes technically available, but also whether the correct versions, relevant metadata and access permissions are present. Ask users to assess whether they can resume their work, and record how long investigation, restoration and checks actually take. In a security incident, it must also be clear how the trustworthiness of the recovery point is established and which conditions must be met before the data is brought back into use.
A test should also make clear what falls outside the scenario tested. Successfully restoring one file does not demonstrate recovery of all project information at scale. Compare the measured results with the agreed objectives, record shortcomings and assign someone to follow up improvements. New data locations, different permissions or changes to business processes may warrant reassessing coverage and recovery procedures.
Recovery capability needs clear responsibility
Microsoft manages the infrastructure and provides the functionality of its services. An IT service provider can configure, secure and monitor the environment and manage additional provisions. The organisation itself must identify essential information, explain the consequences of loss and decide which residual risks are acceptable. These responsibilities need to come together in concrete agreements about protection, oversight and recovery.
This includes clarity about day-to-day operations: who checks that protection is working properly, who responds to alerts and who coordinates recovery? Also establish who decides which information takes priority and who authorises work to resume after checks. Without these arrangements, even a technically sound solution can prove insufficient during an incident, for example when nobody has the authority to approve a significant recovery action.
Microsoft 365 deserves the same attention to continuity as other business-critical systems. Malenco therefore assesses the relationships between data, user permissions, security, management and the processes that depend on them. Testing existing capabilities against concrete recovery objectives reveals where the foundations are sufficient and where improvements are needed. Ultimately, the value of a backup is determined by the extent to which your organisation can recover its important information and safely resume work.
