How much of Odoo PCI DSS scope your payment design removes
Odoo's documentation states that it delegates sensitive payment data to certified payment providers and stores no card numbers on Odoo servers or in Odoo databases, using reference numbers instead. If a certified provider handles card capture, your Odoo instance never receives the primary account number, which removes the largest share of cardholder data handling from your environment. A self-hosted eCommerce site still carries duties, though, and how many depends on how the payment page is built: whether customers are redirected to the provider, whether the provider's form is embedded as an iframe, or whether card fields are rendered by your own code.
The platform reduces your burden most clearly around storage and data flow, but it does not remove your responsibility for the web layer you operate. If your checkout embeds a provider's page or form, the PCI SSC's eligibility criteria for SAQ A require you to confirm the site is not susceptible to script attacks that could affect the payment page. That confirmation is where Requirements 6.4.3 and 11.6.1 come into play for many merchants, covering payment page script authorization, script integrity, a script inventory with written justifications, and change and tamper detection. These controls concern your theme, custom modules, third-party scripts and tag managers, not Odoo's core code alone.
Several duties stay with you regardless of design. Quarterly external vulnerability scans by an Approved Scanning Vendor apply to merchant webpages that redirect to a provider or embed its iframe, and they cover the public hosts you run. Patching is also yours: the v4.0.1 wording applies a 30-day installation window to critical patches only, while other patches follow a timeframe you define, so your Odoo version, operating system and database patch cadence must be written down and followed. Odoo's standard support window and SaaS release cadence, covered in the support section, set how long a version can be patched at all.
Mapping PCI DSS requirements to Odoo capabilities and configuration
This table maps the PCI DSS requirements that most affect an Odoo eCommerce site to what Odoo provides, what the merchant configures and what stays with the merchant. Read each row against your payment setup, because several requirements depend on whether the payment page redirects to a provider or embeds its iframe. The main takeaway is that Odoo keeps card data with a certified provider, while script control, change detection, scanning and patching remain the merchant's responsibility.
| Requirement | What Odoo provides | Configuration the merchant needs | What remains with the merchant |
|---|---|---|---|
| Cardholder data storage | Card entry is delegated to a certified payment provider. Odoo stores reference numbers only. | Certified provider configured under payment providers. Record the embedding method and hosting type in the scope document. | Confirming provider certification, keeping its attestation, and keeping card data out of logs, exports and custom code. |
| Requirement 6.4.3 (payment page scripts) | Odoo does not document a script inventory or integrity method for storefront scripts. Confirm this with Odoo. | List every script on payment pages, including provider iframes and custom modules, with a written justification for each. | An authorization method and an integrity method for each script, the inventory itself, and periodic review. Mandatory since 31 March 2025. |
| Requirement 11.6.1 (change and tamper detection) | Odoo does not document change and tamper detection for the consumer browser view. Confirm what the provider's embedded page covers. | Set a baseline for security headers and payment page content, and restrict scripts with a content security policy. | Alerting on unauthorized changes to headers and payment page content as the consumer browser receives them. |
| Requirements 11.3.2 and 11.3.2.1 (ASV scans) | Odoo does not act as an approved scanning vendor or run the scans. | Storefront hostnames in scan scope, including the redirect or iframe host where the payment flow uses one. | Quarterly external scans by an ASV, passing results, and retained reports. Required for SAQ A redirect or iframe embedding. |
| Requirement 6.3.3 (patching) | Security updates during standard support, which covers three years after a major release. | Hosting type fixed as Odoo Online, Odoo.sh or on-premise, on a version still in standard support. | Installing critical patches within 30 days under v4.0.1, setting timeframes for other patches, and testing upgrades in a copy first. |
| Requirement 12.3.1 (SAQ A) | Odoo does not produce the merchant's risk analysis or eligibility statement. | Record the script-attack eligibility check for the embedded page and review it after each site change. | Confirming the site is not susceptible to script attacks that could affect its e-commerce systems, and signing the attestation. |
Why redirect, iframe and POS payments end up in different scope
The payment design an Odoo store uses decides which PCI DSS requirements apply to the site, so this is the first decision to settle. In an online checkout, the merchant either redirects the customer to the provider's hosted page, embeds the provider's iframe or form in its own page, or fully outsources payment so that the card fields never sit on the merchant's pages at all. Odoo's documentation states that sensitive information is delegated to certified payment providers and that card numbers are not stored on Odoo servers, using reference numbers instead. That delegation narrows the card data environment, but it does not by itself remove every obligation on a self-hosted eCommerce site. The design choice determines which of the remaining obligations apply.
The PCI SSC's position on the script-attack criterion turns on that choice. According to PCI SSC FAQ 1588, the criterion applies to merchants whose webpage embeds a payment provider's page or form, such as an iframe. It does not apply to merchants that redirect customers to the provider or fully outsource payment. Since 30 January 2025, SAQ A also asks the merchant to confirm that its site is not susceptible to script attacks that could affect its e-commerce systems. A merchant embedding an iframe in an Odoo website template must therefore be able to answer that question for its own theme, custom modules and third-party scripts, and should record how it reached that answer. Anyone who has added a tracking script or chat widget to a checkout page should treat that script as part of this review.
The quarterly scan duty follows the same split. According to PCI SSC FAQ 1604, SAQ A for PCI DSS v4.x requires quarterly external vulnerability scans by an Approved Scanning Vendor (ASV), under Requirements 11.3.2 and 11.3.2.1, for merchant webpages that redirect to a payment provider or embed its iframe. The scan covers the internet-facing Odoo site, so the team needs to confirm which hostnames, reverse proxies and load balancers serve checkout pages and make sure they are in the ASV's scope. Ask the ASV and the acquirer which SAQ type applies to your design before the first scan, and keep the scan reports as evidence.
In-store point of sale is a separate case and should not be assumed to follow the online analysis. The supplied facts do not describe how POS terminals exchange card data with Odoo Point of Sale, which terminal models are involved, or whether the terminal is a standalone device that sends only a payment result back to Odoo. Before drawing any scope boundary, confirm the design against Odoo's point of sale payment documentation and the terminal vendor's documentation, and map each network path that carries card data. Ask the acquirer which SAQ type covers the in-store channel, because a store that combines an embedded online checkout with a terminal may need the online and POS channels assessed on different questionnaires.
The practical output of this section is a short written record: the payment design for each channel, the reason for that design, the SAQ type each channel points to, and the owner who will re-check the design when the payment provider, theme or terminal changes. This record is the starting point for the scope decisions described elsewhere on this page.
What evidence an auditor or acquirer will ask you to keep
The evidence for this scope falls into two groups: records showing that card data never reaches Odoo, and records showing that the payment page, its scripts and the platform beneath it are controlled and monitored. Keep each record dated and current, because an acquirer or assessor will ask how each one was produced and when it was last reviewed.
Payment provider configuration records
Keep the configuration of each payment provider in Odoo, along with the provider's documentation showing that card numbers are entered on the provider's page and that Odoo stores only reference numbers. Record which provider handles online payments and which handles in-store POS payments, since each path has its own data flow. Odoo's documentation states that it delegates sensitive information to certified payment providers and stores no card numbers on Odoo servers, so confirm that statement against your own hosting setup and recheck the configuration after each upgrade or connector change.
Payment page script inventory
Requirement 6.4.3 calls for an inventory of every script on the payment page, with a written justification for each one. Record each script's source, its purpose, who approved it, and the method used to confirm it is authorized and that its integrity is assured. Scripts added through Odoo modules, themes, tag managers and analytics tools all belong in the inventory. Reconcile the list against the live page at each review, because a script added during a theme update is easy to miss.
Change and tamper detection alerts
Requirement 11.6.1 calls for a mechanism that alerts personnel to unauthorized changes to security-impacting HTTP headers and to payment page content as the consumer's browser receives it. Keep the alert configuration, the list of monitored items, and a log of alerts showing the response and the person who closed each one. Run a controlled test change and keep its record. Confirm with your acquirer and assessor how they expect browser-side content to be captured as evidence.
Quarterly ASV scan reports
Merchants that redirect customers to a provider or embed its iframe must complete quarterly external vulnerability scans by an Approved Scanning Vendor under Requirements 11.3.2 and 11.3.2.1 of SAQ A for PCI DSS v4.x. Keep each quarterly report with its date, the hosts it covered, and the remediation records for any findings. Check that the scope includes every public address serving the store and checkout, including subdomains. Ask your acquirer whether the scan scope and report format they accept match what the vendor delivers.
Patch, version and test copy records
Keep a record of the Odoo version in production, its support status, and the dates each patch was applied. Odoo's standard support covers the first three years after a major release, including security updates, so the release date sets how long security patches are available. PCI DSS v4.0.1 applies the one-month installation timeframe to critical patches. Also log each database copied for testing, with the neutralization steps Odoo applied and any extra steps that stopped the copy from reaching live payment providers.
SAQ and Attestation of Compliance
The completed SAQ and its Attestation of Compliance are the first documents a payment brand or acquirer reviews. The SAQ type depends on how payments are built, so confirm with your acquirer which SAQ applies, or whether a Report on Compliance completed by a Qualified Security Assessor is required, before you start. Certificates are not accepted as validation. Keep the signed AOC with its date, the answers supporting each requirement, and the evidence those answers reference.
Which PCI DSS version and deadlines apply to an Odoo eCommerce site today
The active standard is PCI DSS v4.0.1, published on 11 June 2024 as a limited revision of v4.0 with no requirements added or deleted. PCI DSS v4.0 was retired on 31 December 2024, and v3.2.1 was retired on 31 March 2024, so an assessment that still cites either earlier version will not meet current expectations. For an Odoo eCommerce site, your Self-Assessment Questionnaire or Report on Compliance and its Attestation of Compliance should reference v4.0.1 unless your acquirer or the card brands state otherwise. Confirm that expectation in writing before you start the assessment, because the version named on your paperwork determines which requirement numbers you map your Odoo configuration against.
Many of the controls that matter most for a checkout built in Odoo were future-dated. Of the 64 new requirements in v4.0, 51 became effective on 31 March 2025. Two of them apply directly to the storefront: Requirement 6.4.3 covers authorization, integrity and inventory of every script on a payment page, and Requirement 11.6.1 covers change and tamper detection for the payment page and its security-impacting HTTP headers. On Odoo, that means auditing the scripts added by the website theme, analytics tags and any third-party module, and confirming which page elements the payment provider's iframe or redirect actually depends on. On 30 January 2025, the PCI SSC removed 6.4.3, 11.6.1 and the related 12.3.1 risk analysis from SAQ A and added an eligibility criterion: the merchant confirms its site is not susceptible to script attacks. That criterion applies when your page embeds a provider's iframe or form, not when customers are redirected or payment is fully outsourced.
The PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026 to begin the next iteration of the standard. As of October 2026, it had announced no release date for a new version. Treat that as a reason to watch for change, not as a reason to delay controls that already apply. Your Odoo project should record which version your evidence maps to, the date each control was last reviewed, and who owns the review. When a new version is published, the mapping will need updating, and documented evidence makes that update much faster.
Platform support sets a second deadline. Odoo 17.0 standard support ended in September 2026. Odoo 19.0 has standard support until September 2028, and Odoo 20.0, released in September 2026, has standard support planned until September 2029. Standard support is the period in which Odoo provides security patches. Extended support is paid, limited to Odoo.sh for select versions and to on-premise, and does not cover security patches. A version outside support therefore makes the patch duties in v4.0.1 harder to meet. The standard now requires critical patches within one month, with other patches installed within a timeframe you define and document. Confirm your Odoo version's end-of-support date, the upgrade path through a tested database, and the timeframe your acquirer expects before you commit to a hosting plan.
What Odoo does not cover for your PCI DSS obligations
Odoo keeps card numbers out of its own databases, but a self-hosted store still carries obligations that sit outside the platform. The cards below set out what remains with your organization, from scanning and attestation to hosting, custom code and the upgrade calendar.
ASV scans and script review
Odoo does not run the external vulnerability scan that an Approved Scanning Vendor performs for merchants that redirect to a provider or embed its iframe. Your organization must engage an ASV, schedule the quarterly scans, and resolve any findings on the public-facing store. Script inventory and integrity checks on payment pages are also yours to perform, because they depend on what your site loads, not on the Odoo core.
Attestation and scope decisions
Odoo does not issue an Attestation of Compliance, and no product can. The AOC comes from your own assessment on the correct PCI SSC template. Whether a customized page changes your validation type or your scope is a judgment you must make with your acquirer or a Qualified Security Assessor, and the platform cannot make it for you.
Hosting, network and access controls
The hosting environment, network segmentation, access control and logging retention are your responsibility wherever Odoo runs, whether on Odoo.sh, on-premise or in your own cloud account. Confirm which systems can reach the store, who holds administrative accounts, how sign-in is enforced, and how long logs are kept and reviewed. Odoo's sign-in options do not decide these settings for you.
Written policies under Requirement 12
Requirement 12 covers the information security policy, risk assessment, service provider management and security awareness. These are documents and processes your organization owns, and no platform supplies them. Prepare a policy set that names who maintains the Odoo environment, how third parties are reviewed, and how staff are trained before the assessment begins.
Custom modules, themes and scripts
Custom modules, themes and third-party scripts added by developers fall outside Odoo's provider design, so Odoo does not vouch for them. Each one needs an entry in your own inventory, with its source, owner, justification and integrity method. A developer adding a tracking script to checkout can change your payment page scope without any change to Odoo's payment providers.
Patch windows and mandatory upgrades
Odoo's security patches are only provided during standard support, so a version past its standard window no longer receives them unless you have a supported extended option. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. Plan each upgrade as a tested change with a test database and a schedule, because the upgraded environment is what your PCI DSS evidence must describe.
Configuring an Odoo eCommerce site for a PCI DSS scope review
This sequence sets the Odoo hosting, payment and page design that determine which PCI DSS requirements apply to a self-hosted eCommerce site. It ends with a dated evidence folder that the acquirer and the assessor can review.
Confirm hosting type and Odoo edition
Record the Odoo edition, hosting type and exact version of the eCommerce site, then check each against the Odoo plan list. Community, Enterprise and Odoo Online have different constraints, and only the Custom plan can run on Odoo.sh or on-premise. Confirm the version is still in standard support, because security patches are provided only during standard support. Note the upgrade path for the next major version, since Odoo.sh and Odoo Online require major upgrades every two years. Done when the hosting record names the edition, plan, version and support end date, and an engineer has signed it.
Choose and verify payment providers
Select the payment providers for online and in-store payments, then confirm each one is a certified provider that holds its own PCI DSS attestation. Odoo documents that it hands sensitive card data to certified providers and stores reference numbers instead of card numbers. Ask each provider for its current Attestation of Compliance and the service description that covers the integration you plan to use. Record which provider handles which channel. Done when the provider list, the attestation references and the channel mapping are filed. Confirm the POS terminal configuration with the terminal provider as well.
Select the payment page embedding method
Decide whether customers are redirected to the provider's hosted page, the provider's iframe or form is embedded in your Odoo pages, or the payment is fully outsourced. This choice sets the scope. PCI SSC FAQ 1588 says the script-attack eligibility criterion applies when your page embeds a provider's page or form, and not when customers are redirected or payment is fully outsourced. Under SAQ A, redirect and iframe models both require quarterly ASV scans of merchant webpages. Document the chosen method, the reason for it and the pages affected. Done when the decision record is approved by the business owner and the acquirer.
Inventory and justify payment page scripts
For any embedded payment page, list every script that loads in the browser, including those from Odoo modules, themes, tag managers and third-party widgets. For each script, record who authorized it, the method used to check its integrity, such as a hash or subresource integrity control, and a written justification for why the page needs it. Requirement 6.4.3 requires these three elements and was mandatory from 31 March 2025. Remove any script that cannot be justified. Done when the inventory covers every script on the payment pages and each entry has an owner and a justification.
Configure change and tamper detection
Set up a change and tamper detection mechanism on the payment pages and the security-impacting HTTP headers, as the consumer's browser receives them. Requirement 11.6.1 requires alerts to personnel when these change without authorization. Route alerts to a monitored queue with an owner, and test them by making a controlled change to a non-production copy of the page. Confirm that the alert fires, that it reaches the named owner, and that someone records the response. Done when a test change produces a logged alert, and the alert procedure is documented with the owner's name.
Schedule ASV scans and patch windows
Book quarterly external vulnerability scans by an Approved Scanning Vendor for the internet-facing Odoo site, as Requirements 11.3.2 and 11.3.2.1 require for the redirect and iframe models. Under PCI DSS v4.0.1, the one-month installation timeframe applies to critical patches, and other patches follow a timeframe you set. Align patch windows with Odoo's security patch availability, which is provided only during standard support. Schedule upgrades before the end of standard support for your version. Done when the scan calendar, patch policy and upgrade date are approved and visible to the acquirer.
Set up neutralized test copies
Create test copies of the Odoo database using Odoo's documented duplication and neutralization steps, so that the copy does not hold live payment provider credentials or production customer data. Check the neutralized copy against Odoo's documentation for what neutralization changes, and set each payment provider in the copy to a test or disabled state. Keep test copies inside the same access controls as production, and restrict who can use them. Done when a test copy is created, the provider settings in it are confirmed as non-production, and the test copy is listed in the environment inventory.
Assemble the evidence folder for the acquirer
Collect the outputs of the earlier steps into one evidence folder: the hosting record, provider attestations, embedding decision, script inventory, tamper detection test results, ASV scan reports, patch and upgrade calendar, and test copy records. Index each item to the PCI DSS requirement it supports. Ask the acquirer which validation type it expects, such as an SAQ with an Attestation of Compliance or a Report on Compliance completed by a Qualified Security Assessor. DeployOpen prepares this evidence but does not issue attestations, and certificates are not accepted as validation. Done when the acquirer confirms it has received the folder and the index.
Common questions about Odoo PCI DSS scope and effort
What drives the cost of an Odoo PCI DSS scope review?
Cost follows the scope you agree in writing, and DeployOpen does not publish prices or give a fee figure here. The main drivers are payment design (redirect, hosted fields or an embedded iframe), the number of payment page scripts and third-party modules to inventory and justify, hosting type (Odoo Online, Odoo.sh or on-premise), custom modules, scan and patch cadence, and whether your company or a Qualified Security Assessor validates the result. Ask the quote to separate one-time work (inventory, data flow mapping, gap analysis) from recurring work (quarterly ASV scans, change detection, patch cycles), and to name who performs each task and who you pay for it.
How long does a PCI DSS scope review for Odoo take?
Duration depends on your environment, and no duration figure is given here. The main variables are the number of payment flows, scripts and modules, the hosting setup, and how quickly your team returns access, inventories and hosting details. Confirm the expected milestones in the written scope, including which items depend on your provider or hosting team. Also confirm when recurring obligations start, since quarterly external scans and change detection continue after the review ends and do not finish with it.
What does my company need to provide for a PCI DSS scope review?
Before work starts, expect to supply the following: payment provider account details and the merchant configuration you use, admin access to the Odoo database, web server and any payment-related settings, a full inventory of scripts and custom or third-party modules loaded on payment pages, and hosting details showing where Odoo, PostgreSQL, backups and the network perimeter sit. You should also name a business owner who can approve decisions, and share your current patch and scan records. Missing inventories are the most common reason a review slows, so request a checklist in the scope document.
Can our internal team run a PCI DSS scope review for Odoo?
An internal team can do much of the work if it has people who understand PCI DSS v4.0.1, the Self-Assessment Questionnaire (SAQ) choices, Odoo administration and the payment provider integration. The team must also own the validation decision, because the payment brands and your acquirer decide which entities must validate and what they accept. Before committing, check whether you have someone to maintain the script inventory, schedule ASV scans through an approved vendor and handle patching against the timeframes that apply to your environment. Many teams split the work: internal staff own operations, and an outside firm reviews scope and evidence.
Can DeployOpen certify our Odoo store as PCI DSS compliant?
No. DeployOpen does not issue audit reports, attestations or certifications. A scope review prepares your systems, controls and evidence so that a validation can be completed. Validation takes one of two forms: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire with an Attestation of Compliance, both on official PCI SSC templates. A certificate alone is not accepted as validation. Ask your acquirer which validation type it requires before you choose the scope, and treat the scope review as preparation for that validation.
Does Odoo store card numbers, and does that remove our PCI DSS scope?
Odoo's documentation states that it delegates sensitive card information to certified payment providers and stores no card numbers on Odoo servers or on Odoo databases hosted elsewhere, using reference numbers instead. That reduces what you must protect, but it does not remove scope. Your payment page scripts, redirects or iframe embedding, your scan obligations and your handling of POS terminals still need review. Confirm with your provider exactly how your configured integration handles card data, and document the answer as part of your evidence.
Which Odoo version and hosting type affect PCI DSS patching?
Your Odoo version and hosting type determine whether you can receive security patches. Odoo's standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, and security patches are only provided during standard support. Odoo 17.0 standard support ended in September 2026, Odoo 18.0 runs until September 2027, Odoo 19.0 until September 2028 and Odoo 20.0 until September 2029. Extended support is limited to Odoo.sh for select versions and on-premise, and SaaS versions cannot use it. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years, so plan the upgrade path into the scope review.
How DeployOpen scopes and evidences Odoo payment compliance
DeployOpen starts by mapping how each Odoo payment provider, eCommerce page and POS terminal handles card data, then fixes the PCI DSS scope in writing before any build work begins. We build and document the controls that follow from that scope, and we hand over the evidence your assessor or acquirer will ask for. DeployOpen prepares systems and evidence but does not issue assessments or attestations.
How we scope
- Map every payment path, from hosted redirect to embedded iframe, and record which one each store and terminal uses
- Confirm with your acquirer or assessor which SAQ type applies, since the script-attack criterion depends on the page design
- Agree the scope, deliverables and timelines in a written fixed-scope agreement before work starts
- List every payment page script and confirm which requirements apply to your own pages versus the provider's
How we build
- Configure Odoo payment providers so card numbers stay with the certified provider and Odoo holds only reference numbers
- Set up a script inventory with written justifications, and integrity and authorization checks for each payment page script
- Deploy change and tamper detection for security-impacting HTTP headers and payment page content in the consumer browser
- Harden the self-hosted Odoo, its database and its patch process, and keep Community and Enterprise differences documented
How we hand over
- Deliver a scope document, data flow diagrams and the configuration record for each payment provider and POS terminal
- Provide the script inventory, change-detection alert records and patch and ASV scan schedules as evidence to keep
- Document the operating runbooks for scans, patching, alert triage and Odoo version upgrades
- Walk your team through the evidence set so they can produce it for the assessor without DeployOpen in the room
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review scope again when you add a payment provider, change a checkout design or move to a new Odoo version
- Confirm the Odoo support window for your version early, since security patches depend on standard support
- Ask for the retainer scope in writing so quarterly scans, patch cycles and evidence refreshes are defined
