Cybersecurity

Backup and recovery that has to hold under real failure conditions

For many Australian organisations, the question is no longer whether backup jobs are running. It is whether recovery would actually work across Microsoft 365 data, core systems, identity, administrator access and the dependencies that determine the order of restoration.

Inlight IT helps strengthen the recovery position across backup architecture, Microsoft 365 data protection, restore testing, identity recovery, evidence and the operational discipline needed to keep recovery reliable as environments change.

Discuss Backup and Disaster Recovery See the recovery areas
Recovery areas
Protect
Microsoft 365 · servers · workloads · critical data
Preserve
Immutable backup · offsite copies · retention
Recover
Identity · administrator access · privileged recovery
Validate
Restore testing · evidence · recovery records
Operate
Monitoring · remediation · periodic improvement
Overview Recovery areas Architecture When it matters Related work FAQ
The critical context

Backup jobs can be green while recoverability remains unproven

Backup software can be deployed, jobs can complete and dashboards can show green, while the business still carries serious recovery risk. The issue is rarely one control in isolation. It is the relationship between backup coverage, restore testing, Microsoft 365 protection, administrator access, identity, service dependencies and the evidence available when recovery has to be proven.

Recovery is what happens after the backup job. It is the sequence, access model, restore evidence, critical system order and operational ownership behind the technology.

For that reason, backup should be treated as an operating discipline, not a once-configured technical control — reviewed, tested and improved as the environment changes.

The question is not "are we backed up?"
The useful question is: what can recover, how quickly, in what order, and under whose control?
Recovery sequence
  1. Backups
  2. Infrastructure
  3. Applications
  4. Data
  5. Validation
  6. Operations
Recovery confidence comes from the full operating sequence, not from a green dashboard alone.
The connected areas

The same weaknesses often appear across several backup and recovery concerns

Backup and disaster recovery gaps often sit between systems, not inside one tool. A business may have backup software, Microsoft 365 retention, endpoint controls and cloud platforms, but still lack a clear recovery position if the architecture, access model, restore evidence and dependency order are not joined together.

01Backup coverage and immutabilityBackup software has been deployed in most environments, but coverage, retention and immutability often need closer attention. The business needs to know what is protected, what is excluded, how long data is retained and whether recovery points are protected from accidental deletion, compromise or ransomware. Immutability should not be treated as a checkbox. The practical question is whether an attacker or compromised administrator could reach, alter or delete the backup copies inside the retention window.
02Microsoft 365 backup assumptionsMicrosoft 365 native retention is useful, but it is not the same as an independent backup and recovery position. Exchange Online, SharePoint, OneDrive and Teams may contain project records, finance data, legal correspondence, client documents and operational history that need more than standard retention. The risk is assuming Microsoft 365 data is recoverable without understanding retention gaps, large-volume restore needs, malicious deletion, compromised administrator access or tenant-level recovery scenarios.
03Identity and administrator recoveryRecovery planning often assumes identity will be available. A cyber incident or administrator compromise can make that assumption unsafe. If Entra ID, Active Directory, MFA or privileged access is affected, the recovery sequence changes. Backup administration and privileged access need particular care. If the same credentials or administrative pathways can reach production and backup systems, a cyber incident can compromise the recovery path before encryption begins.
04Restore testing and recovery evidenceA successful restore of one file is not evidence that critical services can be recovered under pressure. The business needs dated, specific restore evidence: what was restored, when it was tested, how long it took, what dependencies were involved and what gaps were found. Restore testing is useful because it exposes reality. It shows whether the recovery path works, whether access is available, whether data is usable and whether assumptions in the runbook still match the environment.
05Service dependency orderThe recovery order is rarely the same as the backup order. File services may depend on identity. Microsoft 365 may depend on identity and network access. ERP may depend on databases, applications, infrastructure, DNS, vendors and service accounts. As environments change, recovery runbooks often fall behind. Cloud adoption, SaaS platforms, acquisitions, Microsoft 365 expansion and infrastructure refreshes can all change the sequence required to restore critical services.
06Cyber insurance and audit-ready evidenceCyber insurers, auditors and management increasingly ask for evidence: backup architecture, immutability settings, Microsoft 365 backup scope, restore test records, recovery time expectations and remediation priorities. The risk is answering from assumption. A stronger backup and recovery position gives the organisation clearer evidence about what is protected, what has been tested, what remains exposed and what should be improved first.
Failure map

Where recovery can still fail after a successful backup job

A completed backup job does not prove that the business can recover. The weak point is often outside the backup job itself: the restore path, identity access, Microsoft 365 assumption, service dependency order or missing evidence.

Backup job green Recovery blocked under pressure Restore testing outdated Microsoft 365 assumed protected Administrator recovery tied to the same identity Recovery order unknown Recovery time never validated No evidence for management or insurance

Backup success does not prove operational recovery. The recovery path has to be protected, tested, sequenced and maintained.

Recovery architecture

Layered recovery architecture

Recovery depends on layers working together. Backup copies are the base, but they are not enough on their own. Access, sequencing, validation, evidence and ongoing operation determine whether recovery can hold under pressure.

