Politik for myndighedsadgang

1. Purpose

This document explains how WhistleSafe ApS (“we”, “us”) responds to requests for personal data from law enforcement agencies, courts, regulatory authorities, intelligence services, and other governmental bodies (collectively, “authorities”). It addresses two questions: what data do we have that authorities might ask for, and what process do we follow when we receive a request.

This policy applies to data processed on the WhistleSafe whistleblower platform, both data we hold as Processor on behalf of our customers (Controllers) and data we hold as Controller for our own business (billing, employees, marketing).

2. Core commitments

We disclose personal data to authorities only when legally compelled or, in narrow exceptional cases (imminent risk to life), when disclosure is the proportionate response.
We require authorities to provide written, signed requests citing the specific legal authority and identifying the specific data sought.
We refuse and challenge overly broad, vague, or legally insufficient requests.
We notify the affected customer (Controller) of any request before disclosing data, unless we are legally prohibited from doing so.
For requests involving whistleblower reports, we apply the additional confidentiality protections required by Danish law (see Section 7).
We disclose only the specific data the legal process compels — never more.
We maintain a written log of every request received and our response.

3. What we have, and what we don’t

The most important question for many people reading this is not what we will do with a request, but what we have available to give. The platform was deliberately designed to minimise the data that exists. Even with unrestricted access to our systems, an authority would find:

Available

Case content (report subject, description, attachments) — for cases not yet auto-deleted under the customer’s retention policy.
Case handler accounts — name, email, phone number (optional), role assignments. These users register and consent to the platform’s processing.
Case audit log — who viewed/changed what, with timestamps. Every privileged action against a report is logged.
Email delivery log — recipient addresses (case handlers only — see below), timestamps, delivery status. Retained 90 days.
Sign-in history of case-handler accounts — sign-ins, failed sign-ins, lockouts and account-security events, with user and time but no IP address. Retained 90 days.
Application logs and telemetry — request metadata, errors and log lines that identify accounts and companies by id, without reporter IP addresses and with Report IDs removed or replaced by a one-way reference. Retained 90 days.
Microsoft 365 message trace — sender, recipient address, subject and delivery status of each email the platform sent, reporter notifications included. Held by Microsoft for 90 days; we search it only for staff addresses.
Customer billing data — billing contact, organisation name, VAT/CVR, invoice history. We hold this as Controller.

Not available

Reporter IP addresses — never retained. An OpenTelemetry processor strips IPs from telemetry before export. A defensive Serilog enricher additionally removes IP-shaped property keys from logs.
Reporter device identifiers, browser fingerprints, geolocation — not collected.
Reporter notification email addresses in our own logs — even when reporters provide a notification email for follow-up, that address is never written to our logs, telemetry, email delivery log or CSV exports. A privacy invariant in the email delivery logger and CSV writer enforces this. Microsoft’s message trace (above) does hold it for 90 days.
Identifying metadata in uploaded images and documents — EXIF / IPTC / XMP data from images and the document properties of PDF and Office (.docx, .xlsx, .pptx) files are stripped at upload time before storage. Audio, video, ZIP and password-protected files are stored as uploaded.
Reporter login history — reporters have no personal account, and the shared account behind the reporting link is never recorded in the sign-in history.
Real-time browser session data for reporters — no client-side cookies, no persistent device tokens.
Plaintext passwords or session tokens — only salted PBKDF2 hashes of passwords and SHA-256 hashes of refresh tokens are stored.
Cleartext data subject to per-tenant retention — once the customer’s retention period elapses on a closed report, the data is deleted from the database AND blob storage. Backups are point-in-time and rotate according to Azure SQL’s retention windows.

This is by design. We cannot produce data we never collected.

4. Valid request requirements

For us to act on a request without challenge, it must:

Be in writing and signed by an authorised representative of the requesting authority.
Cite the specific legal basis (statute, court order number, etc.).
Identify the specific data sought (specific user, specific case, specific date range) — not “everything you have”.
Be issued by a competent authority within Denmark, the EU, or via a Mutual Legal Assistance Treaty (MLAT) for non-EU requests.
For data covered by Danish whistleblower confidentiality (§§ 25 and 26 of the Danish Whistleblower Act), the request must satisfy the disclosure conditions in § 26, stk. 2: it must come from a public authority, and the disclosure must serve to counter breaches covered by the Act or to safeguard the right of defence of the persons concerned.

We will not act on:

