Privacy

Who is responsible

Declarable is run from the UK by one person. For your account data we are the controller under UK GDPR. Write to privacy@declarable.io to ask what we hold, to correct it, or to have it deleted.

What we store

• The free tools. The SBOM check reads your file in your browser. To look up known vulnerabilities, it sends component names, versions and identifiers (not the file) to our server, which asks the public vulnerability databases named below.
• An account. Your email, your name if you give one, your organisation, and its members and roles. If you set a password, it is kept only as a one-way hash that we cannot read back.
• Your sign-ins. The IP address and browser of each device you sign in from, so you can see and end your own sessions. Each record is deleted 30 days after that session ends.
• The activity log. Who in your organisation did what and when, with a scrambled fingerprint of the IP address it came from, never the address itself. It is kept for 2 years, even after the organisation is deleted, so a past change can still be explained.
• Extra alert addresses. Email addresses your organisation adds to receive its vulnerability alerts without being a member. The same addresses get its reminders: an Article 14 reporting deadline, a support period ending, a security.txt file expiring. Each stays until your organisation removes it or the organisation is deleted; the person can unsubscribe from any alert email.
• Your customers' contacts for an incident. If you upload a list of the customers you must inform about an incident, we keep their names and email addresses with that incident: until you remove them, until 30 days after you close the incident, or until your organisation is deleted, whichever comes first. We never email them ourselves.
• Webhook addresses. The Slack or other web addresses you ask us to post alerts to, and their signing secret, encrypted, until you remove them or the organisation is deleted.
• Why you cancelled. When an owner schedules a cancellation, we ask why. We keep the reason you picked from a short list, up to 500 characters of what you wrote if you wrote anything, which person answered, and when. Only an owner is asked. “No thanks” is kept too, as an empty “other”, so we do not ask again. It is deleted with your organisation and is in your data export.
• Payment events. A record of each payment event Paddle sends us: the event, the subscription and transaction it concerns and their state, the plan and billing period, the amounts, and the account id of the person who started the checkout. No card details. It is kept after your organisation is deleted, for as long as the accounts require.
• Plan limits you hit. Each time your plan or a limit stops an action, we record which limit, why, and when against your organisation, with no person on the row, so we can see which limits get in the way. It is deleted with your organisation.
• Error reports. When something breaks, a report saying what broke and where goes to our error tracker (Sentry). Error reports we receive when something breaks do not include request bodies, cookies, authorization headers or the email address on your account.
• Page counts. Our analytics (Plausible) count page views without cookies. Plausible receives the page address and, as any site you load does, your IP address and browser. We do not store either.
• Your products. The SBOMs and configuration files you upload, the components parsed from them, and what you record about vulnerabilities, incidents and documents.
• A page report. If you use “Report a page”, we keep your message, the page you reported, and, if you gave one, your email address. We also keep a scrambled fingerprint of the IP address it came from, never the address itself. We keep it until the report is resolved and then reviewed.
• Emails we could not send. When an email to you is refused, we keep a one-way hash of that address for 30 days, so we can see that the same address keeps being refused without being able to read what it is. This is pseudonymous, not anonymous: we could hash a known address and match it.

An SBOM lists what is inside a product and how old it is, so it shows an attacker where to look. We treat every upload that way: it is kept per organisation, and other customers cannot read it.

How long we keep it

We keep the SBOM or build file you upload for a release for 90 days, then delete it. Two kinds of file are kept longer: files you attach to your technical documentation (the set of documents the Regulation has you keep for each product) stay while that technical file exists, and the scan of a signed declaration of conformity is kept until the later of 10 years after signing and the end of the product's support period. The components parsed from a release file stay in your account until you delete the product or the organisation.

Cookies

We set only the cookies needed to sign you in and keep you signed in, and to remember which organisation you are working in. Our own support staff get one more, while they view an account to help its owner. We use no advertising or tracking cookies, and our analytics do not use cookies, so there is no banner.

A Cloudflare Turnstile check, to keep out bots, runs in three places: the “Check for known vulnerabilities” step of the free SBOM check, the “Report a page” form, and the sign-in page when you create an account, sign in with a password or ask for a sign-in link. The script loads from Cloudflare, so like any site you load, Cloudflare sees your IP address.

Vulnerability databases we ask

When you use the “Check for known vulnerabilities” step of the free SBOM check, our server sends the component names, versions and identifiers from your list, never the file, to up to three public vulnerability databases: OSV (run by Google), GitHub's advisory database, and ENISA's EU Vulnerability Database (EUVD). Which ones are asked depends on the identifiers each component carries. The request comes from our server, so they see the components but not your IP address.

Products you upload to an account are not sent to them. Uploads, and the nightly recheck of every product, are matched against our own copy of those databases, which we download on a schedule without naming any customer's components.

Who else handles it

Our hosting, database, email sender, payment processor, bot check, error tracker (Sentry) and page counts (Plausible) each process some of this data for us, and so does GitHub, which runs GitHub sign-in and keeps an encrypted copy of our backups. The full list, with what each one does and where its data lives, is on the sub-processors page.

Your rights

Under UK GDPR you can ask for a copy of your data, a correction, deletion, or to object to how we use it. If you are unhappy with our answer, you can complain to the Information Commissioner's Office (ico.org.uk).