This Policy describes how Stealed SAS ("Stealed", "we") collects, uses, retains, discloses and protects personal data across the stealed.io website, the application, the APIs and related services (the "Platform").
It covers two distinct processing activities, and the distinction matters: the building of our Corpus, for which we act as controller, and the monitoring of a customer's perimeter, for which we act as that customer's processor. Section 2 sets out this split.
Stealed detects compromised corporate credentials already circulating in criminal ecosystems, and alerts the organisation that legitimately owns the affected domain so that it can protect itself. We do not hack anyone, we never test a credential, and we allow no one to search for data outside their own perimeter.
We collect and index login credentials exposed in data breaches and criminal ecosystems. For this activity, Stealed is the controller.
Legal basis: legitimate interest (Article 6(1)(f) GDPR), as recognised by Recital 49, which expressly designates network and information security as a legitimate interest, including for providers of security technologies and services. A written legitimate interest assessment documents this balancing test.
When a customer entrusts us with monitoring its domains, that customer is the controller and Stealed is a processor within the meaning of Article 28 GDPR. A search mandate formalises the customer's instruction and defines the perimeter. Where the customer works through an integration partner, the contractual chain cascades: the customer authorises its partner in writing to engage Stealed as a sub-processor.
| Processing | Stealed's capacity | Legal basis |
|---|---|---|
| Building and maintaining the Corpus | Controller | Legitimate interest, Art. 6(1)(f) |
| Monitoring the declared perimeter | Processor for the customer | The customer's legitimate interest |
| Platform user accounts | Controller | Performance of the contract |
| Exposure diagnostic and pre-contractual demonstration | Controller | Legitimate interest, Art. 6(1)(f) |
| Commercial management and billing | Controller | Contract and legal obligation |
Data can be collected, retained and disclosed, and these three states are independent. A log produced by malware is captured exactly as that malware produced it: we do not choose what it contains. Most of the categories below are collected and retained without ever being disclosed to anyone.
| Category | Collected | Retained | Disclosed |
|---|---|---|---|
| Credentials: login, password, service | Yes | Yes | Yes, password masked by default |
| Session cookies | Yes | Yes | Under development |
| Application tokens | Yes | Yes | Under development |
| Secrets and environment variables | Yes | Yes | Under development |
| Compromised machine fingerprints | Yes | Yes | Partially, as investigation context |
| Credential / machine correlation | Yes | Yes | Not used to date |
| Operating system credentials | Yes | Yes | Not used to date |
| Autofill data | Yes | Yes | Not used to date |
| Browsing history | Yes | Yes | No security use, not intended for disclosure |
| Payment card data | Yes | Yes | No security use, not intended for disclosure |
We state this distinction rather than a general claim of non-processing, which would be inaccurate: minimisation is effective at disclosure, it is not yet effective at collection or retention. What to do with the categories collected but not disclosed is covered by the retention plan described in paragraph 8.
The categories that directly extend the security purpose, session cookies, application tokens, secrets and environment variables, are under development: a valid session cookie bypasses authentication and second factor as surely as a password, and an exposed secret opens an entire system. They will not go live before our counsel has advised on the conditions of such disclosure. Categories with no security use for the monitored organisation, chiefly browsing history and payment card data, are not intended to be disclosed.
Leak data originates from breaches already in circulation, never caused by us. Collection is automated, continuous, and operated by our own processing chain, today on semi-public distribution channels. Other families of sources are being integrated, and each is assessed before being connected. The detail is set out in the collection policy.
We do not buy any data and depend on no data broker. We pay no actor to obtain a dataset, whether directly or through a third party. The origin of each source is documented in an internal register.
The origin of the data, the sources monitored, what Stealed refrains from doing and the procedure applicable to any extension of collection are described in detail in the collection policy, which is binding on Stealed.
We do not disclose the exact identity of our sources: a disclosed channel is a lost channel, which would deprive all of our customers of detection. Customers receive a qualitative categorisation of the source, never its name, its link, or access to the original archive, which contains data concerning third-party organisations.
Leak data is never used for named prospecting. No individual appearing in the Corpus is contacted commercially on that basis.
Individuals whose credentials appear in our Corpus did not provide us with their data and do not necessarily have a reliable contact channel, that data having been exfiltrated by malicious third parties and involving very large volumes. Informing them individually would involve disproportionate effort within the meaning of Article 14(5)(b) GDPR.
This section constitutes the public information required by that provision, as a compensating measure. The safeguards applied are: no public access to the Corpus, no free-search capability, disclosure restricted to the verified owner of the domain concerned, secrets never displayed in clear, data minimisation, and the retention periods set out in section 8.
Any individual may exercise their rights by writing to privacy@stealed.io. Certain requests may be restricted by compelling legitimate grounds relating to security; where this applies, we explain the reasons.
The model is one of targeted disclosure, not a search engine. In practice:
The extent of accessible data is determined by the customer's state, never by the type of action. The more identifying the data disclosed, the stricter the framework required. No state is stored: each is derived from recorded facts, and therefore cannot be forced by hand.
| State | What is accessible | Duration |
|---|---|---|
| Under analysis | Aggregated indicators only, exposure score and volumes. No identity, not even masked. No customer is created. | 24 hours, then referenced or erased |
| Referenced | Daily indicators and a sample whose identity is masked server-side. No credential is routed to a workspace. Password locked, the display function does not exist. | For as long as the customer is referenced |
| Monitored | Real monitoring, reserved for Stealed's internal workspaces. | No commercial clock |
| POC | Detail of the perimeter's occurrences: credentials, hosts, dates, recurrence. Conditional on attestation of a customer mandate. | 15 days, extendable on a logged reason |
| Billed | Same detail. In operated mode the provider alone uses the workspace; in autonomous mode the customer has their own. | Contract term |
| Archived | Workspace closed, perimeter data deleted. Logs remain. | — |
The raw source file is not retained: it is analysed, the useful information is extracted, and it is then deleted. Retention is then organised in three layers:
| Category | Period |
|---|---|
| Downloaded source archive | Deleted immediately after analysis |
| Ingestion and routing tables (global scope) | Short lifetimes, automatic purge |
| Credential registry and normalised extracts (global scope) | No time limit to date. A retention plan is established, see below |
| Data attached to a customer's perimeter | For as long as the domain is monitored. Automatic and immediate deletion when the domain is removed or the relationship ends |
| Domain submitted for exposure diagnostic | Purged within twenty-four hours, unless an account is created |
| Account data | Duration of the contractual relationship, then applicable statutory periods |
| Decision and consultation logs | Durable for decisions, sensitivity-indexed for consultations |
The precise periods applicable to each category are documented and disclosed to customers and partners under the contractual framework. The detail is set out in the security policy.
Account data is retained for the duration of the contractual relationship, then for the applicable statutory periods. Technical and consultation logs are retained according to their sensitivity.
A retention plan is established for the global-scope stocks, to replace the absence of a limit with a determined period on the secret held in clear, the credential and the domain remaining necessary for detection. The period will be established by measurement rather than set arbitrarily. That plan is not yet executed, and this page will be updated when it is. Conversely, deletion of the data attached to a customer's perimeter is structural: it depends on no task to trigger and no delay.
Leak data, which is the core of the service, is hosted and processed in France, on the infrastructure of a French provider, in the Paris region, with no exposure to extraterritorial legislation such as the CLOUD Act. Its encrypted backups are held there too. No leak data leaves French territory.
Certain peripheral functions, which process no leak data, rely on providers established outside the European Union: user authentication for the Platform, and the sending of notification emails, both of which involve account and contact data. The authentication provider does not offer hosting in the European Union. These transfers are governed by an EU-US Data Privacy Framework certification and by the European Commission's standard contractual clauses. The Sub-processors page states, for each provider, its hosting region and the applicable mechanism.
The full list of our sub-processors, their role, their location and the categories of data involved is published on our Sub-processors page, which is kept up to date.
The technical and organisational measures, each with its actual deployment status, are set out in the security policy. In summary:
You have the rights of access, rectification, erasure, objection, restriction and portability, under the conditions set out in the GDPR. Requests should be sent to privacy@stealed.io.
You also have the right to lodge a complaint with the French data protection authority (CNIL), www.cnil.fr, or with your local supervisory authority.
The Platform is intended exclusively for professionals and is not directed at individuals under eighteen. We do not knowingly collect account data concerning minors.
This Policy may be revised. Any substantial change is signalled on this page by an update to its date, and communicated to customers under contract.
Related documents: collection policy, security policy, sub-processors, cookies, acceptable use, terms of use.