skip to content

At 07:00 your CEO forwards a leak-site post naming a company like yours — how do you assess it?

level: seniorimportance: must knowfreq 55%

answer

  1. the listing proves a claim was published
  2. check the exact legal entity first
  3. extortion crews misname and recycle victims
  4. retention bounds what absence can mean
  5. answer with a falsifier and a next update

basics

~20 s

A leak-site listing proves someone published a claim, not that data was taken. Check the exact legal entity, then reseller and supplier lists, identity-provider sign-ins and SaaS audit trails. Answer with a likelihood, a confidence and a stated falsifier.

solid answer

~50 s

First I fix what the artefact proves: a leak-site listing proves someone **published a claim**, nothing more. Extortion crews routinely misname victims, list a reseller's or supplier's data as the customer's, and repost old material. So I grade it as a very low reliability source carrying an uncorroborated claim, and check the cheap discriminators first: does the posted name match our exact legal entity or a similarly named reseller, is that entity on our supplier list, does any posted sample contain our tenants' records. In a SaaS-only estate the estate checks are the identity provider's sign-in and admin-activity logs and the SaaS audit trails over the claimed window, bounded honestly by retention. Then I answer the CEO in estimative language rather than yes or no: the judgement, the confidence, **what would overturn it**, and when the next update lands.

code

text · 6 lines
text
VICTIM: Acme Distribution GmbH
ADDED:  2026-08-28 04:12 UTC
SIZE:   "412 GB, financial and customer records"
SAMPLE: 3 screenshots of a directory tree, no archive published
NOTE:   "data obtained 2025-06"
...

go deeper

for a junior

Know that a leak-site listing shows a claim was published, not that data was taken, and that the first check is whether the named entity is actually your company.

for a middle

Explain the discriminators and the surfaces you would query in a SaaS-only estate, identity-provider sign-ins and tenant audit trails, and why retention limits what an absence of hits can mean.

for a senior

An interviewer expects the whole product under time pressure: source graded apart from claim, the checks sequenced cheapest first, and an answer carrying a likelihood term, a confidence with its basis, a falsifier and a next-update time.

for a principal

Own how the organisation absorbs public claims about itself: who is allowed to speak, what the standing response looks like before the next listing appears, and how a revised assessment is published so hedged language keeps being read.

