Privacy policy

Who we are

RagnarOps Security Labs is a trading name of Pablo Ruiz Encinas, who is the controller of the personal data described in this policy. There is no separate company: the practice is not incorporated, so the controller is an individual.

• Based in: Amsterdam, Netherlands
• Contact: contact@ragnaropsec.com

We have one contact address. Every question, request, or complaint under this policy goes to contact@ragnaropsec.com — there is no separate privacy or legal mailbox.

What this policy covers

This policy covers two things we run. The first is this website, a static marketing site whose contact form is the only place it collects personal data. The second is the client portal at portal.ragnaropsec.com, a private, invitation-only application where clients read the work we have done for them. There is no sign-up: every portal account is created by us, and the portal is not reachable without one. The field notes also carry view and like counters; those hold no personal data, and they are described below so that nothing the site does is left unstated. This policy does not cover data we may process inside a client environment during a contracted engagement — see "When we act as a processor" below.

What we collect

When you submit the contact form, we collect:

• Your name
• Your work email address
• Your company
• An optional free-text note describing the scope of what you want to discuss
• The service-interest tags you select
• The language the site was set to when you submitted the form
• The website you arrived from, as a bare hostname — for example www.linkedin.com — and nothing more of it
• Any campaign labels in the link you followed (utm_source, utm_medium, utm_campaign), which are labels we write into our own published links

That is the complete list for the contact form.

The client portal

If we have issued you a portal account, we hold:

• Your email address, and your name if you gave us one
• The role your account holds, and which client organisation it belongs to
• Whether you have set up two-factor authentication, and the secret that makes it work
• A record of each sign-in, failed sign-in, invitation and role change on your account, with the date and time
• The IP address and browser user-agent recorded against those sign-in records
• If you sign in with Google, the account identifier Google returns to us

We keep the sign-in records because a portal that holds our clients' unresolved security findings has to be able to answer who opened it and when. That is the same standard we would expect of a client.

The portal also holds evidence files — the screenshots and images that prove a finding. These are uploaded by us, not by you, and they show systems rather than people; they may nonetheless capture a name, an address or a session that belongs to someone. They are stored in Frankfurt with everything else, and they never pass through our host in the United States: your browser fetches them from Frankfurt directly. Every image we upload is decoded and written again before anyone can open it, which removes the metadata a camera or a screen capture attaches — location, device, and account names among it — so none of that reaches the report. When a report shows you an image, it does so through a link that works for fourteen days without signing in; we tell you that before the report opens, and we record that you were told. If we withdraw an image, every link to it stops working immediately.

The last two are how we understand which of our own channels reach people, and they are deliberately narrow. We keep the host of the referring site, never the full address: an address on someone else's site can carry their query strings, and those can contain data about you or about other people. Your browser discards everything but the host before the form is sent, and our server rejects anything that does not look like a bare hostname rather than trying to trim it. If you came to us directly, typed the address, or used a bookmark, there is nothing to record and we record nothing.

We do not do this by watching you around the site. There is no script measuring where you go; these two values are read once, from the page you landed on, and are only ever sent if you choose to submit the form.

Field-note counters

Each field note carries a view count and a like count. What we store for this is two whole numbers per article and nothing else. There is no visitor identifier, no IP address, no per-read record, and no timestamp beyond when a total last changed — so we cannot tell who read an article, whether two views were the same person, or which articles any individual has read. These totals are not personal data and are not linked to anything that is.

Opening a note makes your browser call the counter endpoint, which runs on the same Frankfurt infrastructure as the contact form. As with any request over the internet, that endpoint receives your IP address in order to send a reply. It is not written to the counters and we do not store it.

Whether this browser has already been counted for a note, and which notes you have liked, is kept in your own browser's local storage. It is never transmitted to us. Clearing your site data resets it; the only consequence is that a later visit may be counted again.

What we do not collect

• On this marketing site, we do not log or store your IP address, user agent, or any device fingerprint. Automated abuse controls run inside the server-side function that processes submissions and are not persisted anywhere. The client portal is different and does record both against sign-in events; see "What we collect" above.
• We do not run analytics. There is no page-view tracking, no session recording, no third-party analytics service, and no advertising or tracking network. Nothing on this site measures your visit. The field-note counters described above are aggregate totals with no identifier attached, and cannot report who read what. The one thing we do record about where visitors come from is the referring host on a submitted enquiry, described in "What we collect" — that is attached to an enquiry you chose to send us, not to a visit.
• On this marketing site, we do not set cookies. The client portal sets two, and only two: one holding your sign-in session, and one holding the timestamps that end it after 30 minutes of inactivity or 12 hours in total. Both are strictly necessary to keep you signed in, neither is used to measure or follow you, and both are httpOnly — your browser will not hand them to any script, including ours.
• We do not use third-party tracking or advertising networks.
• We do not operate a public account system or accept sign-ups. The client portal has accounts, and we create every one of them; there is no way to register for one.
• We do not build profiles of you, in either place, and nothing we hold is used to decide what you are shown.
• We do not use your data for automated decision-making or profiling that has a legal or similarly significant effect on you (Article 22 GDPR).

Why we process it, and on what basis

We process the data in the contact form to respond to your enquiry and, where relevant, to prepare a scope and quote for an engagement.

