How a Mirror Investigation Runs

The Mirror is our entry-level digital exposure audit. It runs over 48 hours, on a fixed €595 fee, and produces a structured report mapping where a person's name, email, and primary username surface across public sources.

This article walks through what actually happens in those 48 hours: the four sequential stages a finding moves through before it appears in a report, what each stage looks at, and what each stage deliberately leaves out. It is methodology, not a sales page. The service page lives at /the-mirror; the firmwide investigation framework lives at /methodology. This article is the depth view between them.

Intake — what we ask for, and what we don't

A Mirror engagement starts with three anchor data points:

• Full name — including common variants, married or maiden names where relevant, and any prior legal names if disclosure is in scope.
• Primary email address — the one most likely to have been used historically across accounts, mailing lists, and breach-corpus exposure.
• Primary username or handle — the screen name most consistently reused across forums, gaming platforms, social profiles, and developer accounts.

We also ask three scoping questions before search begins:

• Jurisdiction. Where you live, where you have lived in the last ten years, and any other country where you are a citizen, taxpayer, or registered director. This determines which broker-quadrant content is in scope and which public registries are accessible.
• Language. Whether non-English search corpora — Dutch, German, French, Spanish, others — are in scope. A native-English search of someone with a long Continental European presence misses material.
• Family scope. Whether searches should follow up on identifiers that might surface household members. The default is no; a Mirror is a personal audit, and family-graph mapping is opt-in only.

Two further intake requirements close the gate against misuse:

• Signed informed consent. Before any search begins, the client signs a short consent form authorising us to search public sources for records associated with their own identifiers. The consent is engagement-specific and time-limited; it does not extend to family members, business associates, or anyone else who has not separately consented.
• Identity verification. We confirm that the person commissioning the Mirror is the person whose identifiers will be searched. The default is a brief video call with photo-ID match; high-sensitivity engagements may require more. We do not run a Mirror on behalf of a third party — not for a relative, not for an employer, not for a partner. If a third party wants information about another person, that is a different category of work with entirely different legal and ethical posture; the Mirror is not the vehicle.

What we do not ask for, ever:

• Passwords or account credentials. We never request them and we never accept them if offered.
• Account access. No "share your screen and walk me through your inbox." We work strictly from publicly observable surface.
• Financial detail. Account numbers, card numbers, balances, tax IDs — none are needed to map digital exposure, so we don't collect them.

The shorthand: a Mirror is scoped before it is searched. A discovery run that begins without confirmed jurisdiction, language coverage, family-scope policy, signed consent, and verified identity will not run. We don't start until intake is closed.

Stage 1 — Discovery (~12 hours): casting the net

Discovery is breadth. The objective is not yet to establish what is true; it is to capture every candidate hit that the four source quadrants surface, knowing many will fall away in later stages.

The four quadrants:

01 · Brokers. People-search platforms, commercial aggregators, public registries, and electoral-roll surfaces where applicable. A typical Discovery run touches the major US people-search platforms (Spokeo, BeenVerified, Whitepages, Intelius and the long tail behind them), B2B aggregator surfaces tied to corporate enrichment (Acxiom, Experian Marketing Solutions, LexisNexis Risk Solutions), and country-specific surfaces relevant to declared jurisdictions — UK Companies House, NL KvK, US SEC EDGAR, charity commissions, court-record indexes where statutorily public.

One scope boundary belongs here. Many B2B data brokers — large marketing aggregators, identity-risk providers, reputation databases — do not expose a public query interface. The records exist; you cannot see them without invoking your right of access under GDPR Article 15 and equivalent rights under UK GDPR, CPRA, LGPD, and other regimes. A Subject Access Request takes up to one month for a controller response, which is incompatible with a 48-hour Mirror. Brokers in this category are therefore outside Mirror scope. Where the engagement is an Eraser instead, that one-month window is used differently: we skip the question of whether a record exists and submit erasure requests directly to the brokers most likely to hold one, on the principle that proving negative coverage is slower and less useful than asserting the right to delete.

