Search Results

A Microsoft 365 tenant incident can quickly move beyond IT, leaving teams unable to access email, files, identity and the services they rely on. This video shows why tenant recovery planning must account for the loss of normal administrative access. Most Microsoft 365 recovery plans begin with a comfortable assumption: the organisation can still sign in to the original tenant. Administrators remain available. Microsoft Entra ID is functioning. The recovery console can be reached. Production is still considered trustworthy. Someone simply needs to restore a deleted mailbox item, recover a SharePoint file or reverse an accidental change. For routine recovery, that assumption is often reasonable. It is not a complete tenant-recovery strategy. The harder question - What happens when the Microsoft 365 tenant, its identity layer or the administrative path into it is part of the incident? That can happen after an identity misconfiguration, a compromised administrator account, an unauthorised application change, a failed Conditional Access deployment, the loss of administrative access or a security event that leaves the organisation uncertain about which identities and configurations can still be trusted. At that point, the problem is no longer limited to retrieving data. The organisation may first need to establish trusted control, understand what changed, decide whether production is safe, recover identity, provision an alternate environment and make critical information accessible while the wider recovery continues. That is the difference between recovering something inside Microsoft 365 and recovering from a Microsoft 365 tenant-level incident. When the production tenant, identity plane or administrative path cannot be trusted, recovery depends on an independently protected copy and a controlled route to a clean destination. Microsoft 365 tenant recovery has three different outcomes A practical tenant-recovery plan needs to achieve three outcomes. Treating them as separate workstreams makes the recovery process easier to design and test. Microsoft 365 resilience and recovery are not the same thing Microsoft operates Microsoft 365 as a highly resilient cloud service. Its infrastructure is designed to protect service availability and customer data against failures within Microsoft’s platform. That resilience is valuable, but it does not eliminate customer-level recovery problems such as deletion, misconfiguration, identity compromise or loss of tenant administration. Microsoft provides several native retention and recovery mechanisms, including workload recycle bins, Microsoft Purview retention, Microsoft 365 Backup, soft-delete recovery for supported Entra objects and Microsoft Entra Backup and Recovery. Each capability solves a defined problem. They do not all provide the same type of protection or the same recovery destination. A useful distinction - A recycle bin is not a clean recovery tenant. A retention policy is not an independently controlled recovery platform. Restoring a supported object inside the original tenant is not the same as rebuilding operations when the tenant is inaccessible or untrusted. The five layers of Microsoft 365 recoverability Microsoft 365 recoverability is built from multiple layers. Service resilience, native retention, Microsoft 365 Backup, Entra ID recovery and independent recovery each address different failure scenarios. What Microsoft’s native recovery capabilities now provide Microsoft 365 Backup Microsoft 365 Backup is a separate paid service for supported Exchange Online, SharePoint and OneDrive data. Microsoft documents a one-year retention period and point-in-time recovery, with recovery-point frequency varying by workload and age. The service is designed for fast recovery while keeping the protected data within the Microsoft 365 data trust boundary and its existing geographic residency. Source: Microsoft 365 Backup overview and restore documentation Microsoft Entra Backup and Recovery Microsoft made Microsoft Entra Backup and Recovery generally available in June 2026. The built-in service automatically protects supported directory objects once per day and retains up to seven days of backup history. It can create difference reports and recover supported users, groups, applications, service principals, Conditional Access policies, named locations and selected authentication or authorisation policy properties. The backups cannot be disabled, modified or deleted by signed-in tenant users or applications. That is a meaningful improvement for recent accidental or malicious changes. Its boundaries remain important: it covers supported objects and properties, is operated through Microsoft’s administrative experience, stores the backups in the tenant’s Microsoft geography and does not recover hard-deleted objects. Microsoft’s own tenant-recoverability guidance now recommends extending beyond built-in capabilities when recovery scenarios require unsupported object coverage, longer retention, granular rollback or recreation of hard-deleted objects. That is a strong argument for layered recovery rather than pretending native and independent recovery are interchangeable. Sources: Microsoft Entra Backup and Recovery overview Microsoft guidance: Plan for tenant recoverability When the original tenant becomes part of the incident Tenant recovery becomes relevant when the organisation cannot safely assume that production remains an appropriate or available recovery destination. The entire Microsoft 365 service does not need to be offline. The issue may be specific to the organisation’s identities, administrative controls or tenant configuration. A public lockout example - In a Microsoft Q&A post dated 27 May 2026, a tenant owner reported that the organisation’s only Global Administrator account had been compromised, its administrative roles removed and a newly created account granted administrative permissions. The response required urgent escalation through Microsoft support to recover control. This is a user-reported case, not an independently verified incident report, but it illustrates the risk of assuming the normal administrative path will always remain available. Public source: Microsoft Q&A — “My tenant has been hacked” Common tenant-level scenarios include: Administrative lockout after a Conditional Access, authentication or privileged-role failure. Compromised administrator accounts and unauthorised role assignments, applications or consent grants. Destructive changes made by legitimate administrators, automation or deployment tools. A production tenant that remains online but is not yet trusted as a restore destination. A need to test recovery or configuration changes without experimenting in production. What cross-tenant recovery actually means Cross-tenant recovery allows supported identity objects or protected workload data from one Microsoft tenant to be recovered into another authorised tenant. For Entra ID, For Entra ID, Keepit supports cross-tenant recovery for key objects including users, groups, administrative units, roles, policies, app registrations and service principals. This can provide a clean environment for recovery testing, change validation, investigation and the staged rebuilding of critical access while the primary tenant is being remediated. It should not be described as instant recreation of an entire Microsoft 365 tenant. Entra ID cross-tenant restore provides partial disaster recovery: identity objects and configuration can be rebuilt, while full Microsoft 365 operation still depends on licensing, provisioning and workload-specific requirements. Source: Keepit — Cross-tenant restore for Entra ID The dependencies a credible plan must acknowledge Licensing and service provisioning in the destination tenant. Domain ownership, DNS and mail-routing decisions. Authentication methods, Conditional Access and trusted administrative devices. Application registrations, service principals and dependent application integrations. Application credentials: even when identity objects are restored, secrets and certificates must be validated and may need to be reissued. Endpoint enrolment, device trust and security tooling. Permissions, external sharing, compliance controls and line-of-business workflows. Source: Microsoft — Remove a domain from Microsoft 365 Different workloads require different recovery routes A serious tenant-recovery plan should not treat Microsoft 365 as one indivisible restore job. Identity, mail, files, sites and collaboration services have different destination requirements and different dependencies. Internal link: FullBackup Microsoft 365 Tenant Recovery Backup independence is about control, not geography alone Data residency matters, particularly for Australian sovereignty, regulatory and contractual requirements. But recovery independence is broader than datacentre location. Keepit stores backup data in an independently operated cloud, using two mirrored datacentres within the selected region. Data remains within that region unless the customer initiates a restore or download. For applicable Entra ID offerings, Keepit also provides unlimited hot storage with no egress, ingress or transaction fees. Source: Keepit — Backup and recovery for Entra ID A recovery path should be assessed across five dimensions: administrative, infrastructure, retention, destination and operational independence. Weakness in any one of them can limit recovery during a tenant incident. A six-stage clean-tenant recovery path Tenant recovery is a controlled operating process: contain the incident, maintain access to critical information, establish clean administration, recover trusted identity, restore priority workloads and validate the resulting environment. Recovery speed: the wait to start is not the total recovery time During a tenant incident, the first question is not only whether protected information exists. It is how quickly authorised staff can begin using it. An independent platform with immediately readable recovery points can remove the wait for an archive retrieval or rehydration process before search, inspection, download or restore work begins. That is a real operational advantage. It does not remove Microsoft API throughput, destination provisioning, licensing, identity mapping, application dependencies or validation. No responsible provider should promise a fixed recovery time for a full Microsoft 365 tenant rebuild without testing the customer’s actual environment. Test the recovery plan, not merely the backup job A successful backup report proves that a process ran. It does not prove the organisation can restore trusted identity, provision a clean destination or return a critical business service to operation. The Australian Signals Directorate’s Essential Eight maturity model requires backups of data, applications and settings to be synchronised to a common point in time and restoration to that common point to be tested as part of disaster recovery exercises. For Microsoft 365, a meaningful exercise should include identity, administration and workload dependencies—not only the recovery of an individual file. Source: ASD Essential Eight maturity model A useful tenant-recovery test should establish: who has authority to declare and lead the recovery; how the backup platform and recovery documentation are accessed independently; which tenant and domain strategy will be used; which identity objects and applications are restored first; which Microsoft 365 workloads are provisioned and recovered first; what manual steps remain; how long each stage takes in the actual environment; and what evidence demonstrates that the recovered service is usable and trusted. Does Microsoft Entra Backup replace independent Entra ID backup? Not in every environment, and not for every recovery scenario. For a recent supported change inside an accessible and trusted tenant, Microsoft Entra Backup and Recovery may be the best first recovery option. It is native, protected from tenant administrators and designed to roll supported objects back to a known-good state. Independent Entra ID backup adds value when the organisation needs longer history, additional coverage, separate administration, cross-tenant testing, an alternate recovery destination or an operational path that does not depend entirely on the original tenant. Building a practical recovery path with FullBackup FullBackup helps Australian organisations assess and strengthen their Microsoft 365 and Microsoft Entra ID recovery position. The objective is not to dismiss Microsoft’s native controls or present every incident as a full tenant disaster. It is to identify where native recovery ends, where business requirements continue and whether the organisation has a credible path through the scenarios that matter most. A Microsoft 365 Recovery Readiness Review can map: current Microsoft 365 protection, retention and native recovery controls; Entra ID backup coverage and recovery history; administrative and infrastructure independence; clean-tenant preparation, domain and licensing dependencies; workload-specific recovery routes; priority identity, applications and business data; a scoped recovery test; and a documented gap and dependency summary. Through Keepit, supported Microsoft 365 and Entra ID information can be protected on an independently operated platform with granular recovery, long-term retention, secure access options and supported cross-tenant identity recovery. The detailed product workflows and current screenshots are available on the FullBackup tenant-recovery page. Explore Microsoft 365 Tenant Recovery | Plan a recovery test

