Why Cloud Breach Dashboards Misstate the Blast Radius • Lucian Systems

A practical evidence model for separating source volume, confirmed impact, tenant scope and uncertainty in cloud incidents.

“Twenty million records exposed” looks like a precise statement. It often is not.

The number might describe database rows, user accounts, files, transactions, email addresses or an estimate copied from an early disclosure. It may include duplicates. It may combine several tenants of a shared service. It may also be the latest value in a sequence of changing estimates, while the dashboard presents it as a settled fact.

This is more than a reporting problem. An inflated figure can send responders toward the wrong systems, trigger unnecessary escalation and weaken confidence in later updates. An understated figure can leave affected business units outside the response. In cloud incidents, where evidence is divided among providers, customers and third parties, the quality of the scope model often determines the quality of the response.

The fix is not a more impressive visualization. It is a stricter evidence contract.

A number without a unit is not an impact estimate

“Records affected” and “people affected” are different measures. The UK Information Commissioner’s Office reflects that distinction in its breach reporting guidance, which asks organizations to report both the number of people and the number of records affected.

A useful breach dashboard should preserve at least five separate units:

Source objects: Rows, files, messages or other items observed in the evidence.
Unique accounts: Distinct service accounts after a stated deduplication process.
Unique people or organizations: Data subjects or legal entities, where the evidence supports that inference.
Affected tenants: Customer environments whose data or control boundary is confirmed to be involved.
Affected business services: Operational capabilities impaired, exposed or placed at material risk.

These values answer different questions. A security team may need to know that 14 million rows were found because storage and handling decisions depend on volume. A privacy team may need an estimate of unique people. An incident commander needs the affected assets and tenants. An executive needs to understand which business services are at risk.

Collapsing those measures into one large number makes the dashboard easier to read and harder to trust.

Shared infrastructure is not the same as shared compromise

Cloud architecture makes the unit problem more difficult. NIST defines resource pooling as serving multiple consumers through a multi-tenant model. That architecture creates efficiency, but it also means that a single provider incident can sit above many customer environments.

Suppose a provider reports unauthorized access to a shared administrative service. The provider has 600 tenants. A dashboard that labels all 600 as breached is making a claim the evidence may not support. The incident may have touched a shared control plane without crossing every tenant boundary. Confirming customer impact could require tenant-specific logs, object access histories, identity records and provider findings.

The opposite error is also common. If every customer report is counted as a separate unrelated breach, the dashboard can hide the shared upstream cause. That makes a systemic provider risk look like dozens of isolated customer events.

The correct model keeps two linked objects:

The provider-level incident, including the shared component and root cause.
Each tenant-impact assessment, including the evidence and confidence for that tenant.

This lets a dashboard say “one provider incident, eight tenants confirmed affected, 34 still under review” instead of choosing between an unsupported claim of total compromise and an equally misleading collection of disconnected alerts.

One incident can become many source entries

Public breach information rarely arrives as a single clean report. An incident may produce an initial company notice, a regulator filing, an amended notice, a threat actor post, several archive mirrors and later reporting based on the same material. Each source is useful. Counting each one as a separate incident is not.

Deduplication should therefore happen at more than one layer:

Exact-object deduplication identifies identical files or messages.
Dataset deduplication identifies repackaged or partially overlapping collections.
Incident deduplication links different reports to the same underlying event.
Subject deduplication estimates unique accounts, people or organizations within the available data.

These layers should not be confused. Two archives with different hashes can contain substantially the same data. Two regulator notices can refer to one event while reporting different populations. One person can appear in several accounts and in several breaches.

Good deduplication also does not delete inconvenient evidence. It preserves each source object, records its lineage and links it to a canonical incident. Superseded estimates remain visible as historical assertions rather than disappearing from the record.

One breach has several dates

A dashboard field called “breach date” usually hides several timelines. At minimum, incident records should distinguish:

The suspected intrusion or unauthorized-access period.
The first known exposure or exfiltration period.
The organization’s discovery or confirmation date.
The notification or public-disclosure date.
The first date that redistributed data was independently observed.

Those dates can be months or years apart. A recently published dataset may come from an old intrusion. A new regulator notice may update the estimated impact without describing a new event. An archive first observed today may contain data that was already circulating elsewhere.

Date semantics matter operationally. Responders use the intrusion window to preserve and query logs. Privacy and legal teams track discovery and notification. Threat intelligence teams care about first observation and redistribution. Executives need to know whether a headline describes current compromise or newly discovered evidence from the past.

The dashboard should label each date by meaning and source. If the date is only an estimate, it should say so.

Confidence must attach to a claim

Confidence labels are useful only when they answer a defined question. OASIS STIX 2.1 includes a 0 to 100 confidence property and treats an omitted value as unspecified. That is a helpful interoperability pattern, but a single score for an entire incident is still too broad.

