security.txt: Why Vulnerability Reports Are Now a GRC Topic

On 6 August 2026, the BSI reported that only 1.8 percent of website operators in Germany currently provide a security.txt file. The finding is based on measurements conducted as part of the BSI Cyberdome project. security.txt, defined in RFC 9116, is intended to give security researchers, CERTs and other reporters a clearly discoverable way to submit vulnerabilities safely and quickly.

What may look like a small technical file is actually an important governance signal. Without a clear reporting channel for vulnerabilities, companies risk that critical information arrives late, reaches the wrong team or is not processed at all. In the context of NIS2, the Cyber Resilience Act, DORA and increasing expectations for vulnerability management, this has become a clear GRC issue.

Key Takeaways

The BSI reports that only 1.8 percent of website operators in Germany currently provide a security.txt file. The file is defined in RFC 9116 and gives organisations a standardised, machine-readable way to publish security contact information. It is typically made available under /.well-known/security.txt.

security.txt is not a complete vulnerability management strategy. It is an entry point into a structured Coordinated Vulnerability Disclosure process. For GRC teams, the key question is therefore not only whether the file exists, but whether there is a reliable process behind it for receiving, assessing, escalating, remediating and documenting vulnerability reports.

What Is security.txt?

security.txt is a simple text file published on a website. It contains security contact information and additional details on how vulnerabilities should be reported. RFC 9116 describes security.txt as a machine-readable format that allows organisations to disclose their vulnerability disclosure practices so researchers can report security issues more easily.

The file can include a contact address, a link to the vulnerability disclosure policy, encryption information, preferred languages and an expiry date for the information. However, the most important point is not the file itself. The real value lies in what happens behind it: a reachable, accountable and operationally capable process.

Why the BSI Signal Matters

The BSI figure of 1.8 percent shows a large gap between technical feasibility and organisational implementation. security.txt is relatively easy to deploy. Still, the vast majority of website operators in Germany do not provide it.

The problem is not only a lack of visibility. It is a lack of process clarity. If an external researcher finds a critical vulnerability, they need a reliable contact quickly. If they have to rely on general contact forms, switchboards or unclear email addresses, valuable time is lost.

The same issue is also described by Swiss authorities: security contacts are often difficult to find or not published at all. This forces the reporting person to search for the right contact, explain the issue multiple times and risk that the report is not forwarded or is ignored.

For companies, this is a clear risk. A vulnerability that does not reach the right internal team in time can later become an incident, a data breach, a customer issue or a regulatory finding.

security.txt Is Not an IT Gimmick, but Governance

Many companies treat security.txt as a technical task for website administrators. That misses the point. The real question is not whether a text file can be placed on a web server. The real question is whether the organisation can reliably receive, assess, escalate and track vulnerability reports.

This requires clear responsibilities. Someone must review incoming reports, assess criticality, initiate technical analysis, involve legal or data protection teams where needed, inform product teams and document remediation actions. If these steps are not defined, even the best contact address will not help much.

This makes security.txt an entry point into governance, risk and compliance. It shows whether the organisation is capable of processing external vulnerability information in a controlled way.

The Link to Coordinated Vulnerability Disclosure

Coordinated Vulnerability Disclosure describes the structured handling of reported security vulnerabilities. The goal is to enable researchers, manufacturers and operators to work together so vulnerabilities can be reported, assessed, remediated and communicated responsibly.

security.txt can support this process, but it does not replace it. Without a CVD process behind it, the file remains little more than a contact directory. A functioning process needs defined intake channels, accountable owners, triage, risk assessment, technical analysis, escalation paths, communication with the reporter and documented remediation tracking.

For GRC teams, this is especially relevant because CVD connects several disciplines: cybersecurity, legal, compliance, data protection, product management, IT operations, vendor risk and incident management.

Why CRA, NIS2 and DORA Make This More Important

security.txt is not automatically a legal requirement. Companies should therefore avoid claiming that the Cyber Resilience Act or NIS2 directly require a security.txt file. The decisive point is the broader regulatory context: vulnerability management, reporting processes and cyber resilience are becoming more binding.

The Cyber Resilience Act introduces requirements for products with digital elements. These include vulnerability management, security updates, product documentation and reporting obligations. The first CRA reporting obligations apply from 11 September 2026, while the broader requirements apply from 11 December 2027.

NIS2 strengthens the focus on risk management, incident handling and reporting processes. DORA requires financial entities to maintain robust ICT risk management, incident reporting, resilience testing and third-party risk management.