Security and recovery are complementary disciplines within a resilient Power Platform strategy. Microsoft Power Platform is no longer just a collection of handy low-code tools. Inside many Australian organisations it now runs approvals, compliance workflows, reporting, field operations and internal applications that people depend on every day. A flow routes an urgent request to the right person. An app has quietly replaced a spreadsheet, an email chain and three manual processes. A Power BI report is the view executives use to make decisions. A Dataverse environment holds the data and logic tying it all together. That is useful progress. It also means Power Platform has become part of the operational backbone, often without receiving the same recovery planning as more traditional business systems. The Australian Signals Directorate’s Blueprint for Secure Cloud provides detailed guidance for configuring and governing Power Platform securely. Its Power Platform design guidance covers connectors, Data Loss Prevention policies, environments, administrative access, tenancy isolation and audit logging. The Blueprint describes these settings as a baseline implementation and makes clear that each organisation must adapt them to its own operating context. That is exactly as it should be. But there is another question that deserves a place in the same conversation: Once Power Platform has been secured, governed and monitored, how will the organisation recover it when something still goes wrong? This is not a criticism of the Blueprint. It is the difference between reducing the chance of an incident and being ready for the consequences of one. Governance reduces risk. Recovery provides a way back. Power Platform has moved beyond "citizen development" The phrase citizen development can make Power Platform sound less consequential than it really is. It suggests small productivity tools built at the edge of the business: a simple form, a departmental dashboard, an automation that saves someone a few minutes. Some Power Platform use still fits that description. A growing amount does not. Power Apps and Power Automate can connect to Microsoft 365, Azure services, third-party platforms, on-premises systems and custom APIs. ASD’s own guidance recognises the breadth of these connections and the need to control how organisational data moves between them. That connectivity is where much of the value comes from. It is also why a failed app or broken flow can have consequences far beyond the app itself. A single automated process could update a customer record, trigger a compliance review, create an approval, notify a field team, transfer information between systems and initiate a financial action. When that process stops, the technical failure may be small. The business interruption may not be. The blunt truth is that many organisations now have production-grade dependencies running on Power Platform without production-grade recovery planning behind them. They may know who owns the Microsoft tenant, who administers Power Platform, and they may even have a mature Centre of Excellence. But ask which apps, flows, reports and Dataverse records must be recovered first — and how long that recovery can take — and the answer often becomes less certain. What the ASD Blueprint gets right about Power Platform governance The Blueprint’s Power Platform guidance deserves to be taken seriously. It recognises that low-code does not mean low-risk. For example, the Blueprint addresses how connectors should be controlled through Data Loss Prevention policies. These policies classify connectors into business, non-business and blocked groups, helping stop organisational data from being moved into inappropriate services or combined in unsafe ways. Across its Power Platform pages the Blueprint also addresses: • Power Platform environments • Role-based access control • Tenancy isolation • Power Platform audit logging • Power Platform specific conditional access policies • Dataverse and Power Apps model-driven apps • Mitigation of Power Platform security risks • Power Platform Customer Lockbox • Power BI tenancy settings • Power Platform services availability and enablement These are practical controls, and they answer real questions: who should administer the platform, which connectors should be permitted, where applications should be developed and tested, how activity should be recorded, and how sensitive data can be prevented from travelling through inappropriate flows. This is the work of governing and hardening a platform properly. None of it should be skipped. But none of it eliminates the possibility of data loss, accidental change, malicious activity or operational failure. Power Platform Recovery: Where the ASD Blueprint Stops This is worth being precise about, because it is a scoping boundary rather than an oversight. The Blueprint does address backup. It has a dedicated Backup and operational management page, and regular backups are one of the Essential Eight mitigation strategies. But that guidance sits under the platform layer. The eleven Power Platform pages listed above are concerned with secure configuration, governance and monitoring. None of them is a recovery page. The Blueprint is explicit about the limits of its own prescription. Its Power Platform configuration section notes that the settings described provide a baseline implementation and should not be considered prescriptive as to how an organisation must scope, build, document or assess a system, and that implementation will differ depending on operating context and organisational culture. It also notes that the Blueprint does not currently provide a mechanism to automatically deploy or assess Power Platform settings. So the recovery question is not missing from the Blueprint through neglect. It sits outside the scope of what the Power Platform guidance sets out to do, and ASD says as much. That leaves the work of translating backup principles into Power Platform practice with the organisation. It is worth adding that the Blueprint is an open source project. ASD invites contributions and issues through its GitHub repository, so organisations that develop good Power Platform recovery patterns have a route to feed them back upstream rather than keeping them internal. Security controls are not time machines A good security control can prevent an inappropriate action, restrict access, raise an alert and record what happened. It cannot always return an application, flow, report or record to the state it was in before the damage occurred. Audit logging may show that a privileged user changed a production flow at 2:17 pm. That is valuable. It does not rebuild the previous version of the flow. A DLP policy may stop a user from combining a business connector with an unapproved consumer service, which is exactly what the policy is designed to do. It does not recover a legitimate app that someone later deletes. Role-based access control can reduce the number of people capable of making a damaging change; it cannot guarantee that an authorised person will never make the wrong one. Tenancy isolation can reduce inappropriate cross-tenant communication. It does not recreate lost Dataverse records. This is not unique to Power Platform. Preventive controls reduce risk. Detective controls reveal activity. Recovery controls provide a way back. Confusing those jobs leaves a gap. What can actually go wrong? The obvious answer is cyberattack. But focusing only on ransomware misses the more ordinary - and often more likely - causes of disruption. An app is deleted. A developer, administrator or business user removes the wrong application. The mistake is discovered immediately, or three weeks later when someone tries to use it. A flow is changed. A Power Automate flow is updated to support a new process. The change works in testing but behaves differently in production, overwriting records or routing actions incorrectly. A deployment introduces a fault. A solution moved between environments replaces working components with incorrect versions or missing dependencies. Dataverse information is altered. Records are deleted, overwritten or changed in bulk. The platform remains available, but the information inside it can no longer be trusted. Permissions are damaged. An application still exists, but the people who need it can no longer access it, or the wrong people can. A privileged account is compromised. An attacker need not encrypt the tenant - changing workflows, deleting apps or damaging access settings may be enough. The problem is discovered too late. The organisation has a recovery option, but its retention window no longer reaches the last known-good state. A worked example of the retention problem Consider a mid-sized organisation running a monthly financial reconciliation. In early March, a solution deployment introduces a change to an approval flow that silently writes an incorrect cost-centre code on a subset of transactions. Nothing fails. No alert fires. The apps stay available, the audit log faithfully records every action, and DLP policies are working exactly as intended. The problem surfaces on 12 April, when the finance team reconciles the quarter and the numbers do not agree. By then the damaging change is roughly forty days old. Every preventive and detective control performed correctly. The organisation still cannot roll back to a clean state, because its recovery window does not reach that far. This is the scenario that retention limits decide, and it has nothing to do with an attacker. Microsoft automatically backs up Power Platform environments that contain a database. As at July 2026, the default system backup retention period is seven days, and for production Managed Environments retention can be increased to a maximum of 28 days. Manual backups are generally retained for seven days unless extended for eligible production Managed Environments. Recently deleted environments can generally be recovered within seven days, with longer availability applying in some Dynamics 365 production scenarios. These figures change from time to time, verify current limits against Microsoft Learn before relying on them. Those capabilities are useful and should form part of an organisation’s recovery approach. But a seven-day or 28-day window may not be enough when a damaging change remains unnoticed for longer. Nor does environment-level recovery answer the need to restore one specific app, flow, report or data item without affecting everything else that has legitimately changed since the recovery point. Availability, disaster recovery and backup are not the same thing This distinction is often lost in cloud discussions. Microsoft provides availability and disaster recovery capabilities, in-region resiliency and optional cross-region failover for eligible production environments, designed to keep services operating through infrastructure failures. That is important platform resilience, but it protects against a different class of problem. Failover preserves service when infrastructure fails; it does not undo logical changes made inside a working service. If a valid administrative action deletes information, a resilient platform faithfully preserves the deletion. If a compromised account changes a flow, high availability keeps the altered flow highly available. If corrupted data is replicated, the secondary copy contains the same problem. This is why mature organisations separate four questions: 1. Can the service remain available? 2. Can the platform survive an infrastructure failure? 3. Can we recover information or configuration from before a damaging event? 4. Can we perform that recovery at the level and speed the business requires? A "yes" to the first two does not automatically provide a "yes" to the last two. Availability preserves the current state. Independent recovery preserves history. ASD already treats backups as a core cyber control ASD’s regular backups guidance does not describe backup as merely having another copy somewhere. It focuses on the ability to recover important data, software and configuration settings, and on protecting backups from compromise and unauthorised access. Higher maturity expectations include synchronising backups with the organisation’s essential business information, testing restoration, and preventing lower-privileged accounts from accessing or modifying backups. That principle should not stop at servers and endpoints. If Power Platform now contains essential business information, business logic and operational processes, those assets belong in the recovery discussion too, which means knowing which apps, flows, reports and Dataverse tables are business-critical, how far back recovery must reach, whether a single item can be restored without an environment rollback, and whether any of it has been tested. That is the point where backup stops being a product discussion and becomes an operational resilience discussion. Native recovery is valuable - but understand what it is designed to do There is no sensible argument for ignoring Microsoft’s native capabilities. They provide automatic system backups for supported environments, manual backup options, environment restoration and recovery mechanisms for recently deleted environments. Use them. Document them. Test them. But do not assume they satisfy every recovery requirement simply because they exist. The right test is not whether Microsoft backs up Power Platform. The better questions are whether the available recovery method meets your required recovery point, recovery time, retention and granularity and whether it remains usable in the incident scenarios you are planning for. For some environments, native recovery may be sufficient. For others, restoring an entire environment to recover one damaged component creates unnecessary disruption, a short retention period may not cover slow-moving corruption, and a recovery process depending entirely on the same administrative plane needs examination in scenarios involving compromised tenant credentials. There is no universal answer. There should, however, be a deliberate one. The case for independent Power Platform backup An independent backup does not replace Microsoft’s resilience, ASD’s guidance, good administration or disciplined application lifecycle management. It adds another recovery path. Keepit protects Power Platform workloads including Power Apps, Power Automate, Power Pages and Power BI. Coverage includes canvas and model-driven apps, desktop and cloud flows, Power Pages, and Power BI dataflows and reports, with granular recovery so administrators can restore specific protected items rather than necessarily restoring an entire environment. Protected copies are held in Keepit’s independent cloud infrastructure rather than as another copy inside the production Microsoft platform; data is held across two mirrored data centres in the selected data-centre region and stored immutably. For an Australian organisation, that can provide several useful capabilities: A separate recovery boundary. The recovery copy sits outside the primary Microsoft environment, reducing dependence on one platform, one administrative plane and one failure domain. Granular recovery. An administrator may be able to recover the affected app, flow, report or object without rolling back the entire environment and disturbing unrelated changes. Longer historical reach. Retention can be aligned with business, regulatory and operational needs rather than a short native recovery window - which is precisely what the forty-day reconciliation scenario above turns on. Faster investigation. Search and historical versions help determine when an item changed and identify a clean recovery point. A clearer recovery workflow. Recovery becomes a defined operational process rather than an improvised response assembled after the incident has begun. The point is not that every organisation must buy the same backup product. The point is that every organisation using Power Platform for meaningful work should decide whether its current recovery options are enough. A resilient Power Platform strategy combines governance, platform resilience and independent recovery. Start with the business process, not the product list The fastest way to get Power Platform recovery wrong is to begin by counting apps. Not every app matters equally: a departmental lunch-ordering app and a field safety application should not receive the same recovery priority. A sensible review begins with the business process. For every important Power Platform workload, identify the process it supports, the business and technical owners, the underlying environment, connected data sources, dependent identities and service accounts, maximum tolerable data loss, maximum tolerable downtime, required retention, required recovery granularity, recovery order, and evidence that the recovery process has been tested. This work tends to expose uncomfortable truths. A critical application may have no clear owner. A flow may rely on the account of an employee who left six months ago. A production process may still be running in the default environment. A recovery test may never have been performed because everyone assumed somebody else was responsible. That is exactly why the review is worthwhile. Questions to take into the review 1. Which Power Platform workloads would stop a business process if they failed? Start with operational impact rather than technical complexity. 2. Are critical apps and flows formally classified? If they are treated as informal departmental tools, they are unlikely to receive appropriate governance or recovery planning. 3. How long could damage remain unnoticed? A seven-day recovery window may sound reasonable until a faulty workflow is discovered during a monthly reconciliation. 4. Can the organisation recover one item, or does recovery require a full environment rollback? 5. What legitimate changes would be lost during an environment rollback? Recovering yesterday’s environment may also remove today’s valid work. 6. Is the recovery copy independent of the same cloud, identity system, administrative accounts and control plane? 7. Who can access or alter the backups? Recovery data should be protected from ordinary users, administrators who do not require access, and compromised production credentials. 8. Can the organisation recover during an identity or tenant incident, when normal administrative access is unavailable or untrusted? 9. Has restoration been tested? A documented capability is not the same as a demonstrated capability. 10. Is the result recorded in business continuity, disaster recovery, cyber incident and application lifecycle planning? Business processes—not applications—should determine recovery priorities. Secure configuration is the beginning - not the end The ASD Blueprint gives Australian organisations a strong starting point for securing and governing Power Platform. Its controls should be understood, adapted and maintained. Secure configuration was never intended to answer every recovery question, and the Blueprint is explicit about that boundary. Power Platform can still be affected by human error, damaging changes, compromised accounts, software faults, data corruption and incidents discovered beyond a native retention window. When the business depends on an app, flow, report or collection of Dataverse records, hoping the platform can recover it is not a strategy. The organisation should know what can be restored, how far back, how granularly, how long it will take, who can perform it, whether recovery survives a broader Microsoft or identity incident, and whether the process has actually been tested. ASD’s Blueprint helps organisations reduce the risk. Microsoft helps keep the platform available. Independent backup can provide another route back when the running platform contains the wrong state, or when native recovery does not meet the requirement. Those are not competing ideas. They are different parts of the same resilience plan. A secure platform is harder to compromise. A recoverable platform is harder to permanently disrupt. Australian organisations using Power Platform for real business operations need both.

Most organisations have backups. Few can prove recovery. Most organisations can show backup activity. Recovery assurance shows whether the business can restore trusted data, identity, permissions and evidence when it matters. Most organisations can answer the first question quickly. Do we have backups? The answer is usually yes. There is a backup platform. Retention settings. Snapshots. Green ticks. Perhaps a report showing successful jobs. But that is not the question that matters when something goes wrong. The harder question is: Can the organisation prove it can recover? Not just recover a file. Not just restore an email. Not just bring back a record. Can it recover the right data, from the right point in time, with the right permissions, identity state, metadata, relationships, workflows and evidence? Most organisations discover the answer only after an incident, audit, cyber insurance renewal or executive review asks for evidence. Not confidence. Evidence. That is where backup ends and recovery assurance begins. What the gap looks like in practice Consider an organisation that discovers unusual account activity over a weekend. Backups are running. Jobs are green. A restore is initiated. The mailbox comes back. But the wider investigation reveals compromised accounts that had been active for six days before detection. The restore point before the compromise is unclear. Permissions across SharePoint have drifted. The identity state in Entra ID - conditional access policies, MFA methods and privileged role assignments - is uncertain. The question is no longer whether the data exists. It is whether the recovered environment can be trusted. That is not a backup failure. That is a recovery assurance gap. A protected workload may have backups, retention and green job status. A recoverable workload has a known-good restore point, trusted identity, restored permissions and evidence captured. Protected is not the same as recoverable This is the starting point. The first step is separating what is merely included in a backup, retention policy or native recovery feature from what can actually be restored, verified and explained when it matters. A workload can be protected on paper and still fail the real recovery test. · The data may be there, but not in the form the business needs. · The restore may work technically, but not restore operational confidence. · The files may return, but the structure may not. · The user account may exist, but the access model may no longer be trusted. · The record may be recovered, but the evidence trail may be incomplete. This is why recovery assurance is not a product checkbox. It is a confidence question. Can the organisation show what is recoverable, what is partially recoverable, what is unknown and what is exposed? The real recovery problem is no longer just data SaaS platforms changed the shape of recovery. For many organisations, the three most critical platforms are Microsoft 365, Entra ID and Salesforce. Each carries considerably more than data. Microsoft 365 Exchange Online. SharePoint. OneDrive. Teams. Groups. Permissions. Collaboration history. Records. Workflow. Entra ID Users. Groups. Privileged roles. Conditional access. Enterprise applications. Authentication methods. Control-plane trust. Salesforce Objects. Relationships. Metadata. Profiles. Permissions. Flows. Automation. Commercial truth. Google Workspace, Jira, Confluence, Zendesk, GitHub, Azure DevOps, Power Platform and other SaaS platforms carry similar business context. Context is what makes data usable. The recovery question is no longer: Can we get the data back? It is: Can we restore the business state the data depends on? That is a much harder question. Green ticks can create false confidence Backup platforms are good at showing operational success. Jobs completed. Snapshots taken. Policies applied. Retention running. Errors cleared. That information matters. But it can also create a dangerous illusion if nobody has tested what recovery actually looks like in practice. Green backups do not answer questions such as: · Can we recover from a known-good point before the damage occurred? · Can we recover without depending on the same tenant, identity plane or administrative path that failed? · Can we restore permissions, structure, metadata and relationships? · Can we prove who restored what, when and why? · Can we show evidence to an auditor, insurer, board or customer? · Can we validate the recovered state before trusting it again? That is the difference between operational backup status and recovery assurance. One tells you backup activity happened. The other tells you whether the organisation can recover with evidence. Recovery assurance is about evidence Recovery assurance is the ability to prove recovery can work. That means being able to answer six questions. The six recovery assurance questions What is protected? Which platforms, workloads, users, groups, objects, records, files, metadata, permissions and configurations are included? What is recoverable? Can the organisation restore the parts that matter to the business, not just isolated data? How independent is recovery? Does recovery depend on the same SaaS tenant, cloud boundary, identity system or administrative control path involved in the incident? What has been tested? Has recovery been validated against real scenarios, or only assumed from backup success? What evidence exists? Can the organisation show restore history, access control, recovery timing, source copy, operator action and recovered state? What is still unknown? Which areas are not tested, not documented or not clearly owned? Unknown is not neutral. Unknown is risk that has not yet been named. The goal of recovery assurance is to move recovery confidence from assumed or unknown to documented, tested and evidenced. Cyber insurance and audit conversations are getting sharper Cyber insurers, auditors and governance reviewers are increasingly asking recovery-specific questions. Not simply: Do you have backups? But: Independence · Are backup copies separated from the affected environment? · Are backups immutable, isolated or protected from deletion? · Is privileged access to recovery controlled and MFA enforced? Testability · Has recovery been tested against real scenarios? · Can critical systems be restored within required timeframes? · Are SaaS and third-party dependencies understood? Evidence · Can evidence be shown if a claim, audit or review occurs? · Are Microsoft 365, Entra ID and Salesforce included in the recovery evidence story? · Who owns recovery assurance, testing and improvement? A backup policy alone will not answer those questions. Recovery evidence will. Recovery assurance closes the gap between confidence and proof Many organisations are confident until they have to prove recovery. That is the dangerous gap. Confidence says backups exist. Proof shows what can be restored, who can recover it, how it is governed, what has been tested and what evidence can be produced. Confidence says: · We have backup. · Jobs are green. · Retention is set. · We have never had a problem. · We would figure it out. · Our provider handles it. Proof says: · We know what is protected. · We know what can be restored. · We know who can recover it. · We know how recovery is governed. · We know what has been tested. · We know what evidence we can produce. That is the purpose of a Recovery Assurance Review™. Not to create another theoretical assessment. Not to produce a 40-page report nobody reads. Not to make recovery more complicated than it needs to be. The purpose is to make the current recovery position visible. What is confirmed. What is partial. What is unknown. What is exposed. Once that is clear, the next step becomes much easier. What the Recovery Assurance Review™ looks for The Recovery Assurance Review™ assesses recovery evidence, SaaS platform coverage, identity dependency, cloud boundary risk, critical workload exposure and governance ownership. The Recovery Assurance Review™ is designed to make recovery risk visible across the areas that matter most. It looks beyond backup status and asks where recovery can be proven. Recovery evidence Can the organisation show what was recovered, when, by whom and from which copy? SaaS platform coverage Are Microsoft 365, Entra ID, Salesforce and other critical workloads properly included? Identity dependency Could Entra ID, Okta or another identity platform become the recovery bottleneck? Cloud boundary risk Does backup and recovery depend on the same provider, tenant or control plane as production? Critical dependency analysis Which platforms could materially constrain recovery if they failed? Cyber insurance evidence Can the organisation support renewal, underwriting or claims conversations with recovery proof? Governance and ownership Who owns recovery assurance, testing, evidence and improvement? It is not simply about whether data exists. It is about whether recovery can be trusted. Backup remains essential. Without it, recovery options shrink quickly. But backup is only one part of the story. Backup proves data was copied. Recovery proves data can be restored. Recovery Assurance proves the organisation can trust what comes back. That is the difference that matters when the incident, audit, insurer, customer or board asks the harder question: Can you prove recovery? Recovery Assurance FAQ What is recovery assurance? Recovery assurance is the ability to prove that business-critical data, identity, permissions and configurations can be recovered, trusted and evidenced following an incident, audit, cyber insurance review or executive request. Is backup the same as recovery assurance? No. Backup proves data was copied. Recovery assurance proves the organisation can recover the right data, from the right point in time, with the right permissions, identity state and evidence. Why is recovery evidence important? Recovery evidence helps an organisation show what was restored, when it was restored, who performed the recovery, which copy was used and whether the recovered state can be trusted. Does Microsoft 365 provide recovery assurance? Microsoft 365 provides native retention and recovery capabilities, but organisations still need to validate recovery requirements, identity dependencies, permissions, evidence and governance obligations. What does a Recovery Assurance Review™ assess? A Recovery Assurance Review™ assesses recovery evidence, SaaS platform coverage, identity dependency, cloud boundary risk, critical workload exposure, governance ownership and recovery confidence. Start your Recovery Assurance Review™ Complete the Recovery Assurance Review™ to identify recovery evidence gaps, identity dependency, cloud boundary risk and critical SaaS recovery exposures before an incident exposes them. The Recovery Assurance Review™ provides a structured assessment of: · Recovery evidence · SaaS platform coverage · Identity dependency · Cloud boundary risk · Critical workload exposure · Recovery confidence Complete the assessment and identify the recovery gaps before an incident finds them for you. Start your Recovery Assurance Review™

