A One-Page Vulnerability Disclosure Policy for a Small SaaS Company

On 11 September 2026, Article 14 of the EU Cyber Resilience Act (Regulation 2024/2847) started to apply, and ENISA opened its Single Reporting Platform the same day. The rest of the regulation applies from 11 December 2027, and that part includes a requirement that manufacturers "put in place and enforce a policy on coordinated vulnerability disclosure." If an enterprise customer has just asked you for your vulnerability disclosure policy (VDP), you are not waiting for a regulator. You are answering a questionnaire row, probably this week.

A VDP is a public page that tells outsiders how to report a security hole, what they may test, and what you will do next. It does not need a bounty budget or a security team. It needs one monitored mailbox and about 400 words of plain text.

What's affected

Any company that ships software or runs a service other people depend on. Three sources define what a minimal policy contains, and they agree closely.

BOD 20-01 binds US federal agencies only. For everyone else it is a well-tested checklist. The CRA is binding law for manufacturers of products with digital elements sold in the EU, with the dates above. ISO/IEC 29147 and 30111 are paid standards that describe the same flow, but they are guidance, not law.

How to check if you're exposed

Test what an outsider can find today. Run these from a machine outside your network.

# 1. Does a security contact file exist and parse?
curl -sIL https://example.com/.well-known/security.txt | head -n 5

# 2. Is there a policy page at a predictable path?
for p in /security /vulnerability-disclosure /.well-known/security.txt; do
  printf '%s ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' https://example.com$p
done

# 3. Does the security mailbox accept mail and reach a human?
echo "VDP intake test" | mail -s "VDP intake test" security@example.com

Then ask three internal questions. Who reads that mailbox on a Saturday? Who may decide a report is valid? Who may speak to the reporter? If any answer is "nobody" or "I am not sure", a published policy would make a promise you cannot keep.

What to do now

1. Create the mailbox and route it to at least two people. Name an owner for triage.
2. Pick your scope: list production hostnames and the apps you run. Name what is out of scope.
3. Paste the template below into a page on your own domain, edit the brackets you control, and have counsel read the legal sentences.
4. Add a security.txt file that points to the page (see the companion post on deploying it).
5. Put the policy URL in your next questionnaire answer and in your trust center.
6. Send yourself a fake report in week one and time how long it takes to answer.

Here is a plain-text starting point.

Vulnerability Disclosure Policy
Issued: 18 October 2026

We want to hear about security problems in our products. This policy
explains how to report one and what you can expect from us.

Scope
In scope: app.example.com, api.example.com, and our mobile apps.
Out of scope: third-party services we use, social engineering of our
staff, physical attacks, and denial of service testing.

What we allow
Testing against your own accounts and data. Stop and report as soon as
you reach data that is not yours. Do not copy, keep, or share personal
data you encounter.

How to report
Email security@example.com. You may report anonymously. Please include
the affected URL or component, steps to reproduce, and the impact you
see. Encrypted mail is welcome but not required.

What we commit to
If you act in good faith under this policy, we consider your research
authorized and we will not pursue legal action against you. We will
confirm receipt within 3 business days, tell you our assessment within
10 business days, and keep you informed until the issue is fixed. With
your permission we will credit you when we publish.

Disclosure
Please give us a reasonable time to fix the issue before you publish.
We aim to resolve confirmed issues within 90 days and will tell you if
we need longer. We do not offer payment for reports.

Change the numbers to ones you can hit. A missed commitment is worse than a slow one.

How to avoid this trap

The common failure is a policy that promises more than the team can deliver. Avoid it with these controls:

1. Copy response times from your real on-call capacity, not from a competitor's page. If nobody works weekends, say business days.
2. Route the mailbox to a shared inbox or ticket queue, never to one person's address that leaves with them.
3. Set a calendar reminder to review the page every six months and update the issuance date.
4. Keep the "no payment" sentence if you have no budget. Silence invites researchers to assume a bounty exists.
5. Make "out of scope" explicit so you are not asked to authorize attacks on your cloud provider.

Why it matters

A VDP converts a stranger's discovery into a report instead of a post. Without a stated path, researchers choose between guessing an email address and going public. Neither helps you.

For small companies the benefit is also commercial. Procurement teams read the page, check that a named contact exists, and tick a box. Having the page ready removes one blocker from a deal.

Try it yourself

Take the template above and fill every bracket and address for your company. Then ask a colleague outside engineering to read it and answer: where do I send a report, and when will I hear back? If they hesitate, rewrite that sentence. The walkthrough below shows where a published policy sits next to other customer-facing security material.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I Part II and Article 71
• ENISA Single Reporting Platform FAQ
• CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure