SkyKick backup: decide what can continue

SkyKick backup, now called ConnectWise Cloud Backup, is a service businesses may use through an IT provider to protect Microsoft 365 information and recover it when needed. Its current interruption affects both backup and restoration. If your provider uses it, you need to establish what recovery is available while the responsible security team investigates access to your Microsoft 365 environment.

This is a specific supplier incident, not evidence that every Microsoft 365 customer is affected. Ask your provider whether your organisation has relevant current or dormant connections. An organisation's Microsoft 365 environment is often called its tenant. Access granted to a backup application can make the tenant investigation a separate question from whether stored backup archives remain preserved.

For a business owner, the immediate decision is which work can continue within the conditions the responsible technical and security owners establish. Keep that decision separate from approval to reconnect applications or resume backup jobs. A desire to recover a file does not override the incident team's restrictions.

What the current vendor update establishes

In its 18 October update at 01:00 UTC, ConnectWise confirms unauthorised access to application identities associated with Cloud Backup. An application identity represents software access rather than an employee's ordinary sign-in. The vendor reports disabling the affected application identities at 07:00 UTC on 17 October, but that action is distinct from verifying settings and access in each customer's tenant.

ConnectWise says affected shared credentials are invalid. Previously issued access tokens may remain usable until they expire or are invalidated, and disabling an original connection does not remove separate access created elsewhere. These qualifications are why a provider should not declare the investigation finished solely because the vendor disabled an application.

The vendor's current notice says Cloud Backup remains suspended, with scheduled backups, affected archive access and restoration unavailable. It gives no restoration time. It also reports that backup archives are encrypted, isolated and preserved, with no evidence that the archives were accessed. That statement concerns the stored archives. ConnectWise says it lacks downstream visibility into activity in customers' live Microsoft 365 tenants, so archive preservation cannot establish that a tenant was unaffected.

SaaS Security and Cloud Management are temporarily offline as precautions too. The notice describes the corresponding loss of monitoring and alerting, and user and licence management. A precautionary interruption does not prove compromise of every customer, but the provider needs to account for any business process that relied on those services.

Use the latest dated update on the advisory page. Older questions and answers remain alongside newer information and may no longer describe the current position.

Give investigation and continuity separate owners

The qualified security or incident-response owner assesses tenant activity and directs necessary containment. The provider should verify relevant application identities and local settings, including dormant connections, rather than relying on display names alone. ConnectWise asks partners to keep affected applications disabled until restoration instructions and to preserve evidence promptly without delaying urgent containment. It does not recommend deleting applications as the first response.

The investigation may need to consider changes to other identities, permissions or mailbox arrangements. Huntress's investigation describes a tenant where credentials were added to other applications. That observation explains why checking only the original connection can miss a separate access route; it is not evidence that the same activity occurred in every tenant.

The business owner should receive the investigation's current scope and practical restrictions, with uncertainty stated. Successful authentication alone does not prove that data was copied. Equally, an incomplete set of logs with no suspicious entries cannot establish that nothing happened. Notification and other applicable obligations need their appropriate owner alongside the investigation; business continuity planning is not a reason to postpone them.

Meanwhile, the operational owner identifies the work that depends on a usable recovery route. Ask for the last successful recovery point for the relevant workload, what evidence supports that time, and whether the route can actually restore now. "The archive exists" and "we can recover the required record" are different findings during this interruption.

Work through a failed recovery option

Consider a fictional distribution company reviewing a planned cleanup of its order records at 09:00 BST on 18 October. The cleanup would merge records and remove duplicates in a Microsoft 365 workload. Its existing change plan assumes that the IT provider can restore the earlier state if the cleanup damages valid orders.

All times, records and findings in this example are invented to explain the decision. They are not a customer's incident history, a product test or a claim about a particular tenant's safety.

The provider's retained job record shows the last successful backup point for the relevant workload at 18:00 BST on 16 October. At the 09:00 review, that point is 39 hours old. The team cannot presently test restoration through the suspended service. It records the point as a documented successful backup, not a currently verified usable recovery route.