Microsoft 365 can remain available while business data, permissions or identity configuration still need independent recovery. Microsoft 365 is reliable. That is not the problem. The problem is that many organisations still confuse Microsoft 365 availability with Microsoft 365 recoverability. The platform can be online while your business data is deleted, overwritten, inaccessible or untrusted. That is the uncomfortable gap. A mailbox can be damaged. A SharePoint library can be overwritten. A Teams workspace can lose context. A OneDrive folder can disappear after a user leaves. An administrator can make the wrong change. An identity policy can be altered by mistake or compromise. In those moments, the question is not: “Is Microsoft 365 running?” It is: “Can we recover the data, permissions and configuration the business needs?” That is why Microsoft 365 backup should be treated as a recovery-control issue, not just an IT administration task. This is the real issue behind Microsoft 365 Backup Australia searches: organisations are not simply looking for another copy of data. They are looking for a reliable way to recover Microsoft 365 data, permissions and identity configuration when native controls are not enough. For a practical view of how this applies across Exchange Online, OneDrive, SharePoint, Teams and Entra ID, see our guide to Microsoft 365 backup and recovery in Australia. FullBackup helps Australian organisations build an independent Microsoft 365 recovery position using Keepit’s SaaS backup platform. As a Keepit Elite Reseller Partner, FullBackup focuses on helping customers separate recovery from the primary SaaS environment, so Microsoft 365 data and identity configuration can be restored when native recovery is not enough. Why Microsoft 365 Backup Australia Starts with Recovery, Not Retention Microsoft 365 includes powerful native controls. Retention policies, retention labels, recycle bins, version history, litigation hold and eDiscovery all have a role. They are valuable tools. But they are not the same thing as independent backup. Retention is built around governance. Backup is built around recovery. Those are not the same job. Retention answers questions like: How long should content be kept? When should content be deleted? Is this item subject to a compliance policy? Can this data be preserved for legal, regulatory or governance reasons? Backup answers different questions: Can we restore the right mailbox, file, folder, site, team or identity object? Can we recover to a known-good point before the incident? Can we recover if the live tenant, administrator account or identity plane is compromised? Can we restore quickly without rebuilding business context manually? Can we prove recovery works before an incident? That distinction is the whole issue. Retention governs information. Backup restores the business. Retention helps govern information. Independent backup gives the organisation a recovery path. Microsoft 365 Retention Is Useful - But It Is Not Backup This conversation needs to be honest. Microsoft 365 native controls are not useless. They are important. Recycle bins help with short-term mistakes. Version history helps roll files back. Retention policies help manage lifecycle and governance. eDiscovery and legal hold support investigation and preservation. Microsoft’s platform resilience helps keep Microsoft 365 available. All of that matters. But none of it removes the need for an independent recovery position. A recycle bin is a safety net. It is not a resilience strategy. A retention policy can preserve content. It is not the same as a tested restore path. A legal hold can support discovery. It is not an operational recovery plan. A cloud platform can be available. Your data can still be wrong. That is the gap Microsoft 365 backup is designed to close. Native Microsoft 365 Controls Help. They Do Not Finish the Job. Most serious Microsoft 365 recovery problems are not Microsoft outages. They are customer-side incidents. The platform is available. The user still cannot find the file. The mailbox is still damaged. The SharePoint library is still wrong. The Team is still missing context. The permissions are still broken. The identity configuration still cannot be trusted. That is why asking “Is Microsoft 365 down?” is often the wrong question. The better question is: “Can we recover what the business needs, from a point we trust?” That includes data. But it also includes structure, permissions, identity and evidence. If a SharePoint site is restored without the right permissions, recovery is incomplete. If Teams files come back without useful context, recovery is incomplete. If Entra ID access cannot be trusted, recovery is incomplete. If IT cannot prove what was protected and what was restored, recovery is incomplete. Backup is not just about having another copy. It is about having a controlled recovery path when the live environment is no longer enough. Why Microsoft 365 Backup Matters for Australian Organisations For Australian organisations, Microsoft 365 backup is no longer just an IT hygiene issue. It is becoming part of the wider cyber-resilience, governance and operational-risk conversation. That matters because Australian businesses now rely on Microsoft 365 for the records, collaboration and identity controls that keep daily operations moving. Email sits in Exchange Online. Files sit in OneDrive and SharePoint. Project work happens in Teams. Access depends on Entra ID. When that environment is damaged, deleted, misconfigured or compromised, the issue is not just technical. It can affect: customer service legal discovery privacy response audit evidence executive communication student, patient or client records operational continuity board reporting cyber insurance conversations incident response This is especially relevant for organisations in education, healthcare, legal, finance, professional services, not-for-profit, local government and critical service environments. The question is no longer: “Do we use Microsoft 365?” Nearly everyone does. The better question is: “Can we recover Microsoft 365 data and identity configuration when the business actually needs it?” For Australian boards and executives, that is the difference between assuming resilience and being able to prove it. Hope is not a recovery control. For organisations that need to connect backup, recovery testing, governance and audit readiness, our Microsoft 365 backup compliance guide for Australian organisations explains how Microsoft 365 recovery fits into the wider resilience conversation. Microsoft 365 recovery is becoming part of cyber resilience, audit and operational-risk conversations in Australia. Microsoft 365 Backup Is Not One Recovery Problem Microsoft 365 is not a single workload. That is why backup conversations often get oversimplified. Recovering an email is not the same as recovering a SharePoint site. Recovering a OneDrive folder is not the same as recovering a Team. Recovering a deleted user is not the same as recovering an identity policy. Recovering a document is not the same as proving the business can resume work. A proper Microsoft 365 backup strategy needs to look across the environment people actually use: Exchange Online OneDrive SharePoint Online Microsoft Teams Entra ID Each workload has different recovery pressure. Exchange is often about mail, calendars, contacts, folders and investigation. OneDrive is often about user-owned files, departed users, accidental deletion and sharing context. SharePoint is often about libraries, sites, permissions, document structure and business process. Teams is often about collaboration context spread across chats, channels, files, groups and SharePoint. Entra ID is about users, groups, roles, applications, access and control. Treating Microsoft 365 backup as “email backup” is outdated. The business has moved on. Recovery needs to move with it. SharePoint Backup and Recovery Is Business-Process Recovery SharePoint is often where Microsoft 365 becomes operationally critical. It is not just a place to store files. For many organisations, SharePoint holds departmental libraries, project records, client documents, policies, procedures, intranet content, permissions, metadata, version history and business process structure. That makes SharePoint recovery different from simple file recovery. A damaged SharePoint site can affect more than documents. It can affect: document libraries folder structures permissions metadata links version history shared access departmental records project workspaces business workflows compliance evidence That is why SharePoint backup needs to be assessed carefully. If a SharePoint library is overwritten, deleted, misconfigured or restored without the right structure and permissions, the business may still be unable to work properly. The files may exist. But the working environment may still be broken. SharePoint is where data, permissions and process meet. That is what makes it business critical. For organisations that rely heavily on shared document libraries, policies, project sites, intranet content or controlled records, SharePoint recovery should be treated as a core part of Microsoft 365 resilience — not as an afterthought behind email. A serious Microsoft 365 backup strategy should be able to recover SharePoint content in a way that supports how the business actually uses it: sites, libraries, folders, files, permissions, metadata and usable recovery points. Because when SharePoint breaks, the issue is rarely just one missing document. It is often the structure around the document that matters. We cover this in more detail in our dedicated guide to SharePoint backup and recovery, including why SharePoint recovery needs to preserve more than just files. SharePoint recovery is about restoring the structure, permissions and document context the business depends on. Microsoft Teams Backup Is Business-Context Recovery Microsoft Teams is not just chat. It is where people work. A Team can hold project history, channel structure, files, meetings, decisions, links, permissions and the working memory of a department or project group. That makes recovery harder than many organisations expect. A deleted Teams channel may not be just a deleted conversation. It may involve: files folders SharePoint content membership permissions conversations meeting artefacts tabs links business context That is why Teams recovery is not only about restoring messages. It is about restoring the collaboration environment people rely on. Teams is business context spread across Microsoft 365. If that context is lost, the organisation does not just lose data. It loses the map of how people were working. We cover this in more detail in our dedicated guide to Microsoft Teams backup and recovery, including why Teams recovery needs to be assessed differently from basic file or mailbox recovery. Teams recovery is about restoring collaboration context across files, channels, membership and SharePoint content. Entra ID Backup Now Sits Beside Data Recovery Microsoft 365 backup used to be discussed mostly in terms of mailboxes and files. That is no longer enough. Identity is now part of the recovery problem. Entra ID controls users, groups, roles, access, applications, policies and trust relationships. If identity configuration is changed, deleted or compromised, the organisation may have a bigger issue than missing documents. It may not know who should have access. It may not know which policies were changed. It may not know whether a restored user, group or application is safe. It may need to restore control before it can safely restore data. If identity is broken, recovery slows down. If access cannot be trusted, restored data cannot be trusted either. That is why Entra ID backup and recovery should sit beside Exchange, OneDrive, SharePoint and Teams in the Microsoft 365 recovery conversation. For a deeper look at this risk, see our guide to Entra ID backup and identity recovery, where we explain why identity recovery now belongs inside a serious Microsoft 365 resilience strategy. Identity recovery sits beside data recovery because access and control determine whether restored data can be trusted. The dangerous assumption: “Microsoft already backs it up” This phrase causes a lot of confusion. Microsoft protects the Microsoft 365 service. That is not the same as giving every customer an independent, business-controlled recovery position for their own data, permissions and identity configuration. That distinction matters. Microsoft 365 is a shared responsibility environment. Microsoft operates the platform, but organisations still have responsibilities for the data, identities, access, configuration and controls they use inside that platform. That is why Microsoft 365 backup should not be framed as a criticism of Microsoft. It is the opposite. Microsoft 365 is so important that it deserves a proper recovery strategy. The stronger the dependency, the stronger the recovery requirement. What good Microsoft 365 backup looks like A strong Microsoft 365 backup strategy does not need to be complicated. But it does need to be deliberate. It should include seven things. 1. Independent backup The backup copy should sit outside the normal Microsoft 365 data lifecycle. That matters because the incident may involve the live tenant, user accounts, administrator permissions, identity controls or retention configuration. The recovery copy should not simply be another dependency inside the same operational blast radius. 2. Broad workload coverage Microsoft 365 backup should not stop at Exchange. Organisations should assess recovery across: Exchange Online OneDrive SharePoint Online Microsoft Teams Entra ID Depending on the environment, they may also need to assess related SaaS platforms such as Dynamics 365, Power Platform, Azure DevOps, Salesforce, Google Workspace, Zendesk, Jira or Confluence. The point is simple. Backup should follow the business systems people actually use. 3. Granular search and restore Recovery should not become a manual investigation under pressure. IT should be able to search, locate and restore the right item, folder, site, mailbox, user, group or policy quickly. Granular recovery matters because most incidents are not total platform failures. They are specific, messy, operational failures. A few lost files. A damaged mailbox. A broken SharePoint library. A deleted Team. A changed identity object. Small incident. Big business impact. 4. Long retention Native recovery windows may not match business, legal, audit or operational needs. Australian organisations should align backup retention to business risk, not just platform defaults. That includes thinking about: departed users long-running projects legal matters compliance records education cohorts healthcare files client records board and executive correspondence sensitive operational data The right retention period is not the same for every organisation. But it should be a conscious decision. 5. Known-good recovery points Recovery is not just about getting “a copy” back. It is about getting the right copy back. A clean copy. A trusted copy. A point before the damage happened. That matters when data has been altered, encrypted, deleted, overwritten or compromised. A good backup strategy should help the organisation recover from a known-good state, not simply recover the most recent damaged version. 6. Controlled restore access Recovery access should be governed. Not every administrator should have unlimited search, export and restore rights across all Microsoft 365 backup data. A serious backup model should consider: who can search who can restore who can export who can access sensitive mailboxes who approves restores who can change retention who can delete or alter backup settings This is especially important when backup data includes executive mailboxes, HR records, legal material, student data, patient data, client files or confidential commercial information. 7. Recovery evidence This is the part too many organisations skip. They buy backup. They assume it works. Then nobody tests restore until something goes wrong. That is backwards. Backup without restore evidence is still an assumption. Microsoft 365 backup should produce evidence: what is protected when backups run what workloads are covered what restore tests were completed who performed them what was restored how long it took what gaps were found This is what turns backup from a product into a control. Build the Microsoft 365 recovery evidence trail A serious Microsoft 365 backup strategy should not stop at: “The backups are running.” That is not enough. The organisation should be able to show: which Microsoft 365 workloads are protected how often backups run what retention applies who can perform restores what restore tests have been completed what was recovered how long recovery took what gaps were found what has been improved since the last test This is where Microsoft 365 backup becomes more than a technical control. It becomes recovery evidence. For regulated or risk-sensitive Australian organisations, that evidence matters. It gives IT, security, risk, audit and executive stakeholders a clearer view of whether Microsoft 365 can actually be recovered when it matters. It also exposes uncomfortable gaps before an incident does. That is the point. A recovery test that finds a gap is not a failure. It is a warning delivered early enough to do something about it. The practical next step is to test the recovery position before an incident. FullBackup’s Microsoft 365 recovery gap check helps Australian organisations assess whether Exchange, OneDrive, SharePoint, Teams and Entra ID can be recovered when it matters. Where FullBackup Fits in Microsoft 365 Backup Australia FullBackup helps Australian organisations move beyond the assumption that Microsoft 365 native retention is enough. As a Keepit Elite Reseller Partner, FullBackup provides Microsoft 365 backup and recovery powered by Keepit, covering key workloads such as Exchange Online, OneDrive, SharePoint, Microsoft Teams and Entra ID. The value is not simply having another copy of data. The value is having an independent recovery position when the live Microsoft 365 environment, administrator workflow, identity configuration or native recovery path is no longer enough. That matters in real scenarios: a departed user’s OneDrive data needs to be recovered a SharePoint site is damaged or overwritten Teams content is deleted or loses context Exchange Online mail needs to be restored Entra ID users, groups, roles or policies need to be recovered audit or incident-response teams need evidence of what was protected and restored FullBackup’s role is to help make Microsoft 365 recovery clearer, testable and easier to explain to the business. Not because Microsoft 365 is weak. Because Microsoft 365 is critical. And critical systems need a recovery plan the business can trust. The Board-Level Version of Microsoft 365 Backup The board does not need a technical lecture. It needs the truth in plain English. Here it is: Microsoft 365 keeps the platform available. It does not remove the organisation’s responsibility to recover its own data, permissions and identity configuration when something goes wrong. That is the board-level message. The stronger version is this: If Microsoft 365 holds critical business data, then Microsoft 365 backup is a resilience control. Not a nice-to-have. Not an optional add-on. Not something to revisit after an incident. Because by then, the conversation will not be about whether Microsoft 365 is reliable. It will be about whether the organisation can recover what matters. Final Thought: Backup Is Not the Opposite of Microsoft 365 Backup is not a criticism of Microsoft. It is a recognition of how important Microsoft 365 has become. The more your organisation depends on Exchange Online, OneDrive, SharePoint, Teams and Entra ID, the more important it becomes to protect the data, permissions and configuration inside them. Retention is valuable. Recycle bins are useful. Native controls matter. But they are not the same as independent backup. For Australian organisations, the question is no longer whether Microsoft 365 is a good platform. It is whether the business can recover when the data, permissions or identity layer inside Microsoft 365 are no longer trustworthy. That is the real test. And it is a test worth running before the incident. Check Your Microsoft 365 Backup and Recovery Position FullBackup helps Australian organisations assess Microsoft 365 backup and recovery across Exchange Online, OneDrive, SharePoint, Teams and Entra ID. As a Keepit Elite Reseller Partner, FullBackup provides independent SaaS backup and recovery for Microsoft 365 and other critical cloud platforms. View Microsoft 365 Backup & Recovery Book a Recovery Gap Check

