Search Results

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.

Interpreting the ACSC’s 2025–26 Cyber Security Priorities for Directors through the lens of operational resilience and recoverability. ( Cyber security priorities for boards of directors 2025-26 ) Australia’s boardrooms now sit on the front line of cyber resilience. The question is no longer “Are we protected?”  but “Can we recover - and prove it?” There was a time when cybersecurity lived deep in the IT basement, buried in patch reports, firewall logs, and budget line items that rarely reached the boardroom. That era is over! In a year defined by ransomware hearings, regulatory reforms, and insurer mandates, boards can no longer treat cyber resilience as a technical line item. The Australian Cyber Security Centre (ACSC)  and Australian Institute of Company Directors (AICD)  have made the shift explicit in their Cyber Security Priorities for Boards of Directors 2025-26. Directors are now expected to own  cyber resilience, not simply endorse it. This isn’t about approving bigger budgets. It’s about asking sharper questions: Can we recover from a breach? Are our backups immutable? Is our data sovereign? And when - not if - an incident occurs, can we prove resilience instead of just claiming it? These aren’t technical questions anymore. They’re governance questions. They go to the heart of fiduciary duty. The Board’s New Reality - Accountability Without Excuses The ACSC guidance makes it clear: cyber accountability sits squarely with the board, not just IT. Boards can no longer delegate cyber resilience to “the tech team.” Every director now shares legal and reputational exposure if the organisation can’t recover. The ACSC guidance urges boards to verify that technology used is secure by design  and secure by default. That means understanding critical assets , supply-chain risk , and recovery capability . Each director must now answer a single, deceptively simple question: “If our systems failed tomorrow, could we get back up - and prove it?” For many, that answer starts (and ends) with backup. But not all backups are equal. Why Backup Has Become a Governance Control This is where FullBackup focuses - helping Australian organisations verify their SaaS recoverability with independent, sovereign backup through Keepit . True resilience means protection outside  the production platform - not within it. In the cloud era, critical data has drifted beyond the data centre. Email, identity, collaboration, CRM, contracts, most of it now lives in SaaS platforms like Microsoft 365, Salesforce, Google Workspace, Atlassian, DocuSign, and Zendesk. These platforms guarantee uptime, not recoverability. If data is deleted, corrupted, or encrypted, the vendor’s duty is to keep the service running, not restore your records. That gap is where governance now lives. Under APRA CPS 230 , regulated entities must provide evidence of operational resilience and data recoverability. The Essential Eight  makes the same demand: at maturity levels 2 and 3, data recovery and system availability  are measurable controls. Resilience isn’t a checkbox; it’s a verifiable, auditable, sovereign control. From IT Control to Board Assurance Backup used to be an IT checkbox: jobs ran, reports ticked green. Now it’s a board-level proof point. Directors should be able to demonstrate that:: Data is stored independently of production systems. Storage is immutable  - no deletions, no edits. Residency aligns with APP 11 , SOCI Act , and CPS 230 . Restoration testing is regular and auditable. Keepit provides that assurance. It delivers a sovereign, immutable, audit-ready backup cloud, independent from production, protected against deletion, and verifiable across compliance frameworks. That independence is what regulators mean by control effectiveness. Boards must now demonstrate it - not assume it. Australia’s cyber priorities for boards are clear - resilience must be proven, not presumed. FullBackup resells Keepit to give organisations the sovereign, immutable, audit-ready assurance regulators now call control effectiveness. The Four Board Priorities for 2025–26 - and What They Mean for Data Resilience 1. Secure-by-Design, Secure-by-Default Built-in resilience is board-designed resilience. Boards must insist that resilience is built in, not bolted on. In SaaS ecosystems, recovery cannot rely on the same cloud that failed. It must live independently - immutable by default, sovereign by design. Think of it as the spare engine of the ship , not the life raft under the bed. When power fails, that’s what gets you home. 2. Defend Critical Assets - Assume Compromise Knowing your crown jewels isn’t enough - plan for when they’re stolen. Boards are told to identify their “crown jewels” and plan as though they’ve already been breached. Today those jewels are identities, records, contracts, and SaaS data. Assume compromise Then ask: If our tenant was encrypted or deleted, how fast could we restore - and who verifies that? 3. Detect, Respond, Recover - Logging and Proof of Control Recovery evidence is the new incident report. Logging matters. But logs without recovery are autopsies, not resilience. Boards should demand: Restore testing evidence Immutability verification Data-integrity checks FullBackup selected and resells Keepit , the leading independent SaaS backup platform, to deliver those controls - immutable versioning, retention time-lock, and cryptographic verification - giving boards CPS 230-aligned, Essential Eight and SOCI-ready assurance of recoverability. 4. Supply-Chain and Sovereignty Risk Visibility defines accountability. The ACSC urges boards to map data dependencies and third-party exposures - the invisible web beneath every cloud service. For Australian directors, sovereignty is the linchpin . Backups hosted in sovereign Australian data centres  (e.g., Sydney/Melbourne) with local legal control and customer-held keys  reduce exposure to extra-territorial laws (such as the U.S. CLOUD Act) and align with SOCI  oversight expectations and the Essential Eight  objective of assured recoverability. Boards cannot mitigate what they cannot see, nor control what sits outside jurisdiction. Sovereign architecture brings data and accountability home. SOCI link-up:  For critical-infrastructure entities, board oversight of supplier obligations should include recoverability evidence from third parties  (documented restore tests, log retention, and exit/portability plans) - not just security claims. Translating the ACSC’s board priorities into measurable backup governance and recovery assurance. Translating Policy into Board Questions Board Question Keepit Response How do we ensure recoverability if our SaaS provider suffers a breach or misconfiguration? Keepit maintains an independent backup cloud , separate from the SaaS vendor’s infrastructure. Even if Microsoft 365, Google Workspace, or Entra ID are compromised, backup data remains untouched and recoverable. Can backup data be altered or deleted by administrators, attackers, or the vendor? Immutable, append-only architecture  means data can’t be changed or removed once written. Every version is cryptographically verified  to ensure integrity. Is our backup data stored in Australia under Australian law? Yes - Keepit uses sovereign Equinix Australian data centres , operated independently of hyperscalers and fully compliant with Australian privacy and security frameworks. Have we tested our ability to restore within regulatory timeframes? On-demand and scheduled restore tests  generate audit-ready reports , providing evidence of recoverability for CPS 230, Essential Eight, and ISO 27001 . These are not technical diagnostics; they are board-level audit questions and the answers define whether an organisation can demonstrate control effectiveness. This is how the ACSC’s priorities become measurable outcomes, recoverability, accountability, and sovereignty expressed in evidence. From Risk Awareness to Cyber Resilience for Boards Resilience is measurable. Directors don’t need to understand encryption algorithms, but they must insist on evidence that someone does. The ACSC and AICD guidance marks a cultural shift: cyber resilience is no longer the CISO’s lonely battle; it’s the board’s collective obligation. To meet it, directors should: Treat recoverability as a standing agenda item. Demand proof of immutable, sovereign backup. Tie backup testing to CPS 230 operational resilience  frameworks for financial entities. Align recovery controls with SOCI Act  requirements for critical infrastructure and Essential Eight  maturity levels for government and enterprise. Include resilience metrics in quarterly governance and risk reports. Confirm ASD-aligned logging : centralised, time-synced, alerting wired to incident playbooks, documented retention, regular review. Own legacy IT risk : name risk owners, define compensating controls, maintain a decommission roadmap. Start a post-quantum transition plan : crypto-agile backups, vendor timelines, test in non-prod first. Keep the basics  tight: patching cadence and MFA on all public-facing services. This approach doesn’t just satisfy regulators, it builds trust. Boards that can demonstrate control over their digital assets earn confidence from investors, insurers, and customers alike. Every storm ends in light. Keepit’s dual independent clouds deliver verified, sovereign recovery - proving resilience beyond the production platform. Every Story Has Its Turning Point In every cyber incident, there’s a quiet second after the screens go dark when someone asks, “Can we get it back?” That moment defines reputation, resilience, and responsibility. With FullBackup and Keepit , the answer is provable: Independent. Immutable. Sovereign. Resilience isn’t something you buy - it’s something you demonstrate when everything else stops working. Because in that moment, proof is everything. Run a SaaS Resilience Pilot → fullbackup.com.au/demo-and-pilot Show your board what verifiable recovery looks like. Immutability. Sovereignty. Audit-ready proof. FullBackup × Keepit - Where Australian resilience becomes verifiable. Further reading • ASD: Cyber Security Priorities for Boards of Directors (2025–26) • AICD/CSCRC: Cyber Security Governance Principles v2 • ACSC: Essential Eight Maturity Model

