1. Who we are
The service is provided by RAM Labs ApS ("Canonir", "we", "us"), a company registered in
Denmark under company registration number (CVR) 46665449, with its registered address at
Ny Strandvej 12 B, DK-3060 Espergærde, Denmark.
For the processing described in this policy we are the data controller. You can reach us at
privacy@canonir.com for any question about this policy or about your personal data.
We have assessed whether we are required to appoint a data protection officer under Art. 37 and
concluded that we are not: our core activity is the security assessment of infrastructure, not the
regular and systematic monitoring of individuals on a large scale, and we do not process special
categories of data at scale. We will revisit this if our processing changes.
2. What this policy covers
This policy explains what we do with personal data about you as someone who visits our website,
creates an account, uses the service, or pays for it.
It covers two surfaces, and says which is which where they differ. The marketing website at
canonir.com is what you are reading now; the application is what you sign in to. They are the
same company and the same policy, but they are not the same software and they do not store the same
things, so §11 names each cookie against the surface that sets it. Everything else here applies to
both.
3. Where our responsibility ends and yours begins
Two different roles, and the difference decides who you contact about what:
- We are the controller for your account, your use of the service, billing, security and the website. That processing is described here.
- You are the controller for the personal data inside your workspace: the assessment results, the evidence, and anything your colleagues put there. We process it on your instructions as your processor, under the Data Processing Agreement. If someone wants their data in your workspace erased, they ask you, and we give you the means to do it.
Most of what an assessment records is not personal data at all: hostnames, network addresses,
software versions and weaknesses describe systems rather than people. Evidence attachments are the
exception: a captured page or document may contain names or email addresses, and we treat evidence
as personal data whenever there is doubt.
4. What we collect, and why
| What | Why | Legal basis |
|---|
| Account details: name, work email, role, workspace membership | to create and run your account, authenticate you, and let colleagues collaborate | performance of a contract (Art. 6(1)(b)) |
| Authentication data: password hash, second-factor secrets, recovery codes | to keep the account secure and let you recover it | contract; and our legitimate interest in securing the service (Art. 6(1)(f)) |
| Billing details: billed-to name, billing email and address, VAT number, payment-method metadata (card brand, last four digits, expiry) | to take payment, invoice you, and meet tax obligations | contract; and a legal obligation for the records themselves (Art. 6(1)(c)) |
| Usage, session and access logs, including your IP address and times of activity | to operate the service, investigate faults, and detect misuse | legitimate interest in a service that works and is not abused |
| Records of what you agreed to: the text, version, time, your identity, the second factor you used, and, until you ask us to erase your personal data, your IP address and the browser and device you used (see §8) | to prove what was agreed, which is the point of agreeing to it | legal obligation and legitimate interest in evidence of authorization |
| Abuse-prevention signals: see §5 | to keep the service from being used against people who did not ask for it | legitimate interest, ours and that of the people who would otherwise be scanned |
| Support correspondence | to answer you | contract and legitimate interest |
| How your account came to exist: the marketing campaign and creative a visit arrived from, whatever you tell us in "how did you hear about us", and the moments the account is created, starts a trial, starts paying, changes plan or closes, with the amount charged | to see which of our marketing brings customers rather than only visitors | legitimate interest in knowing which of our marketing works (Art. 6(1)(f)) |
| Cookies and similar: see §11 | to make the site work, and to understand how it is used | necessity for essential cookies; consent for anything else |
| Operational telemetry: counts of systems assessed and of assessment runs, per workspace and per domain | to operate the service, plan its capacity and set its pricing | legitimate interest in running and pricing the service by its actual use |
We never hold your card number. Card details go directly to our payment processor; we hold only
the metadata listed above.
Marketing measurement does not follow you. Nothing is stored on or read from your device for it,
so there is no tracking cookie and nothing to consent to. The records used for measurement carry no
name and no email address, and cannot be connected back to you without information that stays with
us. If you would rather we did not do this at all, §9 explains how to object.
5. Abuse prevention, and what we record about it
Our service sends requests to systems on a customer's instruction. A customer who declares a domain
they have no authority over would make us the instrument of something we do not permit, so we record
signals that let us notice it:
- Whether the email domain of the account matches the domain being assessed. We hold both already; recording the relationship costs no new information about you.
- Which domains were declared, by which account, and when.
- How much assessment traffic a given domain has received from us in total.
These are observed, not acted on automatically. No decision about you or your account follows
from them by itself: they exist so a person can look at a pattern and judge it. This is not automated
decision-making and it does not profile you for any purpose beyond keeping the service from being
misused.
Who sees it: our own security operators, and no one else. We do not show these signals to other
customers, and they do not appear in any workspace.
6. Who we share personal data with
6.1 Service providers acting for us
| Who | What they do | Where |
|---|
| Amazon Web Services EMEA SARL | hosts the entire service: databases, compute, storage, secrets | AWS Europe (Frankfurt), Germany |
| Amazon Web Services EMEA SARL (Amazon SES) | sends our email to you: verification, password reset, invitations, billing notices, assessment notifications, and setup guidance about the service you hold, the last of which you can switch off from a link in any of those messages, while the others concern your account, your payments or your data and cannot be | AWS EU |
| Stripe Payments Europe, Ltd. | takes payment, manages subscriptions, issues invoices, handles VAT | Ireland; processing may involve the United States |
Each acts only on our instructions under a data processing agreement. The current list is published
and we will tell you before we add to it. We do not sell personal data, and we do not share it for
anyone else's marketing.
6.2 Public sources an assessment asks about your estate
This category is stated separately because it is easy to miss.
An external security assessment works partly by asking public sources what they already know about
a customer's estate. Doing so tells the operator of each source which organization is being
assessed, and when. This happens on every assessment: it is part of how the product works, not an
option a customer switches on.
The categories: certificate transparency logs, domain registration records, IP-to-network mapping,
web archives, public code search, public container registries, mobile app stores, and the public
storage endpoints of the major cloud providers. The specific services involved are published, and
the published list is kept current.
Two precisions:
- Domain registration lookups also happen when a domain's control is verified, not only during an assessment. A customer who verifies a domain and never runs an assessment has still had that domain sent to a registry.
- What is sent is a domain, brand term or address, not your name or your account. These are queries about infrastructure, and only rarely about a person.
6.3 Everyone else
We disclose personal data outside the above only where the law requires it, or to our professional
advisors under equivalent obligations of confidentiality.
We do not tell the operator of an assessed system who authorized the assessment. That a person or
organization is our customer, and which domains they declared, is their confidential information.
7. Sending data outside the EU/EEA
The service runs in AWS regions inside the EU. Two of our providers have parent companies in the
United States, so some processing may involve a transfer: we rely on the European Commission's
standard contractual clauses, supported by a transfer impact assessment and, where applicable,
the EU–US Data Privacy Framework.
8. How long we keep things
| What | How long |
|---|
| Account records | while the account is active, then 90 days |
| Session and access logs | 90 days |
| Assessment findings, assets and evidence | 5 years |
| Records of agreements and authorizations | while the account is active, then up to 6 years |
| Audit events | the life of the workspace, and not deleted |
| Invoices and tax records | 5 years, required by Danish accounting law, and this overrides a request for erasure |
| Other billing data | while the subscription runs, plus a reconciliation period |
| Anti-abuse records | up to 24 months, and held as a keyed one-way value rather than your email address |
| How your account came to exist (§4) | 90 days from the creation of the account |
One row above crosses the §3 boundary on purpose: assessment findings and evidence are your
workspace data, held as your processor and governed by the Data Processing Agreement; the number is
repeated here so you do not have to read two documents to learn it.
When a workspace is deleted there is a 30-day grace period before it is destroyed, so an
accidental deletion can be undone. The same 30 days apply when we end the service instead: the
workspace keeps sign-in, data export and its audit trail for that period, so you can take a
complete copy before anything is deleted.
What erasure can and cannot reach. When you ask us to erase personal data we remove it from the
live service. It persists in encrypted backups for no more than 35 days, counting
point-in-time recovery, snapshots and write-ahead logs together, and then it ages out. Restoring a
backup to delete one record would put back everything else it contains, so we do not do that, and we
do not use backups to reconstitute erased data. Thirty-five days is a ceiling we hold ourselves to
rather than a description of one setting: it is the longest window Amazon Web Services offers for
point-in-time recovery, so you can check the outer bound against them and not only against us. We
expect the real figure to be well inside it, and when it is fixed we will narrow this sentence.
Two things survive an erasure request, and we would rather state them than let you find them.
The first is the audit trail. Audit events are kept for the life of the workspace and are not
deleted. An erasure request replaces the identity in the audit record with a pseudonym that cannot be
reversed, so the record of what happened survives and the record of who does not. The reason is
that the trail is what makes an account's history verifiable at all: entries are appended and never
edited, and each one is chained to the one before it, so removing a row would break the chain and
leave every later entry unprovable. What remains after an erasure names nobody.
The second is a record of acceptance. When someone accepts the Terms, the Data Processing
Agreement or an Authorization Declaration, we keep the record of that acceptance for the period
stated in the table above. The record establishes that a particular person, at a particular moment,
permitted an assessment of a system, and a third party whose systems were assessed may one day
require that proof. For that reason the record itself is retained rather than deleted, and an
erasure request does not remove it.
Two outcomes follow, according to who asks and on what basis.
Where an individual asks us to erase their personal data, we retain the record and remove from it
the IP address and the browser and device string it was made from. What remains identifies the text
that was accepted, its version, the time, the person who accepted it and the second factor they
used. We take this position because those two fields add little to the purpose the record serves:
an IP address is commonly shared and reassigned, a browser and device string is readily altered,
and a dispute about an authorization concerns whether a person agreed rather than the connection
they agreed from. Everything else an erasure request reaches is erased in the ordinary way.
Where a customer closes their workspace, the record is retained in full for the period stated
above, including the IP address and the browser and device string. A customer bringing a commercial
relationship to an end is not an individual exercising a right of erasure, and the evidence that
the relationship was authorized is the evidence a third party would rely on after it has ended.
The clock on those records runs from the end of the relationship, not from the day the record was
made. We keep an acceptance for as long as the account exists, because it is what proves the terms
that account runs under, and the six years begin when the account is erased. Where someone accepted
something and never went on to have an account, there is no relationship to measure from, so the six
years run from the acceptance itself. Then the record and the countersigned copy of the document are
both deleted.
9. Your rights
You may ask us to give you a copy of your personal data, correct it, erase it, restrict or object to
how we use it, or provide it in a portable form. Where we rely on consent you may withdraw it at any
time, and that does not affect what we did before you withdrew it.
Write to privacy@canonir.com and we will respond within one month. Where a request is
complex the law allows us longer; if we need more time we will tell you within the first month and
say why.
If you are unhappy with how we have handled your data you may complain to the Danish Data Protection
Agency (Datatilsynet, datatilsynet.dk), or to the authority where
you live or work.
Two limits, stated rather than discovered: invoices and tax records must be kept for five years
whatever you ask, and records of what you agreed to are evidence of an authorization; erasing them
would destroy the proof that the assessment was permitted.
10. Automated decisions
We do not make decisions about you by automated means that have a legal or similarly significant
effect. The signals in §5 are observed by people, not acted on by machines.
11. Cookies
We use only cookies that are necessary, on both surfaces, and none of them requires your consent.
Which cookie comes from where matters if you are checking, so:
- The marketing website sets one, remembering the language you chose. That is the whole list, and the site publishes it with its duration on the cookie page.
- The application sets what signing in requires: a session cookie to keep you signed in, and a token that protects against cross-site request forgery. You meet these only after you have an account.
If we ever add a cookie that is not necessary, on either surface, it will require your consent
before it is set, it will be listed on the cookie page, and the provider will appear in §6.1.
Our sign-up protection runs on our own servers and our fonts are served from our own domain, so
neither sends anything about you to a third party.
We run no analytics product on either surface. No third-party script measures your visit, and
nothing about you is sent to an advertising or analytics service. What we do measure, we measure on
our own servers, from requests you make to us. That includes the marketing measurement in §4: it
needs no cookie and sets none, which is why it is not on this page.
12. How we protect it
We sell security, so the short version belongs in the policy rather than only in a contract. Your
data is encrypted in transit and at rest. It is held in AWS regions inside the EU and nowhere else.
Operators reach it through individually named accounts under least privilege, with a second factor,
rather than through shared logins, and each customer's workspace is isolated from every other one.
Backups run automatically and restores are tested.
The itemised list is Annex C of the Data Processing Agreement, which is the Art. 32 version a
customer's own auditor will ask for, and the one we are held to contractually. This section
summarises it and never widens it.
13. Children
The service is for organizations. It is not directed at children and we do not knowingly collect
their personal data.
14. Changes
Any change to the wording of this policy is a new version. Where a change is material we will tell
you before it takes effect. Superseded versions remain available so you can see what applied when.