Identity is no longer just where people log in. It is the control plane behind access, privilege, policy and SaaS operations. The next major recovery failure may not start with data. It may start with identity. That is the real lesson from Microsoft’s Storm-2949 research. What began as targeted Microsoft Entra ID compromise rapidly evolved into a wider cloud infrastructure breach spanning Microsoft 365 applications, file-hosting services and Azure-hosted production environments. Microsoft describes the attack as crossing SaaS, PaaS and IaaS layers, with the attacker using legitimate cloud and Azure management features to gain control-plane and data-plane access. That matters because identity is no longer just where people log in. Identity is where control lives. Users. Groups. MFA. Admin roles. Conditional Access. Service principals. Application assignments. SaaS access. Azure RBAC permissions. Cloud resource access. When identity is compromised, the organisation does not just face an access problem. It faces a control problem. And when the control plane has been abused, recovery is no longer just about getting users back online. It is about restoring a known-good identity state the business can trust. Storm-2949 shows the new recovery problem Microsoft’s investigation breaks the attack into two major phases: targeted identity compromise and cloud infrastructure compromise. That distinction matters because it shows how quickly identity abuse can move beyond the account and into the wider cloud estate. The attacker did not need to start with traditional endpoint malware. The path began with identity. Microsoft assessed with high confidence that Storm-2949 used social engineering consistent with abuse of Microsoft’s Self-Service Password Reset process. The attacker impersonated internal IT support, persuaded users to complete MFA prompts, reset passwords, removed existing authentication methods and registered their own authenticator to maintain access. That is not just account takeover. That is control-plane entry. Once the attacker had valid cloud identities, the better question became: What can those identities control? The attack expanded through legitimate cloud operations A compromised identity can become a path into directory discovery, Microsoft 365 data, Azure RBAC, Key Vault secrets, storage, SQL databases and virtual machines. After the initial identity takeover, Microsoft says the attacker used Microsoft Graph API for directory discovery, enumerating users and applications, searching for privileged identities and mapping application-level access paths. The attacker also attempted to add credentials to a compromised service principal, showing an effort to create persistence beyond the original user accounts. That is the part many recovery plans still miss. The issue is not only that an account was compromised. The issue is what that account could see, change, enumerate, assign, weaken or abuse. Storm-2949 then used the compromised accounts to access and exfiltrate Microsoft 365 data, including OneDrive and SharePoint content. Microsoft noted that the attacker focused on sensitive files, including IT documents related to VPN configuration and remote access procedures. From there, the attack shifted deeper into Azure. Microsoft says the attacker targeted Azure App Services, Key Vaults, Storage accounts, SQL databases and virtual machines. This marked the move from identity-centric abuse and SaaS data theft into broader cloud infrastructure compromise. That is why the recovery question changes. It is no longer enough to ask: Was the user account secured? The better question is: Which control paths did that identity open? Key Vault shows why identity compromise can become production compromise The Key Vault detail in Microsoft’s write-up is one of the most important parts of the story. Microsoft says the attacker used privileged Azure RBAC permissions to manipulate Key Vault access configurations and access dozens of secrets. Those secrets included database connection strings, identity credentials and other sensitive material. Microsoft states this dramatically expanded the attack’s blast radius. That is the point. Identity was not the final target. Identity was the path. Once the attacker reached Key Vault, the breach could move from user accounts into production systems, databases, application credentials and cloud-hosted services. That is where identity security becomes business recovery. Because after this kind of compromise, the organisation has to answer difficult questions: Which secrets were accessed? Which credentials were exposed? Which applications depended on those secrets? Which RBAC roles were abused? Which policies were changed? Which accounts had persistent access added? Which service principals were touched? Which access paths need to be revoked or rebuilt? Which state can still be trusted? These are not simple helpdesk questions. They are recovery questions. Native recovery is not enough when identity runs the business Native recovery actions can help restore access, but identity recovery must also restore the trusted relationships, policies and privileges the business depends on. Most native identity recovery thinking is still too narrow. It focuses on restoring access: Reset the password. Revoke the session. Re-register MFA. Disable the account. Re-enable the account. Remove the attacker’s authentication method. All of that matters. But it is not enough. After a control-plane compromise, the organisation needs to know what changed across the identity environment and whether it can return to a trusted state. That means recovering more than the user. It means recovering the relationships: Users and groups. Roles and privileges. Policies and settings. Service principals and applications. Authentication methods. Conditional Access. SaaS assignments. Cloud permissions. Administrative relationships. If those elements cannot be compared, validated and restored, recovery becomes manual reconstruction under pressure. That is where the real business risk sits. Recovery needs a known-good identity state Recovery is not complete until users, groups, roles, privileges, policies, settings, SaaS applications and integrations can be returned to a trusted state. A clean recovery process needs a known-good identity state. Not a vague assumption. Not “we think everything is back to normal.” Not “we reset the compromised users.” A known-good state. That means the organisation can compare the current identity environment against a trusted point in time and identify what changed. Who was added? Who was removed? Which groups changed? Which privileged roles were assigned? Which MFA methods were modified? Which policies were weakened? Which applications gained access? Which service principals were altered? Which SaaS permissions changed? Which relationships need to be restored? Without that visibility, recovery becomes guesswork. And in an identity-driven breach, guesswork is dangerous. Because the attacker may have used legitimate administrative functions. They may have blended into expected behaviour. They may have created persistence through permissions, credentials, service principals or management-plane changes. Microsoft specifically notes that Storm-2949 used legitimate cloud and Azure management features in ways that allowed activity to blend into expected administrative behaviour. That is exactly why identity recovery has to be treated differently. The goal is not only to restore access. The goal is to restore trust. Security controls reduce risk. Recovery restores control. Security controls are still essential. Microsoft’s mitigation guidance includes least privilege, privileged account auditing, Conditional Access, MFA, phishing-resistant MFA for administrators and privileged users, protection against malicious MFA registrations, Entra ID protection, and monitoring across identity, cloud and endpoint environments. Those controls matter. But prevention and detection are not the same as recovery. A strong identity security strategy should reduce the chance of compromise. A strong identity recovery strategy should help the organisation regain control when compromise happens anyway. That is the missing layer. Identity security asks: How do we stop this happening? Identity recovery asks: What do we do when the control plane has already been abused? That second question is now a board-level issue. Because the impact does not stop at login. In the Storm-2949 case, the attacker moved through Microsoft 365 data, Azure resources, Key Vault secrets, Storage accounts, SQL databases and virtual machines. Microsoft also describes abuse of Azure VM management features such as VM extensions and Run Command to create access paths and conduct further discovery. That is a business resilience problem. Not just an identity administration problem. The board-level question has changed The old question was: Can users get back in? That is too narrow. The better question is: Can the organisation restore the trusted identity state the business depends on? That includes: Users. Groups. Roles. Policies. MFA methods. Privileged access. Application assignments. Service principals. SaaS integrations. Administrative settings. Cloud access relationships. It also includes proof. Can the organisation prove what changed? Can it compare against a known-good state? Can it recover the right objects and relationships? Can it avoid manually rebuilding trust during an incident? Can it restore identity outside the original blast radius? That is the identity recovery conversation boards and executives need to understand. Because when identity is the control plane, recovery failure is not just technical downtime. It is loss of control. Identity recovery is now part of cyber resilience Storm-2949 is not important only because it involved Microsoft Entra ID. It is important because it shows where cloud attacks are heading. Attackers are targeting identities. They are targeting administrative paths. They are targeting cloud control planes. They are targeting the relationships between identity, SaaS, secrets, workloads and infrastructure. That changes the recovery conversation. Backup is no longer only about files, mailboxes or SaaS records. Recovery must include the identity layer that controls access to those systems. For Microsoft Entra ID and Okta environments, that means identity backup and recovery need to be assessed as part of the organisation’s broader cyber resilience strategy. Not as a future maturity item. As a current control. Because when identity becomes the attack path, recovery must restore more than data. It must restore control. Assess your identity recovery readiness FullBackup helps Australian organisations assess identity recovery readiness across Microsoft Entra ID and Okta. As a Keepit Elite Reseller Partner, FullBackup helps organisations strengthen SaaS and identity recovery with independent backup, immutable protection and recovery designed to sit outside the original blast radius. Assess your identity recovery readiness: https://www.fullbackup.com.au/identity-backup-recovery Need a workload-specific view? Explore Microsoft Entra ID recovery: https://www.fullbackup.com.au/entra-id-backup-recovery Explore Okta backup and recovery: https://www.fullbackup.com.au/okta-backup-recovery Sources Primary source: Microsoft Security Blog - How Storm-2949 turned a compromised identity into a cloud-wide breach. Supporting news source: Cyber Security News - Hackers Abuse Microsoft Entra ID Accounts to Exfiltrate Microsoft 365 and Azure Data.

