One in Ten Breaches Targets a Website: Why Government Needs a Patch Management Policy

Roughly one in ten breaches in Verizon's 2026 Data Breach Investigations Report (DBIR) was a basic web application attack, meaning an attack aimed directly at a website or web app, and in the 2025 edition that share was 18%. For a government agency, the public website is the most visible piece of that exposure, and it is usually maintained by an IT team with a long list of other priorities and, often, no written patch management policy.

It's a Wednesday afternoon. A county IT director has a budget meeting at three, a help-desk queue that hasn't moved since lunch, and a new batch of advisories from the Drupal Security Team in her inbox. Some of them may affect the county website. Deciding which ones, and whether they can wait until next month, is now somebody's job, and in most agencies nobody has written down whose.

The latest breach research shows how common this is. When IT leaders ask me how often a government website should apply security updates, my answer starts somewhere most security conversations skip: a written patch management policy. On paper, the 43-day patch gap in this year's data looks like a technology problem. In practice, it comes down to who owns the decision to update and how fast they have agreed to move.

What does 2026 breach data say about government websites?

Exploiting a known software vulnerability is now the most common way public sector breaches begin. The DBIR public snapshot stated that exploitation was the initial access vector in 40% of public administration breaches, twice the share that started with phishing, across 2,410 confirmed breaches in the sector.

Across all industries, Verizon reports that exploitation started 31% of breaches, the first time in the report's 19-year history that it passed stolen credentials as the top entry point (Verizon, May 19, 2026). The same announcement says attackers are using AI to shrink the window between a public disclosure and a working exploit from months to hours. A public website runs on a core platform plus dozens of contributed modules, and every unpatched module is a place where that window can open.

How long are organizations taking to patch?

Most organizations patch far more slowly than attackers move. The 2026 DBIR executive summary puts the median time to fully resolve a critical vulnerability at 43 days, up from 32 days a year earlier, and found that only 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities catalog were fully remediated in 2025.

Federal civilian agencies now work to a much shorter clock. CISA's Binding Operational Directive 26-04, issued June 10, 2026, replaced the timelines in BOD 22-01 with deadlines based on risk. A vulnerability on an internet-facing system that is already being exploited, can be exploited automatically, and gives an attacker full control must be fixed within three days. Lower-risk combinations get 14 or 60 days, and the lowest-risk issues can wait for the next scheduled upgrade.

The directive binds federal civilian agencies only, and state and local agencies adopt it voluntarily. CISA has long recommended that state and local governments use the same Known Exploited Vulnerabilities catalog to prioritize their fixes. Measured against the new three-day tier, a 43-day median is more than 14 times too slow for the flaws attackers can exploit at scale.

When I talk with public sector IT and web leaders, including the people I met at the National Association of Government Web Professionals (NAGW) conference in October, patching is something they care about and rarely something anyone owns on paper. Their vulnerability management tools are good at finding problems, and the gap opens after that, when nobody has written down how fast the fix goes live. The website competes with a long list of higher-stakes priorities, so a security update waits its turn like everything else. A 43-day median is what that looks like at scale.

Why does a government website need a patch management policy?

Before I started Promet, I coordinated functional and maintenance releases at Nextel across internal and external development groups. Release work at that scale is change management at heart, and it taught me that most of the effort goes into coordination: agreeing who decides, who tests, and who signs off, then writing it down so the next release follows the same path.

Years later, I worked on ThirdPartyTrust, a platform where companies share their information security governance profile with partners through a standard questionnaire. Reviews like those ask about written policy and accountability alongside tools, because a documented process is something an auditor or a partner can actually check, and it says more about an organization’s security posture than any product list.

Government agencies already handle other public commitments this way. Many states set response deadlines for public records requests, and agencies build staffing and workflows around them. An effective patch management policy belongs in the same category: a short set of written procedures, approved by leadership, that says how fast critical fixes go live and who is accountable for getting them there. In my experience, agencies often have patch management policies for laptops and servers, and the public website is the system that gets left out.

How often should a government website apply security updates?

Government websites should apply fixes for exploited, internet-facing vulnerabilities within three days and other critical security updates within a week, then handle routine updates on a fixed, tested schedule. That cadence matches the three-day tier in CISA's BOD 26-04, the federal standard for the most dangerous flaws, which state and local agencies can adopt voluntarily.

For Drupal sites, the Drupal Security Team publishes contributed-module fixes in a window every Wednesday and core fixes usually on the third Wednesday of the month, and highly critical fixes can arrive outside those windows. On Wednesday, October 14, 2026, the team released a critical core fix (SA-CORE-2026-014) for a remote code execution flaw affecting all supported versions of Drupal core, and warned that exploits might be developed within hours or days. A week later, PHP, the language Drupal and WordPress run on, issued emergency fixes for two critical flaws, and several European governments took websites offline while they patched. A written target turns weeks like those into routine triage.