The operations manager checks the company's authorised change log. It lists eleven order amendments since that backup point. Those amendments are known work that the old point would not include. They are not eleven records proven lost, nor evidence that the change log captures every tenant modification or malicious action.

At 09:15, a colleague proposes using another archive within the same backup service. The provider checks the proposal against the current service restriction. It still depends on the unavailable restoration route. The manager rejects it as the cleanup's fallback; selecting a different restore point does not make the service accessible.

The provider has no evidenced independent route that meets this particular cleanup's reversal requirement. A local copy suggested by another colleague has neither a complete record set nor a tested way to restore the workload. The manager records why it is insufficient rather than treating a copy of some files as an equivalent backup.

By 09:45 the decision record is complete:

This is a decision about a particular risky change. It is not a rule that every affected business must stop all ordinary work.

Define what the business can do before the next review

At 10:00 the fictional incident lead confirms the limited activities the team may perform under the current response plan. That permission is specific to the example. It does not rely on the vendor's archive statement as proof that the tenant is safe.

The operations manager agrees to defer the bulk cleanup and keep incoming change requests in an already approved separate queue. The queue has a named owner and restricted access. Staff record a request reference and the work needed, rather than copying confidential order files into an improvised tool. They do not apply the queued changes to the affected workload until the agreed restriction is lifted.

The queue preserves requests for later review. It does not preserve a recoverable copy of the Microsoft 365 workload, investigate access or replace the backup service. Its usefulness is limited to preventing requests from disappearing while the bulk change remains on hold.

The manager accepts the resulting delay and assigns a colleague to cover the queue owner's absence. Requests that cannot wait go to the manager for a specific decision with the incident lead. Staff are not told to bypass the restriction using a personal account or another connection.

The next business review is 12:00 BST, two hours after this temporary arrangement starts. That is an internal checkpoint, not a vendor restoration promise. The provider reports any change in technical restrictions, recovery availability and the age of the protection gap. The manager reports queued work and deadlines that the delay threatens.

If no usable recovery route is available at noon, the cleanup remains deferred. The owner revisits the operational consequences rather than approving it merely because the planned review time has arrived. If the queue itself becomes unavailable, staff escalate through the agreed operational contact; they do not invent an unapproved storage location.

Require evidence before resuming the change

Resumption needs both the responsible incident team's conditions and a recovery arrangement that supports the proposed work. The business owner cannot substitute a supplier status headline for either.

ConnectWise asks partners to follow authorised restoration instructions and then verify workload connections and successful backup jobs. A provider should report which workloads those checks cover. A successful new job is useful evidence of resumed backup activity, but the cleanup's owner still needs evidence that its required recovery route works and that the intervening gap has been addressed in the change plan.

In the fictional case, the provider must establish the appropriate technical restoration conditions with the security owner, verify the relevant backup and recovery arrangements, and identify what remains uncertain. The operations manager reconciles the eleven known amendments and the separate request queue against the authoritative records through an approved process. This avoids replaying a request that has already been completed or treating an old snapshot as the current business position.

If a recovery check fails, the provider retains that result and investigates the cause. The cleanup stays on hold until a suitable route is demonstrated or the business explicitly assesses and approves a different plan. A return of the service does not silently remove the original requirement to reverse a damaging cleanup.

No resumed backup or tenant clearance is assumed in this example. Its completed outcome is a rejected fallback, a deferred bulk change and a bounded operational arrangement with owners and a review time. Those decisions remain useful while technical answers are outstanding.

Bring the unresolved decision to an IT management review

For wider recovery planning, the IT disaster recovery guide explains how recovery objectives relate to business tasks. Here, the immediate issue is more specific: an ongoing access investigation and an unavailable backup-and-restore service affect whether a particular change can proceed.

My IT management consulting can help review supplier responsibilities, business priorities and the evidence needed for a continuity decision. Discuss your backup dependency and operating plan with the affected workload, proposed change and provider's current findings. We can agree the advisory scope alongside your existing team. Qualified security investigation, containment and technical recovery remain with the appropriately appointed specialists; this is not a promise of emergency remediation or a reason to migrate away from Microsoft 365.