ExaGrid is designed for the moment backup storage gets tested - when urgent restores, ransomware recovery, running jobs, competing copy jobs and users waiting all put pressure on the same architecture. Backup storage is often bought on capacity, retention, deduplication and cost. But when recovery is urgent, the real question is whether the backup target can help the business come back quickly, safely and predictably. Backup storage is judged when recovery is urgent Backup storage architecture is usually bought on a calm day. It is judged on the worst one. Capacity. Retention. Deduplication. Backup windows. Cost per terabyte. All important. But none of them prove the one thing the business actually needs when systems are down: recovery. A backup target can be excellent at storing backup data and still be poor at helping the business recover. That is the gap most storage refresh conversations miss. When recovery is urgent, the backup target stops being a quiet storage destination and becomes part of the recovery path. If it is slow, recovery is slow. If it is exposed, recovery is exposed. If it cannot scale cleanly, recovery becomes constrained. If it was designed mainly around inline deduplication, capacity efficiency and steady-state backup ingestion, it may look acceptable on a normal day but struggle when recovery becomes the primary workload. Backup storage should not only be evaluated by how well it stores backup data. It should be evaluated by how well it supports recovery. A green backup report is not recovery confidence Most backup environments look healthy on a normal day. Jobs complete. Reports are green. Retention policies are met. Capacity is monitored. Data is being protected. That matters. But a successful backup job is not the finish line. It is only evidence that a copy was created. Recovery confidence is different. It means knowing what happens when the environment is under pressure: an urgent restore, a ransomware event, a failed system, a corrupted workload, a bad change, a security investigation, a business unit waiting, and executives asking how long it will take. Backup jobs may still be running. Copy jobs may be competing for resources. Teams may be trying to recover recent data quickly while older retained data still needs to remain protected. That is when the backup target gets tested. And that is when architecture matters. Backup success proves the job ran. ExaGrid is designed for the harder test: recovery pressure, where ransomware recovery, urgent restores, active jobs and users waiting all converge. Recovery exposes what sits underneath the backup platform Most organisations have invested heavily in backup software. That investment matters. Backup software controls policies, jobs, schedules, retention logic and restore workflows. But recovery does not depend on the backup application alone. When recovery is urgent, the storage underneath the backup platform starts to matter just as much. A backup target built mainly around capacity and storage efficiency can look perfectly acceptable during steady-state operations. Backup jobs complete. Retention is met. Capacity is managed. The environment appears under control. Recovery changes the test. Can recent backup data be restored quickly? Can retained backup data survive deletion pressure? Can restore jobs run while backup jobs and copy jobs are still active? Can the platform scale without a forklift refresh? Can the architecture support the business under pressure, or does it become another constraint? The old question was: how much backup storage do we need? The better question is: what happens when we need to recover? Capacity growth is not recovery architecture This is where many backup storage refresh conversations go wrong. Not every backup target fails suddenly. Some simply slow down over time. Data grows. Retention grows. Backup jobs increase. Copy jobs expand. More workloads are added. More disk is added to keep up with capacity. On paper, the environment has grown. In practice, it may not have scaled. A backup target designed mainly around inline deduplication and capacity efficiency can be good at reducing stored data footprint. But adding more disk does not automatically add the processing power, memory, I/O, concurrency and recovery headroom needed to keep up. That is when the creep starts. Backup windows stretch. Copy jobs compete harder. Restore performance becomes less predictable. Operational headroom disappears. The platform gets larger, but not necessarily stronger. This is also where rehydration belongs in the recovery conversation. If backup data has to be rehydrated before it can be restored at speed, the target is not just storing backup data. It is influencing the recovery timeline. Capacity scaling is not the same as recovery scaling. HDD vs flash does not solve the architecture problem by itself Media performance matters. HDD matters. Flash matters. There are good reasons to care about both. But faster media does not automatically fix an architecture where dedupe processing, rehydration, concurrency limits or scale constraints sit in the recovery path. A flash-based target can still be constrained if the surrounding architecture cannot scale processing, memory, I/O and concurrency with the data. An HDD-based target can still be effective if the architecture is designed around the right recovery path, workload separation and scale-out model. The real question is not simply: is the target fast? The better question is: does the architecture scale performance, capacity and recoverability together? Inline deduplication and rehydration can become recovery bottlenecks Inline deduplication can be valuable. The issue is not deduplication itself. The issue is what happens when the architecture is built mainly around ingest efficiency and stored-capacity reduction, then has to support urgent recovery under load. In some environments, growth is handled by adding more disk. That may increase capacity, but it does not always add the compute, memory, I/O and concurrency needed to keep backup and recovery performance moving. If restore data must also be rehydrated before it can be recovered at speed, the target can become part of the recovery delay. That matters because recovery is rarely a single clean restore job. It often happens while backup jobs, copy jobs, security investigation and business pressure are all active at the same time. Snapshots are useful, but they are not the whole recovery strategy Snapshots can be extremely useful. In the right scenario, they provide fast rollback, short-term recovery points and operational convenience close to the production environment. But snapshots are not the same thing as independent backup and recovery architecture. They are often close to the source platform or primary storage environment. That closeness can be useful for speed, but it can create risk if the source platform, storage layer, administrative boundary, credentials, replication chain or snapshot management plane is compromised. Snapshots can help with some recovery scenarios. They should not be mistaken for the whole recovery strategy. The better question is not “do we have snapshots?” It is “do we have a recovery architecture that remains usable when the production environment is under pressure?” When ransomware reaches the recovery path This is not theoretical. KNP Logistics, the UK transport group behind the Knights of Old brand, became one of the clearest public examples of what can happen when ransomware affects the recovery path itself. Public reporting linked the incident to the Akira ransomware group and weak password access. Reporting also described severe operational disruption, a reported multimillion-pound ransom demand, around 700 job losses and the collapse of a 158-year-old business. Some reporting stated that backups and disaster recovery systems were compromised, leaving the company without a clean path back. The lesson is not only that passwords matter. They do. The bigger lesson is that recovery architecture has to assume a bad day: compromised access, encrypted systems, deleted or inaccessible backups, security teams under pressure, executives demanding timelines, and recovery teams trying to restore while the business is already down. That is the moment when backup strategy becomes real. Not when the report is green. Not when the backup window closes. When systems are down and the business needs to come back, the recovery path either works or it does not. When ransomware reaches the recovery path, the problem is no longer just disruption. It becomes recoverability. What actually fails during recovery In a real recovery event, the problem is rarely one failed system. It is pressure stacking on pressure. Restore jobs need to run while backup jobs continue. Copy jobs may still be moving data. Recent backup data needs to be recovered quickly. Older retained data still needs to be protected. Security teams may be investigating the same environment recovery teams are trying to restore. Executives may be asking for recovery timelines before the technical team has confirmed which recovery points are usable. If ransomware is involved, deletion pressure, compromised credentials and encrypted systems may all be part of the same operational window. A target designed mainly around inline deduplication may look efficient while backup jobs are running, but recovery is a different workload. If data growth has been handled mostly by adding capacity, not scaling the full performance architecture, the target can become constrained when backup jobs, copy jobs and restore jobs collide. Add rehydration into the recovery path, and the backup target can become part of the delay. The business does not care that the target was efficient yesterday. It cares whether it can recover today. Backup efficiency is not the same as recovery usability This is the distinction many storage refresh conversations miss. Backup efficiency matters. Deduplication matters. Capacity reduction matters. Retention cost matters. But recovery is not just a storage efficiency problem. Recovery is an operational outcome. The business does not ask how efficient the backup target was when systems are offline. It asks whether the organisation can recover fast enough, safely enough and predictably enough. Which recovery points are still usable? Can we restore without waiting on rehydration, retrieval, copy-back or overloaded infrastructure? Can retained data survive attack pressure? Can the platform handle recovery while backup and copy jobs still run? Can performance scale as data grows? Can the architecture hold up when backup, copy and restore activity collide? A backup target should not only store backup data. It should help make recovery usable. How ExaGrid changes the backup storage architecture conversation ExaGrid is not generic storage sitting underneath a backup application. It is purpose-built Tiered Backup Storage designed around the difference between backup efficiency and recovery usability. That distinction matters because recovery is not only about keeping backup data. It is about how quickly, safely and predictably that data can be used when the business needs it back. ExaGrid separates the parts of the architecture that often get blended together: fast recovery, efficient retention, scale-out growth and ransomware resilience. Landing Zone: fast access to recent backup data The Landing Zone is designed for recent backup data. That matters because recent data is often the first place teams go during an urgent restore. When a VM, file server, database or application needs to come back quickly, restore performance is not a technical footnote. It is the point. Repository Tier: efficient long-term retention The Repository Tier is designed for deduplicated long-term retention. Organisations still need efficient retention for operational, regulatory and business reasons. But retention efficiency should not create recovery uncertainty. Keeping backup data is only useful if the organisation can recover from it when it matters. Scale-out growth: capacity and performance together In many backup storage environments, growth means adding capacity first and hoping performance keeps up. That can work for a while, but data growth eventually becomes a performance, concurrency and recovery-headroom problem. ExaGrid’s scale-out model adds appliances into a single system, with compute and capacity growing together. That matters because recovery pressure is not only a capacity problem. It is an architecture problem. Retention Time-Lock: resilience when deletion pressure is part of the event In a ransomware scenario, the question is not simply: do we have backups? The harder question is: can usable backup data survive the attack path? Retention Time-Lock is designed to help protect retained backup data using delayed deletes, immutable data objects and a non-network-facing Repository Tier. These are not cosmetic features. They are architectural controls for the moment when deletion pressure, ransomware activity or compromised access may be part of the recovery scenario. That is why architecture matters. Not just capacity. Not just deduplication. Not just media type. Not just a feature checkbox. Architecture. ExaGrid separates fast recent restores, deduplicated long-term retention, ransomware recovery controls and scale-out growth into one backup storage architecture. The backup application still matters This is not an argument that backup software does not matter. It absolutely does. Veeam matters. Commvault matters. NetBackup matters. Rubrik matters. The operational processes around those platforms matter. The people who run them matter. Most organisations are not looking to rip and replace their entire backup environment. They already have policies, jobs, retention schedules, operational processes and internal skills built around the platforms they run today. The point is simpler: recovery does not depend on the backup application alone. It also depends on the architecture underneath it. The value is not that organisations need to abandon the platforms they already run. The value is that they can strengthen the recovery architecture supporting them. Backup storage is now part of cyber resilience Backup storage used to sit quietly in the background. That is no longer good enough. During a serious incident, the business does not care that yesterday’s backup job completed. It cares whether systems can come back fast enough, cleanly enough and safely enough. The board may never ask about dedupe ratios, backup targets or rehydration paths. But they do ask about ransomware, downtime, operational continuity, risk and recovery timelines. Backup storage sits underneath all of that. · If the backup target slows recovery down, resilience suffers. · If retained backup data is exposed to deletion, resilience suffers. · If the platform grows in capacity but not in recovery performance, resilience suffers. · If snapshot access depends too heavily on the same compromised environment, resilience suffers. That is why backup storage is no longer just infrastructure. It is part of cyber resilience. Questions to ask before your next backup storage refresh Before the next backup storage refresh, organisations should ask more than capacity, deduplication and price questions. Those questions still matter. But they are not enough. Is the platform designed for recovery under pressure, or mainly for backup ingestion? Does performance scale with capacity? Does adding disk also add the compute, memory and I/O needed to keep up? How much rehydration sits in the recovery path? Can recent backup data be recovered quickly when the business is waiting? How is retained backup data protected from deletion or ransomware pressure? Can the platform scale without forklift upgrades? Will recovery performance hold up when backup jobs, copy jobs and restore jobs compete for resources? Are snapshots being treated as one recovery tool, or as the whole recovery strategy? Does the architecture support the recovery outcomes the business actually expects? These are not theoretical questions. They are the questions that matter when recovery is urgent. Before you refresh backup storage, ask better recovery questions. Do not let backup storage become the recovery bottleneck Backup storage used to be judged mainly by how well it handled backup jobs. Today, it needs to be judged by how well it supports recovery. Capacity still matters. Retention still matters. Deduplication still matters. Cost still matters. Media type still matters. Snapshots still matter. But recovery architecture matters more. When recovery is on the line, the backup target is not background infrastructure. It is part of the recovery path. That is why FullBackup works with Australian organisations reviewing ExaGrid as part of their backup and recovery architecture, especially where recovery speed, ransomware resilience, long-term retention, scale-out growth and predictable recovery under pressure all matter.