All these frameworks have one thing in common: companies must be able to detect, assess, escalate and evidence security information faster. security.txt is a small but visible building block in that process.

What Belongs in a Good security.txt File

RFC 9116 describes several fields. Particularly important are Contact and Expires. The Contact field specifies how vulnerabilities can be reported. The Expires field indicates until when the information should be considered current. Outdated or incorrect information can result in security reports not being received or being sent to the wrong contact.

In practice, a security.txt file should at least include a reliable contact channel. A link to the disclosure policy, encryption information, preferred languages, a canonical URL and an expiry date are also useful. The key requirement is maintenance. An outdated security.txt can create more risk than value.

Common Mistakes in security.txt Implementation

In practice, security.txt rarely fails because of technology. It fails because of organisation and maintenance. A contact address may exist, but no one checks the mailbox regularly. Reports may arrive at a general support team that cannot perform security triage. Or a policy may exist, but internal escalation paths are unclear.

Another risk arises when external service providers are not included. Many vulnerabilities affect hosting, SaaS applications, external developers, open-source components or cloud infrastructure. If it is unclear who needs to be involved in such cases, reports may remain unresolved or be handled incompletely.

The result is problematic: the company appears reachable from the outside but cannot process the incoming information in a controlled way internally. This is exactly where GRC risk emerges.

What GRC Leaders Should Check Now

GRC leaders should not treat security.txt in isolation. A short but structured review of the broader vulnerability disclosure process is more useful.

Companies should check whether they provide an up-to-date security.txt file on all relevant domains and whether it is correctly available under /.well-known/security.txt. They should also verify whether the listed contact channel is actively monitored, whether a disclosure policy exists and whether intake, assessment, escalation and remediation are documented.

In addition, responsibilities across security, legal, data protection, product management and external service providers should be clarified. In the end, the decisive question is not only whether a report arrives, but whether it is assessed, prioritised and closed in a traceable way.

Why Excel and Mailboxes Are Not Enough

Many companies start with an email address such as security@example.com and an Excel list for vulnerabilities. That may work initially. But it does not scale well once multiple products, locations, service providers, systems and regulatory requirements are involved.

The challenge lies in the connections. A report often relates to a specific asset or product. That product has an owner, a criticality level, technical dependencies and potentially regulatory relevance. This creates actions, deadlines, escalations, service provider tasks and evidence requirements.

If this information is spread across emails, tickets, Excel files and document repositories, uncertainty arises. In a critical situation, it becomes unclear what was decided, when it was decided, who was responsible and whether the measures were effective.

Conclusion: security.txt Is Small, but Strategically Important

The BSI figure of 1.8 percent shows that many companies still have work to do on a simple but important building block of vulnerability management. security.txt is technically easy to implement. The real challenge lies in the organisation behind it.

A clear reporting channel is only effective if reports are assessed, escalated, remediated and documented. This is exactly where security.txt becomes a GRC topic.

Companies should now check whether they provide security researchers and CERTs with a reliable contact and whether a robust CVD process stands behind it. Organisations that approach this in a structured way improve not only their ability to respond to vulnerabilities, but also their readiness for CRA, NIS2, DORA and ISO 27001.

Zazoon helps companies connect vulnerability reports, risks, controls, responsibilities and evidence in one central place. This turns a simple file into an effective component of modern cyber governance.

FAQ

What is security.txt?

security.txt is a text file published on a website that contains security contact details and information on how vulnerabilities should be reported. It is defined in RFC 9116.

Where is security.txt placed?

For web-based services, RFC 9116 provides for the path /.well-known/security.txt. A file in the root directory may also exist for compatibility reasons, but the well-known path is the key location.

Is security.txt legally required?

No, security.txt is not generally required by law. However, it is a useful building block for Coordinated Vulnerability Disclosure and a visible element of mature vulnerability management.

Why is security.txt relevant for GRC?

Because vulnerability reports require clear processes, responsibilities, risk assessments, escalations, actions and evidence. This makes security.txt relevant for governance, risk and compliance.

What did the BSI report?

The BSI reported on 6 August 2026 that only 1.8 percent of website operators in Germany currently provide a security.txt file.

Is security.txt enough for good vulnerability management?

No. security.txt is only the intake channel. Companies also need triage, assessment, escalation, remediation, communication and documentation.

How does Zazoon support vulnerability management?

Zazoon helps companies centrally manage vulnerability reports, risks, actions, responsibilities, regulatory requirements and evidence. This makes vulnerability disclosure traceable, efficient and audit-ready.