Privacy Policy

Section 1Who we are and how to reach us

0DaySecure builds an external threat intelligence platform with three modules: dark web monitoring, attack surface management and brand protection. This policy is issued by [COMPANY LEGAL NAME], a company registered in [COUNTRY OF INCORPORATION] under number [COMPANY NUMBER], with its registered office at [REGISTERED ADDRESS].

For anything to do with personal data, write to support@0daysecure.com or to the postal address above. Our data protection contact is [DATA PROTECTION CONTACT ROLE OR NAME].

Section 2What this policy covers

This policy covers personal data we handle as a controller: information about people who visit this website, ask for a demo, correspond with us, apply for a job, or use the platform as a named user.

It does not describe what we do with the data our customers put into the platform, or with the intelligence we collect on their behalf. For that material we act as a processor under the customer contract and the data processing agreement that sits alongside it. Sections 5 and 6 explain how that material is handled, because it is the part of our processing most likely to involve other people’s personal data.

Section 3The data we collect and why

Website visitors

Pages on this site are served without third-party trackers. Our hosting and edge provider records ordinary server logs — IP address, timestamp, requested URL, user agent, response status — for delivery, abuse prevention and debugging. We do not use those logs to build a profile of you and we do not enrich them with data from other sources.

Demo requesters and other enquirers

If you complete the demo form or email us, we collect the details you send: name, work email address, organisation, job title, the domains you want us to look at, and whatever you write in the message field. We use it to reply, to prepare the demo, and to keep a record of the conversation. If you ask us to run a scoped demo on your own domains, the findings from that exercise are treated the same way as customer intelligence data under section 5.

Platform users

When your organisation buys the platform, an administrator creates accounts for named users. For each user we hold an email address, a display name, a role, authentication metadata (including single-sign-on identifiers where SSO is used), notification preferences, and an audit record of security-relevant actions — sign-ins, permission changes, scope changes, and who viewed or exported a finding.

Billing and contractual contacts

We hold the names, business addresses and email addresses needed to raise invoices, run subscriptions and administer the contract. Card details are handled by our payment provider; we do not store full card numbers.

Job applicants

If you apply for a role we process your application materials and interview notes for the purpose of that recruitment process. Retention is covered in section 9.

Section 4Lawful bases for processing

Where the UK GDPR or the EU GDPR applies, we rely on the following bases.

Section 5Data we collect about your exposure

This section is specific to what our product does, and it deserves a plain explanation rather than a generic paragraph.

When a customer puts a domain, brand name or IP range in scope, we go and look for material about that organisation in places attackers use. That includes credential dumps and combolists, ransomware leak sites, access-broker adverts, data-for-sale postings, paste sites, code repositories, mobile app stores, certificate transparency logs, domain registration feeds and public DNS. The material we bring back is evidence about the customer’s exposure. Some of it contains personal data.

What that material typically contains

• Email addresses and usernames belonging to the customer’s staff, contractors and sometimes their customers, appearing in a leaked dataset.
• Credential material — password hashes, and in some breach data, plaintext passwords.
• Contextual detail from the source — the name of the breach or the marketplace, the date it appeared, the seller or actor handle, the asking price, and the claims made about the data.
• Technical fingerprints — hostnames, IP addresses, open ports, TLS certificate details, software versions, and screenshots-as-text of what a service returns.
• Impersonation evidence — lookalike domains, phishing page content, counterfeit app listings, and the public profile details of accounts impersonating the customer or its staff.

How we limit it

• We collect against a scope the customer has declared and warranted it is authorised to include. We do not run open-ended collection on organisations that are not customers.
• We collect what is needed to make a finding actionable and no more. Where a leaked record contains fields irrelevant to the finding, our aim is to discard them at ingest rather than store them and filter on display. [CONFIRM AGAINST THE INGEST PIPELINE]
• We do not attempt to authenticate to any system using credential material we find, and we do not test found credentials against live services — the customer’s or anyone else’s. [CONFIRM THIS IS AND STAYS TRUE]
• Findings are visible only to the customer they concern. Intelligence is not pooled across customers in a form that exposes one customer’s data to another.
• Access to raw collected material inside 0DaySecure is restricted to the engineers and analysts who need it, and every access is logged.

If you are named in someone else’s findings

You may be reading this because your email address appeared in a breach dataset and an organisation using our platform told you so. In that situation we are the processor and that organisation is the controller. We cannot delete a record from their tenant on your instruction alone, and we will not act on a request that would destroy a customer’s security evidence without their involvement. Contact us and we will route the request to the right customer and support them in answering it. Section 10 explains how.

Section 6How we handle leaked credentials

Leaked credential material is the most sensitive thing we hold, so we treat it differently from the rest of a finding.