• Where we are responding to a general enquiry, our lawful basis is our legitimate interest in operating this business and answering messages addressed to us (Article 6(1)(f) GDPR).
• The referring host and campaign labels are processed on the same legitimate-interest basis (Article 6(1)(f)): a practice this size has to know which of its own channels actually reach people. We weighed that against your interests and kept the processing to the minimum that answers the question — no identifier, no browsing history, no profile, nothing that changes how we treat you or what you are shown. You can object to it under Article 21; see "Your rights" below.
• Where your enquiry is the first step toward a contract — for example, scoping a specific engagement — our lawful basis is the steps necessary to enter into that contract, and its subsequent performance (Article 6(1)(b) GDPR).

For the client portal:

• Holding your account and showing you your organisation's work is necessary to perform the engagement contract we have with that organisation (Article 6(1)(b) GDPR).
• The sign-in records, including the IP address and user agent, are processed on our legitimate interest in keeping the portal secure and being able to account for who accessed client findings (Article 6(1)(f) GDPR). We weighed that against your interests and limited it: the identifying half of each record is erased after 90 days, leaving only that an account signed in on a date.

We do not use the data for any other purpose, and we do not send you marketing you have not asked for.

Where it goes

We use four subprocessors. This is the complete list.

• Supabase — receives your contact-form submission and stores it, and holds the field-note counters. The functions that handle both, and the database they write to, run in the eu-central-1 (Frankfurt, Germany) region. The database denies all direct access from your browser; only those server-side functions can write to it.
• Scaleway — a European transactional email provider. Submitting the form triggers a notification email to us, sent from Scaleway's fr-par (Paris, France) region.
• Netlify — serves the pages of this website, and runs the client portal. Your contact-form submission does not pass through Netlify: the form posts directly to the Frankfurt endpoint above. As the host, Netlify processes the technical request data involved in delivering a page to you, including your IP address. For the portal, Netlify also runs the server code that renders each page and reads your session; see "Where your data is processed" below.
• Google — only if you choose "Continue with Google" on the portal. Google tells us the account identifier and email address for the account you signed in with; we send Google nothing about you beyond the fact that a sign-in was requested. Choosing the email and password option instead means Google is not involved at all.

Where your data is processed

The contact form. It submits directly to infrastructure in Frankfurt, and the data stays there. What you send through the form is not transferred outside the European Economic Area, so no adequacy decision or standard contractual clauses are engaged for it. The field-note counters run on the same Frankfurt infrastructure and hold no personal data to transfer.

The client portal. Its database is in Frankfurt with everything else. The server code that renders its pages currently runs in the United States, on Netlify's default region, which means the technical data involved in serving you a page — including your IP address and your session cookie — is processed there in transit. That is a transfer to a third country under Chapter V of the GDPR, covered by Netlify's standard contractual clauses.

We would rather it ran in Frankfurt, and it is one configuration setting away. That setting is only available on our host's paid tier, and we have chosen not to carry that cost until the portal is serving paying clients. So this is a deliberate, current arrangement and not an oversight, and we are telling you which it is. We will move it when the portal is in real use, and this paragraph will be replaced when we do.

We do not sell your data, and we do not share it with anyone outside this list except where the law compels us to.

How long we keep it

Enquiries are deleted 24 months after submission. We keep them that long because enterprise and public-sector security procurement cycles routinely run past a year from first contact to a signed engagement. A scheduled job runs against the database daily and deletes anything past that age.

The referring host and campaign labels sit on the same record as the rest of the enquiry, so they are deleted with it and on the same schedule. There is no separate copy anywhere.

The field-note counters have no retention period, because there is nothing in them to retain about you — they are running totals per article with no record of any individual read.

Portal accounts last as long as your organisation's relationship with us; we remove an account when it is no longer needed, or sooner if the organisation asks. Sign-in records are kept for 12 months, so that we can answer who accessed a client's findings over a full contract year. The identifying parts of those records — the IP address, the browser user-agent, and any address typed into a failed sign-in — are erased after 90 days. After that the record still shows that an account signed in on a given date, and no longer shows from where. Both are enforced by scheduled jobs that run daily against the database, not by anyone remembering.

Evidence files are kept for the life of the project they belong to, and for 90 days after that project is closed. Then they are deleted. The record of the file — what it was called, who added it, and when it was removed — stays with the finding; the image itself does not. This is enforced by a scheduled job that runs daily, on the same principle as the records above: a retention period nobody has automated is a retention period nobody is keeping.

Your rights

Under the GDPR, you can ask us to:

• Give you a copy of the personal data we hold about you (Article 15)
• Correct inaccurate data (Article 16)
• Delete your data (Article 17)
• Restrict processing while a dispute is resolved (Article 18)
• Give you your data in a portable format, where the processing is based on consent or contract and carried out by automated means (Article 20)
• Stop processing based on our legitimate interest, unless we can show compelling legitimate grounds that override your interests (Article 21)

Send a request to contact@ragnaropsec.com. We will respond within one month of receiving it, as required by Article 12(3) GDPR. Where a request is complex or we have received a number of them, that period can be extended by a further two months — if that applies, we will tell you within the first month and explain why.

Complaints

If you are unhappy with how we have handled your data, contact us first at contact@ragnaropsec.com. You also have the right to lodge a complaint with the Dutch supervisory authority, the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl), or with the data protection authority in the EU member state where you live or work.

When we act as a processor

If your enquiry leads to a signed engagement, we may process personal data inside your environment while carrying out that work — for example, data we encounter while testing a system you have authorised us to assess. In that context you are the controller of that data and we act as processor, working on your instructions.

That processing is governed by the data processing terms in the engagement contract, not by this policy. We do not describe those practices here because they are set out, engagement by engagement, in that agreement.

Changes to this policy

If we change this policy, we update the date at the top of this page.