A coordinated vulnerability disclosure policy for a public agency

Reference article · 6 min read

Someone will eventually find a flaw in an agency system and try to tell you about it. It may be a resident who changed a number in a permit portal URL and saw another applicant's documents. It may be a student scanning public address ranges, or a former employee of a vendor. What happens next depends almost entirely on whether the agency decided in advance how it wants to receive that message. Without a published policy, the report lands in a general web contact form or a council member's inbox, gets forwarded twice, and stops. Or it reaches someone who reads "I was able to view records that were not mine" as a confession and refers it to law enforcement.

A coordinated vulnerability disclosure policy, usually shortened to VDP, is a short public document that addresses both failures. It tells finders what systems they may test, how to send a report, what the agency promises in return, and that the agency will not pursue legal action against people who follow the rules. It is not a bug bounty. No money changes hands and the policy creates no obligation to pay anyone. That distinction matters in the approval conversation, because a VDP can usually be adopted without a procurement action.

What the policy contains

Workable policies tend to run one to three pages and cover the same elements:

• Scope. Which domains, applications, and address ranges are in scope, and what is explicitly out. Be concrete. Many agencies start narrow, with public-facing web properties only, and expand later. Name the systems you are actually prepared to fix.
• Prohibited techniques. Denial of service, social engineering of staff, physical intrusion, and scanning that degrades service are commonly out of bounds. So is accessing, modifying, or retaining more resident data than is needed to demonstrate the issue.
• How to report. A single dedicated address, commonly security@ the agency domain, or a simple form. Say what a useful report includes: the affected system, steps to reproduce, and the impact. Offer an encryption option if you can support one.
• Safe harbor. A statement that the agency considers good faith research conducted under the policy to be authorized, will not initiate or recommend legal action, and will make that authorization known if a third party pursues action.
• Response commitments. A window for acknowledging receipt and a cadence for status updates. Pick intervals the team can meet. A policy promising same-day acknowledgment that the agency misses is worse than one promising several business days and honoring it.
• Coordination and credit. How long the agency asks for before public disclosure, and whether finders may be named.

International standards describe disclosure and handling processes, and federal agencies have published template language that state and local governments frequently adapt. These are useful starting points, but versions and guidance change, so confirm the current source before copying text.

Who signs off

A VDP creates legal exposure and public commitments, so the security team cannot adopt it alone.

1. Counsel, for the safe harbor language. The agency can promise not to sue and not to refer a matter for prosecution. It cannot bind a state attorney general, a district attorney, or federal prosecutors, and the policy should say so plainly rather than imply blanket immunity. Federal and state computer crime statutes still apply, and prosecutorial policy regarding good faith security research has shifted over time, so ask counsel for the current posture.
2. The elected body or governing board, where local practice requires policy adoption by resolution. Even where it does not, a brief public agenda item settles the later question of who authorized inviting the public to test government systems.
3. The records officer, because every report becomes an agency record the moment it arrives.
4. Communications and the executive, so no one is surprised when a finder writes publicly about an issue after it is fixed.

Routing and triage

Send reports to a monitored shared mailbox that feeds a ticket queue, never to a named individual. Assign one owner for the clock and one backup. Expect volume to be mixed: real findings will arrive alongside automated scanner output and low-value notices about mail records or missing headers. Write a short template reply for those so the queue does not stall.

Most reports at the local level will concern a system the agency does not operate: a hosted permit or licensing portal, a content management platform, a payment processor. Forward the technical detail to the vendor's own disclosure channel, but keep ownership of the relationship with the finder. Do not hand off the reporter and go quiet. Track vendor-owned findings in the same queue with the vendor named as the remediation owner, and escalate through the contract manager when a fix stalls.

Public records and the report itself

A vulnerability report is a record, subject to retention and potentially to disclosure. Many states exempt records that would reveal security vulnerabilities or IT security plans, but the exemptions vary in scope, some are permissive rather than mandatory, and some weaken once the issue is remediated. Confirm with counsel before the policy is published.

Two practical consequences follow. First, the policy should say the agency will protect a reporter's identity to the extent the law allows, not promise absolute confidentiality. Second, keep reporter contact information in a separate field or system from the technical narrative so redaction is straightforward later.

What to ask vendors and require in contracts

Before renewal or award, ask each vendor operating a public-facing system:

• Do you publish a disclosure policy and a security contact, and will you accept reports we forward?
• What are your acknowledgment and remediation targets by severity, and how are they measured?
• Will you notify us of vulnerabilities in our tenant, including those reported by others?
• May the agency or a third party test the hosted instance, under what notice and conditions?

In the contract, name a security contact, require acceptance and status reporting on forwarded reports, require notification to the agency, and confirm that nothing prevents the agency from acknowledging a resolved issue publicly.

How to start

Publish one page. Stand up the mailbox and the queue. Write a one-page internal runbook that names the triage owner, the severity scale, and the escalation path. Walk the team through one invented report before the policy goes live. Review the scope annually as systems are added.

HQT works with state and local agencies on security program design and the technical remediation work that follows a report.

Frequently asked questions