This policy describes the technical and organisational measures implemented by Stealed pursuant to Article 32 of Regulation (EU) 2016/679. It is binding and forms an integral part of the contractual set.
Each measure is marked "in production" or "being deployed". No measure being deployed may be presented as achieved, in any document whatsoever, before it is effectively in production. That rule applies to our own sales material.
| Area | Measure | Status |
|---|---|---|
| Encryption | Encryption in transit (TLS 1.2 minimum), encryption of storage at rest and encryption of backups | In production |
| Encryption | Separation of keys and data, periodic rotation, storage in a secret manager, never in clear | In production |
| Access | Mandatory multi-factor authentication for all administrative access | In production |
| Access | Least privilege, role-based access control, entitlement review at least twice a year | In production |
| Traceability | Durable logging of decisions, with no purge and no cascade, identifying the author, their address and the timestamp | In production |
| Traceability | Logging of consultations, with retention indexed on the sensitivity of the data consulted | In production |
| Architecture | Strict multi-tenant segregation, no data flow between organisations | In production |
| Architecture | Network segmentation, filtering, monitoring and alerting on security events | In production |
| Architecture | Push disclosure model: no access to the corpus, no free search, no query on an unmandated perimeter | In production |
| Continuity | Encrypted backups, held in France, periodically tested, documented restore procedure | In production |
The password is masked by default, in the interface as in the API: first and last character, plus the real length. Below six characters the value is fully masked, since showing the ends of a four-character password gives away half of it. This masking publishes the length: it accompanies the conditions below, it does not replace them, and it must not be presented as strong protection.
Reading in clear exists, for one reason only: a victim organisation can only prioritise its remediation by knowing whether a credential is genuinely its own and whether it is still in force. Total masking leads in practice to treating every line the same way, hence to treating none. It requires three cumulative conditions, checked on every read.
| Condition | Content |
|---|---|
| 1. Domain opened | By DNS proof, or by a Stealed grant on reasoned request for an owner unable to publish a record. A provider can never open a domain itself: its attestation is enough to place a domain under monitoring, never to read its passwords. |
| 2. Customer authorisation | Where the read crosses an organisation boundary. A "Delegated management" setting in the customer's workspace, off by default, naming the provider explicitly, editable by a customer administrator only, revocable at any time with immediate effect. |
| 3. Administrator caller | On both sides. Consent is given to the organisation, and the organisation decides who within it may act on it. |
Through the API, reading in clear further requires a key carrying a dedicated right and an explicit parameter on the call. Every read is logged, with the number of rows revealed, the domains that authorised it and which route opened the door. A credential that is not covered returns "not found" rather than "forbidden", since "forbidden" would confirm its existence to anyone probing the corpus. If the domain store is unavailable, everything is masked: an outage never opens anything.
Two distinct and cumulative requirements govern access to an organisation's perimeter. Ownership answers "is this domain really this organisation's" and is proven technically. The mandate answers "does this provider have instructions to act on it" and is proven legally. Neither replaces the other.
| Status | Meaning | Monitoring | Clear read |
|---|---|---|---|
| Pending | The domain has been added, nothing is proven | No | No |
| Validated | Ownership accepted without DNS proof, on a partner's attestation or by Stealed decision | Yes | No |
| Verified | Ownership proven by a TXT record published in the DNS zone | Yes | Yes |
The distinction between validated and verified is deliberate: accepting an attestation to place a domain under monitoring is a bounded risk, accepting one to hand over passwords is not.
DNS proof is the normal route. Where publishing the record is not possible, for whatever reason, DNS managed by a third party, IT lead time or internal constraint, the domain may be validated by Stealed once we have satisfied ourselves that it belongs to the organisation. That route places the domain under monitoring; it does not open a cleartext password read, which is its own decision.
One distinction structures this section. A global stock covers the whole corpus and must justify itself. A customer stock is bounded to an established perimeter and is justified by the relationship. The precise periods applicable to each category are documented and disclosed to customers and partners under the contractual framework.
| Category | Period |
|---|---|
| Downloaded source archive | Deleted immediately after analysis. What remains is a normalised extract, never the published file |
| Ingestion and routing tables (global scope) | Short lifetimes, automatic purge with no intervention |
| Credential registry (global scope) | No time limit to date. A retention plan is established, described below |
| Normalised extracts on object storage (global scope) | No time limit to date. Not required by any product function |
| A monitored organisation's perimeter (customer scope) | For as long as the domain is monitored. Automatic and immediate deletion when the domain is removed or the relationship ends |
| Decision logs | Retained durably, with no purge |
| Consultation logs | Retention indexed on the sensitivity of the data consulted |
| Aggregated statistics with no identifier | Retained indefinitely |
All deletion is carried out by overwriting or destruction of the medium, not by mere logical deletion, with written confirmation where the contractual set requires it.
Deletion of a customer's perimeter is structural, tied to the routing mechanism itself. It depends on no task to trigger, no delay and no declarative undertaking on our part.
A retention plan is established for the global 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, by cross-referencing the collection date of a credential with the date of the last password change on the account concerned, without any password ever being tested. That plan is not yet executed, and this page will be updated when it is.
Stealed currently holds no SOC 2 or ISO/IEC 27001 certification and claims no such qualification. The hardening baseline adopts their criteria, which is not a certification.
Leak data is hosted and processed in France, with Scaleway SAS, in the Paris region (fr-par), and its encrypted backups are held there too. No third party accesses it, and no leak data leaves French territory.
Technical providers support peripheral functions and never process leak data, only account and contact data. Their up-to-date list, location and safeguards are on the Sub-processors page. Where such a provider is established outside the European Union, its processing of account and contact data falls under the law of its country of establishment, which this policy states without reservation.
For any export or data taken out of the Platform, the customer implements at minimum:
Each party notifies the other, without delay and at the latest within forty-eight hours of becoming aware of it, of any security incident affecting the data concerned, stating its nature, estimated scope, the categories of data and individuals affected and the measures taken or contemplated. That period is shortened for financial entities within the meaning of Regulation (EU) 2022/2554 (DORA) and for important or essential entities within the meaning of Directive (EU) 2022/2555 (NIS 2), under the corresponding addenda.
Anyone may report a vulnerability affecting the Platform or Stealed's services to [email protected]. Stealed acknowledges receipt within three business days, investigates, keeps the reporter informed and publishes a security advisory after remediation where appropriate.
Stealed undertakes to bring no civil or criminal action against a good-faith reporter who refrained from accessing data beyond what was necessary to demonstrate the issue, from affecting service availability, from demanding consideration, and from making the vulnerability public before it was fixed. Reporting to the French national authority under Article L. 2321-4 of the Defence Code remains open to the reporter.
Stealed fixes the vulnerability within a timeframe proportionate to its severity. The reporter regains freedom to publish ninety days after their report, or earlier if Stealed confirms the fix.