Responsible disclosure: found a vulnerability? Report it
This page describes how to report a security problem in a TheSEO system, what we ask of you and what you get back from us. In ordinary language, so you know in advance where you stand.
How to report it
Put SECURITY in the subject line. Then your message is seen with priority and does not get lost among the ordinary post.
Report confidentially, so directly to us and not yet in public. The more concrete your report, the faster we can reproduce and fix it.
What we would like to see in your report
- The URL or the system it concerns.
- The steps to reproduce the problem, in the order you took them.
- What somebody could do with it maliciously: which data or which function is at risk.
- Only the minimum necessary evidence. One screenshot or one line from a response is enough. Do not send a complete dump containing other people's data.
- How we can reach you with questions, and whether you want to be named once it is fixed.
A scanner report without a demonstrated problem is something we cannot assess. So describe what goes wrong and how you saw it, not only which tool turns something red.
Reporting encrypted
If you want to supply the details encrypted, ask for that in your first message. We will then agree a method before you send the content.
There is no fixed encrypted reporting channel yet, such as a published PGP key or a secure form. While there is not, we agree it per report. If that channel arrives, it will be here and in security.txt.
What this policy covers
This policy covers systems we run ourselves and can repair ourselves. That means this website and the free tools and plugins on it, the MyParcel Dashboard, Jarvis, LinkLoop, the AI Index and our MCP connections. Those product pages describe what each system does and what it is built on, which is often the quickest way to work out whether your finding sits in something of ours; how we secure Jarvis specifically is set out under Jarvis security.
Systems belonging to other parties fall outside it. Our site runs at a hosting provider and payments go through a payment service. If you find a problem in such a service itself, report it to that party, because we cannot change anything there. If it sits in the way we configured or connected that service, it is for us and we would like to hear it.
That last distinction is the one that causes the most doubt, so here it is as a picture rather than as a sentence. The question is not who owns the software but who can change the setting you found.
# The middle lane is the one people send to the wrong address. A supplier's product can be flawless while our use of it is not, and that half is entirely ours.
# In doubt, send it here anyway. Being forwarded costs you one email; a report that nobody reads costs everybody more.
# The right-hand column is what happens next, not what we owe you. The periods themselves are in Figure R.01 below.
If you work with us and you see something in an environment we manage for you, you can also simply report it through your usual contact. The reporting address above works just as well.
What we ask of you
Research is fine, as long as you do not affect anybody else. Concretely we ask this:
- Test only on your own accounts and your own data.
- Stay away from phishing, social engineering, denial of service, physical attacks, spam, malware, changing data and access to other people's data.
- Do not download or keep personal data. Use as little data as possible to show that the problem is real.
- Stop as soon as you see personal data, keys or data belonging to another client, and report that immediately.
- Do not make the problem public before it is fixed, or before we have agreed a reasonable period together.
- Ask permission in advance for actions that could affect the availability, the cost or the correctness of data.
Those last two are not a formality. A test that takes the site down or that runs up costs hits clients who have nothing to do with it.
What you can expect from us
# The solid half of the line is the periods we aim for and can be held to. The dashed half deliberately carries no period: a fixed repair time we cannot always meet is not something we should write down here.
# The pulse fades out where the line goes dashed, because that is exactly what the promise does.
# There is no reward for a report. There is no bug bounty.
We normally confirm a report within two working days. After that we determine how serious it is and keep you informed in outline. We aim for a first substantive assessment within five working days.
How long a fix takes depends on the severity and on where the problem sits. If it is in our own code, it usually goes quickly. If it hangs on a supplier or on a connection, we depend on their pace.
These are the periods we aim for and can be held to. They are not guaranteed periods, and we deliberately name no fixed repair time that we cannot always meet.
Once it is fixed, we let you know. If you want to be named for it, say so in your report and we will discuss how.
What this means legally
If you act carefully and within the rules on this page, we will not report you to the authorities and we will not start civil proceedings over the research itself. That is the undertaking we set down here.
What is not written here: this is not permission for unlawful conduct outside these rules. If you go further than the above, ordinary law applies. And here is the honest limit of what we can promise. TheSEO is a Dutch company and this undertaking binds us, not a prosecutor. A prosecuting authority, in the Netherlands or in the country you are testing from, decides independently what it does. That is not ours to give away, and a page that suggested otherwise would be selling you a comfort it cannot deliver.
We also promise no reward. There is no bug bounty and no sum attached to a report. We would rather say that in advance than afterwards.
What we do with your data
If your report contains personal data, for instance your own name and email address or data you happened to see, we use it only to investigate the problem, to stay in touch with you, to put the security right and to meet legal obligations. Nothing else. It does not go to marketing and not to third parties with purposes of their own.
What we keep and on what basis is in our privacy statement.
Reports do not yet have a retention period of their own as a separate category. The privacy statement does name the periods closest to it: messages twelve months after the last substantive contact, and evidence of a confirmed security incident for up to five years. As soon as a period of its own has been set for reports, it will be here.
security.txt: the same arrangement, for machines
Researchers and scanners first look in a fixed place to see whether an organisation has a reporting address. That place is /.well-known/security.txt, described in RFC 9116. Ours says this:
Contact: mailto:sales@theseo.nl Expires: 2027-08-01T23:59:59Z Preferred-Languages: nl, en Canonical: https://theseo.nl/.well-known/security.txt Policy: https://theseo.nl/responsible-disclosure/
In ordinary language: where you report it, until when this file is valid, which languages you can use, where the file belongs and where the policy you are reading now can be found.
The expiry date is 1 August 2027. It is not there for decoration. A security.txt with a lapsed date is worse than no file at all, because a reporter can no longer tell whether the address is still right. So we renew it before that date.
The Policy line points at the Dutch page, because that is the canonical location of this policy. This English edition says the same thing; where the two ever differ, the Dutch one is the one we maintain first and we will fix the difference rather than argue about it.
Data breach, complaint and changes
Do you think data has leaked?
That is something other than a vulnerability. A vulnerability is a hole that could be abused; a data breach means data has already come out. If you see signs of the second, email sales@theseo.nl with the words data breach in the subject line. What happens after that is in the privacy statement.
Unhappy with how we handle your report?
Tell us at the same address. If it is about the handling of personal data, you can also go to a supervisory authority, and which one depends on where you are: the Autoriteit Persoonsgegevens in the Netherlands, the Information Commissioner's Office if you are in the United Kingdom, the Data Protection Commission if you are in Ireland. The full routes are on the privacy statement.
Changes
If this policy or the reporting address changes, we amend this page and then security.txt immediately afterwards, so that the two do not contradict each other. The version is at the top and the date of the last change is below.
See also our terms and conditions and our privacy statement.
Last changed on 25 August 2026