Here is the tiered patch management policy I would put in front of an agency's leadership as a starting point. Adjust the timeframes to your own risk assessment and any state or local compliance requirements that apply.

Will faster patching break the website?

It's a fair concern, and it is the main reason I see agencies hold updates back. A module update can change how a form validates or how an integration passes data, and when updates go straight to production, residents tend to find those problems first. Speed and stability come from the same place: a test environment that every update passes through before it reaches the live site, with visual and functional checks on the pages residents use most, then a patch deployment during low-traffic hours with a rollback plan ready. Patch testing is where most of the effort should go.

Billing matters here too. When every update is billed by the hour, an agency has a budget reason to wait, and small updates pile up into larger, riskier releases. If you are reviewing a support plan, this breakdown of Drupal support tiers shows the response times for critical updates worth asking any provider about.

How secure is Drupal for government websites?

Drupal backs its open-source code with a long-established security process. According to the Drupal Association, its Security Team has coordinated private vulnerability disclosure for more than two decades, fixing and reviewing issues out of public view before publishing scheduled advisories that cover Drupal core and tens of thousands of contributed modules.

That process ends with a tested fix and a public advisory, and applying the fix is the site owner's job. Once an advisory is public, attackers can read it too, which is why the speed of patching matters as much as the quality of the code. In my experience, a Drupal site that applies security patches as soon as they are released is one of the most secure platforms a government agency can run. I have written about why public sector websites struggle and how open source helps, and our team has covered why auditable code matters for government.

Where should IT teams start with patch management policies?

Start your patch management policy with a written target for critical patches, since that one decision closes most of the distance between a 43-day median and the three-day federal tier. Then check the rest of your patch management process against these five points:

1. A current inventory of every module, theme, and plugin on each site, including legacy software that is no longer supported, plus the server software they run on.
2. A named owner for the weekly security advisory review.
3. A staging environment that every update passes through.
4. Tests that cover the forms, payment pages, and integrations residents use most.
5. A monthly patch compliance report to leadership on what was patched, when, and on which sites, which is how the policy gets enforced.

October is Cybersecurity Awareness Month, which makes it a good time to get a policy in place. The question worth asking your own team this week is a simple one: if an advisory lands on Wednesday, who decides when the fix goes live, and is that decision written down anywhere?

Frequently asked questions

What is the process for patch management?

A patch management process follows the same cycle each time: identify the advisories that affect your sites, apply each update to a staging copy, run patch testing on the pages and forms residents use most, then release it to production on a set deployment schedule and document what changed. NIST’s SP 800-40 frames it as finding, prioritizing, deploying, and verifying fixes.

How quickly should critical vulnerabilities be remediated?

Critical vulnerabilities that are already being exploited on internet-facing systems should be fixed within three days, the tightest deadline in CISA's BOD 26-04. That matters because the median organization took 43 days to fully resolve a critical vulnerability in 2025, according to Verizon's 2026 Data Breach Investigations Report.

What are the CISA vulnerability remediation timeframes?

Under BOD 26-04, issued June 10, 2026, federal civilian agencies have three days to fix the highest-risk known exploited vulnerabilities, with 14 or 60 days for lower-risk combinations and the lowest-risk issues deferred to the next scheduled upgrade. The directive replaced the timelines in BOD 22-01 and binds federal agencies only.

How often should patch management be performed?

Patch management should run continuously, with a weekly review of new security advisories and a scheduled update cycle every two to four weeks for non-critical fixes. For Drupal sites, the Drupal Security Team publishes contributed-module advisories in a window every Wednesday, which makes a weekly review the natural rhythm for government web teams.

Does a patch management policy help with compliance?

Yes. A written patch management policy gives auditors and oversight bodies a documented standard to check against, and a monthly patch compliance report shows whether the agency met it. Aligning critical-patch targets with the three-day tier in CISA’s BOD 26-04 also shows the policy follows a published federal benchmark, even where it is not required.

When should system security updates be applied?

Apply security updates after they pass through a staging environment, and schedule the production release for low-traffic hours. Critical fixes for exploited, internet-facing flaws should still go live within three days, the timeline CISA set in BOD 26-04 for the most dangerous vulnerabilities on federal systems.

What are the NIST guidelines for patch management?

NIST’s main guidance is Special Publication 800-40 Revision 4, Guide to Enterprise Patch Management Planning, published April 6, 2022. It treats patching as preventive maintenance and a routine cost of running technology, and recommends an organization-wide strategy for finding, prioritizing, deploying, and verifying patches to reduce risk.

If you're exploring support for keeping your Drupal or WordPress updates current and tested, see how Fully Managed Updates works.