Why utilities run Drupal for outage and service information
A utility's public website carries outage maps, restoration estimates, service alerts and billing help, and during a storm it takes the heaviest traffic of the year while regulators, emergency managers and customers read the same pages. The first decision is architectural: the public information site should be a separate system from operational technology, with no network path that lets a web compromise reach control or SCADA environments. Drupal fits this role because you can host it entirely inside your own cloud accounts, data centers or private networks, and because its core and contributed modules are licensed under GPL-2.0-or-later with no paid edition. That means no per-seat or per-site license fee sits between you and the code, but it also means your team, or a partner you engage, owns patching, hosting, caching for surge traffic and the module choices that come with the platform.
Drupal's contributed modules cover much of the identity work that utility portals need. The SAML Authentication module lets the site act as a SAML service provider, which suits customer portals or employee-only content behind your identity provider, and the OpenID Connect module covers OIDC providers and creates accounts on first sign-in. Confirm each module's supported Drupal versions before you choose it, because support differs by release. For the team, the change is that the CMS, the caching layer, the SSO integration and the release calendar become your responsibility to design and run together, and outage pages must still render when the database or identity provider is degraded.
Drupal does not make an entity compliant with NERC CIP on its own. The CIP Reliability Standards apply to BES Cyber Systems and their associated assets, and a public-facing website is usually outside that scope, but whether it is outside depends on your own asset categorization under CIP-002 and on how the site connects to in-scope systems. Ask your compliance lead to document that boundary, confirm that no Electronic Security Perimeter or Interactive Remote Access path runs through the web tier, and record the vendor and supply chain controls that CIP-013 expects for any third-party software. The Drupal work produces evidence for those controls, such as patch records and access reviews, but the compliance determination itself stays with your organization and its auditors.
Which utility requirements shape the Drupal build
This table maps each utility requirement named in the supplied sources to the part of a Drupal build it affects. Read each row as a question to answer with counsel and your compliance lead before architecture decisions are fixed. The main takeaway is that Drupal usually sits outside the bulk electric system perimeter, so the build must prove that boundary rather than assume it.
| Requirement | What it asks for | What it means for the Drupal build |
|---|---|---|
| CIP-002-5.1a impact classification | Sorts BES Cyber Systems into high, medium or low impact using bright-line criteria | Confirm with counsel whether any Drupal-hosted function touches a BES Cyber System. A public outage site normally should not, so document that conclusion and keep it out of control paths. |
| CIP-005-7 Electronic Security Perimeter | Routable-connected assets of high and medium impact systems sit inside an Electronic Security Perimeter | Keep the CMS, its database and its integrations outside the perimeter. Any feed from operational systems should pass through a one-way, reviewed interface. |
| CIP-005-7 Interactive Remote Access | All interactive remote access passes through an Intermediate System with encryption and multi-factor authentication | Customer portal logins are not the same as utility remote access. Ask counsel whether any staff or vendor access to OT assets is in scope, and if so, keep it on the Intermediate System path, not through Drupal. |
| CIP-013-2 supply chain risk management | Plans covering vendor incident notification, vulnerability disclosure, software integrity and authenticity verification, and vendor remote access coordination, reviewed at least every 15 calendar months | Record Drupal core, contributed modules and build artifacts as vendor software. Define how security advisories from the Drupal Security Team reach your team and how package integrity is verified before deployment. |
| CIP-011-3 information protection | Protection of BES Cyber System Information through defined handling and access controls | Do not place BES Cyber System Information in content, forms, logs or search indexes. Map which fields and attachments are excluded and how exports are controlled. |
| NIS2 Annex I energy coverage | Lists energy as a high-criticality sector with electricity, district heating and cooling, oil, gas and hydrogen subsectors | If you operate in the EU, confirm which entity category and subsector apply. The obligations attach to the organization, so the Drupal site inherits the programme, not a compliance status. |
| EU cross-border electricity network code | Commission Delegated Regulation (EU) 2024/1366 sets sector-specific cybersecurity rules for cross-border electricity flows | Relevant mainly to transmission and cross-border market participants. Confirm with counsel whether any Drupal-hosted interface supports cross-border flow data, and if not, document the exclusion. |
How to keep outage pages up during a storm
The safest pattern for outage and service information is a read-only public site that stays up even when the operational systems behind it are under strain. Drupal serves the pages, but during a storm the public traffic should mostly hit cache layers and a CDN in front of Drupal, not the origin. Caching, reverse proxies, CDN cache tag purging and cache warming are separate pieces of work with their own design decisions, so the outage page plan should name each one and assign an owner rather than treating "caching" as a single setting. Ask your team to confirm which of these layers already exists in your estate and which must be built before the next storm season.
Outage data should reach Drupal through a separate feed from the outage management system, not through live calls from public page requests. A scheduled or event-driven import, published to a narrow set of content types or a static JSON document, lets the public site show the last confirmed state even if the feed or the OMS is slow or offline. Decide the publishing rules up front: which fields are public, how often the feed updates, what the page shows when data is stale, and who can override a status manually. Keep the feed credentials, endpoints and field mappings in configuration you can version and test, not in the page template.
What should not be live-coupled to operational systems is anything that changes the grid's behavior or exposes its internals. The public site should have no write path into the OMS, SCADA or customer information systems, and no authenticated call from an anonymous page view to an operational API. Customer account lookups belong behind SSO in a separate, access-controlled application, not on the storm page. Plan these boundaries with your OT and security teams using the zoning guidance in NIST SP 800-82 Rev. 3, and confirm with your own compliance lead whether any feed crosses an asset classification boundary under your NERC CIP or NIS2 scope.
Customer portals behind SSO: choosing SAML or OpenID Connect
Many utilities already run a SAML 2.0 identity provider for workforce access, and some extend it to customers or contractors. In that case the contributed SAML Authentication module (samlauth) lets the Drupal site act as a SAML service provider. Its latest stable release, 8.x-3.14, supports Drupal 10.3 and later and Drupal 11, so the target Drupal version should be settled before the module is chosen.
- Metadata exchange: Service provider metadata, signing and encryption certificates, and assertion consumer URLs must be agreed with the identity team and loaded into both systems.
- Attribute contract: Confirm which attributes arrive in the assertion, such as a stable user identifier, email, and group or role claims, and how they are named.
- Logout behavior: Decide whether single logout is required, since session termination across the portal and identity provider has to be tested rather than assumed.
- Certificate lifecycle: Plan rotation dates for signing certificates so a renewal does not break customer sign-in during an outage window.
- Account handling: Decide whether accounts are created from assertions or pre-provisioned from a customer information system.
Before committing, confirm with your identity team which SAML profile and attributes your provider can issue to external users, and test a sign-in with a non-production account.
If the utility's identity platform issues OpenID Connect tokens, the contributed OpenID Connect module lets that provider authenticate Drupal users. The module creates an account on first successful sign-in, and it includes built-in clients for generic OAuth 2.0, GitHub, Google, LinkedIn, Facebook and Okta. For most utility identity platforms, the generic OAuth 2.0 client is the path that needs configuration work.
- Client registration: The identity provider needs a registered client with the correct redirect URIs for each environment, and secrets must be stored outside the codebase.
- Scopes and claims: Agree on the scopes requested and the claims mapped to Drupal user fields, including how a customer's account number or service address is represented.
- First sign-in behavior: Automatic account creation is convenient, but it means every authenticated identity can create a site account unless access is restricted elsewhere.
- Role mapping: Account creation does not assign meaningful roles on its own. Map identity groups to Drupal roles deliberately, and remove access when a customer or employee leaves.
- Token and session settings: Confirm token lifetimes and refresh behavior with the identity team.
For a customer portal, the question to settle is whether first sign-in should create a bare account that is then linked to billing records, or whether accounts should exist only after a verified match against the customer information system.
Many utilities run more than one identity source. Workforce staff may sign in through a SAML provider tied to the corporate directory, while customers authenticate through an OpenID Connect platform or a separate customer identity service. A mixed estate is common after mergers or acquisitions, and it is the case where the Drupal design has to separate audiences rather than rely on one login path.
- Separate login paths: Decide whether staff and customers use distinct entry points, distinct Drupal roles, or both, and keep administrative access off the customer path.
- Identifier matching: When the same person appears in two sources, define which identifier is authoritative and how duplicate accounts are merged or prevented.
- Provisioning ownership: Name the system of record for each population, such as the HR directory for staff and the customer information system for account holders.
- Lifecycle events: Define how deprovisioning from either source propagates to Drupal sessions and content ownership.
- Testing matrix: Test each identity source with each Drupal role, including failed sign-ins, expired sessions and lockouts.
Ask your identity team to document every source of users that will reach the portal and who owns each one before any module is configured.
Account provisioning and role mapping are where SSO projects usually take longer than the module configuration. Authentication only proves who the user is. The portal still has to decide what that person can see and change, such as their own bills, outage notifications for their address, or service requests. Those decisions need written rules before the build.
- Role model: Define roles for customers, delegated account managers, contractors and internal editors, and state which pages and data each role can reach.
- Attribute-driven rules: Specify which assertion or token claims grant which roles, and what happens when a claim is missing or unexpected.
- Account linkage: Decide how a portal account links to a customer account, meter or premise record, and who approves exceptions.
- Audit trail: Log account creation, role changes and failed sign-ins so that access decisions can be reviewed later.
- Offboarding: Plan how disabled accounts stop access to protected pages, including cached responses and active sessions.
The written role matrix and linkage rules are the artifacts to request from any implementation partner before development starts.
Customer portals at utilities fall within the security expectations placed on critical infrastructure operators, but the portal itself is usually outside the operational technology boundary. Whether a particular system is in scope for NERC CIP or NIS2 depends on the utility's classification and registration, so the identity design should be reviewed with compliance staff before it is treated as out of scope. Drupal security advisories also need a patch route that works with the identity integration.
- Patch cadence: Drupal core bugfix releases come on the first Wednesday of each month and security releases on the third Wednesday, and contributed modules such as samlauth need their own update checks.
- Advisory response: The Drupal Security Team publishes advisories with CVE identifiers and risk scores, so assign an owner who reads them and tests the identity modules after each update.
- Secrets handling: Keep signing keys, client secrets and certificates in a managed store with rotation procedures.
- Monitoring: Alert on spikes in failed sign-ins, unusual account creation volume and changes to role mappings.
- Environment separation: Use separate identity registrations for test, staging and production so that test credentials never reach customer data.
Before go-live, ask your security and compliance teams to confirm the regulatory scope of the portal, and ask the implementation partner to show the update and monitoring runbook for the identity modules.
Modules and settings that matter for utility sites
A utility site usually depends on a short list of contributed modules and core settings: how staff and customers sign in, how outage pages stay available under load, how notices are approved, and what gets recorded. Each card names one component and what to confirm before relying on it in your environment.
SAML sign-in with samlauth
The samlauth module lets Drupal act as a SAML service provider, so staff portals and customer areas can sign in through the identity provider you already run. The latest stable release, 8.x-3.14, supports Drupal 10.3 and later and Drupal 11. Confirm the attribute mapping for roles and account linking, how the site handles a provider outage, and whether your identity provider's signing certificate rotation is covered by a documented procedure before go-live.
OpenID Connect client for external providers
The OpenID Connect module lets an external provider authenticate Drupal users and creates accounts on first sign-in. This suits customer accounts where your identity platform is OpenID Connect based. Confirm which provider client you need, since built-in clients cover generic OAuth 2.0, GitHub, Google, LinkedIn, Facebook and Okta, and decide whether first-sign-in account creation is acceptable for customers or should be blocked until a record exists in your customer information system.
Caching and access control for outage pages
Outage and service interruption pages must load during the events that generate the most traffic. Use core page caching and cache tags so a notice update invalidates only the affected pages, and place a reverse proxy or CDN in front of anonymous outage content. Confirm that outage pages are not served from a stale cache after a status change, that restricted or internal notices are never cached for anonymous visitors, and that the origin can absorb a traffic spike if the CDN is bypassed.
Content workflow for regulated notices
Notices about outages, safety actions or rate changes often need review by operations, legal or regulatory staff before publication. Model these as a distinct content type with a moderation workflow, restricted publish permissions and scheduled unpublishing. Confirm who may publish emergency notices without review, how a notice is withdrawn or corrected, and whether revision history meets the retention rules your regulator expects for public statements.
Accessibility checks on public pages
Customer-facing bill, outage and payment pages carry accessibility obligations in many jurisdictions, so accessibility checks belong in the release process rather than a one-time audit. Run automated checks against templates and key pages in continuous integration, and add manual testing with assistive technology for forms, maps and outage tables. Confirm which conformance level your regulator or contract requires and who signs off on the results.
Logging and audit trails
Drupal records watchdog-style events and content revisions, but utility operators need to show who changed a notice, who signed in and which administrative actions were taken. Forward logs to a central system, set retention in line with your compliance program, and restrict who can read or clear them. Confirm which events are captured by default, which need custom logging, and how log integrity is protected when logs leave the Drupal host.
How a utility rollout is phased
The sequence starts with what data and systems are in scope and ends with a handover that operations can run without the build team. Each phase closes with evidence the operator can review before the next one begins.
Classify scope and data before design
Define which sites, content types and customer journeys are in scope, and classify each data type by sensitivity, such as public outage notices, customer account data and any information about operational assets. DeployOpen runs this with the operator's compliance, OT security and communications leads. Done means a signed data classification register and a list of systems Drupal will and will not touch. Ask early whether any content could reveal network layout or asset locations, because that content stays out of the public site.
Separate public and operational networks
Design the hosting boundary so the public-facing Drupal site and customer portal sit apart from any operational technology network. Integrations with outage management or SCADA-adjacent systems pass through controlled interfaces, not direct database or network access. Your OT security team reviews the zone and conduit diagram against the segmentation model in NIST SP 800-82 Rev. 3 and your own policies. Done means an approved diagram, firewall rules documented per flow, and a test showing the public tier cannot reach internal zones.
Integrate identity for customer and staff access
Connect the customer portal and any staff-facing editorial tools to the identity provider the operator already runs. The SAML Authentication module (samlauth) and the OpenID Connect module are the contributed options to evaluate, and each needs confirmation against your identity provider's configuration and your session and MFA policy. Test account creation, role mapping, logout and account deprovisioning with real test identities. Done means a documented login matrix for each role and a tested deprovisioning path.
Model content and approval workflows
Build content types for outage notices, service area pages, rate and program information, and emergency guidance, with fields that carry status, effective times and expiry. Define who can draft, review and publish each type, including who may override during an incident. DeployOpen configures these as custom modules and workflow states agreed with communications staff. Done means a walkthrough where each role publishes, expires and rolls back content, with the audit trail confirmed.
Load test the outage and status paths
Test the pages that matter most during an event: the outage map or status page, notice lookups and the login flow for customers checking their accounts. Use traffic profiles agreed with the operator, based on their own historical peaks, and test caching behavior, database connections and any upstream feed. Done means a written report of response times and error rates at target load, plus a list of fixes and a retest. Confirm the target load figures with your own data, since no general benchmark applies to every utility.
Review accessibility and run security testing
Check templates, forms, outage maps and the portal against the accessibility standards that apply to your jurisdiction and customer base, and fix defects before content is authored at scale. Then run application, API and infrastructure security testing against the public tier and the identity integration, with the findings tracked to closure. Done means an accessibility report with issues resolved or accepted in writing, and a security test report with retests showing the critical and high findings are closed.
Cut over and hand over operations
Move the site to production through a rehearsed cutover with a rollback plan, a freeze on content changes and a named incident contact. Hand over runbooks for updates, backups, restore tests, monitoring and the security advisory process, and train the operator's team to run them. Done means a completed cutover checklist, a successful restore test performed by the operator's staff, and a support arrangement that names who responds to security advisories and outage incidents.
Compliance boundaries a utility must respect
Utilities face several overlapping regimes, and the web estate often sits at the edge of them. The cards below separate what is usually in scope, what must be confirmed with your compliance and OT teams, and where a Drupal site can create evidence but never a finding of compliance.
NERC CIP scoping for the web estate
NERC CIP applies to BES Cyber Systems, so a public Drupal site is usually outside that boundary. The risk is in connections: any routable path from the CMS to an in-scope asset, such as an outage feed read from an operational system, can pull parts of the design into scope. Confirm the impact rating and asset list with your CIP program owner before the first integration is designed.
Electronic Security Perimeter boundaries
CIP-005-7 requires routable-connected assets of high and medium impact BES Cyber Systems to sit inside an Electronic Security Perimeter, and it routes all Interactive Remote Access through an Intermediate System. A customer portal or vendor support login that reaches OT networks must be designed around that rule. Document which Drupal components cross the boundary and how traffic is brokered.
Vendor and supply chain obligations
CIP-013-2 expects supply chain risk management plans that cover vendor incident notification, vulnerability disclosure, software integrity verification and vendor-initiated remote access. For Drupal, that means recording where core and contributed code comes from, how patches are verified, and who is notified when a Drupal security advisory affects your site. Map these to your plan and review it on the cycle your plan requires.
NIS2 duties for EU energy operators
NIS2 Annex I lists energy as a sector of high criticality, covering electricity, district heating and cooling, oil, gas and hydrogen. Operators in scope must manage cybersecurity risk across their networks and information systems, including public-facing services such as outage portals. Confirm with national counsel whether your entity is in scope and which national transposition rules apply to you.
EU cross-border electricity cybersecurity rules
Commission Delegated Regulation (EU) 2024/1366 is a network code on sector-specific cybersecurity rules for cross-border electricity flows, supplementing Regulation (EU) 2019/943. It applies to market and system operators involved in those flows rather than to a general content site. Check with your regulatory team whether any Drupal-hosted data, such as market or flow information, falls within the code's obligations.
Accessibility and evidence for auditors
Customer-facing outage and billing content carries accessibility obligations that depend on your jurisdiction and customer base. DeployOpen can prepare test results, accessibility settings, change records and patch evidence for your assessors. DeployOpen does not issue audit reports or certifications, and auditors and regulators decide whether your controls meet the requirement.
Questions utilities ask before hiring a Drupal partner
What drives the cost of a Drupal build for a utility?
Scope drives cost more than anything else: the number of content types, how many outage or service feeds you integrate, how many customer portal flows sit behind single sign-on, and how much accessibility testing the public pages need. Your partner is paid for planning, custom module and theme work, integration build, security hardening, testing and handover. Some of that is one-time, such as the initial build, while ongoing support, patching and upgrades recur. Ask any quote to split one-time and recurring costs, list each integration separately, and state what testing and documentation are included.
How long does a Drupal build take depending on scope?
Duration follows scope: a public information site with a few content types takes far less time than a build that adds outage feeds, a customer portal, SSO and a security review. No duration figure is given here, so ask for a timeline tied to the written scope, with milestones for content modeling, integration build, accessibility testing and go-live. Check whether the plan includes a staging environment and a load test before any outage or storm-related traffic is expected.
What must the utility team provide before a Drupal project starts?
Three inputs are needed early: an identity owner who confirms how customers and staff sign in, named data owners who approve outage, service and account data for each feed, and a security reviewer who signs off on hosting, network placement and access. Your team should also provide test accounts, API credentials, network routes to integration endpoints and a decision on where the site is hosted. Missing any of these usually adds rework, so list them in the statement of work with owners and due dates.
Can our internal staff run and maintain the Drupal site after launch?
Yes, if the handover is planned for it. Internal staff need to know how to deploy code through your build pipeline, apply Drupal core and contributed module updates, run backups and restores, read logs and respond to alerts. Ask for documented runbooks, a training session for the people who will own the site, and a clear split between what your team patches and what the partner supports under a retainer. Confirm that your team has the PHP and database skills the chosen Drupal version requires.
How are Drupal security advisories handled on a self-hosted site?
The Drupal Security Team publishes advisories for core and contributed projects, with CVE identifiers and risk scores, and releases security fixes on the third Wednesday of the month. Your team needs a process to read advisories, test patches on staging and deploy them quickly, so define who receives advisories and how fast a critical patch must go to production. Drupal 7 is a special case: its security support ended on January 5, 2025, and sites still on it need a migration plan or an extended support provider, as covered in the migration section.
How does CIP scoping change the Drupal work?
CIP scoping decides whether a Drupal site can touch any system classed as a BES Cyber System, and that decision is made by your compliance team under CIP-002-5.1a, not by the web project. In practice, most public outage and service sites sit outside the Electronic Security Perimeter, so the design keeps them away from operational networks. Integrations that send data toward OT or control systems need a supply chain review under CIP-013-2, which covers vendor incident notification, software integrity checks and vendor remote access. Ask your partner to document every integration path so compliance can classify it.
What should a Drupal quote contain before we sign?
A quote should follow from a written scope and list the content model, each custom module and theme, every integration with its endpoint and data owner, the identity approach, testing types including accessibility and security testing, hosting assumptions and the handover package. It should separate one-time build fees from recurring support, patching and upgrade work. Ask for assumptions about your environment, what changes require a new quote, and which Drupal version and PHP version the build targets, so that future upgrades are costed too.
How DeployOpen scopes and supports utility Drupal projects
DeployOpen plans, builds, hardens, documents and supports Drupal inside your own cloud accounts, data centers or air-gapped networks. For energy and utility sites, we start from the written scope, then agree how outage content, customer portals and security evidence will be delivered and maintained.
How we scope
- Written, fixed-scope agreement covering content types, modules, integrations and environments before work starts
- Inventory of outage, service and customer portal pages, with the audiences and load patterns each one must serve
- Confirmation of which systems sit in scope for your NERC CIP or NIS2 obligations and which stay outside the Drupal boundary
How we build
- Custom modules and themes built to run on Drupal 11, with PHP and database versions confirmed against the Drupal requirements
- SSO wiring for customer portals through contributed SAML or OpenID Connect modules, tested against your identity provider
- Accessibility and security testing scoped into each sprint, with findings tracked to closure before release
How we hand over
- Runbooks for deployment, cache purging during outage events, backup restores and rollback on your hosting platform
- Documentation of configuration, module inventory and the evidence your compliance team needs for patching and change records
- Knowledge transfer sessions with your operations and content teams, with access controls agreed before go-live
How we support
- Ongoing support, upgrades and continuous testing available as a retainer, scoped separately from the build
- Monitoring of Drupal core and contributed security advisories, with patch planning aligned to your change windows
- Periodic review of the upgrade path toward later Drupal majors, so each move is planned rather than urgent