Without backup, Salesforce data loss can be permanent. Independent recovery is the only way back. Introduction: Salesforce Doesn’t Guarantee Recovery Salesforce is the backbone of customer operations for thousands of Australian enterprises, powering sales, service, and mission-critical processes. But here’s the gap most overlook: Salesforce does not guarantee data recovery. Uptime is not resilience. Deleted, corrupted, or compromised data quickly outlives the recycle bin. Once that window closes, it’s gone. For Australian enterprises, under CPS 230, the Essential Eight, and sovereignty rules, the answer is clear: independent Salesforce backup and recovery is essential. Why Salesforce Data Is at Risk Even Salesforce data is at risk - from accidental deletion to misconfigurations, insider threats, and supply chain breaches. Accidental Deletion Bulk updates, admin errors, or user mistakes can erase thousands of records instantly. Salesforce’s recycle bin is temporary and insufficient for long-term protection. Misconfigurations and Integrations Modern Salesforce environments are highly connected. Misconfigured permissions, over-permissive OAuth tokens, or faulty third-party integrations can cause widespread corruption or data loss. Insider and Malicious Activity When an insider deletes or alters records deliberately, Salesforce provides no independent safeguard. Without a secure backup, recovery is impossible. SaaS Supply Chain Failures Even if Salesforce itself remains secure, vendor dependencies or connected applications can introduce risk. A breach in one integration can cascade into your CRM. These risks don’t just threaten Salesforce data - they threaten compliance, resilience, and customer trust. That’s why independent Salesforce backup and recovery is essential for Australian enterprises. The Australian Compliance Lens Independent Salesforce backup isn’t just smart - it’s required. CPS 230, Essential Eight, and data sovereignty demand independent recovery you can prove. The Compliance Mandate for Australian Enterprises For Australian organisations, Salesforce backup and recovery is no longer just best practice - it’s a compliance requirement. CPS 230 (APRA):  Financial institutions must prove operational resilience , including evidence of independent recovery for critical SaaS platforms like Salesforce. Essential Eight (ASD):  Demands tamper-proof data recovery  strategies attackers cannot alter or delete. Data Sovereignty:  Backup data must be stored within Australian jurisdiction , outside U.S. Cloud Act exposure. Without independent Salesforce backup and recovery, meeting these standards is not only difficult - it’s impossible. How Keepit Protects Salesforce - Brought to You by FullBackup As an Elite Keepit Reseller in Australia , FullBackup enables organisations to deploy enterprise-grade Salesforce backup and recovery built for resilience, compliance, and sovereignty . Keepit delivers: ✅ Immutable Recovery Points  - Snapshots attackers cannot alter or delete. ✅ Independent Storage  - Data sits outside Salesforce, safe from outages and compromise. ✅ Granular Restore Options  - Recover single records, objects, or full environments in minutes. ✅ Always Accessible  - Even if production or identity systems are down. ✅ Compliance-Ready  - Meets CPS 230, Essential Eight, ISO 27001 , and Australian sovereignty standards. Keepit makes recovery independent, compliant, and unstoppable - with FullBackup reselling it locally. Immutable Recovery Points  - Snapshots that cannot be altered, deleted, or encrypted. Independent Storage  - Data stored outside Salesforce’s infrastructure, safe from vendor outages. Granular Restore Options  - Recover single records, objects, or entire environments quickly. Always Accessible  - Recovery points remain available even if identity or production systems are down. Audit-Ready  - Built for CPS 230, Essential Eight, ISO 27001, and Australian sovereignty requirements. Conclusion: Resilience Requires Independent Recovery Salesforce is critical to business operations, but its native tools are not enough to guarantee recoverability . For Australian enterprises, the combination of regulatory pressure, compliance obligations, and operational risk  makes independent backup and recovery essential. As an Elite Resell Partner of Keepit , FullBackup enables organisations to deploy immutable, independent, and compliant Salesforce recovery  - protection that can always be relied on, even when production systems fail. 👉 Book a Free Pilot  to see how quickly your Salesforce data can be recovered with Keepit. 👉 Explore the full Salesforce Backup & Recovery page to see what’s protected, how restores work, and how it aligns with CPS 230 and the Essential Eight: https://www.fullbackup.com.au/salesforce-backup-recovery