Informal requests (phone calls, emails without signed authority).
Requests for “all data on a person” without specific identifiers.
Foreign-authority requests that bypass MLAT.
Requests that would compel us to violate Danish or EU law.

5. How we respond to a request

When a request is received:

1. Acknowledge receipt to the requesting authority within one business day.

2. Verify legitimacy. We confirm the request is signed by the authority claimed, that the cited legal basis is real and applicable, and that the scope is specific. We do not disclose unless we are legally compelled to.

3. Notify the affected Controller (customer organisation) before disclosure. The Controller is the legal recipient of any data subject’s interaction with their tenant; they are entitled to know about the request and may object. We delay this notice only if the request includes a legally enforceable gag order.

4. For whistleblower-report data, notify the reporter if reasonably possible and not legally prohibited, before disclosing identity-revealing information. § 26, stk. 4 of the Danish Whistleblower Act requires this unless it would jeopardise related investigations or court proceedings.

5. Disclose only what is compelled. We narrow disclosures to the specific records named in the request. We do not “round up” or include additional data for convenience.

6. Log the request and response in our internal records.

6. Notice to affected parties

We commit to notifying:

The affected customer (Controller) before disclosure, unless prohibited by an enforceable gag order.
The affected reporter (whistleblower) before disclosure of identity-revealing information, where notification is reasonably possible and is not legally prohibited (Danish Whistleblower Act § 26, stk. 4).
The affected case handler before disclosure of their personal data.

Where we are legally prohibited from giving notice (e.g. by a gag order or non-disclosure provision in a court order), we will provide notice as soon as the prohibition lapses.

7. Special protections for whistleblower reporters under Danish law

The Danish Whistleblower Act (Lov om beskyttelse af whistleblowere, Act No. 1436 of 29 June 2021) makes the confidentiality of a reporter’s identity a statutory obligation, not merely a policy preference.

Specifically:

§ 25: Whoever is designated to receive and follow up on reports has a duty of confidentiality about the information in them.
§ 26, stk. 1: Information that can directly or indirectly identify the reporter may not be disclosed without the reporter’s explicit consent to anyone other than the authorised staff who receive or follow up on reports.
§ 26, stk. 2: Without that consent, the information may be disclosed only to another public authority, and only to counter breaches covered by the Act or to safeguard the right of defence of the persons concerned.
§ 26, stk. 4: The reporter must be informed before a disclosure under stk. 2, unless that would jeopardise related investigations or court proceedings.

This means we cannot voluntarily hand over reporter identity even if asked. A request must satisfy the conditions in § 26, stk. 2 — it must come from a public authority and serve one of those two purposes. We apply this protection regardless of the requesting authority’s nominal legal authority.

8. Foreign authority requests

Requests from authorities outside the EU/EEA must be channelled through the Danish authorities under a Mutual Legal Assistance Treaty (MLAT) or equivalent international agreement. We do not respond to direct requests from foreign authorities (e.g. subpoenas issued under the U.S. CLOUD Act delivered directly to us) without a corresponding Danish judicial process.

We do not have a U.S. presence, and no parent or affiliate is incorporated in jurisdictions that would expose data to direct foreign subpoena. All platform data is hosted in Microsoft Azure North Europe (Dublin, Ireland), within the EU Data Boundary.

9. Pushback and challenge

We commit to formally challenging any request that:

Lacks a sufficient legal basis.
Is overly broad relative to the stated investigation.
Conflicts with EU or Danish law (including GDPR fundamental-rights protections).
Would compromise the confidentiality of a whistleblower’s identity outside the narrow exceptions in § 26.

Where a challenge is warranted but we lack the means to mount a full legal defence, we will at minimum notify the affected parties (Controller, reporter, case handler) so they may pursue their own challenge, and disclose only the minimum compelled by the unchallenged portion of the request.

10. Transparency

To date, WhistleSafe has not received any government access or law enforcement request. We will update this statement if that changes. Customers may request a written confirmation of our current request count at any time by emailing kontakt@whistlesafe.dk.

11. Contact for legitimate requests

Authorities may submit requests to:

Paw Ormstrup Madsen
WhistleSafe ApS
Ndr Dragørvej 151, DK-2791 Dragør, Denmark
kontakt@whistlesafe.dk

Requests must be sent in writing. We will acknowledge receipt within one business day.

This contact information will be replaced with a dedicated DPO contact when one is designated.