Privacy Policy
What personal data we hold, why we hold it, who else touches it, and what you can make us do with it.
Last updated 20 August 2026
1. Who is responsible for your data
LockDep, Norway, is the data controller for the personal data described in this policy. In this document “StackRadar”, “we” and “us” mean that entity.
For anything to do with privacy — questions, requests, complaints — write to contact@stackradar.io.
2. What this policy covers
This policy applies to:
- the StackRadar website at
stackradar.io, including the docs and blog; - the StackRadar dashboard at
app.stackradar.io; and - the StackRadar API at
api.stackradar.io, which the scanner uploads to.
The StackRadar scanner itself runs inside your infrastructure and is controlled by you. What it sends us — and, just as importantly, what it never sends — is set out on the security page, which this policy incorporates by reference.
3. What we collect
Account data
StackRadar has no passwords. You sign in with GitHub or Google, and we receive from your chosen provider: your name, email address, profile picture URL and the account identifier at that provider. We also store the OAuth tokens the provider issues for your session (access, refresh and ID tokens, their scope and expiry), because that is how the link between your StackRadar account and your provider account is maintained.
We request only the minimum scope needed to identify you. We do not read your repositories, your Google account contents, or anything else on the provider side.
We also record which version of the terms of service you accepted and when— at sign-up, when you accept an organisation invitation, and when you confirm an updated version in the dashboard — and, where you act within an organisation, that the version was accepted on the organisation’s behalf, by whom and in what role. These records exist to evidence the contract between us. Your own acceptance record is kept for as long as your account; an organisation’s record is kept for as long as the organisation, though if you delete your account it no longer names you.
Session and sign-in data
Sessions are stored in our database rather than in a self-contained token, so they can be revoked server-side. We store a session identifier and its expiry. Sessions have a rolling 24-hour idle window: they extend while you are active and expire within a day of your last use.
Organisation and team data
We store your organisation’s name, its plan, and the membership list with each member’s role (owner, admin or member). When someone is invited to an organisation, we store the invited email address, the role offered, who issued the invite and an invite token, until the invite is accepted, cancelled or expires.
Scan data you send us
The substance of the service. Per scanned container image we receive and store a CycloneDX SBOM — package names, versions, licences, file paths inside the image and the image's own labels as the scanner records them. Alongside it we receive a workload inventory: cluster name, namespace, workload name and kind, container name, image reference and digest; an allowlisted set of well-known workload labels and Helm/ArgoCD attribution annotations; running-pod counts and first-started timestamps; Helm release names, chart names and versions; and ArgoCD application names, repository URLs (with any credentials redacted), paths and target revisions. The scanner also reports its own version and the cluster's Kubernetes version in a periodic heartbeat. The exact field list is on the architecture page.
This is normally infrastructure data rather than personal data, but it can contain personal data incidentally — a namespace or workload named after a person, for instance. Where it does, we process it as your processor, on your instructions, under the terms of service.
Billing data
Payments are handled by Stripe. Card details never reach our servers. What we store is the Stripe customer and subscription identifiers, the subscription status, the current period end and any scheduled cancellation date. Your billing name, address, tax identifiers and payment method live with Stripe, and you manage them through the Stripe billing portal we link to from the dashboard.
Technical logs
Our API writes request logs containing the HTTP method and path, response status, duration, a request identifier, the source IP address and the user agent. Known-sensitive headers, including API keys and authorisation headers, are redacted before anything is written. We keep these to operate the service, investigate faults and detect abuse.
Website and product analytics
The marketing site and the dashboard use PostHog, hosted in its EU region, configured to set no cookies and no identifier on your device. On the marketing site this gives us anonymous page counts and referrers; each visit is independent and we cannot recognise you across visits or across sites. In the dashboard, where you are signed in, usage events are associated with your account so we can see which features are used and where people get stuck. We do not use session recording.
What we do not do
- We do not send marketing email. The only email StackRadar sends is transactional: a welcome message when your account is created, and an invitation when someone adds you to their organisation. There is no newsletter and no drip sequence.
- We do not sell or rent personal data, and we never have.
- We run no advertising, profiling or automated decision-making, and no cross-site trackers. Our analytics processor acts only on our instructions and does not use your data for its own purposes.
4. Why we are allowed to process it
Under the GDPR our legal bases are:
- Performance of a contract (Art. 6(1)(b)) — account data, session data, organisation data and scan data. Without them there is no service to provide.
- Legitimate interests (Art. 6(1)(f)) — technical logs and aggregate analytics, for keeping the service up, secure and free of abuse. We have weighed this against your interests; the data is minimal, retained briefly, and never used to build a profile of you.
- Legal obligation (Art. 6(1)(c)) — invoices and payment records we are required to keep for accounting and tax purposes.
5. Who else processes your data
We use a deliberately short list of subprocessors. Each is bound by a data processing agreement and may only act on our instructions.
| Subprocessor | Purpose | Location |
|---|---|---|
| DigitalOcean | Application hosting, database, backups | Frankfurt, Germany (EU) |
| Stripe | Payment processing and subscription billing | EU / United States |
| PostHog | Cookieless analytics for the marketing site and the dashboard | EU |
| Resend | Sending transactional email (welcome, organisation invitations) | EU / United States |
GitHub and Google act as your identity providers when you sign in. They are not our processors — their handling of your account is governed by their own privacy policies — but signing in necessarily tells them you authenticated to StackRadar.
Beyond this, we disclose personal data only where we are legally compelled to, or to establish or defend legal claims. If we are ever served a request for your data and are not prohibited from telling you, we will tell you.
6. Where your data is processed
All application data — your account, your organisation and every SBOM you upload — is stored and processed on servers in Frankfurt, Germany. There is no replication to a non-EU region.
The one transfer outside the EEA is Stripe, which may process billing data in the United States under the European Commission’s Standard Contractual Clauses. No SBOM content and no scan data is sent to Stripe.
7. How long we keep it
- Account, organisation and scan data — for as long as your account exists, and for 30 days after you close it, after which it is deleted from live systems.
- Backups — retained on a rolling 7 days, so deleted data can persist in a backup for that long after deletion before it ages out.
- Technical logs — 30 days.
- Billing records — for the statutory accounting retention period in Norway, which overrides a deletion request for those records specifically.
A note on plan history windows. Your plan determines how far back your history reaches — 30 days on Free, one year on Pro, two years on Business. The window is a real retention schedule: trend snapshots and scan records older than it are deleted by a periodic sweep, and the SBOM of an image you have stopped running is deleted once it ages past the window. The SBOM of an image that is still running is different — that is your current inventory, and we keep it for as long as the image is deployed, on every plan. If you want any of it erased sooner, ask us and we will erase it.
8. Your rights
If you are in the EEA or the UK, you have the right to:
- access the personal data we hold about you, and get a copy of it;
- have inaccurate data corrected;
- have your data erased;
- restrict or object to processing based on our legitimate interests;
- receive your data in a portable, machine-readable format; and
- lodge a complaint with a supervisory authority — for us, Datatilsynet (the Norwegian Data Protection Authority) — though we would rather you came to us first.
Exercise any of these by emailing contact@stackradar.io from the address on your account. We respond within 30 days and we do not charge for it.
Deleting your account. There is currently no self-serve delete button in the dashboard — closing an account is a request to the address above, and we act on it. We will say so on this page until the button exists.
9. How we protect it
All traffic runs over TLS. Sessions are database-backed and therefore revocable server-side. Each cluster authenticates with its own scoped API key, which cannot be used to write data attributed to another cluster and can be revoked independently. Sensitive headers are redacted from logs. The full picture, including how the scanner itself is signed and attested, is on the security page.
If we suffer a personal data breach that is likely to result in a risk to your rights, we will notify the supervisory authority within 72 hours and tell you without undue delay where the risk is high.
10. Cookies
StackRadar sets no advertising or analytics cookies, which is why you see no cookie banner. The only cookies we set are the ones the dashboard needs to function:
| Cookie | Purpose | Lifetime |
|---|---|---|
authjs.session-token | Keeps you signed in. Strictly necessary. | Rolling 24 hours |
authjs.csrf-token | Cross-site request forgery protection. Strictly necessary. | Session |
authjs.callback-url | Returns you to the right page after sign-in. Strictly necessary. | Session |
sr_org_id | Remembers which organisation you were last viewing. Validated against your actual memberships on every request, so it grants no access by itself. | 1 year |
In production the Auth.js cookies are issued with the __Secure- or __Host- prefix and the HttpOnly flag.
11. Children
StackRadar is a tool for professional software teams and is not directed at children. We do not knowingly collect data from anyone under 16. If you believe a child has given us data, tell us and we will delete it.
12. Changes to this policy
We will update this page when our practices change, and move the “last updated” date at the top. For changes that materially affect your rights we will give notice in the dashboard before they take effect. The current version always governs.
13. Contact
LockDep, Norway. Privacy enquiries: contact@stackradar.io. Security reports: security@stackradar.io.