Security / Disclosure policy

Vulnerability disclosure policy.

Found a weakness in our own systems? This page says what is in scope, how to test without causing harm, what we promise in return, and how we disclose what we find in other people's software. It matches our security.txt file.

Updated: 2026-10-10
Sources: 04
Version: 0.1

Draft for lawyer review. Not in force. PLACEHOLDER

This page is a working draft. A lawyer reviews it before it applies, and bracketed slots fill in once the company is registered.

How to report a vulnerability to us.

Our reporting mailbox opens together with our own domain. Until we own that domain we publish no address on it: a report sent to a domain someone else could register is a report someone else could read. In the meantime our security.txt, the file RFC 9116 defines for exactly this, names this page as the contact, as the standard allows, with an expiry date.Note 1

FIG. 1 / OUR SECURITY.TXT, AS SERVED/.well-known/security.txt

Contact: https://scotoma-epj.pages.dev/security/disclosure-policy/
Expires: 2027-10-09T00:00:00.000Z
Preferred-Languages: en, nl
Canonical: https://scotoma-epj.pages.dev/.well-known/security.txt
Policy: https://scotoma-epj.pages.dev/security/disclosure-policy/

EXPIRES 2027-10-09 / RENEWED EVERY YEAR, OR THE BUILD FAILS 30 DAYS BEFORE

Write in English or Dutch. A useful report says what you found and where, what an attacker could do with it, and enough for us to reproduce it: the URL or component, the conditions, and what you observed. A screenshot helps; a weaponised exploit is not needed and not wanted.

If your report holds sensitive data, ask us for an encrypted channel before you send it.

What is in scope.

In scope: This website, scotoma-epj.pages.dev, and its subdomains, our mail domain, and the services we run ourselves.
Out of scope: Systems that belong to our clients or to anyone else, including the third-party services we use. Report those to their owners.
Not wanted: Denial of service or load testing, spam, social engineering of our people, physical attempts, and scanner output without a demonstrated impact.

How to test without causing harm.

Stop as soon as you have shown the issue. Access no more data than you need to demonstrate it, and do not keep what you saw.
Do not change, delete or encrypt data, and do not disrupt the service for anyone else.
Use what you found only for your report, and keep it to yourself until the issue is fixed.
Give us reasonable time to fix it before you publish.
Stay within the law that applies to you. In the Netherlands, entering a computer system intentionally and unlawfully is a criminal offence; this policy is our invitation, within its limits.Note 2

What we promise in return.

We keep you informed until the issue is fixed, and we tell you when it is.

Issues we find in other people's software.

Our research happens in our own lab, against software we run ourselves. When we find a vulnerability in someone else's product there, we report it privately to the vendor first and agree a date for publication. Our advisory follows on the advisories page once a fix is available or the agreed date has passed, with the vendor's response noted.

That process now meets duties on the vendor's side as well. Since 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities under the Cyber Resilience Act, and NIS2 lists vulnerability handling and disclosure among the measures entities in its scope must take.Note 3

Findings from client engagements are confidential. We never disclose them without the client's written permission, and when a client engagement turns up a flaw in a third-party product, we agree its disclosure with the client first.

Changes to this policy.

This is draft version 0.1, dated 2026-10-10. When the policy changes, its version and date change with it, and our security.txt keeps pointing here.