A ransomware recovery can return readable documents while still leaving out legitimate work completed near the attack. Treat “clean” and “complete” as separate acceptance tests. A file that opens without an error may still contain damaged content or lack an important final revision.
Contain the incident before restoring data
Involve the organization’s incident-response team and isolate affected devices under its direction. Do not restore files into a device that may immediately encrypt or upload damaged copies again. Microsoft places device cleaning before restoration in its ransomware recovery guidance. The consumer notification screens described there should not be assumed to appear for every business account.
Preserve relevant incident evidence using approved procedures. Do not open suspicious attachments, enable macros or run an unfamiliar decryptor simply to see whether a document is recoverable. Use the clean recovery environment approved by IT.
Identify the work that must be recovered
Make a short list of critical documents and the last legitimate change expected in each. Ask their owners for specific content checks: a revised contract amount, the final worksheet, or the new drawing revision. Record the first observed damage separately from the alert time; detection may occur after the attack began.
Preserve verified unaffected work outside the planned rollback scope. Moving it to another folder within the same OneDrive is not sufficient. Label recovery candidates clearly so that an unvalidated file cannot be mistaken for a clean production copy.
Recover candidates according to what is missing
- Existing but damaged file: inspect available historical versions with IT and identify one that passes both the security review and the owner’s content check.
- Deleted file: investigate the owning location’s recycle-bin recovery options. Record its original path to avoid confusing similarly named items.
- Local-only final edits: have the response team preserve and assess authorized device data. Do not reconnect the device merely to upload it.
- No suitable cloud candidate: check an approved backup’s actual coverage. Do not promise that changing retention today recreates lost versions.
Choose a rollback from incident evidence
For widespread damage, follow Microsoft’s OneDrive restore procedure after containment. Review the earliest unwanted activity and everything selected after it. There is no separate start/end scanning range that discovers additional clean versions.
If a useful edit came after the proposed recovery point, list it as work to recover separately. Do not move the point into a known attack period just to include a newer timestamp. Business history availability must be checked against the actual version settings, rather than assumed to expire universally after 30 days.
Validate before returning to normal work
Have IT approve the security state and document owners verify the missing revisions. Check linked files as well as standalone documents. Keep an exception list for anything incomplete, and reconnect devices only under the response plan. A successful restore message alone does not prove that the incident is contained or that every recent edit has been recovered.