1. Controller
Cape K Solutions AB (see Contact); privacy contact [to be provided: privacy email].
2. What we process and why
- Account data (name, email): to perform our contract with you.
- Your workspace content and evidence: to perform our contract with you.
- Billing details and invoices: to perform our contract with you, and our legal obligation for bookkeeping.
- Security logs: our legitimate interest.
- Analytics: self-hosted Plausible, cookieless, no personal data.
3. Processors and where they are
- Clever Cloud SAS (France): hosting, databases, backups.
- Scaleway SAS (France): email delivery, analytics host.
- Mistral AI (France): the evaluation's language model, EU endpoint.
- Mollie B.V. (Netherlands): payments.
- The European Commission's VIES: VAT numbers.
Transfers outside the EU. Mistral's and Mollie's front ends run on Cloudflare (US) and Google (US) respectively; Google Workspace (US) for our own mailboxes; your own identity provider if you use single sign-on. [to be provided: transfer safeguards: SCCs or the EU-US Data Privacy Framework, per vendor]
4. Retention
Account data until you delete your account (erasure destroys the keys); backups roll off within 7 days; invoices [to be provided: invoice retention period] years (Swedish bookkeeping law).
5. Your rights
Access, rectification, erasure (My Account → Delete account), restriction, portability, objection; complaint to the Swedish Authority for Privacy Protection (IMY).
6. Cookies
The sign-in session cookie only (strictly necessary); no advertising or tracking cookies; analytics are cookieless.
7. Changes and date
[to be provided: date of this version]
How we protect your data
NormLens helps you prove compliance with the EU AI Act. It would be a poor advert for that if we were careless with your own data, so this section describes what we actually do — including the parts that are limits rather than features.
We try not to hold it in the first place
The strongest protection is not to have the data. Compliance documentation is about systems, not people, so NormLens rejects personal data at the point of entry: free-text you write into a compliance answer is checked before it is stored, and content that looks like personal data is refused with an explanation rather than quietly saved. This follows the data-minimisation principle in GDPR Art. 5(1)(c) and NIST SP 800-122.
What we do hold is deliberately small: who you are (name, email), which organisation you belong to, the compliance work you create, and billing details if you buy something.
Where it runs
All systems that manage customer data run within the EU and are not subject to the US CLOUD Act. They run on European providers, and we chose them for that reason rather than settling for it:
- Application and databases — Clever Cloud, France.
- AI evaluation — Mistral AI, EU-hosted. We send evaluation content to a European model provider, not a US one, so it does not fall within the reach of the US CLOUD Act.
- Analytics — Plausible, self-hosted by us in the EU. Cookieless, no advertising identifiers, no cross-site tracking, and no personal data: we never send your name, email, organisation or project names to it.
Everything is encrypted at rest — and the key is not in the database
Every piece of customer content and identity in our database is AES-256-GCM ciphertext: your evidence, your project context and answers, evaluation reports, certificates, audit history, your name, your email, your organisation's name.
What makes that meaningful is where the keys are. Encryption is worth little if the key sits beside the data — a stolen copy of the database would contain both. So:
- each organisation has its own key, and each person has their own key;
- those keys are not stored in the application database. They live in a separate database, wrapped by a single master key that is not stored in either.
A copy of our main database — stolen, leaked, or restored from a backup by someone who should not have it — therefore contains no evidence, no reports, no certificates, and no way to tell who any user or organisation is. It is a locked box with no key inside.
Deletion that is actually deletion
Most systems “delete” by removing rows. Rows can come back: from a backup, from a replica, from a snapshot taken the night before. We delete by destroying the key instead.
- Delete your organisation and its key is destroyed. Its projects, evidence, evaluation history, audit trail and certificates become mathematically unreadable — including in any backup that already exists. Your colleagues keep their accounts.
- Delete your account and your key is destroyed, which erases your personal details across every organisation you belonged to at once, without touching any organisation's work. Your login is removed from our identity provider at the same time.
Because the key is destroyed rather than the data hidden, this holds against exactly the scenario ordinary deletion does not: someone with a copy of the database and our master key still cannot read what was erased. We test that claim the way an attacker would — we capture everything a database dump would contain, perform the deletion, and the test fails if the content can still be recovered.
How long deletion takes to become irreversible
Deletion takes effect immediately: from the moment you confirm, nothing in the running service can read that data again.
Full irreversibility waits for the last backup holding the key to expire. Today that is within 7 days, for both an organisation and a personal account.
Note “within”, not “after”. Backups are taken daily and kept for seven days, so a deletion becomes irreversible when the last backup made before it ages out — usually sooner than seven days, and never longer. We quote the ceiling rather than the average, because the ceiling is the part we can promise.
There is no grace period and no undelete. That is a deliberate choice: a guaranteed undo window and a short irreversibility window are mutually exclusive — the two periods add up. Instead, deletion is a typed confirmation behind a warning that names exactly what will be destroyed.
Two things that deliberately survive
We would rather name these plainly than let you discover them.
Invoices. EU and Swedish bookkeeping law requires us to retain invoices for [to be provided: invoice retention period] years, and GDPR Art. 17(3)(b) exempts data we hold under a legal obligation. A retained invoice keeps the billing name and address as they stood when it was issued — so if you ask us to erase you, that specific record remains for the statutory period. Nothing else about you does.
Certificates stop working. Certificates belong to the organisation that earned them, so they are destroyed with it. Anyone who later checks one is told it is not valid rather than being shown details of an organisation that asked to be removed. Download any certificates you need before deleting an organisation — you can do so at any time until then.
If your employer runs single sign-on, they administer your account
We would rather name this plainly than let you discover it, because it is the one part of this page where somebody other than us can see or change something about you.
When a company proves it controls your email domain — by publishing a DNS record in it, which in practice means their IT department — that company's administrators gain three abilities over the account you sign in with. Not over your work: over your sign-in.
- They can see who you are. Your name and email address appear on a list of the organisation's people. That is new as of September 2026, and it is the reason this section exists: before it, an administrator could count the people on their domain but never name them.
- They can suspend your sign-in, and lift it again. Nothing is deleted, and your workspaces and documents are exactly as you left them either way.
- They can erase your personal data — your name and email address — if you leave the company. This is irreversible and immediate, and it reaches every workspace you belong to, including workspaces belonging to other organisations you collaborate in. It does not touch the projects, evidence or certificates themselves, which belong to the workspace rather than to you.
- They can require two-factor authentication and set your inactivity timeout, in which case those settings become read-only for you and the page says so.
What they cannot do: read your documents, reach your projects, or remove you from a workspace. Those belong to the workspace's own Compliance Officer, one tier down, and a domain administrator has no access to them.
Why we allow it. It is the standard model for work accounts — the same thing Google Workspace and Microsoft Entra do — and it is what makes it possible for a company to offboard somebody who has left. It is also the only way your personal data can ever be erased once your employer's identity provider stops authenticating you: you can no longer sign in to erase it yourself, so somebody has to be able to do it for you.
How to tell. If an organisation administers your account, the security settings in your account menu are read-only and carry a notice saying so. If they are editable, nobody has claimed your domain.
What this does not protect against
No honest security page ends without this section.
- A compromise of the running service. The application must be able to read your data to show it to you, so it holds the keys while it runs. Encryption at rest protects against stolen disks, stolen backups and provider access — not against an attacker who has taken over the live system.
- Your login credentials. Email address, name and password are held by our identity provider in its own store, which our encryption does not reach. Deleting your account deletes them there too, but they are not protected by the key model described above.
- Data you have shared elsewhere. Our payment provider holds what it needs to process a payment, under its own terms.
Exercising your rights
You can delete your account, and an organisation's Compliance Officer can delete the organisation, from within the product — no request, no waiting, no support ticket. For access, correction, portability or any other request under GDPR, contact [to be provided: privacy email].