The announcement, published by ConnectWise on August 25 and republished by StorageNewsletter, also includes automated backup-integrity testing, direct-to-cloud and appliance-based protection, centralised management, and integration with ConnectWise SIEM’s Attack-to-Recovery workflow. Much of that is existing x360Recover positioning. The newly available Australian storage location is the operational change that could alter a partner’s service design — but ConnectWise still has not disclosed the facility operator, city, service-level commitments, pricing effect, or the exact migration path for existing APAC backup sets.
An Australian repository is available now, despite earlier September guidance
ConnectWise’s earlier Australian data-centre landing page told prospective partners that x360Recover was expected to go live in September 2026, with in-country x360Cloud availability projected for early October. The August 25 announcement says the x360Recover environment is available now, before that prior estimate.
That is a meaningful shift for partners who delayed deployments while waiting for local storage. It also means ConnectWise’s public material was briefly out of step: the waitlist page still describes the service as forthcoming while the press release says existing x360Recover partners can begin onboarding through account teams and partner resources.
The distinction between the two products matters. x360Recover is the one available in Australia today, according to ConnectWise. It covers server and infrastructure protection through cloud and appliance-based deployment models. x360Cloud, the company’s separate SaaS backup offering for Microsoft 365 and Google Workspace, remains a future regional release scheduled for September in the announcement and early October on the older landing page.
For a Microsoft-focused MSP, that means local x360Recover storage does not automatically solve data-location requirements for Exchange Online, SharePoint Online, OneDrive, Teams, or other Microsoft 365 backup data. Partners should not assume their x360Recover residency selection also applies to x360Cloud when that service arrives.
Data residency is useful, but it is not a compliance certification
ConnectWise is pitching the Australian site around data residency, lower latency, and SOC 2 Type II certification. Those are relevant procurement points, especially for customers with contractual requirements that backups remain in Australia or within a defined APAC jurisdiction.
But the release makes broader compliance implications sound simpler than they are. Australia’s privacy and security obligations do not create one universal rule requiring every organisation’s backup data to remain in-country. Actual location requirements can arise from customer contracts, government procurement terms, sector-specific rules, risk assessments, and an organisation’s own data-handling commitments.
SOC 2 Type II is also not a blanket finding that a deployment complies with Australian privacy law, APRA obligations, customer contracts, or a particular industry’s security standard. It is an assurance report on controls over a specified review period. ConnectWise says the new environment is SOC 2 Type II certified, but it has not publicly identified the report’s scope, the service organisation covered, the audit period, any complementary customer controls, or whether the document can be shared under NDA.
That leaves work for IT buyers before they treat the new location as a compliance answer. A sensible procurement review should ask ConnectWise for the specific data-processing terms, the physical storage jurisdiction, subcontractor and replication details, incident-notification commitments, retention and deletion handling, and the current assurance documentation. It should also establish whether metadata, support telemetry, management-plane records, and recovery operations remain in Australia or may be processed elsewhere.
A local backup target can satisfy an important requirement. It does not, by itself, prove that every part of the service boundary is local.
Recovery testing is more valuable than a completed backup job
ConnectWise’s most practically useful product claim is its emphasis on automated backup-integrity testing. A green backup status commonly proves that data was transmitted and retained; it does not necessarily prove that an application-consistent restore will boot, authenticate, mount volumes, or meet a customer’s recovery-time objective.
That gap becomes particularly painful in Windows environments with Active Directory dependencies, line-of-business databases, virtual machines, application servers, and multi-site networking. A backup can be technically complete while a recovery still fails because of corrupted data, missing dependencies, incompatible drivers, insufficient compute capacity, DNS and identity issues, or a restore sequence that was never rehearsed.
The value of automated testing therefore depends on what ConnectWise actually verifies. The company says the feature helps partners validate that systems and data are recoverable, but the announcement does not specify whether it performs boot testing, screenshot verification, application checks, malware scanning, restore validation, or testing at intervals selected by the partner. Nor does it state which workload types and deployment configurations receive the same level of validation.
MSPs should press for those details rather than treating “integrity testing” as interchangeable with a tested disaster-recovery plan. The useful standard is whether a technician can produce evidence that a protected Windows workload was restored in a realistic recovery scenario — and whether the test measured the time, dependencies, and exception handling needed to meet the customer’s documented targets.
The local site may improve transfer times, but it cannot eliminate recovery bottlenecks
ConnectWise says locating x360Recover infrastructure closer to APAC workloads is designed to reduce latency for backups and recovery. That is plausible for data moving between Australian customer sites and a domestic repository, particularly where the alternative involved trans-Pacific or longer regional paths.
However, recovery speed is not dictated by latency alone. Large bare-metal recoveries and virtual-machine failover exercises are usually constrained by available bandwidth, data volume, deduplication and compression behavior, appliance capacity, source-system performance, and the amount of compute available at the recovery destination. For ransomware recovery, the time spent identifying a clean restore point can matter as much as the time needed to transfer the data.
The Australian data centre may nevertheless make direct-to-cloud protection more viable for regional workloads that were previously protected through an appliance primarily to avoid slow or unpredictable remote transfers. ConnectWise’s hardware-agnostic model lets partners choose between cloud-only and appliance-assisted protection, while also offering turnkey hardware for those who want a predefined deployment.
That flexibility is useful only if partners standardise it. A mixed estate of appliances, direct-to-cloud customers, different retention rules, and varying test schedules can become difficult to operate at scale. Centralised management reduces some console sprawl, but it does not replace a consistent service catalogue defining recovery objectives, testing frequency, encryption-key responsibilities, and escalation procedures.
The SIEM connection needs a real incident runbook
ConnectWise also points to its Attack-to-Recovery integration with ConnectWise SIEM, describing a link between security detection and restoration workflows. The principle is sound: a ransomware alert should lead rapidly to containment, evidence preservation, determination of the last known-clean recovery point, and a controlled restoration process.
The announcement does not explain how much of that workflow is automated, what data moves between SIEM and x360Recover, or whether recovery actions require explicit technician approval. Those unanswered details matter. A security product should help an MSP move from alerting to recovery, but a poorly governed integration could cause operators to restore from an unverified point or overwrite evidence needed for investigation.
Partners evaluating the combined offering should define the sequence before an incident occurs. That includes who may initiate recovery, how potentially compromised backups are identified, when legal or cyber-insurance notification occurs, which systems are restored first, and how restored systems are isolated before being returned to production.
ConnectWise’s Australian x360Recover launch is a concrete new option for APAC backup architecture, not a universal compliance shortcut. The immediate task for existing partners is to obtain the onboarding and service-boundary details, determine whether their customers need an in-country repository, and verify whether the new region fits their actual recovery tests — especially before x360Cloud’s separate Australian data-residency option arrives.
