During a multi-tenant identity incident, status information arrives through several channels. The service status page may announce an outage. The trust center may publish affected application IDs and IOCs. An incident-response partner may describe tenant-level observations. Each source answers a different question and updates on a different schedule.
The ConnectWise Cloud Backup investigation demonstrates why those sources cannot be collapsed into one green or red indicator. ConnectWise suspended a service, disabled application identities and published technical guidance. Huntress reported tenant authentication observations and follow-on activity. A customer needs to know both whether the service is available and whether its own tenant was affected.
Three different status questions
The first question is service availability. Is Cloud Backup running, suspended or restoring access? The vendor's status page is the natural source for that operational state.
The second question is incident scope. Which application identities, services, time windows and indicators are involved? The trust center advisory is more useful than a brief status badge for this question because it can include technical identifiers and changes over time.
The third question is customer impact. Did the application authenticate in this tenant, what token did it receive, and what changes followed? Only the customer's identity and audit records, supported by vendor notice, can answer that.
A green service status can coexist with unresolved tenant questions. A restored service does not erase a credential that was added during the incident. A customer-side review can find suspicious activity even when the service page says the outage is resolved.
Record the update, not the impression
Each status update should be stored with its publication time and retrieval time. Record the source URL, the affected service, the stated state and the exact action requested of customers. If the vendor changes the list of affected application IDs or adds IOC addresses, preserve the earlier version as well.
This matters for investigation. Huntress initially reported a set of tenant observations and later added context. ConnectWise published multiple updates with additional IP indicators and technical guidance. A timeline that uses only the final page can lose the sequence that explains what customers were expected to do at each stage.
The same rule applies to the status page. An update that says "service interrupted" is not a complete record of when backups stopped, when restoration became unavailable or when a new restore path became available. The operational owner should maintain a separate timeline from the public statement.
Use external observations as context
A ZoomEye query for domain="connectwise.com" returned 170 all-asset observations on October 30, 2026. That observation can help the response team map vendor-operated portals, certificates and status services. It does not establish that the service was healthy or that a customer used it.
The exact IOC IP returned zero at scan time. The result is useful only when labeled as a scan observation. A missing IP does not prove that an authentication did not happen earlier, and a visible domain does not prove that a service is restored. External telemetry should be stored beside the vendor and tenant evidence, not used as a replacement.
A response cadence that avoids drift
Set a review cadence while the incident is active. At each review:
Check the vendor advisory and status page for a new update or change in scope.
Confirm whether the update changes customer action, not only service availability.
Search tenant logs for new application IDs, IPs, user agents or time windows.
Update the customer impact matrix with new evidence and remaining gaps.
Record who owns the next action and when it will be verified.
The cadence should continue after the service returns if tenant-side containment is still incomplete. Restoring backups and closing an identity investigation are separate milestones.
Avoid false reassurance
A public status page is written for a broad audience. It may not include enough detail to answer a security team's questions. "Investigation ongoing" can mean that the vendor has not established scope, that it is not disclosing scope, or that the affected service is still being contained.
Do not turn a status update into a statement that no customer data was accessed unless the vendor says so explicitly and the evidence supports it. ConnectWise stated that existing backup archives remained encrypted, isolated and preserved, and that it had no evidence they were accessed. That is different from proving that no tenant token was used or no changes occurred inside a customer environment.
The customer should also avoid treating a lack of local alerts as proof of no impact. Service-principal authentication may not trigger the same alert as a user login. A backup application may read data without creating a detailed mailbox audit event. Detection coverage is part of the evidence.
Prepare the communication package
Keep a short package ready for customers and internal responders. It should include the affected application names and IDs, the current service state, the verified time window, the IOCs, the tenant checks required and the next update time. It should say what is known, what is not known and what action is required.
The package should not include secrets, unnecessary tenant identifiers or speculative attribution. It also should not tell customers to revoke a legitimate partner application without checking whether that action will break backups or managed services. Give the decision owner the operational consequence.
Close the incident with two records
The first closing record is the vendor's service state. It states whether the affected product is available and what restrictions remain. The second is the customer's identity record. It states whether the service principal was present, whether the application authenticated, what changes were found and what containment was verified.
The two records may close on different days. That is a normal outcome, not a communications failure. The failure is claiming that a green status page proves a tenant is clean.
The reliable reading
Status pages help teams coordinate an outage. Trust-center advisories provide technical scope. Huntress-style incident reporting adds independent observations. ZoomEye maps public assets. Tenant logs establish customer-side authentication and change.
The ConnectWise incident requires all five views, each with a timestamp and a limitation. Reading them together gives a response team a path from service interruption to tenant verification. Reading any one of them alone produces either false reassurance or unsupported alarm.