Confidence should attach to individual assertions, such as:

The incident occurred.
A particular archive corresponds to the incident.
A named tenant was affected.
The published count is complete.
The exposed data remains current enough to create material risk.

The evidence for one assertion may be strong while another remains uncertain. A company disclosure can confirm that an incident occurred but provide only an early population estimate. A sample of exposed records can establish that a dataset is authentic without proving that the archive is complete. A threat actor’s claim can justify collection and triage, but not immediate promotion to “confirmed breach.”

Confidence also needs a short basis. “High, based on provider notice and tenant audit logs” is useful. A colored badge with no explanation is decoration.

The minimum evidence contract

A practical breach record does not need to become a forensic case file. It does need enough structure to prevent a signal from turning into an unsupported fact. The following fields are a workable minimum:

Canonical incident identity: The event being tracked, with related incidents linked rather than silently merged.
Source lineage: Who made each assertion, when it was collected and whether it is primary, secondary or unverified.
Scope and unit: The value, its unit, the method used to produce it and whether it is source-reported or independently verified.
Tenant mapping: The provider, shared component, customer boundary and evidence for tenant-specific impact.
Date semantics: Separate fields for occurrence, discovery, disclosure and observation.
Verification state: Signal, under review, validated incident, confirmed tenant impact or disproven.
Confidence and basis: A score or label attached to a specific assertion, with a concise rationale.
Affected assets and data classes: The systems, identities and information types involved.
Known unknowns: The questions still open, who owns them and when the next update is expected.

This structure allows estimates to change without rewriting history. It also prevents the familiar situation in which two teams repeat the same number while assigning it different meanings.

Turning NIST CSF outcomes into dashboard behavior

NIST CSF 2.0 is not a dashboard specification, but its outcomes provide a sound operating model. NIST SP 800-61 Revision 3 further places incident response across all six CSF Functions instead of treating it as an isolated emergency activity.

Several CSF outcomes translate directly into evidence-handling rules:

DE.AE-07: Integrate cyber threat intelligence and other context into analysis. A source mention should gain meaning through asset, identity, tenant and business context.
DE.AE-08: Declare incidents when adverse events meet defined criteria. A new post or archive should begin as a signal unless it crosses an established validation threshold.
RS.MA-02 and RS.MA-03: Triage, validate, categorize and prioritize incident reports. Dashboards should expose those states rather than jumping straight from collection to confirmation.
RS.AN-03: Establish what happened, in what sequence and which assets were involved. This supports separate date fields and explicit scope.
RS.AN-06: Record investigative actions while preserving integrity and provenance. This supports an evidence ledger and versioned assertions.

The practical consequence is simple: a dashboard should represent the response process, not just the latest headline. New evidence may increase or reduce scope. Every material change should retain its source, author, time and reason.

A hypothetical example

Consider a fictional file-transfer provider that reports unauthorized access to a shared service. Forty-two customer organizations used the affected component. Three archives appear on different forums. The largest archive contains 4.2 million rows. A later provider notice estimates that 1.1 million unique people may be involved.

A weak dashboard might display:

Three breaches.
12.6 million victims, after adding the three archive row counts.
Forty-two compromised companies.

None of those statements follows from the evidence.

An evidence-based dashboard would instead display:

One provider-level incident.
Three source packages linked to that incident, with overlap still being assessed.
4.2 million rows in the largest observed package.
1.1 million source-reported unique people, pending methodological verification.
Forty-two potentially affected customer organizations.
Eight tenants confirmed affected, with the remainder under review.
Separate occurrence, discovery, disclosure and first-observation dates.
A confidence statement for each major assertion.

The figures in this example are fictional. The important point is the shape of the record: observations, estimates and confirmed impacts remain separate.

What an executive dashboard should answer

An executive does not need every artifact on the first screen. The summary should answer five questions without creating false certainty:

What has been confirmed about our organization?
Which assets, tenants, identities and business services are affected?
What does each number count, and who produced it?
What is still unknown, and how confident are we?
What decision or evidence is needed next?

The largest number should not automatically dominate the screen. Priority should reflect the organization’s confirmed exposure, the sensitivity of affected data, operational dependency, exploitability and the cost of delay.

Record counts still have value. They can indicate handling volume, potential notification scale and the size of a collection. Their role is to inform the scope assessment, not replace it.

The dashboard is part of the evidence chain

Cloud incident dashboards are often treated as presentation layers. In practice, they influence classification, escalation, notification and investment. That makes their data model part of the incident-response system.

The most useful dashboard is not the one that produces the earliest dramatic number. It is the one that lets a responder trace a claim back to its source, understand what the number measures, see which tenant boundaries have been confirmed and identify the evidence that could change the assessment.

When the blast radius is uncertain, saying so is not a weakness. It is the beginning of disciplined response.