## Start by naming what the artefact proves A post on an extortion leak site is evidence that **somebody published a claim**. It is not evidence that data left your environment, and it is not evidence of an intrusion. Criminal operators list victims wrongly for ordinary reasons: they name the entity whose documents they happened to find, they conflate a parent, a subsidiary and a reseller with a similar name, they attribute a supplier's stolen file share to the brand printed on the documents inside it, and they re-list old material to pressure a stalled negotiation. Getting this direction right is the whole question. The candidate who answers "we are on a leak site, so we are breached" has already failed. The same discipline applies to the coverage that follows. By 09:00 there may be a dozen articles, an aggregator entry and two peers asking about it in a sector channel. Every one of those descends from the same post. The volume measures interest, not truth. ## Grade the source and the claim apart An extortion site is a source with an obvious incentive to overstate and a track record you can actually assess: has this group's listings historically been substantiated, do they post samples, have they misnamed victims before? For most crews the honest grade is low reliability, and the claim itself is uncorroborated until something independent supports it. A low grade does not mean ignore it — some of these listings are entirely accurate — it means the confidence you attach to any conclusion drawn from it starts low and must be earned by your own observations. ## The cheap discriminators, in order Do these before touching anything expensive, because in the common benign case they end the matter in twenty minutes. 1. **The exact name.** Compare the posted string against your registered legal entities, character by character. "Acme Distribution GmbH" and "Acme Software Inc" are different companies and the resemblance is precisely why the alarm reached you. 2. **The relationship.** Is the named entity a reseller, distributor, supplier or acquisition target? A reseller of your product is not you, but it may hold your customer data, which is a different and smaller question you should keep open. 3. **Any posted sample.** A screenshot of a directory tree or a small teaser archive is the strongest discriminator available. Look for your tenant identifiers, your document templates, your employee names. Handle it as evidence, and treat downloading it as a decision with legal weight rather than a reflex. 4. **Claim dates.** Note what period the listing claims, because that determines whether your logs can speak to it at all. ## What a SaaS-heavy estate can actually check With no on-prem estate, the observation surface is small and you should say so plainly: - the **identity provider's sign-in logs** for the claimed window: anomalous administrator sign-ins, unfamiliar locations or clients, consent to new applications; - the **SaaS admin audit trails** for the tenants that hold the data described: bulk exports, new API tokens or service principals, mailbox or drive-sharing changes; - **retention limits**, which are the honest boundary of the answer. If the listing claims material from fourteen months ago and you keep ninety days of sign-in data, the absence of anomalies is weak evidence about that window and must be reported as such rather than as a clean bill of health. ## Answering the executive A CEO wants yes or no; the honest product is a graded judgement, and it is more useful than a guess. Four elements: - **The judgement, on the likelihood ladder.** "We assess it is unlikely this listing refers to us." - **The confidence, with its basis in one clause.** "Moderate confidence: the posted entity is a separately owned reseller with a similar name, and we see no anomalous administrative activity in the identity provider over the last ninety days." - **The falsifier, stated before it is needed.** "This assessment would be overturned by a posted sample containing our tenant records, by the reseller confirming they hold our customer data, or by administrative activity we cannot account for in the affected tenant." - **A next update time.** An executive who has a time will stop asking; one who does not will ask every twenty minutes and you will stop working. Say explicitly what you are *not* claiming. "No evidence of compromise in the sources we hold" is a different sentence from "we were not compromised", and the difference is the part you will be held to. ## Closing it out When it resolves as a similarly named third party, publish the conclusion with the same reach the alarm had, including the reasoning and the residual question about the reseller's holdings. And if the falsifier arrives later, revise in public and say what changed. An intel function that visibly revises keeps its estimative language worth reading; one that quietly lets a wrong assessment stand teaches everybody to skip the hedges and ask for a yes or no.

  • The CEO insists on a yes or no. What do you give them?
    The judgement with its likelihood term first, in one sentence, then the basis and the falsifier in two more: we assess it is unlikely this refers to us; the named entity is a separately owned reseller; this changes if a sample contains our tenant records. That answers the decision they actually face, which is whether to act now, and it survives being repeated to a board without becoming a promise you cannot keep.
  • Your sign-in logs cover ninety days and the listing claims data from fourteen months ago. What do you report?
    That the estate checks cannot speak to the claimed window, and that this bounds the assessment rather than supporting it. Absence of anomalies inside retention is not evidence about a period outside it. Report the gap explicitly, look for surviving surfaces such as SaaS audit trails with longer retention or the reseller's own account of the period, and let the confidence, not the likelihood, carry the weakness.
  • It resolves as a similarly named reseller. Is there anything left to do?
    Yes, two things. Keep open the narrower question of whether that reseller holds your customer data, because a true statement about the name does not settle the data. And publish the conclusion as widely as the alarm travelled, with the reasoning, so the next listing is met with a process rather than a panic and so the team's estimative language keeps its credibility.
  • A journalist asks you to confirm the listing before you have finished checking. What do you say?
    Only what you can defend: that you are aware of the post, that you have found no evidence to date that it refers to your company, and when you will have more. Do not offer the reseller hypothesis as fact before you have confirmed it, because a wrong exculpatory claim in print costs more credibility than silence, and route the exchange through whoever owns external communications rather than answering directly.

A stranger posting your street address on a noticeboard and claiming they have your house keys. It proves the notice exists. Whether the locks turned is a separate thing you go and check.

saying these in an interview costs you the question

  • Treats the listing as proof of a breach
  • Counts news articles as corroborating sources
  • Reports no log hits as proof nothing happened
  • Ignores retention when claiming a clean window
  • Gives the CEO a bare yes or no with no basis
  • Never states what would overturn the assessment
  • Skips comparing the exact registered entity name

context

resolving links…