06Continuous operationMonitoring, remediation, documentation and periodic improvement.
05Recovery evidenceRestore tests, reports, logs, screenshots and management-ready records.
04Restore validationPractical recovery testing across systems, files, Microsoft 365 and critical workloads.
03Recovery sequenceIdentity, network access, applications, data, SaaS platforms and supplier dependencies.
02Recovery accessAdministrator accounts, MFA, privileged access and identity recovery paths.
01Protected backup copiesBackup coverage, immutable retention, offsite copies and protected storage.

The architecture is only useful if it is operated. Recovery coverage, evidence and remediation priorities need to stay visible as systems change.

Practical support

We strengthen the recovery position, not just confirm backups exist

Inlight IT helps organisations strengthen backup and disaster recovery through practical engineering, review, remediation, restore validation and ongoing operation. The work may involve backup architecture, Microsoft 365 data protection, immutable and offsite backup, restore testing, administrator access, recovery sequencing, documentation and monitoring.

The aim is not to produce a theoretical report. The aim is to make recovery more dependable: clearer coverage, stronger protection, tested restore paths, known dependencies and visible priorities for improvement.

How the work usually progresses:

The goal is simple: know what would recover, know what would not, and fix the highest-risk gaps before recovery is tested by a real incident.

01

Understand

Identify critical systems, protected data, existing backup coverage, current ownership and the recovery assumptions already in place.

02

Strengthen

Improve backup architecture, immutability, offsite protection, Microsoft 365 backup coverage, monitoring and administrative controls.

03

Validate

Test restore paths, confirm recovery access, document evidence and check whether the recovery sequence works in practice.

04

Operate

Monitor backup health, review failures, maintain documentation and keep recovery priorities visible as the environment changes.

When it matters

When the organisation needs evidence rather than assumption

Backup and recovery becomes more important when the business can no longer rely on reassurance. This usually happens when risk, insurance, infrastructure change, cyber exposure or support quality puts pressure on the recovery position.

01

Before cyber insurance renewal

Useful when the business needs clearer evidence for backup, MFA, privileged access, endpoint protection, recovery testing and incident readiness.

02

Before MSP review or transition

Useful when backup ownership, monitoring, restore testing, documentation, escalation or vendor accountability has become unclear.

03

After cloud, infrastructure or business change

Useful when Microsoft 365, Azure, SaaS platforms, local infrastructure, sites or critical applications have changed and older recovery assumptions may no longer be reliable.

The work turns backup assumptions into a clearer recovery position: what is protected, what can be restored, what would block recovery and what should be improved first.

Restore drill · evidence capture Illustrative sequence
What a tested recovery position looks like — dated, sequenced, evidenced.
Recent work

Recent backup and recovery work

Property development and construction · Microsoft 365 backup
JQZ
Recovery beyond native retention
Independent backup implemented across Exchange, SharePoint, OneDrive and Teams data, giving a recovery path that sits outside the Microsoft 365 tenant itself.
A more defensible recovery posture beyond native retention.
Read the case study →
Mining equipment and industrial services · Backup and recovery
PPK Mining Equipment
Backup inside the managed IT rhythm
Backup coverage reviewed around the systems and data the business actually uses, then monitored and maintained as part of the managed IT relationship rather than as a standalone tool.
Backup treated as an operating discipline, not a once-configured control.
Read the case study →
Materials handling and conveyor systems · Backup and recovery
VLI Conveyors
Coverage, restore pathways and ownership
Backup coverage confirmed across Microsoft 365, shared files and business systems, with restore pathways, escalation points and ongoing visibility defined alongside it.
A more controlled backup and recovery operating model.
Read the case study →
Common questions

Backup and disaster recovery questions

What is the difference between backup and disaster recovery?

Backup protects copies of data and systems. Disaster recovery focuses on restoring operations after disruption, including access, infrastructure, applications, dependencies, testing, evidence and recovery order.

Why can successful backup jobs still fail during recovery?

Backups can appear successful while restore testing is old, Microsoft 365 data is not separately protected, administrator access is unavailable, dependencies are unknown, backup storage is affected or recovery order has not been planned.

Does Microsoft 365 need separate backup?

Microsoft 365 includes resilience and retention features, but many organisations still need a dedicated backup and recovery position for Exchange Online, SharePoint, OneDrive and Teams. The right approach depends on data risk, retention needs, compliance and recovery expectations.

What is immutable backup?

Immutable backup is designed to prevent backup data from being changed or deleted for a defined period. It can reduce exposure to accidental deletion, compromise and ransomware, but it still needs to be configured, monitored and tested properly.

How often should restore testing happen?

Testing frequency depends on business criticality. Critical systems should have regular restore validation and documented evidence. Less critical systems may be tested less often, but the business should still know recovery time, recovery order and dependencies.

What does Inlight IT support in a backup and disaster recovery engagement?

Inlight IT can support backup architecture, Microsoft 365 backup, immutable and offsite backup, restore testing, administrator recovery access, recovery sequencing, monitoring, documentation and remediation priorities.

Practical next step

Strengthen the recovery position before it has to be proven under pressure

If backup confidence is based on dashboards, assumptions or old restore tests, Inlight IT can help strengthen the recovery position: what is protected, how it is secured, what can be restored, what would block recovery and what should be improved first.

Discuss Backup and Disaster Recovery