A proposal to automate Drupal updates should make it easier to understand who is responsible for your website. Before approving it, ask your agency or technical team to explain what will happen, what requires a decision and what happens when something goes wrong.
You do not need to review code to make that decision. You need clear answers about the service, the evidence behind an update and the authority you are granting.
1. What exactly will happen automatically?
Ask the provider to describe the process from discovering a security update to confirming it is live. Some services prepare changes for a developer to review. Others can merge approved changes or trigger a production deployment. These are different levels of responsibility.
Request a concrete example: “A module used by our site receives a security update on Wednesday. What happens next, and where do we become involved?” The answer should identify each approval point and the person responsible for acting.
2. Which parts of our website are covered?
Confirm whether the arrangement covers Drupal core, contributed modules, themes and other software dependencies. Ask separately about custom development and the hosting environment. A service that updates Drupal packages does not necessarily maintain the server or assess bespoke code.
Drupal's security advisory coverage has boundaries. Ask for unsupported components to be identified explicitly, with a plan for addressing them. Drupal's security advisory policy explains the distinction.
3. How will you check our important journeys?
“The tests passed” needs context. Ask which activities are tested and whether they reflect how people use your site: submitting an enquiry, finding a document, signing in, completing a transaction or publishing an article.
Automated checks can repeat these activities consistently, but their value depends on their coverage. Ask what still needs manual checking and who performs it. A passing build is useful evidence; it is not a promise that every page and integration is unaffected.
4. What happens when a check fails or cannot run?
Establish whether the update stops, who receives an alert and how it is investigated. A dependency conflict, unavailable test environment and application regression can all block progress for different reasons.
Ask whether any checks are optional and why. Distinguish a successfully checked update from one proceeding under an exception. If repair work is needed, clarify who approves its scope and cost.
5. What authority are we granting?
Decide whether you want approval for each production change or a standing authorisation for a defined category of updates. Both can work when the boundaries fit your organisation.
A standing authorisation should specify the websites, update types, conditions and times it covers. Explain periods when disruption would be particularly costly, such as a public campaign or application deadline. Identify who can pause automation and how quickly that instruction takes effect. Understand whether approving a code change also initiates deployment.
6. How would you recover the website?
Ask when backups are taken, what they contain and when restoration was last tested. Drupal's update guidance calls for backups before updating and checks afterwards. A backup policy should be connected to a practical recovery procedure. See Drupal's update guide.
Recovery affects more than page availability. Restoring an older database might remove submissions or transactions received since the backup. Ask how the team would protect recent information, who would make the recovery decision and how you would be informed.
7. How are urgent vulnerabilities handled?
Routine maintenance schedules need an exception process for urgent security work. Ask who assesses whether an advisory affects your site, who is available to respond and what happens if the usual approver cannot be reached.
Update automation helps apply available fixes; it cannot guarantee that unknown vulnerabilities do not exist. Ask how the provider handles situations requiring temporary mitigation or incident investigation. NIST's definition of a zero-day attack explains why some attacks can precede an available fix.
8. What will we receive afterwards?
Request a record that distinguishes preparation, testing, approval, deployment and live verification. It should say what changed, whether production received it and whether anything remains unresolved.
Agree how blocked updates are reported. Silence should not be interpreted as success. Clarify notification channels, escalation contacts and any additional charges for compatibility work, emergency response or recovery. A useful report gives you evidence without requiring access to every technical log.
These questions provide a way to compare proposals against your actual website and business requirements. For tools such as Sentinel Connector, distinguish the software's role from the responsibilities retained by your agency, hosting provider and internal team.
Start with a defined scope and a review after the first few updates. Examine the records, exceptions and communication, then consider broader automation when the process has demonstrated that it fits your organisation.
If your website does not yet have automated tests or a reliable deployment pipeline, TrueCMS and the team behind Sentinel Connector can help assess the technical gaps and plan improvements with your agency. For contractual, regulatory or legal decisions about authorisation, involve your organisation's appropriate advisers.
