Legal: how we collect and handle exposure and threat data

SireShield warns people that their identity has surfaced in leaked data, on dark-web sites or in criminal chatter, and protects their devices with indicators drawn from the same material. Doing that means we handle information that was stolen from somewhere and that we did not collect from you. This page explains, without softening it, where that information comes from, what we refuse to do to get it, why we hold it, how long we keep it, and what you can ask of us.

Version 2026-09-25. Applies to SireShield's exposure monitoring, dark-web and chatter monitoring, and the threat indicators we publish to devices. It sits alongside our Privacy Policy, Terms of Use and Trust & Transparency page and does not replace them. Where this page and an older version of those documents differ, this page describes what we actually do today, and the other documents are being brought into line.

1. Who we are

SireShield is built and operated by CodeSire Private Limited, a company registered in India (CIN U72502KA2017PTC098946, Bengaluru, Karnataka) and recognised under the Startup India programme (DPIIT DIPP51700). All the collection, matching and storage described on this page runs in Microsoft Azure's Central India region, under Indian law, for subscribers in India; the processors we use for e-mail and app distribution are listed in our Privacy Policy. We are a small company with a small number of vetted subscribers; we say that because it is relevant to how we operate and to what regulators would expect of us. We are not the only company doing this kind of work — breach-notification and threat-intelligence services are an established category in India and abroad — but we have chosen tighter rules than most, and this page is where we write them down.

2. What the monitoring does

When you subscribe, you nominate the identifiers you want watched: e-mail addresses, phone numbers, social handles and, if you choose, your name and aliases, your organisation and a work domain. We look for those identifiers in three kinds of material. The first is leaked data: credential dumps, info-stealer logs and the victim lists and files published by ransomware groups. The second is chatter: mentions of you on leak sites, in public Telegram channels used by criminal groups, and on paste sites, including target lists, sale offers, threats and impersonation. The third is attacker infrastructure: the domains, addresses and file hashes that criminals use, which we extract from the same material, review, and send to your device as a signed threat list. If we find something about you, a SireShield analyst looks at it first, and only then do you receive an alert. Nothing about you reaches you automatically.

3. Where the data comes from

Four places, and we want to be precise about each, because the list is deliberately short.

Public sources we crawl ourselves. As of this version: around a hundred human-approved ransomware leak-site index pages on the Tor network, fetched as text only; the public victim-naming tracker RansomLook and the Have I Been Pwned breach catalogue (we also use ransomware.live's free listing to discover leak sites, not for victim names); one public paste site, read through a free open-source paste monitor; and seven public Telegram channels that our read-only account monitors and never posts in. We only read what those sources serve to anyone who visits. Every crawl source is approved by a person before our systems fetch from it; our automated classifier excludes sources it identifies as marketplaces or as media-heavy, and a source flagged by keyword is held in quarantine until an analyst has looked at it. New categories of source — for example open-web forums or social media — are added only after the same human approval and an update to this page. We use the open-source AIL framework, published by CIRCL (Luxembourg's national CERT), for collection, with a matching module of our own.

A licensed breach-data provider. For material that cannot be collected lawfully by crawling, above all info-stealer logs that are traded privately, we buy access under contract. Today that provider is LeakCheck, a company registered in the United Kingdom. We send them only the identifier we are checking, our contract requires that they do not retain or reuse our queries, and it requires warranties that their own data is lawfully obtained.

Ransomware leak sites. Ransomware groups publish the names of their victims and, often, the stolen files. We read the victim lists and the index pages. Whether and how we ever retrieve the files themselves is covered in section 9.

Nothing else. We do not have access to private criminal forums, invitation-only Telegram groups or marketplaces, and we do not buy access to them. Where a vendor would have that coverage and we do not, our coverage is thinner than theirs, and section 17 says so.

4. What we never do

Some of the largest companies in this industry source data through human operatives inside criminal communities. We have chosen not to. It means our coverage of some sources is thinner than theirs, and where that matters we buy from a licensed provider instead. We would rather tell you that plainly than pretend to a coverage we do not have.

