Why a Drupal security assessment matters for your site
A Drupal security assessment is a structured review of a Drupal site you host yourself, covering core and contributed module status, custom code, role permissions and the server underneath the application. It is usually commissioned when a compliance framework, a customer security questionnaire, a launch date or an insurer asks for evidence that the site was tested, not just patched. The assessment answers a narrower question than a penetration test does: where is this specific Drupal installation weaker than it should be, and what should be fixed first.
The risks cluster in four places. Outdated core or contributed modules are the most visible, and the Drupal Security Team publishes advisories for stable releases in supported branches of projects that have opted into coverage. Custom modules and themes fall outside that process entirely, so flaws in your own code will not appear in any advisory feed. Over-broad permissions are the third risk: a role that can edit content types, manage text formats or run administrative views may expose data or functionality that no one intended. The fourth is server configuration, including how the web server handles the settings.php file, file upload directories, PHP settings and TLS. Each of these can be sound on its own and still leave the site exposed in combination.
Patch status alone is not a full assessment. The Drupal Security Team does not issue advisories for issues exploitable only by users who already hold administrative permissions, and it does not cover external libraries. A site can show every advisory as applied and still carry weaknesses in its permissions model, its custom code or its hosting. Before you commit to a scope, ask the provider how it will check contributed modules that lack advisory coverage, how it will review custom code, and whether it will verify roles against your actual user population. The Drupal project's security advisory process and permissions policy explains the boundaries of what advisories cover, and it is worth reading before you write the scope.
What a Drupal security assessment can include
A Drupal assessment covers the platform in layers: the core and contributed code that runs the site, the custom code written for it, the roles that control what each user can do, and the hosting around it. Agreeing these layers in writing before work starts decides what the findings can prove and which environments and accounts the testers may touch.
Drupal core and contributed code status
Confirm the Drupal core version and whether it sits on a supported branch, then compare every contributed module and theme against the Drupal Security Team advisories that apply to it. Only projects that have opted into security coverage receive advisories, so a module with no advisory coverage needs a separate review of its maintenance status. Ask the client for the exact version list from the live site, not the version in the deployment plan.
Custom modules and themes
Custom code is often where the largest exposure sits, because no advisory process covers it. Review the custom modules and themes for input handling, access checks on routes and entity operations, and how they call the database and external services. Decide before work starts whether custom code is reviewed in source form, tested through the running site, or both, since that choice changes effort and what the report can claim.
Roles and permissions
Map each role and the permissions granted to it, then test whether a lower-privileged account can reach administrative functions, other users' content or configuration pages. Drupal's advisory policy excludes issues that only users with administrative permissions can exploit, so the assessment should flag over-broad permissions as configuration findings rather than rely on advisories to catch them. Ask for the role matrix and a list of accounts that hold administrative rights.
Anonymous and authenticated surfaces
Map what an anonymous visitor can reach, including public views, search, forms, file paths and the REST or JSON:API endpoints if enabled, then repeat the mapping for each authenticated role. The exposed surface often grows over time as views and endpoints are added. Agree which routes are in scope and whether testing uses accounts created for the engagement or accounts the client already holds.
Hosting, web server and database access
Review the web server configuration, PHP settings, TLS, file permissions on the Drupal tree, the settings file, and whether the database and private file directory are reachable from outside the application. Decide whether the review is a configuration inspection, an authenticated check from the host, or both. Confirm with the client which systems are inside the rules of engagement and which are shared with other applications.
Environments and rules of engagement
Decide whether testing runs against production, staging or a copy of production, since each carries different risk to live users and data. Agree the testing window, the accounts and test data to be used, the tools and techniques allowed, the escalation path if a critical issue appears, and whether denial-of-service or data modification is excluded. Put these terms in writing before work starts, because they define what the testers may do and what the report can cover.
How the Drupal assessment runs, phase by phase
The sequence turns a Drupal site into a written, version-checked inventory and then tests what an attacker in each role could reach, so the client ends with findings it can prioritize and retest.
Agree scope and rules in writing
Before any testing, the DeployOpen lead and the client agree in writing which sites, environments, hostnames, user roles, modules and test windows are in scope, along with what is excluded and who is the point of contact. Because most engagements are fixed-scope, the written scope also sets deliverables and the schedule, so durations come from that document rather than from a general estimate. The step is complete when the client has signed off the scope and the rules of engagement, and the test environment is confirmed as a copy or a non-production site the client has authorized.
Inventory core, contributed and custom code
The assessor records the Drupal core version, every contributed module and theme with its version, and every custom module and theme, using the client's codebase, composer lock file and a read-only view of the running site where the client allows it. Each contributed project is compared against Drupal Security Team advisories for stable releases in supported branches. Modules with no advisory coverage, because the project has not opted in or the branch is unsupported, are flagged separately for manual review. The step closes with a version matrix that shows each component, its status and the advisories that apply.
Review custom code and external libraries
Custom modules and themes are reviewed for common weakness categories such as unsafe handling of user input, access checks on routes and forms, and direct database queries built from request data. External libraries bundled by modules are checked for known vulnerabilities separately, because the Drupal Security Team does not issue advisories for external libraries. The output is a list of code locations with the weakness category, the reasoning and the suggested fix, reviewed with the client's developers. The step is done when every custom component has been read and each suspected issue is either confirmed or closed with a stated reason.
Test anonymous and authenticated paths by role
Following the OWASP Web Security Testing Guide, the assessor maps entry points, forms, search, file upload, REST and JSON:API endpoints, and user-facing workflows, then tests them as an anonymous visitor and as each defined role, from least to most privileged. The focus is whether access control, input handling and session behavior hold for each role, and whether a lower role can reach functions reserved for a higher one. Testing stays within the agreed scope and avoids disrupting live content. The step closes when each role and path in the scope map has a recorded result, including paths that were tested and found to hold.
Review server and site configuration
The assessor reviews the web server, PHP settings, database access, file system permissions, HTTPS configuration, the private and public file directories, and Drupal's own configuration export for settings that affect exposure, such as error display, update access, and the handling of sensitive files. Where the client provides it, the review also covers the hosting layer and backup storage. Each finding records the setting, the expected state and the evidence. The step is done when the configuration checklist agreed in scope has been worked through and each item is marked as met, not met, or not applicable with a reason.
Deliver the findings report
The report sets out each finding with its affected component, the version and advisory status where relevant, how it was confirmed, its severity and the remediation steps. It separates confirmed issues from items for the client to verify, lists modules without advisory coverage with a recommended action, and states the scope and limits of the test. A read-out walks the client's engineers through the findings. The step is complete when the client has received the written report and the walkthrough has taken place, which gives the client a record it can pass to an auditor or a customer's security review.
Retest and confirm the fixes
Once the client has applied fixes, the assessor retests the specific findings in the same environment and checks that the updated versions, configuration changes and code corrections address the original issue without opening a new path. Retest results are recorded against each finding ID, and anything still open is noted with the reason. Retest terms, including whether it is included or billed separately, are set in the written scope. The step closes with an updated report that shows the status of every finding at the time of retest.
Weakness categories we check on Drupal sites
Core and contributed modules are the first thing we compare against published advisories. An outdated Drupal core or module is often the simplest route to a known weakness, and an assessment that skips this step gives a weak picture of the site. Drupal Security Team advisories cover only stable releases in supported major version branches of projects that have opted into coverage, so the first task is to establish which branch each component sits on and whether that branch is still supported.
- Core version and branch: We record the installed core release and confirm the major branch is still receiving security coverage.
- Contributed module inventory: We list every contributed project, its installed release and whether the project is covered by the security team.
- Advisory matching: Each installed version is compared against published advisories, including those that affect only specific ranges.
- Update path review: We check whether the site's update process, including staging and rollback, can apply advisories quickly.
- Custom forks and patches: Local patches to core or contributed code are listed, since they can block or complicate upgrades.
Ask the client to confirm the update cadence they actually follow, not the one written in their policy, and to provide the last three update logs.
Some modules sit outside what the Drupal Security Team covers. The team's policy covers only projects that have opted into coverage, and it does not issue advisories for issues exploitable only by users with administrative permissions or for external libraries. A module with no advisory can still contain a vulnerability, so a site can appear current while carrying unreviewed risk. These gaps need explicit handling in the report.
- Uncovered projects: We flag contributed modules and themes that have not opted into security coverage and record the business function they serve.
- Excluded issue classes: We note that administrator-only issues and bundled external libraries fall outside advisory coverage and must be assessed separately.
- Third-party libraries: JavaScript and PHP libraries bundled inside modules or themes are inventoried and checked against their own upstream advisories.
- Abandoned or unmaintained code: We identify modules without recent releases and recommend replacement, removal or ownership.
- Compensating controls: Where a module must stay, we record what isolates it, such as access restrictions or a reduced permission model.
The client should confirm which modules are business critical and who owns the decision to keep an uncovered module in production.
Custom modules, themes and hooks are written for one site and are not covered by the general advisory process. Weaknesses here usually come from how user-supplied input reaches database queries, output templates and access checks. We review this code defensively, looking at the patterns that the Drupal APIs are meant to enforce and at places where the code bypasses them. The aim is to find where a defect could appear, not to produce working attack input.
- Database access: We check that queries use the database abstraction layer with placeholders rather than concatenated input.
- Output escaping: Templates and render arrays are reviewed for places where markup is marked safe without a clear reason.
- Access checks: Routes, controllers and entity operations are reviewed to confirm each one checks access, not only the user interface.
- Forms and APIs: Form validation and REST or JSON:API endpoints are reviewed for missing validation and over-exposed fields.
- Secrets in code: Hard-coded credentials and tokens in custom code are identified and their rotation is recommended.
Ask for the custom code repository, its review history and any coding standards it follows, so findings can be traced to specific commits.
Drupal grants access through roles and permissions, and many site-level problems come from roles that carry more capability than their owners need. This category matters because the advisory process excludes issues that only administrators can exploit, so the site's own role design determines how much those excluded issues matter. A tight model limits the damage from any single compromised account or misconfigured module.
- Role inventory: We list every role and the permissions it holds, including those granted by contributed modules.
- Administrator sprawl: Accounts holding administrator or near-administrator roles are counted and compared with operational need.
- Text format permissions: We check which roles can use permissive input formats, since these decide what content can carry active markup.
- Module permissions: Permissions that allow configuration changes, code execution paths or user impersonation are flagged for review.
- Account lifecycle: Dormant accounts, shared logins and offboarding steps are reviewed.
The client should confirm which roles exist on paper and who approves their assignment, since the gap between those two is often where findings sit.
Upload features in Drupal sites, including images, documents and media library entities, accept content from many users and store it in web-reachable locations. Weaknesses in this area typically involve unrestricted file types, weak validation of what a file actually contains, and public access to private files. The assessment checks the controls that decide what can be uploaded, where it is stored and who can retrieve it.
- Allowed extensions: We compare the configured file types with what the business needs and flag executable or script-capable types.
- Private file storage: We confirm private files sit outside the web root and are served through access-checked routes.
- Media access: Media entities and their underlying files are checked so access rules apply to both.
- Image processing: Image styles and derivative handling are reviewed for exposure of original or unintended files.
- Storage and backups: Upload directories and backup archives are checked for directory listing and public exposure.
Ask the client to list every field and feature that accepts uploads, since many sites have more upload paths than the editors realize.
The web server, PHP runtime, database and file permissions form the environment that Drupal runs in. A well-patched application can still be exposed by a permissive server, an outdated PHP version or a writable code directory. This category checks the settings that the Drupal application relies on but cannot set for itself. Findings here are often configuration changes that are quick to fix once they are confirmed.
- Web root and files: We check that the code directory is not writable by the web server user and that sensitive files such as settings files are protected.
- PHP settings: Runtime settings are reviewed for features that widen exposure, and PHP version support is confirmed.
- HTTP headers and TLS: Transport security, cookie flags and security headers are checked against the client's policy.
- Database access: Database accounts are checked for least privilege and separation between the application and administrative tasks.
- Exposed endpoints: Administrative paths, update scripts and development tools that should not be public are identified.
The client should confirm which environment the site runs in, whether that is a single host, a container platform or a managed stack, since the checks differ.
What drives the cost and duration of a Drupal assessment
The table lists the cost components of a Drupal assessment, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to see where a quote comes from and which inputs you can reduce before scoping. No figures are given because DeployOpen does not publish prices and the quote follows from the written scope.
| Cost component | One-time or recurring | What drives it up or down |
|---|---|---|
| Contributed and custom module count | One-time per assessment | Each enabled contributed module needs its advisory status checked, and each custom module needs code review. Removing unused modules before scoping reduces the review set. |
| Roles and permission sets | One-time per assessment | Every role must be tested against its granted permissions, including text formats and administrative paths. A short, documented role matrix shortens this work. |
| Number of environments | One-time, with recurring checks if environments are kept | Production, staging and development each need configuration and version review. Confirm which environments are in scope and whether they share code or data. |
| Custom code volume | One-time per assessment | Custom modules, themes and hooks drive manual review time. A tagged repository with a clear list of custom components lets the reviewer focus on the relevant code. |
| Depth of server review | One-time per assessment | Web server, PHP configuration, database access, file system permissions and TLS settings each add effort. Agree in writing whether the server is reviewed directly or only through its configuration files. |
| Retest rounds | One-time per finding cycle | Each retest checks remediated findings on the same version. Fixing findings in one batch before retest keeps the number of rounds low. |
| Re-running after updates | Recurring | Core and module updates change the risk picture. A retainer or a repeat scoped assessment covers this, and the cost depends on how many components changed since the last test. |
| Pre-inventory of components | One-time, supplied by the client | A current list of core version, modules, themes, roles and hosting details shortens scoping. Ask the assessor which fields they need before you prepare it. |
What you receive and whether it satisfies an auditor or customer
A Drupal assessment produces a written package that can be shared with an auditor, a customer or an internal risk committee. Its usefulness depends on whether the format matches what the requester expects, so agree that format in writing before testing begins.
Executive summary and scope
The summary states the overall position of the site, the most important findings and the business impact in plain language for decision makers. The scope section names the hostnames, Drupal core and contributed module versions, custom modules and themes, server components and any environments excluded from testing. Check that the scope matches the systems your auditor or customer will ask about, because a report that omits a production hostname will be questioned.
Method and evidence trail
The method section explains how core and contributed modules were compared against Drupal Security Team advisories, which checks were manual and which were tool assisted, and which tests were run against a staging copy. For each finding, the report should record the evidence used to confirm it, so a reviewer can reproduce the reasoning without repeating the test. Ask whether the testers will provide screenshots, version outputs and configuration excerpts for each item.
Findings with severity and impact
Each finding should list its severity rating, the affected component, the conditions needed to exploit it and the likely impact on confidentiality, integrity or availability. Ask how severity is scored and whether that scoring is the same method your customer or auditor uses. Findings about modules with no advisory coverage must be labelled as such, because the absence of an advisory does not prove a module is free of defects.
Affected code and remediation guidance
For custom code, the report should point to the file, function or configuration key involved. For contributed modules, it should name the project, the installed version, the fixed version where one exists and the upgrade path. Remediation guidance should be specific enough for your development team to act on, with priorities that reflect the timeline your own policy sets for each severity.
Retest results
A retest confirms which findings were fixed, which remain open and which were accepted as risk with a stated reason. It should reference the same finding identifiers as the original report and record the version or configuration tested. Agree in advance whether a retest is included in the fixed fee, how many rounds are covered and how long after the original report it remains valid.
Attestation letters and auditor limits
DeployOpen does not issue audit reports, attestations or certifications. If you need a letter confirming that testing took place, ask for a letter describing the work performed, and confirm with your auditor or customer that they accept it as evidence. Independent auditors and certification bodies decide whether the test satisfies a framework requirement, so confirm that the scope, format and tester qualifications meet their expectations before the work starts.
How testing differs by hosting environment
On-premises Drupal sites usually run on virtual or physical servers that the organization controls directly, often behind a hardware or software reverse proxy in its own data center. The assessor can normally agree access to the web server, PHP runtime, database host and file system through the client's change process, which makes server configuration review (web server directives, PHP settings, file permissions, and the settings.php file) straightforward to verify on the host itself. The main questions are which team owns the proxy and TLS termination, and where backups are stored.
- Server access: Confirm whether the assessor can review configuration as an authenticated administrator or needs a read-only account and a named host.
- Reverse proxy and TLS: Confirm which team owns the proxy rules, certificate lifecycle and any path restrictions for administrative routes.
- Database and file storage: Confirm where the database and the public and private file directories live, and who holds credentials.
- Backups: Confirm where backups are kept, how they are encrypted and whether they contain personal data that the test team must handle under agreed rules.
- Staging copies: Confirm whether a staging copy with production-like data exists and whether it can be used for active testing.
Before scoping, check who can change the host, who receives the report, and which change windows apply to the test.
Drupal hosted on cloud virtual machines follows the same application model as on-premises hosting, but the infrastructure layer belongs to the cloud provider and the platform team. Security responsibilities are split under the shared responsibility model: the provider secures the underlying facilities and hypervisor, while the customer remains responsible for the operating system, the web stack, the application and its data. Any active testing that touches cloud load balancers, managed databases or network controls must follow the provider's published testing rules, which set out what is permitted and what requires notice.
- Provider rules: Check the current published testing policy of the provider before agreeing any active testing against cloud-managed components.
- Managed services: Confirm whether the database, object storage or load balancer is managed, since the client may be able to review configuration but not the underlying service.
- Network controls: Confirm which security groups, firewall rules and ingress paths apply to the Drupal host and who can change them during the test.
- Backups and snapshots: Confirm whether volume snapshots and cloud backups are in scope for review and where they are replicated.
- Identity: Confirm how administrative access to the cloud console and instance is granted and logged.
Ask for the provider's testing rules in writing and the client's agreed scope before any scanning begins.
Drupal running in containers changes what the assessor reviews on the host. The application image, its base layers, the entry point and the mounted volumes become part of the review, and configuration may come from environment variables, config maps or secrets instead of files on a fixed server. Shared hosting of several containers on one node also means that a weakness in one workload can affect others, so the test may need to cover the orchestration layer as well as the Drupal container itself.
- Image and build: Confirm which image base, Drupal core version and contributed modules are baked into the image and how updates are rebuilt.
- Secrets and configuration: Confirm how database credentials and the hash salt are injected and who can read them from the orchestrator.
- Volumes and file storage: Confirm which volumes hold public files and private files, and whether they persist across redeploys.
- Orchestrator access: Confirm whether the assessor can review pod or service settings, network policies and ingress rules, or only the application.
- Scaling copies: Confirm whether multiple replicas share one database and file store, since this affects how state-changing tests are run.
Check that the test scope names the image tag or digest under review, since a rebuild after testing can change the findings.
Air-gapped Drupal sites have no direct route to the internet, so the assessor often works on site or through a controlled jump host, and the update path depends on media or an approved transfer process. Advisory status must be checked against what the client can actually install, because a site that cannot reach the update source may lag behind advisories for reasons outside the team's control. Testing tools and reports also need to be cleared for the enclave before they enter or leave it.
- On-site access: Confirm the assessor's physical or jump host access, badge requirements and whether the tools can be brought in.
- Update path: Confirm how core and module updates arrive, who verifies them and how long the approval chain runs.
- Advisory currency: Confirm the date of the last offline update package and compare the installed versions with the advisories for those versions.
- Data handling: Confirm whether copies of the database or backups may leave the enclave, and in what form.
- Report transfer: Confirm how the report and evidence are removed from the network and who receives them.
Ask for a written statement of how updates reach the enclave, since that determines most of the patch status findings.
How to prepare your Drupal site for testing
Start with a current inventory of Drupal core and every installed module, theme and custom component, including the exact version of each. The assessment compares that list against Drupal Security Team advisories, and it can only do so accurately if the versions are recorded from the live site rather than from memory or the last deployment ticket. Export the list from the codebase lockfile or Composer metadata and confirm it matches what runs in production. Note which contributed modules are not covered by Drupal Security Team advisories at all, because the Drupal security advisory policy explains that only projects that have opted into coverage receive them. Those modules need a separate review path, so flag them now instead of leaving them for the tester to discover. Any module you cannot identify should also go on the list, because unknown code is one of the things the assessment exists to find.
Next, agree the test environment and window in writing. Testing against a staging copy that mirrors production code, configuration and enabled modules is usually the safer choice, because active scanning and authenticated checks can disturb a live site. Ask the tester to confirm which systems are in scope and that you own them or hold documented authority to test them. Prepare test accounts for each role the site uses, such as anonymous, authenticated, content editor and administrator, with the permissions each role actually holds. Without these, the permissions review can only describe what the configuration appears to allow. Also confirm a recent, restorable backup of the database and files, name the technical contact who can answer questions about hosting and deployment, and name an escalation contact with authority to pause testing. Record any change freeze so that no module updates or content migrations land mid-test.
Finally, tell the tester what you already know about the server. Share the web server and PHP versions, the reverse proxy and TLS arrangement, where the settings.php file and private file directory sit, and whether the site is reachable from the public internet or only from a corporate network. Ask the provider to confirm how findings will be handled if a critical issue appears during testing and who on your side receives it, because this decides whether testing can continue safely. Ask, too, how the provider will treat custom code, since it is often the least documented part of a Drupal estate. Confirm these arrangements in the scope document so that both sides start from the same facts.
What to check before choosing a provider
A Drupal assessment depends on judgment about core, contributed modules and custom code, so the provider's track record and the terms around the work matter as much as the price. The cards below cover what to request in writing before a scope is agreed and a contract is signed.
Drupal core and module review experience
Ask for evidence that the team has reviewed Drupal core upgrades, contributed modules and custom code, not only generic web application testing. Ask how they match installed module versions against Drupal Security Team advisories, and how they handle modules that have no advisory coverage, since the Team covers only projects that have opted in. A provider who cannot explain that difference will miss the modules that carry the most unknown risk.
Written scope and rules of engagement
Require a written scope that names the sites, hostnames, environments, modules and custom code in play, plus the testing windows and the accounts the testers will use. Rules of engagement should state what happens if a finding affects production data or availability, and who the escalation contact is. Most engagements are fixed-scope, so anything not written down is a change request with its own cost.
Sample report and finding format
Request a redacted sample report before signing. Check that each finding states the affected component and version, the evidence, the risk rating with its rationale, and a remediation step that a Drupal developer can act on. Confirm whether the report maps findings to the relevant controls for your auditor or customer, since that changes what you need from the output.
Retest policy
Ask whether a retest of fixed findings is included, how long after the report it can be requested, and whether it covers only the original findings or any regressions. Confirm the retest result will be written up in the same format as the original report. Without a stated retest policy, you may pay twice to prove that a patch closed a finding.
Named testers and their access
Ask for the names and roles of the testers who will work on your site, and whether they are employees or subcontractors. Confirm how credentials for test accounts are issued, stored and revoked at the end of the work. Named testers let you check experience directly and hold the team to the scope you agreed.
Data handling and insurance terms
Confirm where test data, database copies, screenshots and credentials are stored, how long they are kept, and when they are destroyed. Ask what professional liability and cyber insurance the provider holds, and whether the contract sets out liability for accidental downtime or data loss during testing. Review these terms with your legal and procurement teams before the scope is signed.
Common questions about Drupal security assessments
How much does a Drupal security assessment cost?
The cost is set by the size and complexity of the written scope, not by a standard rate. The main drivers are the number of contributed and custom modules, how much custom code needs review, how many roles and permission combinations must be checked, whether the hosting environment and server configuration are in scope, and whether testing is authenticated as several user types. A one-time assessment is priced differently from a retainer that covers repeated checks after each Drupal Security Team release. DeployOpen does not publish a price list. Ask for a quote that lists each component separately: module inventory, code review, permissions testing, server review and reporting, so you can see what drives the total and what you could reduce.
How long does a Drupal security assessment take?
Duration depends on the same scope drivers as cost, plus how quickly the client can provide access and answer questions. Sites with a small module footprint and no custom code generally move faster than sites with many custom modules, integrations with payment or identity providers, or multisite setups. Delays often come from waiting for test accounts, staging environments that do not match production, or unclear ownership of the server. Ask for a timeline in the written scope that separates preparation, testing, reporting and the readout, and confirm which parts depend on your team.
What does our team need to provide before testing starts?
Expect to supply a clear scope document, a staging copy of the site that matches production as closely as practical, test accounts for each role that matters, and a current inventory of core, contributed and custom code. Access to server configuration, web server and PHP settings, and the database backup policy is needed if the server review is in scope. You should also name a technical contact who can answer questions about custom modules and approve testing windows. Confirm with your hosting provider whether testing against their infrastructure is permitted under their terms.
Can our own team run a Drupal security assessment internally?
Your team can check parts of the site internally, such as reviewing the installed module list against Drupal Security Team advisories, confirming the core version and reviewing role assignments. Independent testing is harder to do well from inside, because the people who built the site tend to test the paths they expect to work. Internal checks also rarely cover the full set of permission combinations or custom code review. Many organizations split the work: internal staff keep patch status and configuration current, and an external tester checks custom functionality and access control, then compares findings against the written scope.
Does a fully patched Drupal site pass a security assessment?
A patched site has fewer known issues in core and covered contributed modules, but patch status is only one part of the picture. A tester also looks at modules without advisory coverage, custom code, permission settings and server configuration. Drupal Security Team advisories cover only stable releases in supported branches of projects that have opted in, and the team does not issue advisories for issues that require administrative permissions or for external libraries. That means a site can be fully updated and still contain weaknesses in custom code, third-party libraries or access rules. The report should state what was tested and what was out of scope, so the result is read accurately.
How does retesting work after findings are fixed?
Retesting checks whether each finding has been fixed as described, using the same method and scope as the original test. It usually covers the specific findings, plus a short regression check of the areas changed by the fixes. Ask for the retest terms in the original quote, including whether a retest is included, how many rounds are allowed and how the report will mark each finding as resolved, partially resolved or still open. For ongoing sites, a retainer can cover retesting after each relevant Drupal release, though the cadence and inclusions should be written into the agreement.
Will the assessment report satisfy an auditor or customer?
The report is evidence of testing, not an audit opinion or certification. DeployOpen does not issue audit reports or attestations; independent auditors and certification bodies make that determination. A useful report lists the scope, method, tools categories, findings with severity and reproduction detail for your team, and retest results. Many compliance frameworks ask for penetration test findings to be tracked and remediated on a timeline set by impact and priority, which the report can support. Confirm with your auditor or customer what format and level of detail they expect before the test is scoped.
How DeployOpen scopes, tests, reports and retests Drupal sites
DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside the client's own infrastructure, and runs security testing on them. For Drupal security assessment, we agree a written scope first, test the site against the advisory status and configuration questions that apply to it, and hand over documented findings that the client can act on and retest.
How we scope
- Written scope lists the Drupal core version, each contributed module and theme, and the custom modules to be reviewed.
- Scope states which environments are included, such as production, staging or a copy of the live database, and who approves access.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any testing begins.
How we build
- Inventory of core, modules and themes is compared against Drupal Security Team advisories for the stable branches in use.
- Modules without advisory coverage are flagged separately and reviewed for their maintenance status and code quality.
- Permissions, roles, text formats, file system settings and server configuration are checked against the site's own hardening guidance.
How we hand over
- Report lists each finding with its affected component, evidence, risk rating and a recommended fix that the client's developers can apply.
- Separate section records advisories that apply, modules with no advisory coverage, and items that need the client's own confirmation.
- Documentation is written so that the client can share the relevant parts with an internal auditor or a customer's security team.
How we support
- Retest is scoped in writing to confirm that the fixes for agreed findings work on the same site and versions.
- Ongoing support, upgrades and continuous testing are available as a retainer, which suits sites that receive frequent module updates.
- Where the client's team maintains the site, we agree who owns each remediation task and how the next review is scheduled.
