What Drupal security hardening covers and why it never finishes
Drupal security hardening is the set of configuration, access, file and update controls applied to Drupal core and contributed code, then repeated on every release window. It matters most for a live Drupal site that holds customer or staff data and needs a defined, repeatable security posture. The work covers the codebase, the web server and database configuration, the accounts that can change content or settings, and how the site is deployed and monitored after go-live. Treat it as an operating routine with named owners and a fixed review calendar, because a one-time cleanup before launch will not stay true for long.
The work is harder than it looks for three reasons. First, the Drupal Security Team publishes advisories with CVE identifiers and risk scores, and security releases use Wednesday windows, with the core release schedule placing them on the third Wednesday of the month. Second, contributed modules carry their own advisories, so a site with core fully patched can still be exposed through a module that a former developer installed and no one has tracked since. Third, roles and settings drift. A temporary administrator role created for a migration, a permission granted to a content team for one campaign, or a text format changed by an editor can all persist after the reason for them has passed.
Because of that drift, hardening is a check against the live site, not a checklist completed at launch. A recurring review usually covers the permissions and roles matrix, the protection of the file system and the settings.php file, the trusted host patterns that the site accepts, the two-factor authentication approach for privileged accounts, and an inventory of core and contributed dependencies. Ask whoever will run this work to show you where each of these items is recorded, who signs off on changes, and how a finding from a security release turns into a dated change on the site.
Which Drupal parts need hardening and what each one controls
A Drupal site is hardened in layers, and each layer controls a different part of the attack surface. The cards below separate the code, configuration, files, accounts, server and runtime so that a review can assign an owner and a check to each one.
Drupal core and Composer dependencies
Drupal core and the Composer-managed libraries it pulls in define the code that runs on every request. Hardening starts with knowing the exact core and library versions in the lock file and applying Security Team advisories in the next Wednesday security release window. Check whether the site receives security releases in a timely way and whether Composer updates are reviewed before they reach production.
Contributed modules
Contributed modules extend Drupal with code maintained by different teams, and each one adds its own attack surface. Inventory every contributed project, its installed release and its advisory history, and remove modules that are no longer needed. Confirm that each module still has a maintainer and supports the current Drupal major version before it stays in the build.
settings.php and trusted host patterns
The settings.php file holds the database credentials, hash salt, file system paths and trusted host configuration. Trusted host patterns tell Drupal which host names it will answer to, which blocks host header attacks against password reset and other generated links. Confirm that the file is not writable by the web server after installation and that the patterns list only the production domains.
Public and private file paths
Public files are served directly by the web server, while private files are delivered only through Drupal's access checks. Each path controls who can fetch uploaded documents, images and exports. Review which directories allow script execution, confirm that private files sit outside the web root, and test that a direct URL to a private file returns no content.
User roles and permissions
Roles and permissions decide which people and automated accounts can edit content, configure modules and reach administrative pages. Permissions are often granted too broadly after a site grows, so a role review should compare each role with the tasks it actually performs. Confirm who holds administrator rights, how two-factor authentication is enforced, and how local accounts are reviewed.
Web server and database access
The web server and database define what a compromised Drupal request can reach. Drupal runs on Apache, Nginx and other servers, with MariaDB, MySQL, PostgreSQL or SQLite as the database. Confirm that only the web root is exposed, that the database account has the privileges Drupal needs and no more, and that configuration and backup directories are not served to the public.
PHP runtime and version floor
The PHP version sets which Drupal releases can run and which security fixes the runtime receives. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, and no supported Drupal version runs on PHP 7. Check the PHP version in use against the Drupal major version planned for the site, and confirm the PHP end of life dates with the PHP project before setting the upgrade plan.
Which hardening choices fit your team and what they cost to run
This table compares four common hardening choices for a Drupal site, showing when each fits and what it asks of your team after launch. Read the operational burden column first, because the cheapest build is often the most expensive to keep current. The main takeaway is that each control moves effort from the build phase into ongoing maintenance, and that choice should follow who will carry that work.
| Option | When it fits | What it costs you operationally |
|---|---|---|
| Manual patching | Small, stable sites with a single maintainer who can watch advisories and apply releases the same week | Someone must track Security Team advisories and apply core and contributed updates by hand. Missed Wednesday security windows become your risk, and each update needs a test pass. |
| Composer-managed updates | Teams that want versioned, repeatable updates across development, staging and production | Requires Composer, a lock file under version control and a deployment pipeline. Your team still reviews each update, resolves dependency conflicts and owns the upgrade path to each new major version. |
| Contributed module for a control | A well-maintained module already covers the control, such as two-factor sign-in, and your team wants to avoid custom security code | You take on the module's release cadence, compatibility with each Drupal core upgrade and its security advisories. Confirm the module's maintenance status and open issues before you commit. |
| Custom code for a control | A specific control, such as a narrow access rule, has no contributed module that meets the requirement | Your team or partner owns every line of code, its tests, its review after each core update and its documentation for auditors. Expect this to recur with every major version upgrade. |
| Two-factor sign-in through a contributed module | Local Drupal accounts must keep their own second factor, for example for break-glass administrator accounts | Your team manages enrollment, recovery codes, lockout handling and module updates. Support tickets for lost devices land with the Drupal administrators, not the identity team. |
| Two-factor sign-in through the identity provider | Users sign in through SAML or OpenID Connect and your identity provider already enforces multi-factor policy | Your identity team owns the policy and recovery process. Drupal still needs correct role mapping and a plan for local admin accounts that bypass the provider. |
| Private files outside the web root | Uploaded documents must not be reachable by direct URL, and you can configure the web server and file paths | Requires server configuration, a private file path and shared storage in a multi-server setup. Your operations team must test that direct requests fail after every infrastructure change. |
| Private files controlled through the application | Access rules depend on content state or user role and the application must decide each request | Every file request passes through Drupal, which adds PHP load and needs access rules maintained alongside content permissions. Review these rules whenever you add content types or roles. |
How to harden a Drupal site in sequence
The sequence starts from a known inventory and ends with tested controls, so each hardening change is traceable to a check that proves it works. Each step below closes with a named output that the client can review and keep as evidence.
Inventory the site, versions and contributed modules
DeployOpen records the Drupal core version, every contributed module and theme with its version, custom modules, and the Composer lock state, usually from a read-only export of the codebase and a Drush status report. The client's team confirms which modules are actually enabled and which are leftovers. The step closes with a signed-off inventory file that lists each project, its version and its maintainer status, so later advisories can be matched against exact versions.
Confirm PHP and database support
The team compares the running PHP version and the database engine and version against the requirements for the Drupal release the site runs or will move to. Drupal.org publishes these requirements per major version, and the client should confirm the current table for their target release before changes are made. The step closes with a compatibility note that names any unsupported component, such as a PHP runtime that no supported Drupal version accepts, and a decision on whether it must be upgraded first.
Lock down settings.php and file permissions
Engineers restrict write access to settings.php and the sites directory in production, move database credentials and hash salt into environment variables or a secrets store, and confirm that the private file path sits outside the web root. They also check that public file directories do not execute scripts. The check that closes the step is a permission listing of the web root compared to the agreed baseline, plus a request for settings.php through the web server that returns no content.
Set trusted host patterns
The trusted_host_patterns setting in settings.php is set to the exact production hostnames, including any staging or admin hostnames the client actually uses. Requests with unlisted host headers are rejected by Drupal. The closing check is a request sent with a host header that is not on the list, which should return an error response instead of the site, and a request with the approved hostname, which should load normally.
Review roles and permissions
The team exports the roles and their permissions and compares that export with an approved baseline agreed with the client's security owner. Administrator roles are kept to named people, anonymous and authenticated permissions are checked for anything that exposes content or configuration, and unused accounts are reviewed. The step closes with a documented diff between the exported roles and the baseline, with every difference either removed or signed off with a reason.
Enable two-factor sign-in
Engineers enable a two-factor authentication module for administrative and editorial accounts, choose the factor types the client's policy allows, and decide how recovery works if a user loses a device. Where single sign-on is in scope, the team confirms how two-factor interacts with the identity provider. The closing check is a sign-in test for a privileged account that requires the second factor and a record that a sign-in without it is refused.
Set advisory subscriptions and dependency checks
The client's team subscribes to Drupal Security Team advisories for core and each contributed project in the inventory, and DeployOpen configures a dependency audit in the Composer workflow so that known vulnerable packages are reported. Patch timing follows Drupal's published release windows, with security releases on the third Wednesday of the month. The step closes with a documented owner for each advisory channel and a dependency audit report that runs cleanly on the current lock file.
Test the hardened site
The team runs the checks defined in earlier steps against the production-like environment, including the host header test, the file access test, a permissions export comparison and a two-factor sign-in test, and records the results. Any failure returns to the step that owns it. The step closes with a test report that lists each control, its expected result, the observed result and the date it was run, which the client can keep for internal review or hand to an independent auditor.
How the Security Team release windows set your patch rhythm
Your patch rhythm for Drupal should be set by the core release schedule, not by whatever day an advisory happens to arrive. The schedule says bugfix releases come out on the first Wednesday of each month and security releases on the third Wednesday. The Drupal Security Team publishes its advisories with CVE identifiers and risk scores, and it uses those Wednesday security release windows to ship fixes. Put both Wednesdays on the change calendar for every environment, and agree with your change board in advance which of those days can accept a production deployment. Confirm the current schedule and window practice on the Drupal core release schedule and the Security Team pages before you commit to a calendar, because the team may adjust how it communicates releases.
Triage starts by separating core advisories from contributed module advisories, because they affect your site differently. A core advisory applies to every Drupal site on the affected version, so the question is which of your core releases is exposed and when you can move to the fixed one. A contributed advisory applies only if that project is installed and the vulnerable component is in use. For each advisory, read the CVE identifier and risk score, match the affected project and version range against your composer.lock, check whether the vulnerable feature is enabled, and record whether the fix requires a core upgrade as well. An illustrative case: a contributed module is installed but disabled, so the advisory is logged, scheduled for the next window, and not treated as an emergency.
Patching out of cycle means applying a fix outside the normal monthly and Wednesday windows. Reserve this for advisories where your exposure is high, such as a vulnerable module on a publicly reachable route, a high risk score, or no practical mitigation available while you wait. Ask the Security Team and your upgrade partner what out-of-cycle releases look like for the project in question, and confirm them with the advisory itself rather than assuming. Decide before an incident which role can approve an emergency change, what minimum testing must pass on a staging copy of the database and files, and how you will roll back. Write those decisions down so that the on-call team is not making them during the incident.
Every advisory feed needs one named owner. Drupal core, each contributed project you run, and the platform components beneath Drupal, such as PHP, the web server and the database, each produce their own notices. If no one is accountable, an advisory can be read by several people and actioned by none. The owner reads the feed, performs the triage, records the advisory identifier, the decision and the date the fix was applied, and tracks the follow-up. Name a deputy as well so that coverage holds during leave. A support retainer can take on this monitoring and the Wednesday patching work, but the client still needs to confirm who approves changes to production.
Drupal security hardening controls for roles, files and sign-in
Most Drupal compromises trace back to a short list of settings: who holds administrator rights, what the web server can write, where private files live, which host names the site answers to, how users sign in, and where credentials are stored. The cards below cover each control, what to check during a review, and the decisions your team should record before the site goes live.
Roles and permissions review
Start by listing every role and the permissions it grants, then remove any permission the role's users do not need for their work. Administrator rights should sit with a small number of named accounts, and day-to-day content editing should run under a separate editor account. Check the review against the site's actual workflows, because permissions added for a one-off task often remain after the task ends.
Least-privilege administrator accounts
Create dedicated administrator accounts for the people who maintain the site, rather than using a shared login or the account created at install. Each account should be tied to a named person, have a strong unique password or SSO sign-in, and be disabled when that person leaves. Confirm with your team how the site's first administrator account was created and whether it is still in use.
Read-only settings and sites/default
After installation, the web server should not be able to write to settings.php or the sites/default directory. Set the file to read-only for the web server user and remove write access from the directory, then make configuration changes through a controlled deployment. Writable settings are a common route for an attacker to plant code, so confirm the permissions on your production host after every deployment.
Private files outside the web root
Store private files, such as uploaded documents that should require a login, in a directory outside the web root so the web server cannot serve them directly. Drupal then delivers those files through its own access checks. Confirm the private file path in the site configuration, test that a direct URL to a private file returns no content, and check that backups of the private directory are handled under the same access rules.
Trusted host patterns
Configure trusted host patterns in settings.php so Drupal responds only to the host names your organization uses. This limits host header manipulation in password reset links and other generated URLs. List each production, staging and administrative host name, and test that requests with an unlisted host are rejected before the site is opened to users.
Two-factor authentication through a maintained module
Add two-factor authentication with a contributed module that is actively maintained and has a release for your Drupal version. Before selecting one, confirm its Drupal version support on Drupal.org, since a module that lags a major release can block your upgrade path. Decide which roles must enrol, how recovery codes are issued, and whether single sign-on already provides the second factor.
Database credentials and API keys
Keep database credentials and third-party API keys out of version control and out of files that are shared between environments. Load them from environment variables or a secrets store at runtime, and restrict access to those values to the deployment process. Ask your team to list every key the site uses, who can read it, and how it is rotated when someone with access leaves.
How to verify the hardening works and fails safely
A hardening control only counts once a test shows it blocks the attack and that the site fails safely when something goes wrong. Start by exporting roles and permissions from configuration and comparing that export to the approved baseline, ideally stored in version control. Any difference should trigger a review by someone who owns access decisions. Then send requests with spoofed Host headers to the site and confirm that the trusted host patterns in settings.php reject them. Record the exact response code your environment returns, so the same test can be repeated after each release window.
Next, confirm that private files cannot be reached by URL. Request known private file paths from outside the network and confirm the server refuses them. Check that the public files directory does not expose anything that should be private. For settings.php, run a write attempt as the web server account and confirm the operating system denies it. File permissions are often reset by deployment tools, so repeat this check after every deployment rather than treating it as a one-time task. Keep the results with the change record.
Run a dependency audit against the Composer lock file, using composer audit or an equivalent tool your team already trusts. Save the output and map each finding to a Drupal Security Team advisory and its CVE identifier. Then commission security testing of the running application, covering anonymous and authenticated paths, forms, file uploads and administrative routes. Confirm the scope, test accounts and rules of engagement in writing before testing starts. Security releases arrive on the third Wednesday of the month, so the test plan should include a path to apply a patch quickly.
Safe failure needs its own checks. Repeated failed sign-ins should trigger Drupal core flood control, which temporarily blocks further attempts from the same source. Confirm the threshold and window in your configuration, confirm that lockouts are logged, and confirm that an administrator can clear a lockout without database edits. For errors, set error display to hide details on production, trigger a server error in staging, and confirm the page shows no stack trace, file path or database detail. Those details should appear only in the server log, which must be access-restricted.
Finally, rehearse the recovery path for a module disabled after an advisory. In staging, disable the affected contributed module, then confirm which views, forms, blocks and content types depend on it and how the site behaves without it. Clear caches, run the regression tests, and confirm the site still serves public pages and that editors can still work. Write the steps into a runbook with a named owner. Ask any implementation partner to show you a completed rehearsal and the runbook they produced, because a recovery path that has never been run is not yet a control.
What drives Drupal security hardening effort and how to keep it down
This table lists the factors that move the effort of hardening a Drupal site, why each one changes the work, and how to keep it manageable. Read the driver column first, then check whether each factor is a one-time cost or one that recurs with each release window. The main takeaway is that most recurring effort comes from module count, Drupal version age and evidence collection, so those are the levers to review before asking for a quote.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Contributed modules and custom code (one-time to assess, recurs per release) | Each contributed module and custom module is a separate codebase that needs review, configuration and advisory tracking. Security advisories for contributed projects arrive on the same Wednesday windows as core, so more code means more advisories to triage. | Remove unused modules before hardening. Prefer maintained contributed projects over custom code where a fit exists. Keep a written inventory of each module, its maintainer and its advisory history. |
| Number of roles and permission sets (one-time to review, recurs with staff changes) | Each role carries a permission matrix that must be checked against least privilege. Overbroad roles, especially those allowed to administer users, text formats or site configuration, expand the review and the testing needed after every change. | Map roles to job functions before configuration. Limit administrator roles to a small named group. Re-review the permissions matrix on a fixed schedule and when staff roles change. |
| Identity provider integration (one-time build, recurs with account lifecycle) | Connecting Drupal to a SAML or OpenID Connect provider, or to LDAP, adds role mapping, first sign-in account creation and handling of local administrator accounts. Each path needs its own verification and must stay consistent with the identity provider's account lifecycle. | Decide early which accounts stay local, such as break-glass administrators, and document them. Map identity provider groups to Drupal roles through one reviewed configuration. Confirm the supported protocol and module version with the identity team before scoping. |
| Number of environments (recurs with every deployment) | Each environment, such as development, staging, production and any disaster recovery copy, needs the same hardening settings, file system protections and configuration checks. Drift between environments is a common source of rework and failed verification. | Manage hardening settings through version-controlled configuration and a deployment pipeline rather than by hand. Keep the number of environments that hold production data as low as the delivery model allows. |
| Age of the Drupal version (one-time migration, recurs once supported) | Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later. Drupal 7 security support ended on January 5, 2025, according to Drupal.org, so such sites need migration or a paid extended support stopgap before they can receive current patches. Themes must be rebuilt because they cannot be migrated. | Confirm the Drupal version and PHP version of every site at scoping. Plan migration as a separate project from hardening. Where extended support is used as a bridge, budget it as an ongoing cost and confirm its terms with the provider in writing. |
| Evidence requirements from compliance programs (recurs per assessment cycle) | Assessors typically expect dated records of configuration baselines, access reviews, patch history and change approvals. DeployOpen prepares these controls and evidence for assessments, but independent auditors issue any report. Evidence that is collected manually at audit time takes far longer than evidence collected continuously. | Agree the evidence list with the assessor before hardening starts. Automate exports of configuration and role data where possible. Keep a dated log of each Wednesday security release, its risk assessment and its deployment record. |
| Security release windows (recurs monthly) | Drupal publishes security releases on the third Wednesday of the month, and bugfix releases on the first Wednesday, according to the Drupal core release schedule. Each advisory that affects installed modules requires a triage decision, a test run and a deployment, so effort recurs on every window. | Subscribe to Drupal Security Team advisories for each installed project. Agree a standing triage and deployment process with the client, including who approves emergency changes. Keep staging close to production so patches can be tested quickly. |
| Trusted host, file system and settings protection (one-time setup, recurs on configuration change) | Settings for trusted host patterns, file permissions around settings.php and private file paths must be set correctly on each environment and rechecked after deployments that alter configuration or hosting. Misconfiguration tends to surface only during testing or assessment. | Keep these settings in the same deployment code path as other configuration. Add automated checks to the pipeline that fail when file permissions or host patterns drift from the approved baseline. |
Questions buyers ask before hiring help with Drupal hardening
How much does Drupal security hardening cost?
Cost follows the scope agreed in writing before work starts. DeployOpen does not publish a price list, so a quote is built from the written scope. The main cost drivers are the number of sites and environments, the amount of custom code and contributed modules to review, the hosting setup (web servers, database, file storage and how they are reached), the number of roles and permissions to review, and whether you also need security testing or ongoing support. One-time work includes the baseline review, configuration changes and documentation. Recurring costs come from applying monthly bugfix and security releases, monitoring advisories and any support retainer. Ask each quote to separate these items and to state which environments and modules are covered.
How long does a Drupal hardening project take?
Duration depends on scope, so no single timeline applies to every site. A single site with a small number of contributed modules and a clear hosting setup usually moves faster than a multi-site estate with custom modules, several environments and integrations such as single sign-on. Time is also spent waiting on your team for access approvals, change windows and decisions about which permissions to remove. Drupal core publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so patch cycles can set the rhythm of the final phase. Ask for a phased schedule with named milestones, the dependencies on your side and the testing window before production changes.
What does our team need to provide for hardening work?
Plan for four inputs before work starts: access, a role baseline, named owners and a change process. Access means accounts on the hosting environment, the code repository, the Drupal admin interface and the server or database logs needed for review, granted with least privilege. A role baseline is a written list of who should hold each Drupal role and why, which the review compares against actual assignments. Named owners cover two duties: one person who receives Drupal Security Team advisories and decides on urgent patches, and one approver who signs off on configuration and permission changes. Also name someone for the production change window. Without these, reviews stall and advisories can go unread for weeks.
Can an internal team harden Drupal without outside help?
Yes, an internal team can harden a Drupal site alone if it has the skills and time for the work. It needs Drupal administration knowledge (roles, permissions, text formats and the settings file), web server and PHP configuration, database access controls, file system permissions and enough Composer experience to update contributed modules safely. It also needs a process for reading advisories, testing patches in a staging copy and rolling back. A common gap is the ongoing part: monthly release windows, Wednesday security releases and dependency monitoring need an owner beyond the initial project. Check whether at least two people can cover the work, because a single administrator leaves the site exposed during holidays and absences. An outside partner can cover the initial review, the documentation and the first release cycles.
Does Drupal hardening make a site compliant with a standard?
Hardening reduces risk and produces evidence, but it does not by itself make a site compliant with any framework. Independent auditors assess compliance, and certification bodies issue certifications. DeployOpen prepares systems, controls and evidence for those assessments, such as documented roles, configuration baselines, patch records and change approvals, so an assessor can test them. DeployOpen does not issue audit reports, attestations or certifications. Before starting, confirm which framework applies, which control IDs your assessor will test and whether the hosting provider's controls are in scope. Ask the partner to map each hardening item to the control it supports and to state which items remain your responsibility.
Why does the Drupal version and PHP version matter for security?
Security fixes only reach supported versions, so the version you run sets your exposure. Drupal 7 security support ended on January 5, 2025, according to Drupal.org, so a Drupal 7 site no longer receives community security releases. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet. Drupal 10 reaches end of life on December 9, 2026. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, and no supported Drupal version runs on PHP 7. Hardening cannot fix an unsupported core, so confirm your Drupal and PHP versions first and plan upgrades ahead of end-of-life dates.
How do we keep a hardened Drupal site secure after handover?
Keep a fixed release rhythm. The Drupal core release schedule sets bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so review both on those dates. Drupal Security Team advisories carry CVE identifiers and risk scores, so route them to a named owner who triages them promptly. Maintain a dependency inventory with Composer so you know the version of every contributed module. Repeat permission and role reviews after staff changes, and keep configuration in version control so drift is visible. Test each update in staging before production. A support retainer can cover monitoring and release work, and its scope should be written down before work starts.
What to monitor, back up, patch and document after hardening
This table lists the recurring controls a Drupal site needs once hardening is complete, with the area, the action and the team or role that owns it. Read it as a handover checklist: each row should have a named owner, a schedule and evidence that the work happened. The main takeaway is that hardening decays without these routines, so confirm ownership before go-live.
| Area | What to do | Owner |
|---|---|---|
| Security advisories | Subscribe the site team to Drupal Security Team advisories for core and every contributed module in use, and triage each advisory against the installed versions on the next security window. | Platform lead |
| Dependency audit | Run Composer audit against the lock file on a schedule, record findings with the affected package and version, and track each one to a patch or documented exception. | Development lead |
| Sign-in and permission logs | Review failed sign-in attempts, administrator logins and role or permission changes from Drupal's logging and your web or identity provider logs. Confirm which events are retained and for how long. | Security operations |
| File integrity | Check settings.php, services.yml and the code tree against a known-good baseline, and alert on unexpected changes to files that should be read-only in production. | Security operations |
| Backups and restore tests | Back up the database and the private files directory on a defined schedule, store copies outside the web root, and run restore tests into a separate environment to prove recovery works. | Infrastructure team |
| Patch runbook | Document how security releases are applied on the third Wednesday, how bugfix releases are scheduled on the first Wednesday, who approves them and how rollback works. Include a staging test step. | Platform lead |
| Role and permission baseline | Keep an approved document listing each role, its permissions, its owner and the review date. Compare live role settings against it at each review and record any approved deviations. | Content and IT governance owner |
How DeployOpen scopes, builds, hands over and supports hardening work
DeployOpen plans and hardens self-hosted Drupal sites inside your own cloud accounts, data centers or air-gapped networks. Each engagement starts from a written, fixed scope, is documented as it is built, and ends with a handover your team can run, with optional retainer support afterward.
How we scope
- Written scope that lists each hardening area, such as roles, file system protection and two-factor authentication.
- Current-state review of the Drupal version, PHP version, contributed modules and hosting before any change is agreed.
- Fixed-scope engagements agreed in writing before work starts, with ongoing support available as a retainer afterward.
How we build
- Permissions and roles review that removes unused privileges and maps administrator access to named responsibilities.
- File system and settings.php protection, including trusted host patterns and restricted write access to code directories.
- Two-factor authentication module selection, configuration and testing, plus a dependency monitoring routine for core and contributed projects.
How we hand over
- Patch runbook that follows Security Team advisories and Wednesday release windows, with named owners for each step.
- Documented configuration baseline covering roles, file permissions, settings.php, trusted host patterns and enabled security modules.
- Evidence pack with change records, test results and access reviews for your own assessors, which DeployOpen does not certify.
How we support
- Optional retainer covering advisory monitoring, patch application on release windows and module compatibility checks.
- Security testing of the hardened site, including application and API testing, can be added to a retainer.
- Ask during scoping which Drupal and PHP versions a retainer covers, and who owns each upgrade decision.