5. Leaked data is not "public"

You will sometimes see threat-intelligence companies describe stolen data as "publicly available". We do not think that is honest, and Indian law does not treat it that way either: under the Digital Personal Data Protection Act, 2023, personal data counts as publicly available only if the person it belongs to made it public, or someone was legally obliged to. A stealer log on a Tor site meets neither test. So we treat everything we collect as personal data that was taken without its owner's consent, and we design accordingly, rather than relying on an exemption we do not believe applies.

6. Why we hold data we did not collect from you

Most of the people whose identifiers pass through our systems are not our subscribers and have never heard of us. We cannot ask their consent; we have no way of contacting them, and trying to would mean processing far more of their data than we otherwise would. We hold what we hold because it is the only way to warn the people who have asked us to watch for them, and because identifying that someone's identity has been stolen is in the interest of preventing and detecting the crimes that follow: identity theft, fraud by impersonation, account takeover, extortion.

The material we handle has, by the time we see it, already been published by the criminals who took it. We are not the source of any leak; we do not host or re-publish what we find; and we hold it for no purpose of our own except to notify the people it concerns and to protect their devices. That does not make the data "public" (section 5), but it is why our handling of it is lawful rather than dishonest: no one gains from it, no one loses by it, and it is never used for anything else.

In Indian law, that protective purpose is the basis on which we rely. Until 13 May 2027, the operative rules are section 43A of the Information Technology Act, 2000 and the 2011 rules under it; from that date, the Digital Personal Data Protection Act applies in full, and our reliance for non-subscriber data is on the provision that lifts consent requirements where processing is in the interest of preventing, detecting or investigating offences. We are candid that this provision has not yet been tested against a private company doing what we do; the same is true for every company in our industry. We have taken legal advice on it, we have built our system to be as minimal as that advice requires, and we will change what we do if the law is clarified against us. For subscribers, the basis is simply your consent, which you can withdraw in the app at any time.

7. How we handle what we find

We do not keep a plaintext copy of your identity on the collector. When you nominate an identifier, it is converted into a keyed one-way code before it goes anywhere near the crawled material; the collector holds only those codes and cannot reverse them. A second key, held only by our core backend and never by the collector, is needed to link a match back to you. If the collector were ever compromised, the attacker would obtain neither your identity nor the ability to check whether any given person is watched. Names, organisations and addresses nominated for chatter monitoring (once it is switched on) are held on the backend, not on the collector, and are matched only when at least two independent details agree — a bare name match is never released to you.

We keep raw crawled text for seven days. Text that our crawler fetches is deleted after seven days whether or not it matched anyone. We keep text only: no images, video, archives or binaries are fetched by our crawler, by design. What persists longer is described in section 8.

A human decides before you hear anything. Every finding about you is reviewed by a SireShield analyst before release. That is slower than an automatic alert, and it is deliberate: leaked material is full of noise, and a false alarm delivered to someone in the middle of a security incident does harm. When an analyst releases a finding, you see only your own data, with other people's details redacted, together with a factual note, what to do next, and how urgent we think it is.

We never use what we find for anything else. Not analytics, not marketing, not model training, not "risk scores" sold to third parties. The corpus exists to alert and protect the people it concerns. That restriction is written into our internal retention policy, and we require it of anyone who processes data for us.

8. How long we keep things

This is the public summary of our retention policy. The full policy is an internal document that our Board reviews annually; if you have a reason to see it, ask. The periods below are the policy. The "Today" column says honestly whether the deletion that enforces each period is already running in our systems; where it is not, we are building it, nothing is deleted early or late in the meantime except as shown, and we will update this table when each one runs for the first time.

9. Files published by ransomware groups

This is the one place where we would deliberately retrieve a body of material that is, in its entirety, the proceeds of an extortion, and that contains the personal data of many people who are not our subscribers. We built the capability because it answers the question that matters most to a subscriber whose employer has been breached — "is my data in what they published?" — and no listing can answer it. We describe it here in full so that nobody is surprised by it.