02 · Breaches. Credential dumps, stealer-log corpora, combo lists, paste indices. We query against breach corpora on a first-party-consent basis: the client authorises us to search records associated with their own identifiers, and the raw data is never transferred or retained beyond the engagement. No single corpus is comprehensive — HIBP indexes a large fraction of disclosed breaches but excludes stealer-log compromises and many regional or enterprise-only dumps; we query multiple independent corpora with different inclusion criteria, on the principle that gaps in one are often visible in another. Stealer-log monitoring (Hudson Rock-class infostealer corpora) is in scope where breach-by-malware exposure is plausible.

03 · Social. Current and dormant profiles on the major platforms (LinkedIn, X/Twitter, Facebook, Instagram, Reddit, GitHub), historical post archives where indexed, and forum residue under the declared username. The Mirror maps surface — what exists and what is visible. Active cross-correlation against threat-actor accounts and detection of impersonation or clone accounts targeting the client are out of scope here; those are functions of The Shield, where an active-threat posture justifies the deeper analysis.

04 · Forums. Clearnet marketplaces and leak indices, Tor boards visible to OSINT-grade collection, targeted-group channels where the identifiers might appear in re-shared dumps. We do not purchase, transact, or interact in these spaces; we observe what is publicly indexed.

A clean quadrant is a finding. If Discovery completes without a single hit in, say, the Forums quadrant for a low-profile private individual, that absence is reported — it is signal, and it shapes the threat model.

What Discovery deliberately does not do at this stage:

• It does not verify any candidate hit. A name match on a US people-search platform may or may not be the right person; resolution happens in Stage 2.
• It does not score risk. Risk is downstream of confidence, which is downstream of cross-reference.
• It does not produce a report. Discovery's output is an internal candidate-set worksheet that no client ever sees in raw form.

A Discovery output for a typical mid-career professional with a 15-year online presence might surface 40–80 candidate hits across the four quadrants. A high-profile executive with a long search history can produce several hundred. The volume here is misleading on purpose: most candidates do not survive Stage 2.

Stage 2 — Cross-reference (~12 hours): the pivots

Cross-reference is where the candidate set is tested against itself and against independent corroborating sources. This is the stage that most distinguishes a structured investigation from a free OSINT checker. A free checker tells you that an email appears in a breach. Cross-reference asks: do this email, this username, this photo, this address, and this employer all point to the same person, in the same period, in a way that holds up under at least one independent source?

Five pivots run in parallel during Stage 2.

Username re-use chains. Most adults online reuse a primary username across more platforms than they remember. Starting from the declared handle, we enumerate platforms where that exact handle exists, then check whether each instance plausibly belongs to the same person via posting cadence, language, or biographical fragment. A typical chain might surface six to twelve platforms; three to five will be the same person, and the rest are coincidental matches. The discriminating signal is not the handle — it is the corroborating fragment around it. The Mirror stops at "this handle is the same person across these platforms." Active correlation against threat-actor indices, attacker infrastructure, or known harassment networks is downstream work that belongs to The Lockdown or The Shield.

Email-anchor pivots. An email address that appears in multiple breach corpora is a stronger anchor than one in a single corpus. When the same email surfaces in a 2014-era dump (older registration period) and a 2021-era dump (current period), the timeline alone tells us how long this address has been a usable target. Email-fragment pivots also catch re-aliasing patterns — a .alt, .work, or +tag suffix that the same person used as a throwaway and forgot.

Photo correlation. A reverse image search of the primary social-media headshot frequently surfaces older instances of the same image — on personal blogs, conference websites, mailing-list archives, or pinned content on aggregators. The older instance often carries metadata the newer one strips: a city, an employer, a date range. Reverse search uses public engines (Google Images, Yandex, Bing); we do not use scraped or commercial face-matching services.

Address, phone, and historical IP triangulation. A US people-search platform listing claiming an address from 2017 is a candidate. The same address surfacing in a 2018 marketing-list breach record, with a phone-number area code consistent with the city, becomes a verified residence period. Triangulation is the test: any one source can be wrong, two independent sources rarely are. Historical IP-address exposure in breach corpora — forum dumps that included user-IP fields, gaming-platform leaks with logged client addresses — is included where present, tied to the breach date and marked historical. Live IP geolocation and current-network reconnaissance are not in Mirror scope; they belong to engagements with active-threat posture.

