Does NIS2 apply to a Drupal site, and what does Drupal help with?
NIS2 applies to the organization, not to the software. If you are an essential or important entity under *Directive (EU) 2022/2555* (NIS2), the risk-management measures in Article 21 and the incident reporting duties in Article 23 apply to your whole network and information systems, including a public or customer-facing Drupal site. Drupal helps with the technical parts of those duties, such as patching, access control and logging, but it does not make your organization compliant on its own. Whether you fall under NIS2 depends on your sector (Annex I or Annex II) and your size and classification under Article 3, which decides whether you are essential or important. Confirm that classification with your national competent authority or legal counsel before scoping any Drupal work, because it sets how strictly your authority will supervise you. Essential entities face ex ante supervision and important entities face ex post supervision (Articles 32 and 33), but both face the same Article 21 and Article 23 obligations.
Drupal core and contributed modules are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself, so your costs come from the people and services you buy, not from a license fee. A supported security process still matters: the Drupal Security Team publishes advisories with CVE identifiers and risk scores and uses Wednesday security release windows, and you need a named owner who reads those advisories and applies them. DeployOpen plans, implements, hardens and documents self-hosted Drupal inside your own infrastructure, and prepares systems, controls and evidence for assessments. DeployOpen does not issue audit reports, attestations or certifications. NIS2 also creates no certificate of compliance. National authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines (Articles 32 to 34), so ask your team what evidence they would show an inspector on day one.
Before you commit budget, confirm three points with your compliance lead: which national transposition law applies to you, since NIS2 is a directive and Member States may keep stricter rules under Article 5, which Drupal version and PHP runtime your site currently uses against the supported releases on the Drupal core release schedule, and whether the site holds any data that routes it into a stricter regime. Drupal 7 security support ended on January 5, 2025, so a Drupal 7 site in scope is an immediate risk item, not a planning item. Treat the answers as the input to a written scope, which is what DeployOpen agrees before work starts.
Mapping NIS2 obligations to Drupal capabilities and configuration
This table pairs each NIS2 obligation area with what Drupal provides, what it does not provide, and the configuration your team must own. Read each row as a prompt for evidence: a Drupal feature supports an obligation but never satisfies it alone. The main takeaway is that patch timeliness, module governance and incident reporting depend on your own processes and hosting choices.
| NIS2 obligation area | Drupal capability | Configuration your team must set up |
|---|---|---|
| Article 21 risk management: vulnerability handling | The Drupal Security Team publishes advisories with CVE identifiers and risk scores, and ships fixes in security release windows on Wednesdays. | Subscribe to advisories for core and every contributed module, record a patch deadline per risk level, and schedule a standing security update slot. |
| Article 21 risk management: supply chain of contributed modules | Core and contributed projects on Drupal.org are GPL-2.0-or-later, so source can be reviewed and forked without license fees. | Keep a module inventory with versions and maintainers, pin versions through Composer, and review new contributed modules before they enter production. |
| Article 21 risk management: supported software versions | Drupal 11 is the current major version and Drupal 10 reaches end of life on December 9, 2026, per the core release schedule. | Plan the Drupal 12 path before end of life, and confirm the PHP version each release requires (Drupal 11 needs PHP 8.3 or later). |
| Article 21 risk management: legacy platforms | Drupal 7 security support ended on January 5, 2025, and extended support is available only from certified vendors for sites that cannot yet migrate. | If a Drupal 7 site remains in scope, document the risk acceptance, the extended support contract and the migration date, since themes must be rebuilt. |
| Article 21 risk management: hosting security | Drupal runs on Apache, Nginx and other web servers with MariaDB, MySQL, PostgreSQL or SQLite, so hardening sits with your host stack. | Set access controls on the web server, database and file system, restrict admin paths, and confirm backup and restore tests for the hosting environment. |
| Article 23 reporting | Drupal core does not send incident notifications to authorities or detect breaches on its own. | Connect logs to your monitoring platform, define who decides an incident is significant, and document the reporting path to national authorities under your transposition law. |
| Implementing Regulation 2024/2690 (cloud or managed providers) | Drupal itself is not a cloud or managed service, but a managed Drupal host or CDN provider may fall within the regulation's listed provider categories. | Confirm with your national authority and the regulation text whether your hosting or managed service provider is in scope, and request their evidence for Article 21(2) measures. |
How security advisories and release windows shape patch timeliness
The clock on patch timeliness starts when the Drupal Security Team publishes an advisory, not when your team reads it. Advisories carry a CVE identifier and a risk score, and fixes ship in security releases on the third Wednesday of the month. Bugfix releases come out on the first Wednesday of each month, so a site on a Drupal core or contributed module release cadence needs both windows in its calendar. Your vulnerability handling procedure should map each advisory to an owner, a risk rating from your own assessment of the affected site, and a deadline you set internally. Subscribe the security owner and the platform team to Drupal.org security advisories, and confirm which notification channel your team will monitor for contributed modules, since advisories for those projects cover the same community process as core.
Two lifecycle dates matter for planning. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, according to the core release schedule. Any NIS2 risk-management record that still lists Drupal 10 as the production version should show an upgrade plan that finishes before that date. Drupal 7 security support ended on January 5, 2025. The extended security support vendors named by the Drupal Association, HeroDevs and Tag1 Consulting, are listed for sites that cannot yet migrate, so a Drupal 7 estate should be recorded as a documented exception with a dated migration plan, not as a supported platform. Confirm the terms, scope and coverage of any extended support contract directly with the vendor before relying on it in a compliance file.
Define the internal patch service level in writing before the next security release. A practical starting point is to separate advisories by risk score and by whether your site exposes the affected component to the internet. Record the time between advisory publication, your triage decision, test deployment and production deployment, and review those intervals after each Wednesday release window. Those records become evidence that your procedure works as designed. The timeframes themselves should be set by your organization and approved by the people accountable for the service, because the regulator will judge whether your own procedure was followed, not whether it matches a published benchmark.
Managing the supply chain of contributed modules and themes
Most of a Drupal site's code comes from contributed modules and themes, not from core, so the supply chain is part of the NIS2 risk picture. The cards below cover the controls a team should be able to show: how each dependency is chosen, pinned, watched and replaced. The Drupal.org project pages and licensing page establish what is in scope, but the team still assesses each dependency on its own record.
Vet each contributed project
Before a contributed module or theme enters the codebase, check its maintainer history, release cadence, open security issues and whether the project is covered by the Drupal Security Team process. Record who approved the addition and why it was needed. Confirm that the project is hosted on Drupal.org and that its licensing is compatible with your distribution model, since Drupal and derivative contributed files are licensed under GPL-2.0-or-later. A module that duplicates existing core or contributed functionality should be questioned before it is added.
Pin dependencies with Composer lockfiles
Commit the composer.lock file so every environment installs the same module versions, and review each change to it as a code change. Constrain version ranges in composer.json to the minor line you have tested, rather than allowing automatic jumps across majors. Run dependency updates in a branch, deploy them to a staging copy, and keep the lockfile history so you can show which version was running on any given date. This record is the basis for answering patch timeliness questions during an incident.
Remove abandoned modules
Flag any contributed project with no release in a long period, no maintainer response to security reports, or a Drupal.org notice that it is unsupported. Plan a replacement or a removal before the project becomes a blocking issue for a core upgrade. Keep a list of modules that are scheduled for removal, with an owner and a target date. Abandoned code that stays in production is hard to patch and hard to explain to an authority reviewing your risk-management measures.
Review custom code like third-party code
Custom modules and themes written by your team or a partner are part of the supply chain too. Require code review for every merge, run static analysis and dependency scanning on custom composer.json entries, and keep custom code in the same version control and release process as contributed code. Confirm that secrets are not committed to the repository. Treat custom patches applied to contributed projects as forks to be tracked and retired when an upstream fix is released.
Track PHP version support
Each Drupal major version sets a minimum PHP version. 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. Maintain a table that maps your Drupal major, PHP runtime and each contributed module's supported Drupal range. Confirm with each module's project page whether a planned Drupal major is supported before you commit to the upgrade, because some contributed modules lag core releases.
Keep an inventory of components and licenses
Maintain a software bill of materials that lists every Drupal core, contributed module, theme, library and PHP package, with the installed version, source, license and the person accountable for it. Generate it from the lockfile rather than by hand, and refresh it on every release. Use the inventory to answer vulnerability questions quickly when a Drupal Security Team advisory names a project you run. Confirm with your legal team which license obligations apply to each component before distribution.
Incident reporting duties and where Drupal logs fit
Article 23 reporting is an organizational process with fixed clocks, and the team must build its Drupal logging to meet them. NIS2 requires essential and important entities to notify their national competent authority or CSIRT of significant incidents within deadlines set in the Directive and in the national transposition law of each Member State. The exact stages and hours are not something this page should state from memory. Ask legal counsel to confirm the Article 23 timeline in the national law that applies to your entity, and write those deadlines into your incident response runbook with named owners for the initial notice, the follow-up report and the final report.
Drupal rarely produces the evidence a reporting decision needs on its own. The Drupal watchdog table and the Database Logging module record application events such as failed logins, permission changes and module installations, but those rows can be lost with the database or rotated away. Web server access and error logs from Apache or Nginx, plus WAF or reverse proxy logs in front of the site, show the request patterns that matter for denial-of-service or exploitation attempts. Forward all of these to your SIEM with synchronized timestamps and retention set by your legal team, so the detection timeline can be reconstructed in the report.
Whether an event is a *significant incident* is defined by the criteria in Commission Implementing Regulation (EU) 2024/2690, which applies to listed service types such as cloud, data center, CDN, managed service providers and online platforms. A standard Drupal site run by a public body or an industrial company may not fall under those listed types, so the classification depends on the service your entity operates and on national rules. Confirm with counsel and your national authority which thresholds apply before you design alerting, and agree who may declare an incident and when the clock starts.
Configuration sequence for a NIS2-ready Drupal platform
This sequence turns NIS2 obligations into a Drupal platform with known versions, a tracked advisory and patch routine, a controlled module supply chain, hardened hosting and rehearsed incident handling. Each step closes with a record the entity can show its competent authority.
Confirm classification and national law first
Before any technical work, the entity's management, legal counsel or compliance lead confirms whether the organization is an essential or important entity, which sector annex applies and how the national law that transposes NIS2 in each Member State where it operates sets its obligations. Ask the national competent authority or counsel which reporting channels and evidence formats apply, and whether the Drupal site falls inside the scope of the entity's risk management measures. The output is a written scope decision that names the systems in scope, so later steps have a clear boundary.
Inventory the Drupal estate and versions
The platform team lists every Drupal site, its Drupal core version, PHP version, database, web server, hosting location and every contributed module and theme, including sites that are multisite or still on Drupal 7. Check each version against the Drupal core release schedule and the PHP requirements, and flag any site that is unsupported or near end of life. Record who owns each site and who approves changes. The output is a versioned inventory that feeds the advisory monitoring and the risk register.
Set up advisory monitoring and a patch routine
Subscribe the security owner and the platform team to Drupal Security Team advisories for core and each contributed project in the inventory. Agree in writing how an advisory is triaged, who decides on an emergency update, and how it is tested in a non-production copy before release. Align the routine with the Drupal core release windows, where bugfix releases come first Wednesday of the month and security releases third Wednesday. The output is a written patch procedure and a log showing each advisory, its risk score, the decision and the date applied.
Lock down the module supply chain with Composer
Build the site from a version-controlled Composer project so every core and contributed package is pinned to a reviewed version, with the lock file committed. Restrict installation to approved sources, review new modules for maintenance status and license before adoption, and remove unused modules. Confirm with legal the license position, since Drupal and contributed derivative works are GPL-2.0-or-later. The output is a repository where every production change traces to a reviewed commit and a known package version.
Harden the hosting stack
Configure the supported web server, database and PHP version for each site, with TLS enforced, secrets kept outside the codebase, administrative access limited to named roles, and file permissions restricted. Set up tested backups of the database and files, and record restore times from a rehearsal. Confirm the hosting provider and data location with the entity's contracts team, since the NIS2 measures also cover the provider. The output is a hardening baseline per environment and a successful restore test on file.
Wire logging into central monitoring
Send web server, PHP, Drupal watchdog and authentication logs to the entity's central monitoring platform, with retention set by the policy agreed in step one. Define alerts for failed logins, permission changes, module installations and unexpected configuration exports. Test that each alert fires in a non-production copy. The output is a list of log sources, alert rules and a test record that shows the alerts reached the security team.
Rehearse the incident process with the Drupal team
Run a tabletop exercise with the security, legal and platform teams and the Drupal development partner, using a realistic scenario such as a compromised contributed module. Walk through detection, containment, the decision on whether the event is a significant incident, and the reporting steps, confirming the deadlines and recipients with the national authority or counsel. Update the runbook from what the exercise exposes. The output is a signed-off runbook and an exercise report with the gaps assigned to named owners.
What Drupal and DeployOpen do not cover for NIS2
A Drupal site is one component inside a wider NIS2 programme. The cards below mark the obligations that sit with the entity's governance, legal, hosting and people functions, so that the site team does not assume a Drupal build closes them.
Entity classification and registration
Whether an organization is an essential or important entity depends on its sector, size and role under the national transposition law, not on the website. Registration and any designation steps run through the national competent authority. Confirm with counsel which Annex I or Annex II sector applies and which national authority receives your filings before scoping the Drupal platform as an in-scope system.
Organization-wide risk management
Article 21 risk management applies to the whole entity, covering policies on risk analysis, business continuity, supplier security and access control across all systems. A Drupal site can evidence its own controls, but it cannot establish the entity's risk register, board oversight or continuity plans. Ask who owns those artifacts and how the site's risk entries feed into them.
Incident reporting decisions and notifications
Reporting duties under Article 23 require the entity to decide whether an event is significant and to notify the competent authority or CSIRT within set deadlines. Drupal logs and monitoring can show what happened on the site, but the classification and the legal notification are management and legal decisions. Agree in advance who makes the call, who signs the notice and which site logs are preserved.
Hosting provider and cloud controls
The hosting provider, cloud account, database service, DNS, CDN and backup storage often sit outside the Drupal application layer. Their controls, such as network segmentation, key management, logging retention and provider incident notice terms, must be assessed separately under the entity's supply chain obligations. Request each provider's security documentation and contract terms before relying on the platform's hosting design.
Staff training and management accountability
Management bodies must approve risk measures and can be held accountable for compliance, and staff across the organization need training on phishing, access handling and incident escalation. Editors, site builders and administrators are only a small part of that population. Plan and record the training program outside the Drupal project and confirm that content teams know how to report a suspected compromise.
Commission proposal COM(2026) 13
The Commission proposed targeted amendments to NIS2 on 20 January 2026, including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, so the current obligations stand. If your organization is a small mid-cap, track the final text, because the amendments may change which obligations apply to you.
Questions buyers ask before hiring help for NIS2 on Drupal
What drives the cost of NIS2 readiness work on a Drupal site?
The cost is driven by how many Drupal sites are in scope, how much custom code and how many contributed modules they run, and how much evidence your team must produce for the national authority. Cost has two parts: one-time work such as an inventory of sites, modules and hosting, gap analysis, remediation and runbook writing, and recurring work such as advisory triage, patching and evidence collection. Ask for a written scope that lists each site, each environment, the modules to be reviewed, the hosting components covered and the deliverables. Ask which items are fixed and which are priced as an option. DeployOpen does not publish prices, and a quote follows from that scope.
How long does NIS2 work on a Drupal site take?
Duration depends on the size of the estate, whether any sites still run Drupal 7, and how much custom code needs review. A single site with mostly contributed modules and a current core version is far shorter to assess than a multisite estate with custom modules and inherited configuration. Drupal 7 changes the picture most: Drupal 7 security support ended on January 5, 2025, according to Drupal.org, and such sites cannot be updated in place to Drupal 10 or later, so they must be migrated into a new site or covered by an extended support arrangement while the migration runs. Ask for a timeline that shows the inventory, assessment, remediation and handover phases separately, with the dependencies between them.
What does the internal team need to provide for NIS2 work on Drupal?
Your team needs to provide access and decisions, not only time. Typical inputs include read access to the code repository and configuration export, staging environments that match production, hosting and database details, the list of contributed modules and their owners, and the names of people who approve changes and receive security advisories. You also need someone who can state which systems the Drupal site feeds or depends on, such as identity providers, CRMs and payment services, because those dependencies shape your incident and supply chain obligations. Confirm with your partner exactly which artifacts you must hand over at each milestone.
Can our own team do NIS2 readiness for Drupal without a partner?
Yes, a capable internal team can do the work, provided it has time, Drupal expertise and clear ownership. The main tasks are mapping sites and modules, applying the Drupal Security Team advisories on the Wednesday security release windows, documenting how changes move from development to production, and writing incident reporting procedures that your entity's legal and management teams can approve. The hard part is usually sustained effort rather than one-off setup. Compare the in-house option against a written scope and ask whether your team would own the recurring duties after handover.
Is Drupal certified for NIS2 compliance?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34 of Directive (EU) 2022/2555. Drupal is licensed under GPL-2.0-or-later and has no paid edition, so there is no vendor certificate to point to. What you can show is your own evidence: the Drupal version and patch history, the controls you applied to your Drupal sites and hosting, and the records that prove they operate. DeployOpen prepares systems, controls and evidence but does not issue certifications or attestations.
How are patching and security advisories handled under a retainer?
A retainer covers recurring work that a one-time project does not: monitoring advisories, testing security releases, applying updates to each environment and recording what changed. Drupal core bugfix releases come out on the first Wednesday of each month, and security releases on the third Wednesday, according to the core release schedule, so the advisory cycle is predictable. Drupal Security Team advisories include CVE identifiers and risk scores, which helps triage. Ask the partner which advisories they triage, how quickly they test and deploy updates on your sites, who approves emergency changes, and how each action is recorded. Retainers are available from DeployOpen, and the terms are agreed in writing.
Which PHP and Drupal versions must we confirm before scoping?
Confirm your runtime before you agree on scope, because it sets the upgrade work. 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, according to the Drupal.org PHP requirements page. No supported Drupal version runs on PHP 7. Drupal 11 is the current major version, and Drupal 10 reaches end of life on December 9, 2026, according to the core release schedule. A written scope should state the target Drupal and PHP versions and who owns any upgrade that falls outside the agreed work.
How the work is scoped and handed over
DeployOpen scopes Drupal work for NIS2 readiness as a fixed-scope engagement, with the scope, deliverables and timeline agreed in writing before any work starts. For this topic, the written scope should name the Drupal version and PHP runtime in use, the web server and database, the contributed modules that carry security-relevant functions such as the SAML Authentication module or the OpenID Connect module, and the hosting boundary. Confirm early whether your organization needs a site-level review only or also a review of the hosting platform and the processes around it, because those are separate pieces of work with separate evidence. The written scope is also where you record what is out of scope, such as your own risk assessment, your incident response plan or any filing with a national authority.
The work typically covers Drupal configuration review, hardening of the site and its server components, preparation of evidence that shows how advisories are tracked and patched, and optional security testing of the site and its APIs. Hardening is applied in your environment, and the handover includes configuration exported to version control, a record of the settings changed and the reasons for each change, and a runbook for applying Security Team releases during the Wednesday windows described in the release schedule. Ask for a named list of artifacts in the quote, including who keeps each one after handover. Security testing is scoped separately, and you should agree in writing who receives the findings and how retests are verified.
Ongoing work after handover is available through a retainer, which can cover routine updates, advisory triage, periodic security testing and support for upgrades as Drupal versions change. Retainers recur, so compare the monthly or periodic effort against your own team's capacity to watch advisories and apply patches on time. DeployOpen does not issue audit reports, attestations or certifications. Whether your organization is an essential or important entity, and which obligations apply, is a determination for your legal counsel and the national competent authority in your Member State. The evidence DeployOpen prepares is meant to support that determination, not to replace it.
How DeployOpen prepares Drupal estates for NIS2 scrutiny
DeployOpen plans, builds, hardens and documents self-hosted Drupal sites inside the client's own infrastructure, with the NIS2 obligations of the organization in view from the first scoping meeting. Each engagement is defined by a written scope, and the handover is designed so the organization's own team can show how the site is maintained.
How we scope
- Map which Drupal sites fall within the entity's risk-management and incident reporting obligations, and which sit outside them.
- Inventory Drupal core version, PHP version, contributed modules, themes and hosting components against the supported release lines.
- Agree the written scope, deliverables and timeline in writing before work starts, since most engagements are fixed-scope.
How we build
- Set up the hosting stack in your cloud accounts, data centers or air-gapped network, with the web server and database you have chosen.
- Vet contributed modules for maintenance status and security advisory history, and document the reasons for each inclusion.
- Test security configuration, patch routines and backup restores in a staging environment before any production change.
How we hand over
- Document the update routine, advisory monitoring steps and ownership for each component, so your team can run them without us.
- Record configuration export, access roles and change procedures as evidence your compliance and audit teams can review.
- Walk your operations and security staff through runbooks for incident triage, escalation and reporting timelines.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer once the initial handover is complete.
- Plan core and contributed module upgrades around scheduled Drupal security release windows and your change calendar.
- Confirm with your legal and compliance advisers which obligations apply to your entity, since DeployOpen does not issue attestations.
