.svg)
.svg)
.svg){kind=icon}
.svg){kind=icon}
Someone found a vulnerability in your systems. What happens next?
6 min. reading time - Why vulnerability disclosure requires more than a published policy, what NIS2 and the Cyber Resilience Act mean for your reporting processes, and how to manage external findings without adding to your security team's workload.
A security researcher discovers a vulnerability in one of your applications. They want to report it responsibly. But where do they send it? Who receives the report? And how quickly can your team determine whether it's a genuine security risk?
These questions are becoming increasingly important as organizations face growing expectations around vulnerability handling, disclosure, and regulatory accountability.
A published policy is only the beginning
Let's start by clarifying two terms that are often used interchangeably, yet serve different purposes: A Vulnerability Disclosure Policy and a Vulnerability Disclosure Program.
A Vulnerability Disclosure Policy (VDPolicy) establishes the rules for responsible reporting. It defines which systems are in scope, how researchers can submit findings, and what they can expect from your organization.
Researchers can discover your reporting channel through a security.txt file, in a standardized format defined in RFC 9116. Typically this is published on your website at /.well-known/security.txt. The file must include valid contact and expires fields, as an expired file or an outdated contact address can prevent researchers from reaching the right people, undermining the purpose of having a reporting channel in the first place.
Making your reporting channel discoverable is only the first step.
A Vulnerability Disclosure Program (VDProgram) puts your policy into practice, ensuring that incoming reports are properly managed from submission, acceptance, and prioritization through resolution. When an external report arrives, someone needs to:
- Receive and acknowledge the report through a clearly established reporting channel
- Triage and validate the finding to determine whether the vulnerability is genuine
- Assess and prioritize the risk based on severity, exploitability, and business context
- Coordinate remediation with the responsible technical teams
- Document and communicate the outcome, including updates to the researcher
Without these processes, even a well-written policy can leave important findings sitting unanswered, and potentially expose your organization to regulatory non-compliance.
Why NIS2 and CRA matter
For example, your organization may fall within the scope of NIS2 if it operates in certain critical or important sectors in the European Union (EU), or the Cyber Resilience Act (CRA) if it manufactures or places products with digital elements on the EU market.
NIS2 — Article 21
Organizations within scope must implement appropriate cybersecurity risk-management measures, including vulnerability handling and disclosure.
Cyber Resilience Act (CRA)
For manufacturers of covered digital products, the CRA requires coordinated vulnerability disclosure policies and reporting contact points. Reporting obligations for actively exploited vulnerabilities and severe security incidents took effect on September 11, 2026, with broader requirements coming December 11, 2027.
Importantly, receiving a vulnerability report from an external researcher does not automatically trigger a regulatory reporting obligation. The question is not simply whether your organization has a published policy, but whether your processes can identify, assess, and escalate relevant findings when they arrive.
Who's handling your vulnerability reports?
External reports arrive at unpredictable times, with varying levels of detail and technical accuracy. Some identify genuine vulnerabilities. Others are duplicates, automated scanner results, or findings that don't represent a meaningful risk. Each report still requires attention.
When your team is already managing security operations, remediation priorities, and compliance requirements, maintaining a responsive disclosure program can become another operational burden.
Have you covered the bare minimum?
Create a security.txt in ten minutes at zero cost to you, using the free generator on securitytxt.org. Publish it at /.well-known/security.txt on your website. Congratulation, your reporting channel can now be found.
Publishing a security.txt is quick (check out SignalFisher’s here). However, an effective VDProgram aligned with ISO/IEC 29147 and ISO/IEC 30111 requires more:
- Scope: Which domains, applications and products are covered, and what is excluded?
- Policy: Scope, reporting channel, response times, safe harbor, publicly linked from the security.txt.
- An inbox with an owner: For example security@, with a named person and a deputy, including during holidays.
- A handling process: Acknowledgement, reproduction, severity rating (e.g. CVSS), fix, feedback to the reporter.
- Reporting obligations: Who decides whether a vulnerability is actively exploited, and who reports within 24 hours?
- Maintenance: The security.txt expiry date in your calendar, an annual policy review.
The managed approach to vulnerability disclosure
SignalFisher helps organizations establish and operate their VDPs without adding unnecessary complexity or effort to internal security operations. Our managed service approach includes:
- Dedicated reporting channel: A clear way for external researchers to submit findings
- Expert-led triage: Reports are reviewed, validated, and assessed before escalation
- Coordinated communication: Researchers receive appropriate acknowledgements and updates
- Actionable findings: Your team receives validated vulnerabilities with the context needed to prioritize remediation
- Documented reporting: A structured record of findings and their handling to support internal oversight and applicable compliance requirements
Getting started is free. SignalFisher offers a fully managed VDProgram at no cost for a limited number of annual reports, with expanded managed services available. Your security team can focus on addressing the vulnerabilities that matter, while we handle the reporting process.
Vulnerability disclosure waits. Attackers do not.
Don't forget, a VDPolicy provides a structured channel for external researchers to report vulnerabilities they discover. However, it doesn't guarantee that someone is actively looking for weaknesses across your environment.
This is where proactive, adaptive security testing comes into play. By combining structured vulnerability disclosure with intelligent, context-informed testing activities, organizations can move beyond checking the compliance box and waiting for external reports towards a more coordinated understanding of their exposure.
Confidence in your security doesn't come from having a reporting channel alone. It comes from knowing that vulnerabilities are being discovered, understood, and ultimately fixed.
How confident are you in your current process?
If someone reported a critical vulnerability at your organization tomorrow, would your team know exactly what happens next? SignalFisher can help establish a clear, managed VDP that supports your security operations and applicable regulatory requirements.
Talk to an expert
ABOUT THE AUTHOR
Head of Sales, SignalFisher
Turning security confidence into a competitive advantage.
This article is for informational purposes only and does not constitute legal advice. The applicability of NIS2, DORA, the CRA, and other regulations depends on your organization's activities, products, and jurisdiction. Important to note: Actual enforcement of NIS2 depends on when each EU Member State transposed NIS2 into national law. Not all countries met the October 2024 deadline.
Sources
.png)