Why recovery has become a board-level issue This article focuses on SaaS recoverability, the ability to restore data in a way that is independent, auditable, and defensible under scrutiny. SaaS recovery evidence Sa Sa A board-level view of the minimum conditions required for SaaS recoverability to withstand audit, regulatory, and assurance scrutiny: independence, immutability, precision, and proof. SaaS platforms now underpin critical business operations. Email, identity, collaboration, CRM, finance, HR, and customer data increasingly exist only  inside third-party cloud services such as Microsoft 365, Entra ID, and Salesforce. Availability is high. Uptime is excellent. That is not the issue. The issue is recoverability and, more specifically, whether it can be proven . Boards are no longer asking whether backup exists. They are asking whether recovery can be demonstrated, defended, and repeated under scrutiny . This shift has been driven by three realities: SaaS now supports critical business services, not ancillary systems Identity compromise has become the dominant failure mode, placing recovery paths inside the blast radius Regulatory and assurance frameworks have moved from intent to evidence In this environment, “we believe we can recover”  is not a position - it is an exposure . When recovery becomes a formal question during audit, insurance review, CPS 230 uplift, or post-incident review, confidence without artifacts becomes a liability. Recovery is no longer an IT hygiene discussion. It is an assurance problem . What auditors actually assess (and what they don’t) Auditors, regulators, and risk committees do not validate vendor claims, architecture diagrams, or policy statements in isolation.   They assess evidence . Specifically, they look for answers to a small number of non-negotiable questions: Can recovery occur independently of the failed or compromised control plane? Is recovered data protected from alteration, deletion, or dispute? Can recovery be executed precisely, without introducing broad operational disruption? Can the organisation demonstrate - after the fact - exactly what was restored, by whom, when, where, and with what outcome? If these questions cannot be answered with verifiable artifacts, the capability is treated as untested or unproven  - regardless of how confident the IT team may be. This is where many SaaS recovery strategies fail: not because recovery is impossible, but because it cannot be evidenced under scrutiny . Manual reconstruction versus - complete recovery etc etc and permissions and system-generated recovery evidence.  Left: recovery reconstructed from architecture knowledge and assumptions. Right: system-executed restore with an authoritative execution record - the starting point for audit and assurance. The SaaS Recovery Evidence Framework The framework below defines the minimum conditions  a SaaS recovery capability must meet to withstand audit and board scrutiny. It is deliberately outcome focused. It does not assess tools, vendors, or architectures in isolation. It assesses whether recoverability can be demonstrated . Each pillar represents a non-negotiable requirement. If any one is missing, recovery assurance is incomplete. The sections that follow expand each pillar into practical expectations, evidence artifacts, and minimum testing standards - reflecting what boards, auditors, and regulators look for in practice. Pillar 1: Independence Why independence matters Most SaaS incidents today are not infrastructure failures. They are identity failures . Independence defines the blast radius. When production and protection share the same system, failure propagates. When recovery is independent, it stops. When identity systems such as Entra ID are compromised - through credential abuse, misconfiguration, or privileged access error, attackers or administrators can alter permissions, disable safeguards, and interfere with recovery mechanisms. If backup and recovery operate within the same control plane, recovery itself sits inside the blast radius . From an assurance perspective, recovery that depends on the same identities, permissions, or platforms that contributed to the incident cannot be considered independent. What independence looks like in practice Independence is the ability to execute recovery even when primary administrative access is constrained or compromised . It does not require isolation from the internet, nor does it rely on manual or offline processes. It requires separation of control . In practice, this includes: Separate authentication and authorisation boundaries for backup and restore operations Restricted administrative overlap between production SaaS platforms and recovery systems Documented restore paths that remain viable during identity or privilege-related incidents What auditors expect as evidence Auditors will not accept statements such as “independent by design” without validation. They typically expect to see: A documented control-plane separation statement Evidence of access and role separation between production and recovery environments Restore procedures that have been validated under constrained identity conditions Minimum viable test At least annually, organisations should be able to demonstrate independence by: Simulating restricted administrative access within the SaaS tenant (in a controlled manner) Executing a scoped restore using the documented recovery process Capturing timestamps, approvals, system logs, and recovery outcomes The objective is not disruption. It is demonstrability. Common failure modes Backup systems integrated with the same SSO and administrative groups as production “Break glass” accounts that exist on paper but have never been exercised Restore procedures that require global administrator access in the affected tenant   Pillar 2: Immutability Why immutability matters In any serious incident, investigation, or legal dispute, organisations must assume that privileged access may be abused, whether intentionally, accidentally, or under duress. If backup data can be altered or deleted by administrators, attackers, or insiders, the integrity of recovery becomes contestable . From an audit perspective, this directly undermines defensibility. Immutability is not a statement of intent. It is a set of enforced technical constraints . Immutability is what makes recovery defensible.  If backup history can be changed, it can be challenged. If it’s write-once, tamper-evident backup, it stands. What immutability looks like in practice Immutable backups are protected from deletion or modification for a defined retention period, enforced by the backup platform itself, not by operational policy or administrative discipline. In practice, this includes: Retention enforced at the storage or backup layer Administrative actions restricted and fully logged Tamper resistance that can be demonstrated, not asserted What auditors expect as evidence Auditors do not accept immutability claims at face value. They typically expect: Documented retention and immutability policies Evidence that deletion or alteration is technically prevented, even by privileged users System logs demonstrating enforcement of immutability controls Minimum viable test In a controlled or non-production environment, organisations should be able to demonstrate immutability by: Attempting to delete or alter protected backup data using an administrative account Capturing denial responses, system logs, and policy enforcement evidence The objective is not to simulate malicious behaviour. It is to demonstrate that controls cannot be bypassed. Common failure modes ·       Treating retention labels or soft-delete features as immutability ·       Backup administrators able to purge historical data ·       Immutability controls documented but never tested ·       Absence of verifiable evidence that immutability is enforced in practice Pillar 3: Precision Why precision matters Auditors and boards care deeply about blast radius . Recovery approaches that rely on exports, bulk restores, or manual reconstruction may technically return data, but they introduce disruption, delay, and secondary risk. They also weaken assurance by increasing operational uncertainty during recovery. From an assurance perspective, recovery that cannot be executed precisely is not controlled. Precision means restoring the exact object , with context intact - not rebuilding data manually after the fact. Precision means fixing only what’s damaged.  Coarse restores change too much. Object-level restore brings back the right item, in the right place, without collateral impact. What precision looks like in practice Precision recovery enables restoration at the smallest meaningful unit of impact, without collateral disruption. In practice, this includes: Object-level restore of individual items (for example: mailbox items, files, records, or configurations) Restore to the original location within the SaaS platform Preservation of permissions, metadata, relationships, and version history What auditors expect as evidence Auditors look for evidence that recovery can be executed surgically and repeatably. Typically, this includes: Logs identifying the specific object restored Proof of restore target and timestamp Verification that permissions, structure, and metadata were preserved post-restore Minimum viable test On a quarterly basis, for each critical SaaS workload, organisations should be able to demonstrate precision by: Restoring a deliberately high-friction object (not a trivial example) Validating permissions, metadata, and structural integrity ·Capturing restore logs and verification evidence The objective is to demonstrate controlled recovery , not convenience. Common failure modes Export-and-reimport processes presented as recovery capability Restores that return content but lose permissions, metadata, or relationships Recovery tests limited to simple or low-impact objects that do not reflect real incidents Pillar 4: Proof Why proof matters Assumptions don’t count. Evidence does. Recovery isn’t complete until it can be independently verified, documented, and defended. Proof is what converts recovery from a technical capability into assurance . Boards, auditors, insurers, and regulators do not assess recovery based on intent or confidence. They assess whether the organisation can reconstruct the recovery event itself  — months later, under scrutiny — using verifiable records. If the recovery narrative cannot be recreated, the recovery cannot be relied upon. What proof looks like in practice A defensible recovery record answers, unambiguously: Who initiated the restore What object or scope was restored The point in time from which data was recovered The target location of the restore How long the recovery took Whether the restore completed successfully This information must be available without interpretation or institutional memory. What auditors expect as evidence Auditors typically expect proof to be packaged as a structured Recovery Evidence Pack , containing: System-generated restore logs with timestamps References to change, incident, or problem records Documented verification steps and outcomes Formal approvals and sign-off The emphasis is on traceability,  the ability to follow the recovery event from initiation through to completion and validation. Minimum viable test Organisations should standardise a single Evidence Pack format and require: At least one documented restore test per quarter for each critical SaaS workload Evidence stored in a controlled repository and retrievable on demand The objective is not volume. It is repeatability and defensibility . Common failure modes Restore tests performed without capturing verifiable artifacts Evidence dispersed across screenshots, emails, or personal storage Recovery activity not linked to formal change, incident, or risk reporting processes Where most organisations quietly fall short Most organisations test recovery. Very few test recoverability . The difference is evidence. These failures are not exceptional. They are routine in modern SaaS environments. Common SaaS recovery scenarios. These aren’t edge cases - they’re routine operational events that test independence, immutability, precision, and proof In practice, the following gaps are routinely observed: Recovery paths that depend on the same identity systems implicated in the incident Backup data that can be altered or deleted by privileged users Restore methods that rely on manual reconstruction rather than controlled recovery Testing activities that generate confidence, but no verifiable artifacts Individually, these gaps may appear manageable. Collectively, they undermine assurance. They also tend to remain hidden until scrutiny is applied during audit, insurance review, regulatory uplift, or following a real incident - when recovery shifts from an operational task to a formal question of accountability. What “good” looks like Enterprise-grade SaaS recovery aligns to this framework by design , not through procedural workarounds. It is characterised by recovery capability that is independent of the primary SaaS control plane, protected by enforced immutability, capable of precise object-level restoration, and supported by verifiable audit trails. Platforms such as Keepit  support this model by providing independent, immutable copies of SaaS data, granular restore capability, and system-generated recovery logs suitable for assurance and audit review. As a Keepit Elite Reseller Partner , FullBackup helps organisations implement this evidence-based recovery model and operationalise it into repeatable testing and audit-ready Evidence Packs  suitable for board, regulator, and insurer scrutiny. Crucially, this model allows recovery testing to be performed without introducing production risk . Capabilities such as sandbox-based restores for platforms like Salesforce and Dynamics 365, non-destructive testing approaches, and controlled access to Microsoft 365 recovery data enable organisations to validate recoverability regularly - without impacting live operations. This is what separates theoretical recoverability from defensible assurance : recovery that can be tested, evidenced, and repeated without disruption. Final thought Recovery is no longer a matter of confidence. It is a matter of defensibility . If a SaaS recovery capability cannot be demonstrated with verifiable artifacts, it will eventually be challenged - by auditors, regulators, insurers, or following a real incident. Evidence is what closes that gap. If your organisation cannot currently produce this evidence on demand, the gap is already measurable. Asset

C-Suite Briefing | CPS 230 & Essential Eight Essential Eight SaaS Resilience: Executive Overview Australian organisations are entering 2026 with unprecedented dependence on SaaS platforms such as Microsoft 365, Dynamics 365, Salesforce, Jira, Confluence, Miro, DevOps and others. Business-critical processes, operational workflows, and decision-making now operate almost entirely within these cloud ecosystems. The Essential Eight was designed for a perimeter-based world of servers, desktops, and networks. In 2026, that world no longer exists. Business operations now live inside SaaS platforms governed by identity, APIs, and configuration state. When those fail, prevention controls do not restore service. Recovery does. Resilience in 2026 requires applying Essential Eight not only to endpoints and servers, but to the identity and SaaS layers where operations now live. The next material incident will target identity first and SaaS platforms second - disrupting operations, not merely stealing data. At the same time, threat actors have shifted decisively toward operating inside  trusted SaaS environments. Modern incidents are increasingly characterised by: identity compromise privilege escalation SaaS manipulation destruction of recovery capabilities This sequence is no longer theoretical - it has become the dominant failure pattern in real-world incidents. This briefing provides an updated 2026 interpretation of Essential Eight, outlines SaaS-driven resilience gaps, and summarises the expectations now emerging from auditors and regulators. Modernising the Essential Eight for a SaaS-first, identity-driven environment. The left column shows the official ACSC controls; the right column highlights their practical 2026 interpretation for SaaS resilience, identity protection, and independent recovery. The Material Shift: Essential Eight Was Designed for Infrastructure. Your Business Now Runs on SaaS. Essential Eight remains a strong framework. What changed is the operating environment: Identity is the central trust and compromise point. SaaS platforms now contain core operational workflows and decisions. Browsers function as the new OS. Threat actors target operational continuity. Backup destruction is routine once privileged access is gained. Many organisations believe they are tracking toward ML2 or ML3, while their actual SaaS resilience remains at ML0–ML1 - a material operational risk. How organisational architecture has shifted from infrastructure → cloud → SaaS- and identity-centric operations, with recovery now requiring isolation beyond the identity blast radius. Identity Compromise Now Determines the Blast Radius Modern incidents follow the same progression: 1. Authentication or credential compromise  2. Privilege escalation  3. Lateral movement into SaaS  4. Manipulation or corruption of SaaS data  5. Targeted destruction of backups  ACSC’s 2023 model explicitly states attackers at ML2/ML3 will destroy backups accessible to compromised privileged accounts. Two board implications: Resilience requires backup independence from identity systems. SaaS must be treated as operational infrastructure. The ‘Blast Gradient Stack’ illustrates the modern attack sequence and the only layer designed to withstand identity-driven compromise: an independent, immutable recovery architecture. The Reality: Most Organisations Underestimate SaaS Resilience Gaps Findings from assessments: SaaS backups live in the same cloud and identity boundary.  Administrators can delete or modify backup data.  Backups capture raw objects, not operational systems.  Full restoration of metadata, workflows, relationships is not possible.  Recovery testing is infrequent or superficial.  BCPs assume recoverability that does not exist. This creates a false sense of Essential Eight maturity - exposed only during real incidents. Emerging Expectations from Auditors and Regulators Across finance, government, utilities, education and healthcare, uplift expectations now include: Independent backups isolated from identity  Immutable copies not deletable by privileged accounts  Sovereign or controlled storage  Ability to restore full SaaS environments  Evidence of tested RTO/RPO  Reduction of cloud administrative privileges  Phishing‑resistant MFA for all privileged access  These expectations align with Essential Eight, SOCI, CPS 230 operational‑resilience requirements. Practical Recommendations for Executive Teams Executives should request structured reporting on: Identity Blast‑Radius Assessment  SaaS Resilience Assessment  Backup Independence Review  Privileged Access Reduction  Recovery Testing Audit  Reports should include validated recovery times, confidence levels, and identified dependencies. Executive Bottom Line Resilience in 2026 depends on three truths: Identity is the primary target.  SaaS contains the operational core of the organisation.  Backup architecture determines survivability when identity fails. Essential Eight remains effective only when applied to the systems where the organisation actually operates. Resilience is not about preventing incidents - it is about continuing operations when incidents occur. The Path Forward - Turning Insight into Assurance The shift to SaaS-driven operations means Essential Eight maturity cannot be measured solely through endpoint controls, patching cycles, or domain admin restrictions. Those remain necessary - but they no longer define resilience on their own. Your operational resilience now depends on three questions: How far can a compromised identity travel through your SaaS estate? Can your organisation restore a working SaaS environment - not just data - after a failure? Are your backups independent enough to survive an identity-layer breach? Boards and regulators increasingly expect these answers as evidence, not assertion. Most organisations discover their gaps only during an incident. The leaders surface them before  one occurs. Introducing the Essential Eight SaaS Resilience Assessment To help organisations benchmark real resilience - not perceived maturity - we’ve aligned our assessment model with ACSC Essential Eight outcomes, SOCI, CPS 230 expectations, and modern SaaS dependency patterns. It provides structured, evidence-based scoring across: Identity blast-radius exposure SaaS platform recoverability (metadata, logic, hierarchy) Backup independence and immutability Privilege design across identity and SaaS tenants Recovery testing completeness Alignment with ML1, ML2 and ML3 expectations Where traditional maturity models stop at infrastructure, this evaluation continues into the operational heart of your environment. What You Receive (Board-Ready Outputs) A SaaS-adjusted Essential Eight maturity score A heatmap  of identity and SaaS failure modes A dependency map  of high-impact workflows A SaaS recovery confidence rating A prioritised uplift roadmap  tied to ML2–ML3 expectations Evidence for CPS 230 , ISO 27001 , NIST , and internal audit This assessment does not replace traditional Essential Eight maturity reviews - it corrects the blind spot those reviews currently contain. Closing Message to the Executive Team Resilience in 2026 is not about whether you can prevent an incident. It is about whether your organisation can continue operating when identity and SaaS fail at the same time . Essential Eight still holds - but only when expanded into the systems where your business now runs. The organisations that thrive in the next wave of cyber-events will be those that: minimise identity blast radius, harden SaaS systems as core infrastructure, ensure backups are genuinely independent, and validate recovery as a lived capability, not a checkbox. Your shift to SaaS has already happened. Your resilience model must now catch up. If you read nothing else, read this. Final Word to Boards and Executive Teams The Essential Eight remains one of Australia’s most respected cyber resilience frameworks. What has changed is not its intent, but the environment it must now protect. In 2026, identity is the primary attack surface. SaaS platforms hold the workflows that run the organisation. Recovery architecture determines whether operations continue when prevention fails. Boards that rely on legacy interpretations of Essential Eight risk mistaking control coverage for operational resilience. Boards that extend Essential Eight into identity, SaaS and independent recovery gain something far more valuable: confidence under pressure . Resilience is no longer measured by how well incidents are prevented. It is measured by whether the organisation can continue operating when incidents occur. That is the standard now being applied - by attackers, by regulators, and increasingly by boards themselves.

If You Can’t Restore the Structure, You Lose the System. Dynamics 365 has become the operational spine of the enterprise. Sales, finance, service, supply chain, every critical function runs through the same interconnected engine. That interconnectedness is powerful. It’s also exactly where the risk hides. Across most organisations, there’s a quiet assumption: “Our Dynamics data is safe because it’s in Microsoft’s cloud.” That belief collapses the moment something actually goes wrong. Microsoft’s responsibility is keeping the platform online. Your responsibility is keeping your data  recoverable - the relationships, workflows, schema, rules, identities, and logic that make your Dynamics environment function. The distinction is blunt but essential: Microsoft protects the service. You must protect the system your business depends on. Shared Responsibility Model Microsoft Doesn’t Back Up Your Dynamics 365 Data the Way You Think They Do Microsoft gives you three things: platform uptime service availability baseline continuity That’s it . What they don’t give you is full, independent, point-in-time backup of your Dynamics 365 environment. The native recycle bins, snapshots and soft-delete features are conveniences, not protection. They won’t save you from: cascading corruption runaway Power Automate flows identity breaches schema or plugin failures bulk deletes faulty integrations API-driven overwrites that rewrite history in seconds Dynamics 365 is not a simple set of tables. It’s a living graph of relationships, workflows, metadata, identity mappings and business rules. Lose the structure, permissions, or relationships - and you lose the system. That’s when teams learn the uncomfortable truth: "The data is back. The system is still broken." Restoring objects isn’t restoring the system. Dynamics 365 fails when the structure doesn’t return. Why Legacy Backup Tools Collapse Under Dynamics 365 Complexity Most backup tools do one thing well: they copy objects. But Dynamics 365 isn’t a bucket of objects - it’s an interconnected system of relationships, metadata and business logic. When a tool only captures the objects, it captures the least important part of the environment. Traditional backups miss the pieces that actually make the system work: relationship mapping custom metadata object graphs workflow context identity links and permissions hierarchy and dependencies version and history chains security and role logic Restore without these, and you don’t get a system back - you get a box of disconnected parts. It’s like trying to rebuild a factory with blueprints for the chairs but none of the machinery, wiring or control systems. The pieces are present, but the operation is impossible. The result is always the same: the environment returns incomplete and unusable. Dynamics 365 doesn’t break when you lose data - it breaks when you lose structure. Keepit protects the whole system: metadata, relationships, logic, workflows, permissions - all stored immutably across two independent private clouds, ready for full-system or sandbox-level restore. Where Keepit Stands Out - Architecture Built for Reality, Not Marketing Dynamics 365 isn’t a pile of records. It’s a living system with rules, logic, identity, and structure woven through every table. That’s why Keepit is designed to capture the entire shape  of the environment, not just the objects sitting inside it. Keepit preserves: deep metadata and schema relationships across all entity types identity and ownership mappings workflow and automation context (within Microsoft’s API boundaries) security roles, teams, and sharing logic historical version chains and audit trails true system-level point-in-time restore independent, sovereign, immutable storage across two private clouds Other vendors hand you a bucket of restored objects. Keepit returns a functioning system at a known-good moment in time. That’s operational continuity. Not marketing. Not hope. Reality. These are the failures that break Dynamics 365 and none of them are fixed by restoring objects. Integration corruption. Runaway flows. Identity breaches. Bulk deletes. Keepit protects the system , not just the data. Where Dynamics 365 Actually Breaks in the Real World The biggest threats aren’t ransomware, they’re the silent, internal failures that happen every day inside your own estate. A sync job overwrites 40,000 records before anyone notices. A misconfigured plugin corrupts workflows and logic chains over weeks. A flow misfire deletes entire related-entity trees in a cascade. A compromised identity quietly modifies or reassigns critical objects. An admin bulk-updates production instead of sandbox and it sticks. Dynamics isn’t a loose collection of objects. It’s a connected system. When one piece goes wrong, the damage travels. Without an independent backup platform that captures relationships, logic, and structure, rollback becomes guesswork and guesswork isn’t recovery. Regulators are converging on the same requirement: independent SaaS data resilience . CPS 230, ISO 27001, SOCI and NIST all point to verifiable, out-of-band recovery. Essential Eight reinforces the outcome - lifting maturity toward independent, auditable resilience. Why Auditors and Regulators Now Care About Your Dynamics 365 Backups CPS 230, ISO 27001, SOCI and NIST have all shifted toward the same expectation: you must prove you can recover independently of your SaaS provider. For Dynamics 365, that means demonstrating: Independent, immutable backups stored outside Microsoft’s blast radius Offline or logically air-gapped copies that cannot be altered or deleted Point-in-time rollback to a known-good system state Recovery of metadata, schema, relationships and identity mappings - not just raw objects Documented RPO/RTO aligned to real business impact No sole reliance on the production tenant as your recovery mechanism Dynamics 365 is now classified as a material service for many organisations. When it breaks, operations stop - and regulators know it. Keepit provides the independent architecture auditors look for: verifiable copies, immutable storage, full-system restoration, and evidence you can defend in a CPS 230 or ISO 27001 review. Most backup tools give you objects . None of that brings Dynamics 365 back to life. A real recovery restores the system  - the relationships, metadata, identity mappings and workflows that make the business run. That’s the difference between data returned  and operations restored The Bottom Line Dynamics 365 isn’t a collection of tables, it’s the system your organisation runs on. It’s too interconnected, too identity-driven, and too operationally critical to entrust to shallow backup tools. Microsoft keeps the platform  alive. You’re responsible for keeping the business logic  alive. When something breaks, “objects in a bucket” won’t rebuild a working environment. Only a full restore of structure, metadata, relationships, workflows and identity can bring the system and the business - back online. That’s the difference Keepit delivers: not data back… a working Dynamics 365 system back. If you want independent, full-system protection for Dynamics 365 - including point-in-time environment restores - we can show you exactly how Keepit handles metadata, relationships, logic and workflows in a live tenant. → Link to Demo / Pilot Page

(FullBackup Threat Intelligence - November 2025) The Threat Has Mutated For a long time, organisations treated ransomware like a single-event crisis: One attacker. One compromise. One clean-up. One recovery. That model no longer fits the world we operate in. Threat intelligence across 2025 points to a different pattern entirely: multiple ransomware groups active in the same window, each running their own campaigns, each exploiting the same identity weaknesses that almost every SaaS platform depends on. They’re not collaborating. They’re not synchronised. They’re not sharing infrastructure or objectives. But the effect is the same for defenders: persistent, multi-directional pressure on identity systems and the SaaS applications built on top of them. This is the swarm effect - not coordination, but concurrency. The risk created when many unrelated threat actors operate simultaneously across the cloud and identity ecosystem. Organisations are now shifting toward resilient backup architecture to ensure recovery remains possible even when identity systems or SaaS tenants are compromised. A swarm of ransomware variants - the reality driving boards to demand fast, clean, independent recovery. The Swarm Effect: Many Attackers, One Problem October didn’t deliver one dominant ransomware group — it delivered many. Activity spiked across: LockBit Medusa RansomHub Hunters 8Base Play BlackSuit Cactus Each group runs its own playbook. Each targets different industries. Each uses different intrusion methods. Each probes different layers of the modern SaaS stack. None of them work together. But they do  operate in the same month, often the same week and that overlap creates a level of background risk far higher than most organisations are built for. From the defender’s side of the fence, it doesn’t feel like eight separate campaigns. It feels like one continuous, unbroken pressure coming from every angle. That’s the swarm effect in practice: not collaboration, but concurrency, many independent attackers active at once, all exploiting the same structural weaknesses in identity and SaaS. Identity Is the New Blast Radius & Why Identity Resilient Backup Architecture Matters in 2025 Attackers don’t break in through servers anymore. They break in through identity. It’s the part most resilience plans still underestimate. Groups like UNC3944 (Scattered Spider) proved this repeatedly. They didn’t need hypervisor exploits or kernel flaws. They gained control by undermining the trust layer: MFA fatigue SIM swapping social engineering of identity support OAuth consent abuse session hijacking cloud admin portals SaaS-level permissions Once identity falls, every system that trusts that identity becomes exposed - immediately. In a cloud-first organisation, that means the entire SaaS estate: M365 Entra ID Okta-federated apps Salesforce BambooHR Confluence DevOps tooling And yes - the backup systems that authenticate through the same identity plane. Identity compromise doesn’t give attackers access to one system. It gives them access to all of them. That’s why identity is now the real blast radius. Why Identity Breaches Break SaaS Backups Identity attacks don’t stop at production systems, they extend instantly to anything that depends on the same identity plane. If your backup lives inside the same tenant, trusts the same OAuth permissions, or uses the same admin accounts, it becomes part of the blast radius the moment identity falls. This is exactly how real incidents unfold.   M365 / Entra ID Most backup tools operating inside  Microsoft 365 inherit the same trust boundaries as production. They rely on: Entra ID authentication OAuth applications delegated in-tenant permissions Microsoft API scopes the same admin identities used for everyday access So when identity is compromised, attackers can: strip or modify backup permissions delete or corrupt connector apps shorten or disable retention purge objects or entire workloads impersonate backup administrators delete snapshots poison or erase audit logs None of this requires ransomware. None of this requires encryption. Just control of identity. If the backup lives inside the tenant, it lives inside the blast radius. Okta Okta increasingly acts as the identity broker for entire SaaS estates .When Okta is compromised, attackers can: create shadow admin accounts bypass MFA grant malicious OAuth consent steal tokens impersonate administrators escalate privileges across connected apps Any backup solution that authenticates through Okta inherits the same exposure. Once identity is compromised, the backup layer becomes accessible, or modifiable through the same trust path. HR, CRM, Collaboration & DevOps SaaS UNC3944-style identity attacks affect platforms such as: BambooHR Salesforce Dynamics 365 Confluence Jira Azure DevOps Zendesk If backup data is stored inside  these platforms, or if recovery relies on the same SaaS identity trust, the backup fails for the same reason the platform fails. The backup is not separate - it is downstream of the same compromise . When attackers take identity, they inherit everything that trusts it - SaaS platforms and any backups stored inside them. This is the shared blast radius. In-Platform Backups Fail for the Same Reason Attackers don’t need to “break the backup.” They simply: break the identity layer hijack OAuth relationships disable connectors escalate privileges modify retention poison logs delete snapshots disrupt API scopes Once identity fails, everything inside that boundary becomes exposed - including backups. This is why snapshots, versioning, recycle bins, API-driven retention, and in-tenant backup layers are no longer resilience strategies. They’re support features - not  recovery systems. Real resilience requires the recovery layer to sit outside the identity plane entirely. Regulators Already Agree - Why Resilient Backup Architecture Matters in 2025 The shift toward independent, immutable, out-of-band recovery  isn’t just best practice, it’s quickly becoming the regulatory baseline across Australia. And every major framework points in the same direction: recovery must survive a failure of the system being recovered. APRA CPS 230 - “Recovery must survive system failure.” CPS 230 requires entities to prove  they can recover from operational disruption. That is only possible when recovery data is stored outside the system or service experiencing the failure. Backups held inside the same SaaS tenant, relying on the same identity boundary, cannot meet this requirement — because the failure and the backup sit inside the same blast radius. Essential Eight - “Isolation and immutability.” The ACSC’s Essential Eight calls explicitly for: immutable backups , and isolation from compromise pathways . In-tenant snapshots, SaaS recycle bins, and cloud-native version histories fail both tests. ACSC Cloud & Identity Guidance - “Identity compromise breaks everything behind it.” The ACSC has repeatedly warned that identity compromise undermines: authentication, access control, audit integrity, privilege separation, and operational continuity. This is why the ACSC recommends segregating identity, administration, and recovery functions . If your backups use the same identity provider (Entra ID, Okta) as production, they inherit the same vulnerability and break this requirement outright. ISO 27001 - “Recovery data must be independent and non-repudiable.” ISO 27001 requires controls ensuring that recovery data: cannot be altered, cannot be repudiated, and remains available even during system failure. This presumes a recovery layer that is operationally separate  from production systems. In-platform backups simply cannot satisfy this. SOCI Act & CIRMP - “Backup must withstand a critical-infrastructure failure.” For operators regulated under the Security of Critical Infrastructure (SOCI) Act , backup isn’t an IT best practice - it’s a statutory requirement  embedded in the Critical Infrastructure Risk Management Program (CIRMP). SOCI expects operators to: maintain system availability during cyberattack , demonstrate continuity , and prove recoverability even when primary systems or identity layers are compromised . Any backup held inside: the same SaaS platform, the same cloud region, the same identity domain, or the same administrative boundary fails this expectation. If identity collapses or if a SaaS provider suffers a disruption - SOCI requires that recovery remains possible. This is only achievable when backup data is held outside the compromised system and outside  its trust boundary. Independent, sovereign, immutable backup ( Keepit + ExaGrid ) achieves this. In-tenant SaaS backups do not. Australian Incidents Confirm the Trend Across the last two years, Australian breach reports show the same root cause repeatedly: identity compromise → SaaS disruption → data loss or administrative lockout. And in every case where organisations relied on in-platform backups, the result was identical: the “backup” was trapped inside the same environment that had already failed. The FullBackup Approach: Selecting Technology That Survives Modern Threats Modern ransomware and identity-driven attacks require more than one tool, one platform, or one vendor mentality. We select the best technologies globally for the specific weaknesses attackers now exploit: identity compromise in SaaS, and privilege escalation in infrastructure. Two technologies stand out because they solve different halves of the modern failure pattern . Keepit - True Independence From SaaS & Identity Keepit protects SaaS workloads by storing backup data completely outside  the platform it is protecting. That includes: outside the customer tenant outside Microsoft/Entra ID outside Okta outside Salesforce, BambooHR, and Atlassian stored in sovereign Australian data centres enforced through immutable retention with no reliance on OAuth or production identity no trust in the SaaS provider’s control plane Because Keepit operates in a separate identity domain, identity compromise cannot reach it . UNC3944-style intrusions, OAuth manipulation, administrator impersonation, and token theft - none of these can alter or delete Keepit backups. Retention is fixed. Data is immutable. Recovery is guaranteed even when the SaaS tenant or identity layer is fully compromised. This is what it means to be outside the blast radius . Identity compromise doesn’t stop at production. In-platform backups fall with the tenant. Only an independent, immutable vault like Keepit stays outside the blast radius. ExaGrid - Isolation From Privilege-Based Tampering In infrastructure environments, the failure point isn’t usually encryption anymore - it’s privilege. Once an attacker gets domain admin, root, or hypervisor control, most backup platforms collapse with the rest of the estate. ExaGrid breaks that pattern. Its architecture puts the protected data on a non-network-facing Tier-2 repository , a tier you cannot address , scan , or delete from  over the network. On top of that, ExaGrid layers: Immutable objects Time-Lock retention Delayed deletes A design where even ExaGrid admin credentials cannot purge data ExaGrid’s tiered architecture keeps backups outside the blast radius - fast Landing Zone performance up front, and a locked-down, non-network-facing Repository Tier with Time-Lock protection behind it. This flips the usual attack flow on its head. Attackers can move through the network. They can escalate. They can take domain admin. They can compromise vCenter or the hypervisor itself. But they still cannot touch the data sitting inside ExaGrid’s isolated repository tier. That’s the entire point: privilege escalation no longer equals backup deletion. Even a full Active Directory breach - the nightmare scenario - cannot reach the copies held in that tier. This is what true ransomware-resilient infrastructure backup looks like. The Bottom Line Multiple threat actors operate at the same time - and almost all of them break in through identity.If your backup depends on the same identity plane attackers are already exploiting, your recovery plan is compromised before the incident even begins. The path to resilience is simple, but it’s architectural, not operational: FullBackup delivers this model across Australia using independent recovery platforms for M365, Entra ID, Okta, Salesforce, BambooHR, Confluence, and hybrid infrastructure workloads. If you want a recovery layer that sits outside the blast radius, aligns to real-world threat behaviour, and meets CPS 230, Essential Eight, SOCI and ISO 27001 expectations, talk to us. We’ll map it clearly and show you what resilience actually looks like in 2025 and beyond.

