Drupal security advisories land on Wednesday afternoons, core ones on the third Wednesday of the month. When one lands, the clock starts — the advisory tells attackers where to look, so unpatched sites get scanned within days. This is the sequence we run on every maintenance client, and it works the same whether you run one site or forty. You’ll need: drush, a staging copy (or the ability to make one), and ten calm minutes.

Read the advisory before touching anything

Go to drupal.org/security and read the actual advisory. You’re looking for three things: which projects are affected (core or a specific module), which versions are fixed, and the risk score. A “Critical” on a module you don’t have installed is a non-event; a “Moderately critical” on your commerce module is your whole afternoon. Check what you’re running:

drush pm:list --status=enabled | grep -i MODULE_NAME
drush core:status | grep "Drupal version"

Take the backup you’d want to have

Before any update, a database dump with a name you’ll recognize at 11 p.m.:

drush sql:dump --gzip --result-file=../backups/pre-update-$(date +%Y-%m-%d).sql

If your host has snapshots (Pantheon, Acquia, most decent VPS panels), take one of those too. Belt and suspenders — this is the step that turns a bad update from an incident into an anecdote.

Update on a copy, never on live first

Pull the update on staging (or a local copy) first:

composer update drupal/MODULE_NAME --with-dependencies
drush updatedb -y
drush cache:rebuild

For core, the package is drupal/core-recommended. Watch the composer output — if it wants to drag twenty other packages along, stop and read why before agreeing.

Click the paths that make you money

Automated tests are great; two minutes of human clicking catches what they miss. On staging, check the front page, log in, create or edit a piece of content, and — if you sell anything — run a test through the cart. The goal isn’t proving the site perfect; it’s proving the update didn’t break the paths that matter.

Ship it to live

Same commands, now with confidence:

git add composer.json composer.lock
git commit -m "Security update: MODULE_NAME to VERSION (SA-XXXX-YYY)"
git push
drush updatedb -y && drush cache:rebuild

(Adjust for your deploy pipeline — the principle is that live gets the exact code staging just proved, not a fresh composer update that might resolve differently.)

Verify live and write it down

Load the site, log in, spot-check the same money paths. Then note somewhere durable what was updated, when, and against which advisory — future-you doing an audit will buy present-you a beer. If anything looks wrong, that backup from step two restores in minutes, which is the whole reason it exists.