On GovCMS PaaS, your agency owns Drupal security patching. For applicable online-service vulnerabilities, ISM-1876 requires patches, updates or vendor mitigations within 48 hours of release when the vendor rates the issue critical or a working exploit exists. ISM-1690 specifies two weeks for vendor-rated non-critical vulnerabilities without working exploits. Meeting the deadline takes prepared testing, a working release pipeline and evidence of the production outcome. (GovCMS responsibilities; ASD control mapping.)
Sources checked: 19 October 2026 (AEDT).
The October 2026 Drupal core security release brought that responsibility into focus. GovCMS announced that it would patch its SaaS distribution “inline with highly critical SLA (within 48hrs)” and urged PaaS owners to act similarly. A PaaS team still had to assess its application, prepare the update, test it and release it. That work cannot wait until someone finds a convenient maintenance window. Our team has hands-on experience running security patching for GovCMS PaaS sites. This article sets out the workflow we recommend, with the official requirements kept distinct from our operational judgement. (GovCMS hotfix notice.)
Who patches what on GovCMS SaaS and PaaS
The Department of Finance manages GovCMS, but application responsibility depends on the service selected. GovCMS’s pricing comparison and security guidance draw the boundary clearly.
| Responsibility | GovCMS SaaS | GovCMS PaaS |
|---|---|---|
| Infrastructure maintenance | GovCMS | GovCMS |
| Drupal security updates and application maintenance | Included in the managed service | Agency, using its team or a service provider |
| Theme, content and user accounts | Agency | Agency |
| IRAP assessment | GovCMS describes its SaaS assessment as covering the service | GovCMS covers infrastructure; the agency arranges and funds application assessment |
Access to an updated GovCMS distribution does not deploy it to your PaaS website. Your team must complete that release. This ownership should be explicit in the operational handover for any GovCMS PaaS build.
GovCMS’s maintenance guidance says it will intervene if security updates fall behind, adding: “This will mean additional costs that will be billed to your project.”
What 48 hours means under the Essential Eight
The three controls to understand
For a public Drupal site, three controls deserve particular attention:
-
ISM-1876: patches, updates or other vendor mitigations for online-service vulnerabilities must be applied “within 48 hours of release” when vendors assess them as critical or working exploits exist.
-
ISM-1690: the corresponding timeframe is “within two weeks of release” only when vendors assess the vulnerability as non-critical and no working exploit exists.
-
ISM-1698: use a vulnerability scanner at least daily to find missing patches or updates for online-service vulnerabilities.
The first two appear in the ISM system management controls; the third is in the security assurance controls.
These online-service requirements apply at Maturity Level One, Two and Three, as shown in ASD’s Blueprint for Secure Cloud. Meeting them addresses part of an agency’s Essential Eight obligations; patching alone does not establish overall compliance.
The clock starts before your ticket
Record the release time of the relevant patch or vendor mitigation. Your triage meeting, change approval and ticket creation do not provide a later starting point.
There is also an escalation trigger. ASD’s FAQ ties the working-exploit deadline to the announcement of a working exploit or evidence that exploitation is occurring, whichever comes first. Reassess an open advisory when that evidence changes.
Our recommendation is to plan in elapsed hours, including nights and weekends. Drupal’s normal security window is Wednesday 16:00–22:00 UTC: Thursday 03:00–09:00 AEDT, or 02:00–08:00 AEST. Australian teams can start their working day with several hours already gone.
Mapping Drupal risk levels to response timeframes
Drupal’s risk calculator combines six metrics into a score out of 25. The table below is our recommended triage policy, rather than an ASD-published mapping of Drupal labels.
| Drupal rating | Recommended target for an affected site | Reason |
|---|---|---|
| Highly critical, 20–25 | Within 48 hours | Vendor-assessed criticality |
| Critical, 15–19 | Within 48 hours | We treat Drupal’s Critical label as meeting the criticality trigger |
| Moderately critical, 10–14 | Within two weeks, unless a working exploit exists | Both conditions for the longer timeframe must hold |
| Less critical, 5–9 | Within two weeks, unless a working exploit exists | Reassess if exploit evidence changes |
| Not critical, 0–4 | Within two weeks, unless a working exploit exists | A low score does not cancel the exploit trigger |
Confirm this interpretation with your agency’s IT security adviser or IRAP assessor. Check current exploit intelligence as well as the advisory’s E metric; do not wait for the displayed score to change before escalating.
A practical 48-hour runbook for GovCMS PaaS
These are suggested, overlapping time boxes measured from the applicable clock start. They are planning targets, not a promised service SLA. If detection is late, work with the time remaining and escalate immediately.
1. Hours 0–2: detect and triage
Monitor Drupal security advisories and public service announcements, the GovCMS status page and GovCMS GitHub releases. Our security autopilot article describes how these feeds support update preparation.
For each site, identify affected versions, installed modules, relevant configuration and any vendor mitigation. Record the advisory ID, urgency decision, deadline, engineer and production approver. An assumption that a code path is unused needs evidence. Where impact remains uncertain, escalate the assessment while release preparation continues.
2. Hours 2–6: apply an available vendor mitigation
If the patch cannot be released immediately, assess the mitigation specified by the vendor. For SA-CORE-2026-014, Drupal identified uninstalling Field UI, field_ui, as protection while updating. (Drupal advisory.)
Review the operational impact, notify affected administrators and verify that the change took effect. Carry the intended configuration through the release workflow so a later deployment does not undo it. Record its application time and the vulnerability it addresses.
We would use a documented vendor mitigation where appropriate, then complete the update. Confirm the approach with the agency’s security adviser.
3. Hours 2–24: build a controlled release
Prepare a dedicated update branch. Apply the relevant Composer changes and commit composer.lock so reviewers can see the resolved dependencies. Where the project uses them, review the current GovCMS distribution, Lagoon images and scaffold components against the release notice.
Keep unrelated feature work out of the emergency change. Check custom patches and dependency conflicts early. Agree the production approval route, backup and recovery arrangements before testing finishes. A security update should have an established emergency change route through the agency’s process.
Our delivery automation service brings these build, deployment and handover tasks into a repeatable pipeline.
4. Hours 6–36: test the release and deployment
Run the checks that protect the website’s actual risks: static analysis, unit tests, editorial workflows, public-site journeys and visual checks on important templates. Our quality gates guide explains how to build that coverage.
Rehearse database updates and configuration imports in a suitable non-production environment. Review configuration differences in CI/CD before promotion; a package build alone does not prove that the application will deploy correctly.
Give the UAT reviewer a reachable environment, a focused test list and a decision deadline. Keep essential tests ready before an advisory arrives. The incident window is a poor time to discover that nobody knows how to test login or publishing.
5. Hours 24–48: deploy and verify production
Promote the reviewed release through the established pipeline. Execute the project’s database updates, configuration import and cache rebuild, rather than relying on a code deployment alone. Drush’s deployment workflow documents the relationship between these tasks, including drush updatedb.
Confirm the installed production version and the outcome of each relevant advisory. Run smoke tests against the live service and check application errors. Preserve the release identifier, pipeline result and verification time.
A successful UAT deployment is preparation for this step. The evidence must identify what reached production.
6. At completion: reconcile and close
Capture evidence throughout the work, then reconcile it when the release is verified. Close resolved advisories individually, retain any remaining mitigation and schedule outstanding work.
If a deadline was missed, record when, why, the exposure and the corrective action. A completed ticket with no production evidence leaves the central question unanswered.
What the October 2026 release showed
Advance warning creates preparation time
Drupal published PSA-2026-10-12 on 12 October, announcing a 14 October security release window. GovCMS’s hotfix notice carries an initial timestamp of 13 October, 15:19 AEDT. That sequence explains the advance notice; it does not establish that the patch was available on 13 October.
The GovCMS incident record reported SaaS production completion at 21:45 AEDT on 15 October. Its earlier notice timestamp cannot establish elapsed patching time or any PaaS site’s compliance.
Critical already justified a rapid response
SA-CORE-2026-014 was rated Critical, 19/25, with E:Theoretical. Under Drupal’s scoring rules, changing only that metric to E:Proof would add one point and reach Highly critical.
That is a conditional calculation, not evidence that a public proof of concept appeared or Drupal reclassified the advisory. Our practical conclusion is to prepare Critical core updates for the 48-hour track immediately.
One release can resolve several advisories
Drupal 11.3.19 addressed SA-CORE-2026-014, SA-CORE-2026-015 and SA-CORE-2026-016. GovCMS hotfix 4.5.1.2 incorporated that update.
Assess each finding, then deliver a compatible release once. Uninstalling Field UI addressed the mitigation for 014; it did not resolve the other two advisories. GovCMS also stated that PaaS deployment schedules were unaffected by its SaaS rollout.
The same notice assigned the Gin theme update, SA-CONTRIB-2026-219, to site owners with a 30-day target. That notice-specific target does not extend an applicable Essential Eight deadline. For non-critical online-service vulnerabilities without working exploits, ISM-1690 still specifies two weeks.
Evidence to retain for review
We recommend one linked record per site and advisory, containing:
-
Timing: release and relevant exploit-trigger timestamps, assessment time and deadline.
-
Decision: affected versions, applicability, risk rating and the reason for the chosen response.
-
Action: mitigation details, production deployment time and the release or commit identifier.
-
Verification: approval, test results, deployment logs and confirmation of the production version.
-
Exceptions: missed targets, remaining exposure, an owner and the next action.
For daily scanning, identify which vulnerability scanner covers the online service and retain its schedules, results and follow-up. Drupal Update Status, Composer audit output and inventory monitoring can contribute evidence, but selecting a tool does not by itself demonstrate ISM-1698. Confirm scope and coverage with the assessor.
To organise records across sites, SentinelConnector offers paid-plan patching targets from six hours to 28 days and monthly outcome reports. The SentinelConnector help guide explains its monitoring and reporting features.
Disclosure: TrueCMS builds and maintains SentinelConnector. Its inclusion is our product recommendation; GovCMS and ASD do not require it.
It does not install patches. Within GovCMS, its connector is suited to PaaS; SaaS agencies cannot independently add modules outside the GovCMS distribution.
Its records distinguish an observed fix from later confirmation; neither establishes installation time. The published example report starts its clock at advisory publication or site addition, whichever is later. Adding a site cannot reset an Essential Eight deadline. Check which evidence the actual report used, reconcile it with the applicable ASD trigger and retain deployment records. Missing or stale observations are not proof of a met deadline.
If you cannot meet 48 hours
Act before the deadline. Apply a suitable vendor mitigation, verify it and involve the agency’s IT security adviser. Record any exception, remaining risk and the update plan. ASD’s patching guidance supports mitigations followed by patching and explains that change freezes do not remove the need to address vulnerabilities.
If capacity is the obstacle, GovCMS’s maintenance guidance calls for a support arrangement. The Drupal Services Panel is one procurement route.
We can help review the release process through Drupal support and delivery automation. Request a free support audit to discuss delivery risks and practical improvements. Bring an example advisory and its change record: the useful question is whether your team can take the next update from detection to verified production within the required time.
Frequently asked questions
Who is responsible for Drupal security updates on GovCMS PaaS?
The agency is responsible for Drupal application updates, including core and modules, using its own team or a service provider. GovCMS maintains the underlying infrastructure. GovCMS applies the managed Drupal updates on SaaS.
Source: GovCMS security responsibilities.
How quickly must a GovCMS PaaS site apply a critical Drupal security update?
Where ISM-1876 applies, the timeframe is 48 hours from release of the patch, update or vendor mitigation for a vendor-rated critical vulnerability. Working exploits also trigger urgent action. ISM-1690 allows two weeks only for non-critical vulnerabilities without working exploits.
Source: ASD Essential Eight and ISM mapping.
Does Drupal Critical fall under the 48-hour timeframe, or only Highly critical?
Our recommendation is to treat both Drupal Critical, scored 15–19, and Highly critical, scored 20–25, as vendor-assessed critical. Confirm that interpretation with your security adviser or IRAP assessor, and escalate any affected vulnerability when a working exploit exists.
Source: Drupal risk levels.
What happens if a GovCMS PaaS site falls behind on security updates?
GovCMS says it will carry out overdue security updates and bill the project. Agencies without the necessary skills or capacity should arrange ongoing support with a service provider.
Source: GovCMS maintenance guidance.
What can we do if a patch cannot be deployed within 48 hours?
Apply and verify a suitable vendor mitigation where available, record the action and consult your security adviser. For SA-CORE-2026-014, Drupal specified uninstalling Field UI. Complete the update afterwards and assess other advisories separately.
Source: Drupal SA-CORE-2026-014.
When are Drupal security releases published in Australian time?
The usual Wednesday 16:00–22:00 UTC window is Thursday 03:00–09:00 AEDT or 02:00–08:00 AEST. Core windows are normally the third Wednesday of the month; contributed-project windows are weekly. Exceptional releases can occur outside those windows.
Source: Drupal release timing.