Employer and registry corroboration. For executives, directors, and trustees, public registries (Companies House, KvK, SEC EDGAR, charity commissions) anchor the corporate side of the identity graph. A LinkedIn-scraped job-history claim becomes verified when a Companies House director appointment matches dates and entity name.

What Cross-reference removes from the candidate set:

• Same-name false positives. Two people with the same name, one of whom is the client and one of whom is not. Common in countries with high name density. Removed once a single corroborating fragment fails to align.
• Stale broker-quadrant noise. People-search platforms aggressively recycle decade-old records into "current" listings. A broker hit dated 2024 that turns out to derive from a 2014 phone-book scrape is downgraded to historical, not current.
• Coincidental username matches. A six-letter handle on an obscure forum may be the same person, may be someone else who registered the handle later, or may predate the client's adoption. Removed unless one corroborating fragment lands.

Cross-reference typically shrinks a 60-candidate set to 25–35 verified or pending entries. Discarded candidates are not deleted from the working set — they are marked discarded with reason, so that later stages can audit the decision.

Stage 3 — Verification (~12 hours): confidence scoring

Verification is the gate that decides what makes the report and how it is labelled. Every entry that survived Cross-reference is assigned a confidence level on a three-tier scale:

• High confidence. Three or more independent sources corroborate the same data point. Example: a current address appears on two unrelated people-search platforms and matches a phone-number area code from a separate breach record. Included in the report at full attribution.
• Medium confidence. Two independent sources corroborate, but a third is missing or contradictory. Example: an email appears in a breach corpus and is cited by a people-search platform, but the associated employer differs between sources. Included with a confidence note.
• Unverified. Only one source supports the finding, or sources disagree without resolution. Example: a username appears on a forum with a posting cadence consistent with the client, but no other identifier links the account. Included with a flagged label, not dropped. A flagged unverified finding is more useful to a defender than a quietly discarded one — the client can confirm or deny it from their own knowledge.

The independent-source rule is non-negotiable. A single people-search platform listing, however convincing, does not become a verified finding without corroboration from a different quadrant. People-search platforms share data with each other so aggressively that two of them confirming the same address is one data point, not two.

Verification also handles negative findings explicitly. If the Forums quadrant produced no hits, the report says so — phrased as "no findings on monitored forum corpora at search date." Negative findings have a shelf life (dark-web data is volatile; what is absent today may surface tomorrow), and the report says that too.

Stage 4 — Report (~12 hours): structuring delivery

The report is structured by source category, then by risk priority within each category. A typical Mirror report has six categorical sections:

• Brokers — people-search platform listings and aggregator records, with opt-out URLs where applicable.
• Breaches — credential and personal-data exposure across known dumps, ordered by recency.
• Social — public profiles, dormant accounts, and historical archive surfaces.
• Forums — leak-index and marketplace exposure, where present.
• Search engines — what a name, employer, and city query returns at the top of public results, with notes on cache persistence.
• Corporate records — registry-visible director, trustee, and entity affiliations.

Within each section, findings are ordered High → Medium → Low → Informational. Each finding carries four fields:

• What was found. A factual statement of the data point, no narrative.
• Where it was found. Source category, not necessarily the URL. A people-search platform name is identified; a forum index URL is not, on the principle that the report should not double as a navigation guide for a future attacker.
• Risk classification. What this finding enables in plausible threat models — phishing, vishing, address-based delivery harassment, credential-stuffing, account-recovery abuse, doxxing.
• Recommended action. Specific to the finding: an opt-out link, a credential-rotation note, an archive-takedown procedure, a privacy-setting change.

The report ships via encrypted channel, on a two-channel split: the encrypted file moves via one route (default email, with PGP layered on top) and the decryption key — or, for clients without PGP, the symmetric passphrase — moves via a separate route agreed at intake (Signal, voice, or another out-of-band channel). Sending both through the same channel is the cryptographic equivalent of locking the door and leaving the key in it. Proton Mail is supported as an alternative file channel.

