Security and operations

Report a vulnerability

Revised7 August 2026 In force from7 August 2026

We hold sensitive information about people who did not themselves choose to be in our systems. If you find a vulnerability, we would rather hear it from you than from someone exploiting it.

§ 1

If you have found something, we want to know

We hold sensitive information about people who did not themselves choose to be in our systems. If you find a vulnerability, we would rather hear it from you than from someone exploiting it.

Write to us at the address at the bottom of this page and put "Vulnerability" in the subject line. Danish or English is fine.

We do not run a bug bounty programme and do not pay rewards. We do say a proper thank you, and if you would like to be named, we are happy to credit you once the matter is closed.

§ 2

What we promise you

  1. We acknowledge your report within 3 business days.
  2. We assess the matter and come back to you with what we make of it and what we are doing.
  3. We keep you informed until the matter is closed.
  4. We will not pursue or report you if you have stayed within the rules in § 3 and acted in good faith.

We ask you to give us reasonable time to fix the matter before you make it public. Where people’s data is at stake, that time is not a formality.

§ 3

The rules

So that we can promise you what § 2, point 4 says, you must stay within the following:

  • Look only at the data necessary to demonstrate the vulnerability. If you come across personal data, stop, and say so in your report.
  • Do not download, alter, delete or publish data, and do not keep it longer than the report requires.
  • Do not use other people’s accounts without their permission. Test on your own.
  • Do not make the service unavailable to others — no load testing, no attempts to cause an outage.
  • Do not use social engineering against our employees, customers or suppliers, and do not attempt to gain physical access.
  • Do not leave back doors behind, and remove anything you may have placed during testing.

If you are in doubt whether something is within the rules, ask us before you do it.

§ 4

What the report should contain

  • Where you found it — the URL, endpoint or the part of the system concerned.
  • What you did, step by step, so that we can reproduce it.
  • What you assess an attacker could achieve.
  • Screenshots, log excerpts or a short recording, if that makes it clearer.
  • How to reach you, and whether you would like to be credited.

If the vulnerability is serious and you are able to encrypt your message, please do. If you cannot, send it anyway — an unencrypted report is better than none.

§ 5

Out of scope

We do not regard the following as vulnerabilities and normally do not act on them:

  • Missing security headers or cookie flags without a demonstrated consequence.
  • Output from an automated scanner that has not been verified.
  • Questions about our SPF, DKIM or DMARC configuration without a concrete exploitation.
  • Self-inflicted attacks that require the victim to paste code into their own browser.
  • Vulnerabilities in third-party systems — report those to them.
  • Matters that require a lost or unlocked device, or access to the user’s computer.

If you disagree that something belongs here, say so in your report — we will look at it.

Security and operations

Do you need documentation
for a supplier approval?

We are happy to fill in your own security questionnaire and walk your IT department through the setup. Call us, and we will take it from there.

Contact us

Call on any business day or write — we reply within 2 hours on any business day.

35 15 47 65 rieck@rieckflow.com

Operational status

Current status of the portal and website — and the history behind it.

status.rieckflow.com

Found a vulnerability?

Then we would rather hear it from you than from someone exploiting it. The rules are on the page.

Report a vulnerability
  • 30 days free
  • No payment card
  • One day's notice