Every contract is a heartbeat of the business , the deal closed, the supplier secured, the compliance box ticked. And in 2025, most of those heartbeats run through DocuSign. A signed contract isn’t just a file, it’s a legal instrument. Sales agreements, supplier terms, employment letters, compliance attestations: for many organisations, DocuSign has become the default contract vault. But it isn’t a vault. It’s a highway. DocuSign guarantees traffic keeps moving but not that the cargo arrives intact. If an envelope is deleted, a template corrupted, or a signing group misconfigured, the contract falls off the road. And when a contract disappears, so does enforceability, revenue, and trust. Contracts aren’t just documents - they’re business lifebloo d Every contract. Every signature. Guarded like a national treasure with Keepit A contract isn’t a PDF to file away. It’s a living commitment, to pay, to deliver, to comply. When contracts go missing, the impact hits every artery of the business. That’s why we say every contract, every signature must be guarded like a national treasure. Revenue:  A lost sales agreement doesn’t just delay cashflow - it erases recognised revenue. Continuity:  When supplier terms vanish, supply chains grind to a halt. Compliance:  Deleted HR or regulatory records trigger fines, audits, and legal exposure. Without recovery, you don’t just lose data. You lose enforceability, the ability to prove what was agreed, when, and by whom. The SaaS Gap: Uptime ≠ Protection DocuSign excels at keeping its platform available. But availability isn’t the same as resilience. Uptime won’t save you when: Envelopes and templates are deleted  - whether by accident or intent. Retention rules quietly expire agreements  you thought were permanent. API misfires or integrations  overwrite critical settings in bulk. Insider threats or admin errors  alter signing groups and permissions. These aren’t “IT glitches.” They’re business risks, legal, financial, and reputational, hiding behind the veneer of SaaS convenience. For the CFO, it looks like a missed quarter. For the COO, a stalled supply chain. For the CISO, a board-level incident. Independent, Immutable Protection Keepit has extended its independent SaaS backup platform to DocuSign and through FullBackup , that protection is now available in Australia. What this delivers is more than backup - it’s a safeguard for your agreements: Immutable copies  - backups that cannot be altered or erased, not by ransomware, insiders, or even admins. Independent storage  - no shared failure domain with DocuSign, ensuring recovery even if the platform itself is compromised. Granular recovery  - restore a single envelope, template, or signing group without rolling back your entire environment. This isn’t backup as usual. It’s contract certainty, guaranteed recovery when every signature matters. Compliance Pressure Is Rising Contracts aren’t just business documents, they’re regulated records. Auditors no longer stop at financial ledgers; they now expect evidence that all critical records  can be recovered, intact and on demand. CPS 230:  Boards must prove operational resilience. Contracts that govern core services fall squarely in scope. Essential Eight:  Immutable, tamper-proof backups and separation of duties are non-negotiable controls. Cloud Act risk:  With Keepit , DocuSign data is stored in sovereign environments - beyond the reach of extraterritorial access. In this environment, a missing contract isn’t just an IT failure. It’s a compliance failure, and one regulators won’t excuse. When Every Signature Counts, the Cost of Downtime Escalates A single missing contract sets off a chain reaction. One lost contract sets off a chain reaction - but independent, immutable backup prevents the fall. Deals stall.  A lost sales agreement doesn’t just delay cashflow - it pushes revenue into the next quarter and shakes investor confidence. Operations seize.  When supplier contracts vanish, supply chains falter and production lines stand idle. Reputation collapses. Lost contracts don’t just stall deals - they undermine trust with partners and regulators. Regulators close in.  Deleted compliance agreements aren’t a technicality - they’re a trigger for fines, investigations, and reputational damage. Recovery isn’t only about speed. It’s about certainty , knowing that the exact agreement you need will be there, unaltered and enforceable, the moment you need it. FullBackup × Keepit: DocuSign Resilience, Delivered Keepit now protects DocuSign agreements with independent, immutable backup. As Keepit’s Elite Resell Partner in ANZ , FullBackup delivers that protection with the local expertise to align with CPS 230, the Essential Eight, and sovereign data requirements. This isn’t just about having another copy. It’s about independence: data outside the vendor cloud, immutable by design, and ready when auditors, regulators, or executives demand proof. When agreements define your business, resilience isn’t optional - it’s strategy. 👉 Book a demo or start your free pilot 👉 Explore DocuSign Backup & Recovery The protection doesn’t stop with DocuSign. From Microsoft 365 and Google Workspace to Salesforce and Dynamics 365, Keepit delivers independent, immutable, and compliance-ready backup for every SaaS platform you rely on.. https://www.fullbackup.com.au/services The same cloud risk applies everywhere. Keepit protects them all