For clients whose threat model warrants more, bespoke delivery is available: in-person briefing, encrypted physical media, courier with chain-of-custody, or another channel agreed at intake. This can be folded into scope at no extra cost where the engagement justifies it, or added to a fixed-price package where the standard channel is insufficient for the situation. The default is correct for most clients; for some, the standard channel is not the only option, and we say so up front.

The client has 48 hours from delivery acceptance to review and ask clarifying questions; after that, all case data is cryptographically deleted from internal systems, regardless of whether the client engages further. The 30-day follow-up window covers question-answering only — by that point we no longer hold the underlying data.

What we don't do — and why

Each of the following is a category-level commitment, not an exception clause.

• No data purchase. We do not buy from brokers, leak markets, or stealer-log shops. Funding those markets undermines the defensive posture we sell.
• No account access. We never log into a client's accounts, and we never ask. Authorised account audit is a different category of work and requires a different legal posture; a Mirror runs on publicly observable surface only.
• No active scanning. No port scans, no probing, no penetration testing. A Mirror is reconnaissance of public information; it is not a technical assessment.
• No retention beyond 48 hours. Reports are delivered, accepted, and the working set is cryptographically destroyed. We hold no archive, no client database, no portfolio. The reasoning is operational, not just principled: a firm that aggregates the digital exposure profiles of its clients is itself a high-value target — precisely because of the data it holds. The longer that data sits on our systems, the more attractive a breach of us becomes to anyone who would want to harm a client through us. Destruction within 48 hours is the only retention policy that doesn't eventually become someone else's leverage against the people who hired us.
• No automatic upsell. A Mirror that finds little does not get upgraded to a Lockdown to fill out the engagement. If the report is short, the report is short.

The reason these are non-negotiable rather than configurable: every one of them, allowed once, becomes the precedent that forces it the second time.

One clarification on what publicly observable actually means, because the phrase is regularly misread. It does not mean "what a Google search returns about you." It means information that is legally accessible to anyone willing to look — data held by aggregators you have never registered with, records on platforms you have never visited, archive snapshots of pages long since deleted, registry entries filed in your name, forum residue under a username you stopped using a decade ago. Public, in this sense, means findable without authentication — not findable on the front page of search results. Most of what surprises clients in their first Mirror is exactly this: information that was always findable, just not by them.

When the Mirror is the wrong tool

A Mirror is the right starting point for most enquiries. There are four cases where it is not.

• You already know about a specific credential exposure or account compromise. The Mirror will confirm the exposure, but you do not need confirmation; you need response. The Lockdown is the credential and leak investigation that resolves what the Mirror would only map.
• You are facing an active, identified threat. Stalking, targeted harassment, doxxing already in progress, suspected device compromise. Our default advice in these cases is to contact local law enforcement first — they have powers and resources we do not, and a documented police report is often the foundation for any subsequent civil or platform action. Beyond that, mapping is too slow when the surface is being actively exploited; The Shield handles active threat mitigation.
• You want removal, not mapping. If your goal is to suppress data-broker presence rather than understand it, the Mirror's mapping function is overhead. The Eraser is structured around long-term removal. The Mirror fee is credited in full against the Eraser fee if you proceed within 30 days of Mirror delivery.
• The exposure is corporate, not personal. Vendor risk, staff exposure across an organisation, breach-pattern analysis at company scale. The Corporate Audit is the engagement type that fits.

Honest steering is part of the methodology. A Mirror that should have been a Shield wastes time the client may not have.

Closing

A Mirror investigation is bounded by what is findable on public surface at the time of search. It is not exhaustive. Dark-web data in particular is volatile — what is absent today may surface tomorrow, and what is present today may be redacted in a week. The report documents what is verifiable when the search runs, and it is honest about the shelf life of negative findings.

Within those bounds, the four-stage pipeline does specific work: Discovery captures candidates, Cross-reference removes false positives, Verification scores confidence, Report structures delivery. Every entry the client reads has been through all four. That is the only claim a Mirror makes — and the one it has to make every time.