This is how it will work, and the conditions under which it will run at all. We retrieve published files only when a ransomware group names an organisation whose domain matches the verified work e-mail address or the domain that a subscriber has nominated, and only when the leak site serves the files to anyone without a login or a payment. The organisation may be anywhere in the world; the retrieval and everything after it happens on our systems in India, under Indian law. Each retrieval is approved and recorded by a named SireShield analyst in a tamper-evident log before it starts. The files are fetched into an isolated environment that is destroyed afterwards. Before anything is examined, files that are images, video or executables are excluded, and an archive whose listing contains media is checked against a recognised hash set of known illegal material — if we hold no such set, that archive is not processed at all. Extraction is automated: it produces a listing (file names, sizes, types, counts, dates) and the one-way codes of any identifiers found, and nothing else. No person reads the documents; no credential pairs are kept; no full-text index is built; no personal data of anyone other than a subscriber is extracted. The working volume is then cryptographically erased and the erasure logged. What a subscriber receives is a statement that their own identifier was present, how much of the published material we were able to scan, and what to do. We never tell anyone else what a dump contains.

As of this version, we have never retrieved a published file. Part of this process is built and part is not, and none of it will run until every step described above is true in our running systems, our written procedure for it has been approved, and this page says so. When we first use it, we will update this page's version line.

10. Indicators we send to your device

The same collected text contains the infrastructure criminals use: phishing domains, command-and-control addresses, malicious file hashes. We extract these automatically, guard against mistaking a victim's own domain for an attacker's, and put each candidate in front of an analyst with full-admin rights, who must approve it individually and name the kind of threat it is; there is no bulk approval. Approved indicators go into the signed threat list your device already verifies before use. Indicators classed as phishing or malware distribution are blocked silently on your device; any other kind raises a high-severity alert when your device sees it. Approvals expire and are re-reviewed; an analyst can revoke one at any time. This feed carries only attacker infrastructure — never an e-mail address, phone number, handle, credential or victim's domain. Your device reports back only that a listed indicator was blocked, not what you were doing.

As of this version, the extraction and analyst review are running, but the switch that adds these indicators to the list sent to devices is off: your device receives our existing threat list only. We will update this page's version line when we turn it on.

11. Illegal content

Anyone who crawls the dark web will, sooner or later, encounter material that is illegal to possess, above all child sexual abuse material. We treat this as the most serious risk in what we do. Our crawler fetches text only and discards everything else at the point of fetch, so such material should never land on our systems; section 9 describes the additional check on published archives. If an analyst nevertheless encounters it, our written procedure is to keep only the address, time and a hash, to report it to the police and the National Cybercrime Reporting Portal (and to CERT-In where relevant) within 24 hours, to destroy the item, and to log that we did so. This is what Indian law requires of any person who comes across such material, and we would do it regardless.

We are honest about a residual risk: a crawler that discovers new sites can reach places we would not have chosen to send it. We have chosen discovery, filtered by an automated classifier and a human approval of every source, over a hand-curated list, because the sites that matter change weekly. We accept that trade-off knowingly, and the controls above are what make it acceptable.

12. Platform terms

Where a source is a platform with terms of service, we follow those terms, as every reputable vendor in this field must. We read Telegram only through its official API, with an account registered to CodeSire, and only public channels; we do not join invitation-only groups and the account never posts. Where a platform's terms prohibit crawling without permission, we do not crawl it: that currently rules out X and Meta's services except through official, licensed routes, and it means we have no open-web or social-media coverage today. Where a platform restricts what may be done with its content using AI, we respect that too, and use rule-based matching. If we add open-web sources, our crawler will honour robots.txt, identify itself, and be rate-limited, and this page will say so.

13. Other people in what we find