In September 2025, Jaguar Land Rover faced one of the most severe operational crises in its history. Production lines halted. Sales systems froze. Sensitive data was confirmed stolen. This was not a run-of-the-mill ransomware outbreak. The breadth of the collapse points to something deeper: an identity-centric compromise  that struck at tier-zero, the substrate on which every system, every control, and every piece of resilience depends. Identity is not just another IT service. It is the fabric of trust across the enterprise. Compromise AD or Entra ID, and attackers don’t just enter the environment - they inherit authority. While Jaguar has not disclosed the technical root cause, the public reporting and failure patterns align with what we’ve seen in similar large-scale compromises. The following analysis explores those scenarios and the systemic lessons they carry. When identity breaks, every system downstream obeys the intruder. What We Know Jaguar has not disclosed the technical details of the breach. What follows are plausible scenarios , drawn from public reporting and the failure patterns seen in similar large-scale compromises. What is clear is this: Jaguar confirmed that attackers exfiltrated data , not just encrypted it. This suggests persistence and control, not smash-and-grab ransomware. The disruption was systemic . Factory systems, sales platforms, and customer-facing processes all failed. Such breadth is only explained by compromise of the identity/control plane. Analysts quickly converged on identity as the likely vector . The scale and cross-domain nature of the collapse fits the profile of Active Directory or Entra ID compromise. This was not a surface-level breach. It reached into the root of trust. Why Identity Is the Crown Jewel Every system in an enterprise ultimately depends on identity. Active Directory (AD) : decades-old, sprawling, still critical for on-prem. Often messy, full of ghost accounts and legacy trusts. Entra ID (Azure AD) : the cloud control plane, governing Microsoft 365, SaaS platforms, and conditional access. Together they form the substrate of trust . When attackers seize them, they inherit control. They can create new admins, mint tokens, disable MFA, and sabotage recovery. That is why identity is the crown jewel, far more valuable than any database or application. When identity systems are compromised, the disruption spreads everywhere - factories, sales, cloud, and data alike. How Jaguar Could Have Been Compromised (The Attack Chain) Step 1: Social Engineering Attackers target people first. A phishing email, an MFA fatigue campaign, or a fake IT helpdesk call could have yielded the first login. Step 2: Credential Abuse With a foothold, attackers escalate. Ghost accounts, reused logins, or weak service accounts open the path to domain-level rights. Step 3: Substrate Exploitation With privileges in hand, the attackers move into the identity layer: Exploiting federation or SSO misconfigurations. Leveraging vendor trust as a pivot. Using AD ↔ Entra ID sync to replicate compromise across environments. Step 4: Tier-Zero Corruption Now they own trust itself. They can disable MFA, create shadow admins, alter policies, and exfiltrate at will. At this stage, every dependent system collapses. The modern attack chain doesn’t begin with firewalls. It begins with people tricked, credentials abused, and identity poisoned - leading to systemic collapse. The AD ↔ Entra ID Loop Most large enterprises operate in hybrid identity . On-premises AD is synced into Entra ID using Azure AD Connect or Cloud Sync. To the user, this looks seamless. To attackers, it creates recursion. It’s important to be precise: AD → Entra ID  is the normal direction. Users, groups, and attributes are pushed up into the cloud. Entra ID → AD  doesn’t replicate wholesale - but it can  flow back if certain features are enabled. For example: Password writeback : self-service resets in Entra are written back into AD. Device and group writeback : often enabled to support hybrid Exchange, Teams, or device join. Even without writeback, federation and trust links  mean a poisoned Entra tenant can still assert authority on-premises. Attackers can mint tokens or abuse connectors (like PTA or ADFS) to gain access back into AD. The result: whether by writeback or trust abuse, compromise can flow both ways. Poison AD, and the cloud is infected. Poison Entra, and the risk propagates back on-prem. Unless both AD and Entra ID are independently rolled back to a clean state , reinfection is inevitable. AD and Entra ID look seamless to users, but the overlap creates recursion - compromise can propagate in either direction. Recovery Must Begin With Identity A common misconception in cyber resilience is that backups = recovery . But that assumption collapses once identity is compromised. You can restore servers, apps, or databases, but if your identity substrate (AD/Entra ID) is still poisoned, those restored systems will immediately obey the attacker. Think of identity as the root certificate of trust . If it is corrupted, everything signed by it, logins, policies, authorisations, is tainted. No amount of clean application data matters if the keys to access it are still in hostile hands. The scientific recovery sequence is not optional; it’s dictated by system dependency: Rebuild Trust First Restore AD and Entra ID from immutable, sovereign backups  outside the attacker’s reach. This rollback evicts persistence (hidden admins, poisoned tokens, corrupted policies) and resets tier-zero. Re-establish Controls Reinforce the clean identity with phishing-resistant MFA  (FIDO2, not just push prompts). Rotate privileged keys and certificates. Validate federation and vendor access - attackers often lurk in trust links. Then Restore Workloads Only when identity is clean should applications, VMs, SaaS data, and production workloads be restored. Otherwise, recovery risks being a looped reinfection  - attackers slipping straight back in. Anything else is wasted effort. Recovery that skips identity is not resilience; it’s re-exposure. Recovery must begin at tier-zero: restore clean identity, re-establish security controls, then bring back applications and operations. Where ExaGrid and Keepit Fit Modern resilience demands different tools for different substrates . ExaGrid: Resilient On-Prem Recovery ExaGrid integrates with enterprise backup platforms like Veeam, Commvault, and NetBackup to deliver resilient on-prem recovery . Its tiered architecture provides immutable retention in the repository tier, while the Landing Zone enables instant VM recovery . That means you can boot a clean AD controller in a sandboxed clean room and begin re-establishing trust within minutes. Keepit: Identity & SaaS Recovery Keepit provides independent, sovereign backup and recovery for SaaS applications and identity platforms  - Entra ID, Okta, Microsoft 365, Salesforce, Google Workspace, and more. Its strength lies in restoring the roles, groups, MFA policies, and data  that attackers corrupt and cloud vendors cannot roll back. ExaGrid and Keepit don’t “plug into” one another, because they address different resilience gaps : ExaGrid ensures on-prem infrastructure and workloads can be recovered quickly and cleanly. Keepit ensures SaaS platforms and identity systems can be rolled back to a trusted state. 👉 One protects where you run . The other protects who you are . Without both, resilience is incomplete. As a FullBackup partner , we align with both ExaGrid  and Keepit  to deliver full-spectrum resilience  for enterprises. Compliance Demands Proof Regulation is no longer about having backups on paper; it is about being able to demonstrate operational resilience in practice . That proof is impossible if identity itself cannot be recovered. CPS 230  requires boards to show that critical systems can withstand and recover from disruption. AD and Entra ID are not just “systems” — they are the  critical system, because without them nothing else can be restored. If identity cannot be rolled back, compliance fails by definition. The Essential Eight  strengthens identity with MFA, privileged access separation, and application control. But these controls assume the underlying identity substrate is intact. Once Entra ID or AD is poisoned, hardened policies crumble. Without immutable rollback, Essential Eight maturity levels collapse under real-world attack conditions. Regulators don’t accept “plans” or “intent.” They expect evidence  that recovery works across both data and identity. Immutable, air-gapped recovery of workloads (ExaGrid) shows data resilience. Immutable, sovereign rollback of identity state (Keepit) shows trust resilience. Together, they provide the proof regulators demand : not just backups, but verifiable recovery of the systems that matter most. Lessons From Jaguar Jaguar’s breach is more than an isolated incident. It is a case study in how modern enterprises unravel when identity is lost: Humans are the doorway.  Phishing, fake IT calls, and MFA fatigue tricks open the first crack in the wall. Credentials are the ladder.  Stolen logins and ghost accounts give attackers the climb to privileged access. Identity is the substrate.  Once AD or Entra ID is corrupted, every connected system - factories, sales platforms, cloud apps - follows the attacker’s command. Recovery begins with identity.  No amount of clean application data matters if the authority to access it is still hostile. ExaGrid and Keepit address both sides of resilience.  ExaGrid ensures on-prem workloads and AD controllers can be brought back quickly and cleanly. Keepit restores SaaS and identity platforms like Entra ID, M365, and Okta to a trusted state. Jaguar showed the industry that you don’t just lose data in a breach - you lose trust . And without trust, recovery is a mirage. Closing Thought Jaguar’s attackers didn’t just steal data. They stole trust  — the invisible fabric that holds factories, cloud apps, and entire enterprises together. The lesson is clear: resilience isn’t about tape, snapshots, or wishful thinking. It’s about science: Protect tier-zero. Design recovery to start with identity. Build resilience across both planes - ExaGrid for the workloads you run, Keepit for the SaaS and identity platforms that prove who you are. Because resilience doesn’t start with servers or storage. It begins - and ends - with identity. 👉 At FullBackup , we align with ExaGrid  and Keepit  to give enterprises provable, regulator-ready resilience . If Jaguar taught us anything, it’s that trust can’t just be protected - it has to be restorable. That’s why we offer a free demo and pilot  - so you can prove recovery for yourself before you ever need it.