How Drupal Commerce and PCI DSS scope fit together
A Drupal Commerce store that takes card payments can reduce what the site handles by sending card entry to a gateway through hosted payment fields, but the site still owns parts of the cardholder data environment. The Stripe and Braintree integrations shift card capture and storage to the gateway, yet the store's checkout pages, its payment method configuration, its server logs, its admin accounts and the hosting beneath them remain in scope. DeployOpen plans and documents that boundary, prepares the configuration and evidence an assessor will ask for, and keeps the build inside infrastructure you control. Whether the store is in scope, and at what level, is decided by a Qualified Security Assessor or by the process your payment brands run, not by DeployOpen or by a module setting.
The platform helps most with requirements about secure configuration and change control. Commerce Stripe supports the Stripe Payment Element and Express Checkout, and Commerce Braintree stores card data in the Braintree vault for later processing, so you should confirm with your gateway and acquirer which card data paths actually reach your servers. Configuration export, pinned contributed module versions and a documented patch routine make it easier to show that changes are controlled and that the store runs supported code. Requirements on network segmentation, vulnerability scanning, file integrity monitoring, access reviews and log retention depend on your hosting and operations, and they will still need owners outside the Drupal codebase.
Before any build starts, ask the assessor and your acquirer which self-assessment questionnaire or report applies, and whether the store qualifies for a reduced set of requirements under your gateway's model. Then confirm the current version of PCI DSS with the PCI Security Standards Council's PCI DSS page, because a new iteration is under discussion and the timing of any release is not yet set. Plan the quarterly scanning and patching duties as recurring work with named owners, and record which of them the Drupal team performs and which the hosting or security team performs. Quotes for this work should show the scope assumptions, the evidence deliverables and who signs off on the final assessment.
Which PCI DSS requirements the Drupal Commerce setup touches
This table maps the 12 principal PCI DSS requirements to the controls a Drupal Commerce site configures, patches or depends on. Read each row for the Drupal or gateway setting involved, then check whether the gateway, hosting provider or merchant carries the control, since that party's evidence will be needed in the assessment.
| Requirement area | Drupal Commerce role and platform capability | Configuration the team must set |
|---|---|---|
| Secure network and firewalls (requirements 1 and 2) | Hosting provider and network team carry most of this. Drupal only defines which services listen and which hosts can reach the database and admin paths. | Restrict database and admin routes to needed sources, remove default accounts and disable unused services on the web server. Confirm ownership with the hosting provider. |
| Protect stored cardholder data (requirement 3) | With hosted payment fields, card numbers should not reach Drupal. Commerce Braintree keeps card data in the Braintree vault, and Commerce Stripe uses the Stripe Payment Element. | Confirm the Commerce payment flow never stores PAN in the Drupal database, logs or order exports. Review any custom payment or debug code. |
| Encrypt transmission of cardholder data (requirement 4) | Drupal serves the checkout pages. TLS and security headers are configured at the web server or reverse proxy, not in Drupal core. | Enforce HTTPS sitewide, apply current TLS settings at the web server and set security headers such as HSTS and frame restrictions on checkout pages. |
| Vulnerability management and patching (requirements 5 and 6) | Drupal Security Team advisories cover core and contributed modules, including Commerce modules. Security releases come on the third Wednesday of the month. | Subscribe to advisories, track Commerce and payment module versions, and apply security releases on a set cadence. Keep Drupal 10 and 11 on supported PHP versions. |
| Access control to the admin UI (requirements 7 and 8) | Drupal's role and permission system controls who can edit orders, payment settings and gateway keys. Individual accounts and two-factor authentication are configured per site. | Use named accounts, least-privilege roles for store staff, separate roles for developers, and review role assignments on a schedule. |
| Authentication and identity (requirement 8, continued) | Drupal can federate staff sign-in through SAML or OpenID Connect modules, reducing local password handling for back-office users. | Enforce strong authentication for administrators, lock out repeated failures and remove accounts when staff leave. Confirm the exact password and MFA rules your assessor expects. |
| Physical and host access (requirement 9) | Hosting provider or data center carries this control. Drupal has no role here beyond the hosting contract. | Obtain the hosting provider's responsibility matrix and current attestation documents for the platform layers you rent. |
| Logging and monitoring (requirement 10) | Drupal's watchdog and web server logs record admin actions and errors. Logs must be retained and protected, and they must not contain card data. | Forward admin, login and payment-module events to a central log store, restrict who can read them and confirm no card numbers are logged. |
| Testing security and information security policy (requirements 11 and 12) | Scanning and penetration testing are performed by the merchant or an approved party, and the written security policy is owned by the organization, not by Drupal. | Schedule quarterly external scans and recorded patch reviews, define a written policy covering Drupal, and retain evidence for the assessor. |
What evidence the store produces for an assessor
An assessor does not accept a description of the store. They ask for dated records that show each requirement is met and who maintains it. The cards below cover the core evidence categories, how to keep each one current, and which party on the project owns it.
Attestation of Compliance and assessment report
Your SAQ or Report on Compliance, with its Attestation of Compliance, is the primary validation document. The SAQ type and the scope it describes depend on how much cardholder data the site still touches once hosted payment fields are in place. Keep the signed AOC dated and tied to the scope statement, and re-validate whenever the payment flow, gateway or hosting changes. Certificates or badges are not accepted as validation. The merchant owns this document, and a Qualified Security Assessor completes the ROC when one is required.
Gateway attestation and responsibility matrix
Your payment gateway should supply its own PCI DSS attestation and a written responsibility matrix that states which requirements it covers and which remain with the store. Ask for the current AOC for the exact gateway service you use, not a marketing statement. Compare the matrix against your Drupal configuration, especially where the Commerce Stripe or Commerce Braintree module handles the payment form. Confirm the matrix is refreshed each year and filed with the AOC. Procurement or the store owner keeps it, and the engineering lead checks it against each release.
Configuration exports under version control
Commerce payment gateway settings, payment method plugins, checkout flows and Drupal's configuration exports should live in Git with reviewed merge requests. This shows which payment provider is active, which checkout steps collect data, and when each change was made and approved. Assessors often sample a change to see whether it followed a documented process. Export configuration after every change, exclude secrets from the repository, and keep the production export matched to the deployed commit. The development lead owns this record.
Patch records tied to security advisories
Keep a log that maps each Drupal core and contributed module update to the Drupal Security Team advisory it addresses, with the date it was applied to production. Security releases come out on the third Wednesday of the month, so record when your team reviewed and deployed each one, including any that were deferred and why. For Commerce modules, log the update of the payment gateway modules separately because they sit closest to the cardholder data flow. The platform or operations lead owns the log and reviews it monthly.
Quarterly scan reports
Keep the external vulnerability scan reports from an Approved Scanning Vendor and the internal scan reports for each quarter, along with the remediation tickets for any findings. The scans should cover the public store endpoints, the checkout pages and the hosting perimeter. Confirm with your assessor which scan types they expect and whether a rescan is needed after remediation. Filing each report with its scope statement and date makes the trail easy to follow. The security or infrastructure lead owns the schedule, and the vendor produces the external reports.
Access reviews and administrator records
Maintain a current list of Drupal administrator, Commerce manager and gateway dashboard accounts, and review it on a fixed schedule with the date and reviewer recorded. Remove accounts for staff who have left, and confirm that multi-factor authentication covers every account with payment-related permissions. Gateway dashboard users should be reviewed separately from site users. Record each review with the approver's name and any changes made. The security lead or the store owner signs off, and the platform team maintains the account list.
Configuring the store to keep PCI DSS scope narrow
This sequence sets the store up so card data stays with the payment provider, the site's own controls are documented and patched on a fixed rhythm, and the evidence an assessor will ask for exists before the assessment begins. Each step closes with a check the team can show a QSA.
Confirm the integration method with the acquirer and QSA
Before any module is chosen, the merchant agrees the payment integration method with its acquirer and, where one is engaged, its Qualified Security Assessor. The team asks which hosted fields or redirect flows the acquirer accepts, whether the provider's attestation of its own PCI DSS status will be relied on, and which responsibilities sit with the site. The output is a short written note of the agreed integration method and the scope boundary it implies, signed off by the merchant's compliance owner. Without this note, later module decisions rest on assumptions the assessor may not accept.
Choose the gateway module and hosted fields
The development lead selects the gateway module, such as Commerce Stripe or Commerce Braintree, and configures the hosted payment method so card entry happens in fields served by the provider rather than in Drupal forms. For Stripe, this means reviewing which Payment Element and Express Checkout options are enabled. For Braintree, it means confirming that card data is stored in the Braintree vault and that the site holds only tokens. The check is a test checkout in which the browser network traffic shows card numbers going directly to the provider, with no card fields in the Drupal database or logs.
Remove custom card-handling code
The developer reviews the custom modules, themes and checkout plugins for any code that reads, logs, stores or forwards primary account numbers or card security codes. Any such code is deleted, and the payment flow is reduced to calls the gateway module makes to the provider. The review is recorded as a code review sign-off that lists each file examined and the result. The output is a repository in which a search for card field names returns no handling logic outside the vetted gateway integration, and that search is repeated at each release.
Lock down admin roles and two-factor access
The Drupal administrator limits store administration to named roles, removes unused accounts, and requires two-factor authentication for every account that can change payment settings, checkout logic or user permissions. Gateway API keys are kept in environment configuration or a secrets manager, not in the exported site configuration. The output is a role matrix and an account list reviewed by someone other than the administrator, showing who can reach payment settings and how each person authenticates.
Enforce HTTPS and security headers
The platform engineer configures the web server so every page that is part of checkout, account or administration is served over HTTPS, redirects plain HTTP requests, and sends the security headers the team has agreed, including content security policy rules that limit scripts to approved sources. The payment provider's script domains are added to the policy explicitly. The check is a scan of each checkout page and a browser test confirming the policy blocks unapproved script sources without breaking the payment form.
Set up security advisory monitoring and a patch routine
The operations lead subscribes the team to Drupal security advisories and to the advisories for each contributed commerce module in use. The routine is written down: security releases arrive on the third Wednesday of the month, bugfix releases on the first Wednesday, so the team schedules a test and deployment window that follows each security release. Each advisory is logged with the date received, the affected component, the decision and the date applied. The output is a patch log that shows the store's response time to each advisory, which is the record an assessor will ask to see.
Export configuration to version control
The developer exports the Drupal configuration, including payment gateway settings with secrets removed, roles and permissions, and checkout workflows, and commits it to version control. Every change to payment or access settings then arrives as a reviewed commit rather than an edit made directly on production. The output is a repository where the production configuration matches the last reviewed commit, and where a diff can show who changed what and when.
Schedule quarterly scans and assemble the evidence pack
The compliance lead schedules quarterly external vulnerability scans with an approved scanning vendor and ensures the scan results, patch log, role matrix, configuration history, integration note and code review sign-offs are stored together in one evidence pack. The assessor's requirements, the assessment type (a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance) and the scope of each item should be confirmed with the acquirer first. The output is an indexed evidence folder that a new team member could use to answer the assessor's questions without reconstructing history.
Patching and scanning duties that stay with the site
The recurring duties on a Drupal Commerce store stay with the site owner after the payment fields are hosted by the gateway. Patching is the one that changes most often. Drupal core bugfix releases land on the first Wednesday of each month and security releases on the third Wednesday, according to the Drupal core release schedule, so the team needs a standing review slot in those weeks and a way to apply contributed module updates such as Commerce Stripe or Commerce Braintree within the same cycle. Record each patch decision in the change log with the advisory identifier, the date applied and the environment it reached, because that record is what an assessor will ask to see.
The platform upgrade path belongs in the compliance scope, not in a separate project plan. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 requires PHP 8.5 or later, so a store running Drupal 10 will need a planned move to Drupal 11 first and then to Drupal 12 before its PHP and core versions fall out of support. Confirm the PHP version on every host, including the cron and queue workers, and confirm that each contributed payment module has a release for the target Drupal version before you commit to a date. An unsupported platform is a finding a QSA will raise, so the upgrade should be on the same risk register as the scanning results.
Quarterly internal and external vulnerability scans are the site owner's obligation to schedule, and the scanning vendor must be one that PCI SSC approves for that purpose. Ask the vendor to scan the cardholder data environment boundary, including the store host, the admin interface and any system that can reach the payment integration. After each scan, document the scan date, the scope scanned, every finding with its severity, the remediation owner and target date, and a re-scan result that closes it. Keep the rescan evidence with the ROC or SAQ file so the assessor can trace each finding from detection to closure.
Questions buyers ask about PCI DSS scope on Drupal Commerce
Do hosted payment fields take a Drupal Commerce store out of PCI DSS entirely?
No. Hosted payment fields reduce the cardholder data your systems touch, which usually shrinks the assessment, but they do not remove it. The site still runs the checkout page that loads the gateway's fields, controls which scripts run on that page, holds the gateway credentials, and is responsible for any card data that reaches its servers, logs or backups by mistake. The store also still needs the quarterly external scanning and patching duties that apply to the systems in scope. Your acquirer or a Qualified Security Assessor should confirm the final scope in writing, because the answer depends on how your checkout is built.
What drives the PCI DSS effort on a Drupal Commerce store?
Effort follows the parts of the checkout you control and how much evidence already exists. The main drivers are:
- The integration method: the Payment Element or Express Checkout in Commerce Stripe, or the Braintree vault flow, carry different responsibilities for the page that collects card data.
- Custom checkout code: any custom JavaScript, Twig or pane logic that touches the payment step adds to the review.
- The hosting model: shared, self-managed or containerized hosting changes which servers, networks and administrators are in scope.
- The number of admin users with access to the Drupal back end, the database and the server.
- Existing evidence: documented change management, patch records and access reviews shorten the work.
Can our own team handle PCI DSS scoping for Drupal Commerce without a partner?
Yes, if you have security and compliance staff who can own the work, and if your acquirer or a Qualified Security Assessor confirms the scope you choose. Your team needs to map the checkout data flow, decide which validation path applies, document the controls, and run the quarterly scans and patching that keep the evidence current. A partner is most useful where the team lacks Drupal and payment integration experience, or where the codebase has custom checkout logic that someone must review line by line. Assessment reports and attestations are issued by the assessor and the acquirer, not by DeployOpen.
What does the client need to provide for a PCI DSS scope project on Drupal Commerce?
The work depends on access and a named owner. Expect to provide:
- Read access to the Drupal codebase, including custom modules, themes and the configuration export.
- Access to the hosting environment, including web servers, database servers, backups and logging.
- Gateway accounts and test credentials for Stripe or Braintree, with the ability to confirm which integration mode is live.
- A named owner for patching and quarterly scanning who can approve changes and sign off on evidence.
- Your acquirer contact, so scope questions are answered before the design is final.
How long does a PCI DSS scope reduction for Drupal Commerce take?
Duration depends on the scope you agree, not on a standard number of weeks. The main variables are how many custom checkout components exist, how many environments and servers are in scope, how much existing documentation you have, and how quickly the acquirer or assessor responds to scope questions. A narrow hosted-field integration with a clean codebase and documented operations moves much faster than a store with custom payment logic and unclear hosting responsibilities. Ask for a timeline in the written scope that lists the dependencies, such as access approvals and assessor review windows, rather than a single overall estimate.
What should a quote for PCI DSS scope work on Drupal Commerce include?
A quote should follow from a written scope, and it should list the following:
- The systems, sites and environments in scope, and the systems explicitly out of scope.
- The checkout integration to be reviewed, including gateway mode and any custom checkout code.
- Deliverables such as a data flow diagram, a responsibility matrix, configuration and patch procedures, and the quarterly scan and patch runbook.
- The evidence list that your assessor or acquirer will ask for, and who produces each item.
- What is excluded, such as the formal assessment, scanning services, gateway contract changes, or ongoing retainer support.
- Which costs are one-time and which recur, such as scanning and patch cycles.
Which PCI DSS version should a Drupal Commerce team plan against?
Plan against PCI DSS v4.0.1, which is the only active version. The PCI Security Standards Council published it as a limited revision of v4.0 with no added or deleted requirements, and v4.0 was retired at the end of 2024. Many requirements introduced in v4.0 became effective in March 2025, so older checklists may miss them. The Council also ran a request for comments on v4.0.1 in mid-2026 to start the next iteration, but it had announced no release date for a new version. Confirm the version your acquirer expects in writing before you build your evidence.
Handing the evidence to the QSA or acquirer
This sequence turns the scope work, configuration evidence and gateway documentation into a package that an assessor or acquirer can review without rebuilding the picture from scratch. It also fixes who signs what before the assessment starts.
Confirm the assessment type with the acquirer
Ask your acquirer or payment processor which validation route applies to your store, whether a Self-Assessment Questionnaire or a Report on Compliance, and which SAQ type fits your payment flow. The payment brands decide who must validate and run any enforcement programs, and the PCI SSC does not enforce compliance or impose penalties, so the acquirer's written answer is the authority you work from. Record the answer, the contact who gave it and the date. The step is done when the assessment type and the acquirer's requirements are confirmed in writing.
Draft the scope statement
Write a scope statement that names every system in the store that stores, processes or transmits cardholder data or could affect that environment, and states which components are excluded because the gateway's hosted payment fields keep card data off your servers. Include the Drupal site, hosting, database, logging, the Commerce payment modules and any integrations that touch order data. Have the platform owner and the security lead review it against the current architecture diagram. The step closes when the statement and diagram agree on every system boundary.
Build the responsibility matrix
Create a matrix that assigns each PCI DSS requirement area to one of three owners: your organization, the Drupal hosting provider, or the payment gateway. Cover the Drupal patching cadence, the Stripe or Braintree responsibilities for card handling, the quarterly scanning duties, access reviews and logging. Mark gaps where no party clearly holds a control. Ask the gateway for its own attestation documentation so the matrix cites real evidence for each shared item. The step is done when every requirement row has one named owner and a reference to the evidence that proves it.
Assemble the evidence packs
Organize evidence by requirement into folders that map directly to the responsibility matrix. Typical contents include configuration exports from version control, patch records against Drupal security advisories, scan reports and remediation tickets, access and role review records, change records and backup and log samples. Keep each pack dated and tied to the scope statement version. Note that a Drupal site's patch history is only useful if it shows timeliness against the security releases the Drupal Security Team publishes. The step closes when each pack has an index, an owner and a dated artifact for every row it supports.
Obtain the gateway attestation for the assessor
Request the current attestation of compliance from Stripe, Braintree or the gateway you use, and confirm that it covers the hosted payment fields and the services your store relies on. Place a copy in the evidence set and make sure the assessor can see the gateway's own validation status without relying on your summary. Confirm the attestation's validity period with the gateway. Certificates are not accepted as validation under PCI SSC guidance, so request the formal attestation document, not a badge or letter. The step is done when the assessor has the document itself.
Hand over and agree the review schedule
Send the scope statement, responsibility matrix, evidence packs and gateway attestation to the QSA or acquirer in a single transmittal, with a named contact on your side for questions. Agree in writing how clarification requests will be logged and answered, and which version of the scope statement the assessment will reference. Ask the assessor to confirm receipt and to list any evidence they expect that is missing. The step is done when the assessor or acquirer acknowledges the package in writing and the open questions are logged.
Track and answer assessor queries
Route each query from the assessor to the owner named in the responsibility matrix, and record the answer, the evidence reference and the date in a shared log. When a scope change happens during assessment, such as a new integration or a Drupal Commerce module update, update the scope statement and matrix and tell the assessor before the change is relied on. Keep the log as part of the final record. The step closes when every query has a documented answer and no open item remains without an owner.
How DeployOpen scopes and documents PCI DSS work on Drupal Commerce
DeployOpen plans, builds, tests and documents Drupal Commerce stores inside infrastructure the client controls, with the cardholder data boundary defined before the build starts. The written scope, the evidence pack and the handover runbook are set up so your internal team and your Qualified Security Assessor can follow what was built and why.
How we scope
- We map every page, form, webhook and integration that touches the payment flow before agreeing scope.
- The written scope states which gateway fields, redirects and tokens sit inside or outside your environment.
- We confirm with your assessor and acquirer which PCI DSS validation path and SAQ type applies to your store.
How we build
- We configure hosted payment fields from the gateway so card numbers never reach your Drupal servers.
- We test checkout, refunds, webhooks and failure paths in a non-production environment with production-like settings.
- We document each requirement the build touches, with configuration exports and access records kept under version control.
How we hand over
- You receive a scope diagram, data-flow description and responsibility matrix that match the deployed configuration.
- Runbooks cover quarterly scanning, patch routines for Drupal core and contributed modules, and access reviews.
- Knowledge transfer sessions walk your team through the evidence they must keep for each assessment cycle.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing patching, scanning coordination and gateway upgrades are available as a retainer if you prefer continuity.
- Confirm with DeployOpen during scoping which tasks remain with your team, your hosting provider or your gateway.
