Restoring the data is only the start of the conversation that decides whether a client stays
Restoring a client's data after a ransomware attack no longer guarantees the client will stick around. That is the central argument of an analysis published by BleepingComputer on 10 November, drawing on work by Kaseya, which contends that delays, thin communication and unexpected invoices erode trust faster than the outage itself. For managed service providers in Hong Kong — many of whom run lean mid-market IT teams with no dedicated incident-communications function — the observation reframes recovery readiness as a commercial risk rather than a technical one.
The Kaseya analysis, presented as the prompt for the piece rather than its evidence base, attributes much of the client friction to fragmentation: recovery, alerting, ticketing and reporting handled across disconnected tools that force engineers to reconstruct an incident timeline by hand while the client waits. Its counter-argument is that integrated workflows compress time-to-restore and make the status of an incident easier to relay in real time. Kaseya sells that integrated workflow, so the remedy it proposes serves its commercial interest as much as its analytical one. The diagnosis, though, holds regardless of vendor: the cost of a fractured toolchain shows up in the client relationship, not just in the runbook.
Three measures follow as client-facing deliverables. The first is speed of restoration, expressed as a recovery-time figure the client can actually see. The second is quality of communication — how often, how clearly and through which channel the client hears from the provider during an incident. The third is invoice predictability: whether the recovery effort produces a scoped, explained bill or a surprise. Any one of the three can cost the account on its own.
For Hong Kong providers, there is a regulatory dimension that sharpens the first two. The Personal Data (Privacy) Ordinance does not impose a statutory breach-notification obligation on its face, but the PCPD's Guidelines on Data Breach Handling and the Protection of Personal Data Involved in a Data Breach, issued in 2020, recommend that organisations notify the Commissioner and affected data subjects as soon as practicable after a breach is discovered. That guidance is a recommendation, not a notification duty written into the statute — but a provider that cannot establish what was accessed, when, and by whom within the first hours of an incident cannot write that notification with confidence, and a client told late, or told imprecisely, tends to remember it. HKCERT, which handles a steady flow of local compromise reports, has repeatedly advised organisations to treat containment, notification, and digital forensics and evidence collection as a single, rehearsed sequence rather than sequential afterthoughts.
The practitioner view from the ground is consistent: the post-incident conversation is decided less by whether the data came back than by how the preceding 48 hours were handled. Clients rarely audit backup verification logs. They remember whether their calls were answered, whether the timeline was clear, and what the invoice said.
None of this makes recovery quality a reason to switch tooling vendors — the underlying pressure applies whatever stack an MSP runs. What it does argue is that recovery time, communication cadence and cost transparency belong on the same dashboard as uptime, reported to clients in the same rhythm. Providers that can show those three numbers after an incident are handing their clients a reason to renew; providers that cannot are leaving the renewal conversation to chance.
The practical starting point is smaller than a platform decision. A standing monthly client report carrying three fields — the agreed recovery-time objective, the date of the last tested restore, and the incident communication interval the provider has committed to — turns all three numbers from something an MSP produces under pressure into something the client has already seen, understood and signed off on long before an attack forces the question.
還原數據，只是決定客戶去留的對話之始
勒索軟件攻擊後替客戶還原數據，已不再保證客戶會繼續留下。這是 BleepingComputer 於 11 月 10 日發表的一篇分析的核心論點，該文援引 Kaseya 的研究，指出延誤、溝通薄弱以及突如其來的帳單，其侵蝕信任的速度更甚於停機本身。對香港的管理式服務供應商（managed service providers）而言——當中不少營運精簡的中型市場 IT 團隊，並沒有專職的事件對外溝通職能——這項觀察將復原準備工作重新定位為商業風險，而非純粹的技術問題。
Kaseya 的分析在文中被定位為引子，而非其論據基礎；該分析將大部分客戶摩擦歸因於工具割裂：復原、警報、工單（ticketing）與報告分散於互不連通的工具之中，迫使工程師在客戶苦候之際，徒手重建事件時間線。其反論是，整合式工作流可壓縮 time-to-restore，並令事件狀態更易於即時傳達。Kaseya 正是整合式工作流的銷售方，因此其提出的補救方案既服務於分析上的主張，也同樣服務於其商業利益。然而，不論供應商為何，這項診斷依然成立：支離破碎的工具鏈（toolchain）所付出的代價，會反映在客戶關係之上，而不僅僅體現在 runbook 之中。
由此衍生三項面向客戶的交付指標。第一是還原速度，以客戶真正看得見的復原時間（recovery time）數字來表達。第二是溝通質量——事件期間，服務供應商以何種頻率、何等清晰程度、透過哪種渠道向客戶匯報。第三是帳單可預期性：復原工作所產生的，是一份範圍明確、解釋清楚的帳單，還是意料之外的收費。三者之中任何一項，都足以單獨令客戶流失。
對香港的服務供應商而言，還有一個令前兩項更為尖銳的監管維度。《個人資料（私隱）條例》在條文表面上並未訂明法定的資料外洩通報責任，但私隱專員公署（PCPD）於 2020 年發出的《資料外洩處理及保障資料外洩所涉及的個人資料》指引建議，機構在發現資料外洩後，應在切實可行範圍內盡快通知專員及受影響的資料當事人。該指引屬建議性質，並非寫入法例的通報義務——然而，若服務供應商在事件發生後首數小時內無法查明何人何時存取了何種資料，便無法有信心地撰寫這份通報；而被遲告、或被告知得不夠準確的客戶，往往會耿耿於懷。HKCERT 長期處理本地資料外洩事故報告，曾多次建議機構將遏制（containment）、通報，以及數碼鑑證及證據蒐集，視為一套經過預演的完整流程，而非事後才逐步補上的環節。
前線從業員的觀點如出一轍：事件過後的對話走向，取決於此前 48 小時如何應對，而非數據有否找回。客戶極少查核備份驗證日誌。他們記得的，是自己的電話有沒有人接聽、時間線是否清晰，以及帳單上寫了些什麼。
以上種種並不能成為更換工具供應商的理由——無論 MSP 採用哪一套技術堆疊（stack），底層壓力同樣存在。但它確實主張，復原時間、溝通節奏與成本透明度，應與正常運行時間（uptime）並列於同一個儀表板上，並以同一節奏向客戶匯報。事後能向客戶出示這三個數字的供應商，等於遞上續約的理由；做不到的，只能把續約的對話交由運氣決定。
實際的起點，比選擇平台更為細微。一份恆常的每月客戶報告，載有三個欄位——雙方協定的復原時間目標（recovery-time objective）、最近一次復原測試的日期，以及服務供應商已承諾的事件溝通間隔——便能令這三個數字，由 MSP 在壓力之下臨時生產的東西，轉化為客戶早已看過、理解並簽署確認的內容，遠在攻擊逼使這個問題浮現之前。