Your family, household and colleagues. You may want us to watch for people close to you. These are the rules that will apply when we switch this on (section 2); no one other than you is watched before then. There are exactly four ways a person can be watched. You can nominate yourself. You can nominate another adult, but we do not watch for them until they have given their own consent through a link from us, and they can withdraw it independently of you at any time. You can nominate an adult member of your household or office without their prior consent only by certifying the relationship and the reason you believe they are at risk; we record that certification, we tell the person the first time we alert you about them, and a false certification can end your subscription. We do not accept nominations of anyone under eighteen until we have a verifiable parental-consent process that meets Indian law, and we refuse to watch anyone who is not you, a consenting adult, or a certified member of your household or office. Monitoring a person who has no connection to you is not a service we will provide.

Other victims. Leaked material about you will usually sit alongside material about thousands of other people. We do not extract, index in plaintext, or show you any of it. If a file contains your data and another person's, you see yours.

Threat actors. Chatter about you will name the people talking. We keep their handles, wallet addresses and channel identifiers, one-way coded, in a separate store with its own key, for the period in section 8, and we hand that information to police or CERT-In on a lawful request. You see the handle and where we saw it, nothing more. We do not publish it and we do not contact them.

Threats and doxxes. If someone has published threats, insults or private details about you, we will show you what was said, because you need to know. We show it to you alone, with third parties redacted, without images, and we do not forward it anywhere else.

14. Am I in your index? Removal

Because our index holds one-way codes rather than identities, we cannot look you up by name. If you send us the exact identifier (an e-mail address, phone number or handle) and confirm you control it, we can tell you whether it is present and, if you ask, remove it. Removal makes the identifier unsearchable within SireShield; it does not remove the underlying leak from the place we found it, and it cannot, because we did not put it there. It also means we will not be able to warn you if that identifier appears again. Write to privacy@codesire.net; we aim to respond within 14 days and will always respond within the period Indian law requires. The same address is our grievance route under the Digital Personal Data Protection Act, and our Grievance Officer is the Director of CodeSire Private Limited, at the registered address given in our Privacy Policy.

15. Requests from authorities

We will comply with lawful demands from Indian police, courts and CERT-In. "Lawful" means a written order citing the legal provision it is made under, from an officer entitled to make it. Our rule is to produce the minimum that satisfies the order — a record of what was published before raw text, raw text only where the order squarely requires it, and never the one-way-coded index itself — and to decline informal requests and redirect them to the formal route. We commit to keeping a register of every demand we receive and how we answered it, and to publishing the count on our Trust & Transparency page once a year, starting with the count to date. We do not have, and will not build, any capability for authorities to query our systems directly.

Separately, and voluntarily, when our crawler surfaces a significant leak affecting Indian organisations or the public we may notify CERT-In or the relevant sectoral CERT, using only derived information (what was published, where, when and in what volume), never personal data. The CERT-In Directions of 2022 also bind us: an incident affecting our own systems must be reported to CERT-In within six hours, the logs they name must be kept in India for 180 days, and our systems' clocks must follow the national time source. We treat those as minimums.

16. Organisations named on leak sites

If your organisation appears on a ransomware victim list and you are not our client, we have no obligation to tell you and, usually, no lawful way to contact you at scale. What we can say is this: if a verified officer of your organisation approaches us, we will tell you what we observed and when — the listing and the total count, nothing further — at no charge, and we will not use the occasion to sell you anything. If your organisation is the employer of a subscriber whose work domain they nominated, the subscriber will have been told that we watch that domain, and we will tell them that a record exists which you may ask us for; we will not volunteer your data to them or theirs to you.

17. What we cannot promise

18. Contact and changes

Questions about this page, removal requests, grievances, and lawful demands from authorities: privacy@codesire.net. Security researchers who find a problem in our systems: the same address; we will not pursue good-faith research.

We will change this page as the law and our systems change, in particular when the Digital Personal Data Protection Act comes fully into force in May 2027, when we switch on chatter monitoring or the indicator feed (section 2), when we first retrieve published files under section 9, when each deletion in the section 8 table starts running, if we add a category of source, and when we begin serving subscribers outside India. Every version is dated, and material changes are announced on our Trust & Transparency page. If we cannot keep to something written here, we will change the page rather than quietly stop doing it.