• Stored separately and encrypted. Credential material is held in a restricted store, encrypted at rest, apart from the finding metadata that references it.
• Masked by default in the interface. A password is shown as a masked value with its length and character-class shape, which is enough for an analyst to judge the risk. Full reveal is a separate, permissioned action.
• Every reveal and export is logged. The audit record names the user, the finding and the time, and it is visible to the customer’s administrators.
• Not sent in notifications. Alert emails, chat messages and webhook payloads carry a link to the finding, not the credential itself.
• Reduced to a hash where we can. Where a workflow only needs to know whether a password matches a known leak, we aim to keep a hash rather than the plaintext. [CONFIRM WHICH WORKFLOWS THIS COVERS]

Section 7Sub-processors

We use a small number of third parties to run the platform and the business. Each one is bound by a written agreement, is given access only to what its function requires, and is assessed before it is engaged.

The table below is a placeholder and must be completed before launch. Customers are entitled to know exactly who processes their data, where, and for what.

We will publish material changes to this list, and give customers notice of a new sub-processor with an opportunity to object, on the terms set out in the data processing agreement.

Section 8International transfers

Our infrastructure runs in [PRIMARY HOSTING REGIONS]. Some of our sub-processors are established outside the UK and the European Economic Area, which means personal data may be transferred across borders.

Where we transfer personal data out of the UK or the EEA to a country without an adequacy decision, we rely on the European Commission’s Standard Contractual Clauses, the UK International Data Transfer Addendum, or another lawful transfer mechanism, and we carry out a transfer risk assessment for the arrangement. Copies of the mechanism relied on for a given sub-processor are available to customers on request.

Section 9How long we keep data

We keep personal data only as long as we have a reason to. The periods below are drafting placeholders and must be set to real values that the platform actually enforces.

Backups are kept on a rolling cycle and are overwritten in the ordinary course, so a deletion may persist in a backup for a short period after it takes effect in the live system.

Section 10Your rights

If the UK or EU GDPR applies to you

You have the right to:

• ask what personal data we hold about you, and get a copy;
• have inaccurate data corrected;
• have data erased, where we no longer have grounds to keep it;
• restrict or object to processing we carry out on the basis of legitimate interests;
• receive data you gave us in a portable form, where processing is based on consent or contract;
• withdraw consent at any time, where consent is the basis;
• complain to a supervisory authority — in the UK, the Information Commissioner’s Office; in the EEA, your national authority.

If you are a California resident

Under the California Consumer Privacy Act as amended by the California Privacy Rights Act, you have the right to know what personal information we collect and the categories of third parties we disclose it to, the right to delete, the right to correct, the right to limit the use of sensitive personal information, and the right not to be discriminated against for exercising any of them.

We do not sell personal information, and we do not share it for cross-context behavioural advertising. We collect personal information from business contacts and platform users for the purposes described in section 3. You may use an authorised agent to make a request; we will ask for proof of authorisation.

How to make a request

Email support@0daysecure.com with enough detail for us to find your records. We will acknowledge within [N] working days and respond within the statutory period — one month under the GDPR, 45 days under the CCPA — and tell you if we need an extension. We may need to verify your identity first, and we will not use the information you give us for verification for anything else.

If your request concerns data held in a customer’s tenant, see the last part of section 5.

Section 11Cookies and analytics

This website loads no third-party analytics, no advertising pixels and no social media trackers. Fonts are self-hosted and served from our own domain, so viewing a page does not send a request to a font provider. There is no cookie banner because there is nothing to consent to.

The signed-in platform application uses strictly necessary cookies to keep you logged in and to protect forms against cross-site request forgery. These cannot be switched off without breaking authentication.

Section 12How we protect data

Personal data is encrypted in transit and at rest. Access inside the company follows least privilege and is granted by role, with administrative actions logged. Single sign-on with SAML is available for customer tenants. Our security page sets out our practices in more detail, including how sensitive intelligence material is segregated, and how to report a vulnerability to us.

We do not currently hold a formal compliance certification. We say so plainly rather than implying otherwise, and this policy and the security page will be updated when that changes.

If a personal data breach occurs and it presents a risk to individuals, we will notify the relevant supervisory authority and affected customers without undue delay, and in any case within the periods the applicable law requires.

Section 13Children’s data

The platform is sold to organisations and is not intended for anyone under 16. We do not knowingly collect personal data from children through this website or through account creation. If you believe a child’s data has reached us by mistake, tell us and we will delete it.

Breach datasets collected during monitoring can, in principle, contain records relating to minors — for example where a customer operates a consumer service. That material is handled under the customer contract, with the minimisation rules in section 6, and is not used for any purpose beyond reporting the exposure to the customer.

Section 14Changes to this policy

When we change this policy we update the “last updated” date at the top of the page. If a change materially affects how we handle personal data, we will tell affected customers and users directly rather than relying on you to notice. Previous versions are available on request.

Section 15Contact and complaints

Write to support@0daysecure.com or use the contact form. If you think we have handled your data badly, tell us first — we would rather fix it. You can also complain to your supervisory authority, and nothing in this policy stops you doing that.

To report a security vulnerability, please use the process on our responsible disclosure page instead.