Identity is the lifeblood of your business . It flows quietly in the background, powering every login, every SaaS connection, every workflow. But the moment it’s compromised, the whole organization flatlines. Employees are locked out. Customers can’t reach portals. SaaS integrations collapse. Overnight, what once seemed invisible becomes a board-level emergency. At the center of it all are two platforms: Microsoft Entra ID  and Okta . Together, they process billions of authentications every day. They are the beating heart of digital operations, and yet most organizations don’t realize this heart has no backup! Across every incident we review, the missing layer is simple: organisations have no identity backup for Entra ID , which means misconfigurations and deletions hit the entire stack with no rollback path. IAM is the lifeblood of business. If Entra ID or Okta go down, everything stops. Without immutable backup, recovery isn’t possible and resilience flatlines. The lifeblood of digital trust Entra ID and Okta are more than login portals. They are the circulatory system of modern business  - pumping identity through every app, workflow, and transaction. They determine: Who can access which apps, systems, and data How employees authenticate across environments (on-premises, cloud, SaaS) The policies that enforce governance, compliance, and security Cut off the flow, and the body of the business shuts down. Productivity stalls. Compliance crumbles. Customers are left waiting. The chain reaction nobody wants to face Microsoft and Okta both operate under the shared responsibility model . They keep their platforms running but your tenant data, policies, and configurations are on you . And here’s the reality most organizations ignore: There are no native backups  for IAM policies, groups, or configurations A single admin misconfiguration can trigger mass lockouts  in minutes A malicious insider or ransomware attack can knock over everything at once Identity is the first domino. Once it falls, access to email, Teams, Salesforce, Google Workspace, even customer-facing apps, comes crashing down. In one real-world case, a former consultant sabotaged a company’s identity systems and deleted accounts en-masse. The business was offline for two full days . But the aftershocks lasted for three months , with broken calendars, incomplete contact lists, and folder access issues. Customers and suppliers were left stranded in the dark. ( https://cybersecuritynews.com/it-contractor-sentenced/ ) When identity falls, everything falls. Without backup for IAM platforms like Entra ID and Okta, one breach or misconfiguration can trigger a domino effect across apps, access, and business operations. Isn’t Okta Already Backed Up? It’s a dangerous misconception. Okta is highly resilient as a service, with redundant infrastructure and failover built to keep their  platform online. If a data center goes dark, Okta stays standing. But here’s the catch: their resilience is not your resilience. Those protections don’t cover your tenant configuration If an admin deletes a group, corrupts a policy, or breaks an integration, Okta won’t roll it back for you There’s no native way to restore users, roles, or app assignments to a safe state And the Okta Access Gateway?  It’s often mistaken for a safeguard, but it’s really just a reverse proxy for connecting on-prem apps. It offers zero protection for your tenant data. That gap is why independent backup matters. Without it, you’re assuming nothing will ever go wrong in your tenant, a reckless bet in a world of ransomware, insider threats, and inevitable human error. Isn’t Entra ID Already Backed Up? Another common misconception. Microsoft runs one of the most reliable global cloud infrastructures on the planet. They keep their service  available with replication, redundancy, and failover. But again: their resilience is not your resilience. Microsoft’s protections don’t back up your Entra ID tenant The recycle bin in Microsoft 365 is not an enterprise recovery tool - deleted users, groups, or role assignments are often gone for good Conditional access policies, device information, or audit logs can’t simply be “rolled back” if they’re compromised Microsoft’s shared responsibility model makes it clear: the security and recoverability of your tenant data is your job. Without independent backup, you’re trusting that no misconfiguration, insider threat, or ransomware attack will ever target your Entra ID - a gamble no business should take. When the Worst Actually Happens: IAM Horror Stories Okta Access Breach, 2023 Attackers infiltrated Okta’s support system and stole session tokens, allowing them to hijack customer sessions. What started as “just 1% of customers impacted” later ballooned into nearly all Okta support-user records exposed  - a reminder that Okta’s resilience isn’t the same as your  resilience.( Wired ) Entra ID Hijack Scenario In hybrid Entra ID environments, a compromised Global Admin can delete all other admins and wipe policies, effectively locking everyone out. Even routine sync issues can create new IDs, breaking access across SharePoint, SaaS apps, and licenses. Recovery is slow, messy, and often incomplete.( Bleeping Computer Coverage ) The lesson?   Neither Okta nor Microsoft will rewind the clock for you. Without independent backup, a single misstep, insider, or attacker can leave your business stranded. Why Entra ID and Okta Are Both Critical Entra ID:  Microsoft’s identity platform processes more than 8 billion authentications every day . It’s the circulation system for Microsoft 365 and countless enterprise apps - the pulse that keeps hybrid and cloud-first businesses alive. Okta:  The go-to choice for multi-cloud and SaaS-heavy environments. A single broken policy or deleted integration can lock thousands of users  out in an instant. Both are indispensable - but both share the same critical weakness: without independent backup, there’s no way to restore what’s lost. One failure, one misstep, and the heart of the business flatlines. The Regulatory Squeeze It’s not just outages and lockouts you need to worry about - regulators are watching too . Frameworks like NIST CSF  and ISO 27001  demand proof of resilience. Regulations such as GDPR  and HIPAA  require governance over identity and access. In Australia, CPS 230  now puts operational resilience front and center for financial services. Without the ability to show who had access, what changed, and how quickly you recovered , you’re not just exposed - you’re out of compliance . And in today’s regulatory climate, that can be as damaging as the outage itself. How Keepit fixes the gap Keepit Backup and Recovery for IAM  closes the hole that Microsoft and Okta leave open. Immutable backups : Blockchain technology for Entra ID; independent cloud architecture for Okta Fast restoration : Users, groups, roles, policies, and logs can be rolled back quickly -without triggering mass lockout emails Compliance built-in : Detailed restore logs, audit trails, and reporting simplify regulatory audits Centralized control : Manage Entra ID, Okta, Microsoft 365, and Google Workspace backups from a single, easy-to-use platform Data sovereignty : Choose your region - Sydney, Frankfurt, London, Toronto, and more - and your data never leaves it! Why Identity Backup for Entra ID Matters More Than Ever Identity outages aren’t rare - they’re routine. A mistyped policy, a malicious insider, or a provider outage can all stop the heart of your business in an instant . Without an independent backup, you’re betting everything on systems that were never designed to recover themselves. And when identity flatlines, everything else falls with it . With Keepit, you take back control. Immutable, independent backups for Entra ID and Okta  ensure you can recover your most critical digital asset: trust in identity . Don’t wait for a crisis to prove the point. Protect IAM now - because identity is everything. About FullBackup We help Australian businesses protect the systems they rely on most, from Microsoft 365 and Google Workspace to identity providers like Entra ID and Okta. 👉 Want a quick snapshot? Try our Light IAM & SaaS Backup Assessment  (self-service, no signup). Its in the menu 👉 Need more? Ask us about our Deep Dive Resilience Assessment  - tailored, detailed, and available by request. Either way, there’s no hard sell. Just clarity on where you stand and how to keep identity from becoming your next crisis.

What HR data loss really looks like when BambooHR records vanish without warning. Imagine a scenario where crucial employee records or compliance documents stored in BambooHR suddenly become inaccessible - perhaps due to a mistaken deletion, a buggy integration, or even a malicious attack. It’s a CIO’s nightmare and a very real risk. Modern HR platforms like BambooHR guarantee uptime, but not full recoverability of your data. In other words, your BambooHR data may be available day-to-day, yet if something goes wrong, you have no quick way to get lost information back. For lean IT teams without dedicated data protection staff, this gap can instantly turn a routine HR task into an operational crisis. HR data is highly vulnerable without backup: data loss isn’t a hypothetical threat – it happens every day. Studies show over 70% of data loss incidents stem from human error. An HR administrator might accidentally delete an employee file or overwrite a salary record, and without an independent backup, that information is gone for good. Similarly, BambooHR is often integrated with payroll systems, identity management, and other apps; a glitch or bad sync in one of these integrations can wipe out or corrupt data at scale. Cases have hit the public domain, where a script error or misconfigured API integration propagated mistakes across multiple systems, erasing or scrambling critical HR data in minutes. The result? Employee profiles, time-off balances, or attachments could vanish before anyone notices. Malicious and external threats are growing. Cyberattacks on cloud data are increasingly common and HR data is a ripe target. In one well-known case, an IT contractor retained access to a company’s cloud storage after their term and accidentally deleted critical files at their next job. Even more alarming are deliberate attacks: for example, a breach in 2019 saw unauthorized access to BambooHR’s payroll module, potentially exposing personal and financial data. If attackers can steal data, they can just as easily delete or ransom it. The Australian Cyber Security Centre warns that determined adversaries may “destroy all data (including backups) accessible to a compromised account". Without an independent, immutable backup that attackers cannot alter or reach, organizations have no safety net. Compliance and continuity risks compound the problem. HR systems contain sensitive employee records, contracts, tax files, and regulatory documents that companies are legally obliged to retain and protect. If a mishap means you can’t produce an employee’s record during an audit or litigation hold, your organization could face fines or legal penalties. BambooHR itself advises maintaining a backup and recovery plan for emergency data-loss situations. Without an independent backup, you lose your system of record instantly when things go wrong. The Hidden Gaps That Make BambooHR Backup Essential Why BambooHR alone cannot restore deleted or corrupted data. BambooHR is a powerful HR system, but when it comes to data recovery, it has significant architectural gaps. BambooHR does not support point-in-time restoration or rollback of your data. If an employee record was altered or deleted last week, there is no “undo” button . Even file attachments cannot be restored from within BambooHR. BambooHR provides limited options for backup or recovery. It has basic logs and APIs for manual exports, but no automatic backups, no version history, and no built-in archive of historical changes. Its own documentation emphasises the need for organisations to back up employee data themselves. If an admin deletes something (maliciously or by accident) or a sync cleans a field, BambooHR will faithfully replicate that deletion everywhere - and the data may be permanently gone. Multiple industry sources summarise this clearly: “BambooHR doesn’t offer backups or comprehensive recovery options". How Keepit Safeguards BambooHR Data - Independent & Immutable Keepit provides an independent, immutable vault for BambooHR data - completely isolated from BambooHR itself. Keepit’s BambooHR backup fills these critical gaps by providing an independent, immutable backup stored in Keepit’s own private cloud infrastructure . This keeps your HR data protected from accidental deletions, sync disasters, and even compromised BambooHR accounts. Together, these capabilities transform BambooHR from a single point of failure into a resilient, recoverable HR system. Keepit also protects Microsoft 365 , Google Workspace , Salesforce , Dynamics , Zendesk , DocuSign , and more - giving organisations a unified SaaS resilience layer. Alignment with CPS 230, Essential Eight, SOCI, ISO 27001, and SaaS Obligations Backup is no longer optional - it is now a compliance obligation under CPS 230, SOCI, E8, and ISO 27001. A proper BambooHR backup strategy aligns directly with major regulatory and security frameworks: Independent backup satisfies all of these requirements. From Vulnerable to Resilient - A Call to Action Your employees are the lifeblood of your organisation - and their data is irreplaceable. By implementing an independent, immutable backup for BambooHR, you protect the integrity of your HR function, maintain compliance, and avoid catastrophic data-loss scenarios. This is your opportunity to eliminate the single biggest blind spot in BambooHR. Move to resilience today. Protect BambooHR with independent backup.