PCI-DSS 4.0 Compliance Blueprint for Magento & Shopify

1. The Question That Reveals Everything

When a merchant tells me they're PCI compliant, I ask one question: which SAQ did you fill in, and who decided that was the right one?

The answer is nearly always "SAQ A" and "our payment provider's onboarding form suggested it." Sometimes it's "the finance director filled it in." Occasionally nobody can remember.

SAQ A is the shortest self-assessment questionnaire, and it exists for merchants who have fully outsourced card handling — the payment page is served by someone else, and no card data touches anything the merchant controls. If that describes you, wonderful. If your checkout page is served by your own server and merely embeds a payment provider's fields, you are probably on SAQ A-EP, which is roughly four times longer and includes requirements about your own infrastructure that SAQ A skips entirely.

Nobody checks this until something goes wrong. Then your acquirer asks for evidence, a forensic investigator looks at the architecture, and the gap between the questionnaire you signed and the environment you actually run becomes a commercial problem rather than a paperwork one.

I should be clear about what this article is and isn't. I'm an engineer, not a Qualified Security Assessor. What follows is the technical view — what the requirements mean for how you build and run a storefront, where the real work is, and which parts of v4.0 changed things for ecommerce specifically. Your acquirer and your QSA determine your formal obligations, and if there's a conflict between them and this article, they win.

2. What PCI DSS Actually Is

A set of security requirements maintained by the card brands collectively, applying to anyone who stores, processes, or transmits cardholder data. It's a contractual obligation via your acquiring bank rather than a law, which changes the enforcement mechanism but not the consequences: fines, increased transaction fees, and in serious cases losing your ability to take card payments.

Two dimensions determine what you have to do.

Your level, which is driven by annual transaction volume. Level 1 — broadly over six million transactions a year with a given brand, though the thresholds vary — requires an annual on-site assessment by a QSA and quarterly scans by an Approved Scanning Vendor. Levels 2 to 4 generally permit self-assessment, with the thresholds and specifics set by each brand and by your acquirer. A breach can move you up a level regardless of volume.

Your SAQ type, which is driven by architecture — specifically, how card data flows. This is where merchants most often get it wrong, and it matters more than level for day-to-day engineering.

The SAQ types that apply to ecommerce

SAQ A — card data is entirely handled by a validated third party. The classic case is a full redirect to the provider's hosted payment page, where the customer leaves your domain, pays, and comes back. Historically the lightest questionnaire by a wide margin.

SAQ A-EP — you don't receive card data, but your server delivers the page that does. Embedded iframes, hosted fields, drop-in components: the customer stays on your domain, your page is what loads the payment form, and therefore your page's integrity determines whether the card data is safe. Much longer, and includes requirements about your own systems.

SAQ D — everything else, including any case where card data touches your systems. Long, demanding, and the reason "don't touch card data" is the single most valuable architectural decision available.

The distinction between A and A-EP is the one that catches people, because from a customer's perspective a redirect and an embedded iframe look similar and from an engineer's perspective both mean "we don't store cards". They differ in one crucial way: with an iframe, an attacker who compromises your page can replace the iframe, and the customer will type their card into the replacement. That's exactly the Magecart pattern, and it's why the requirements diverge.

3. Scope Is the Whole Game

If you take one concept from this article, take this one. PCI DSS applies to your cardholder data environment — the systems that store, process or transmit card data, plus any system that could affect the security of those systems.

That second clause is where scope quietly expands. A jump host that can SSH into a payment server is in scope. A monitoring agent with credentials to the payment database is in scope. A shared authentication service is in scope. A flat network where the warehouse printer can reach the payment server puts the warehouse printer in scope.

Merchants who find PCI painful are almost always merchants with a large scope. Merchants who find it manageable have spent effort making the scope small.

The exercise that produces the most value, and which I'd do before reading a single requirement, is drawing the data flow honestly. Where does a card number appear? Not where it's stored — where it appears, even momentarily, even in memory, even in a log you didn't mean to write.

Places I find card data that nobody expected:

Application logs. A debug log of a request body from a form post, written during an incident three years ago and never turned off. This is the most common finding I encounter and it's usually a one-line fix plus a very uncomfortable conversation about log retention.

Error tracking. An exception handler that serialises the request context to a third-party error service. Card data leaves your environment entirely, into a vendor with a different retention policy.

Support tooling. Customers email card numbers. They shouldn't and they do. If your helpdesk stores those emails, your helpdesk is in scope, and so is your mail server, and so is the backup of both.

Phone orders. The classic. Someone in customer service takes a card over the phone and types it into an admin interface. That admin interface, the workstation, and the call recording system are all now in scope. This one route can turn a tidy SAQ A-EP environment into SAQ D.

Session storage and browser state. A checkout that keeps form state in sessionStorage for a multi-step flow, including the card field. It never reaches your server and it is still a problem.

4. Reducing Scope, Which Is the Actual Work

Three architectural moves, in descending order of effectiveness.

Full redirect. The customer goes to the provider's domain, pays there, comes back. Your systems never see a card number and your page cannot be manipulated into capturing one, because the capture doesn't happen on your page. This is the strongest position and it's SAQ A territory.

The objection is always conversion. There's a real cost to sending customers to a differently-branded page mid-checkout, though modern providers let you style the hosted page enough to reduce it. Whether the conversion difference outweighs the compliance and breach-risk reduction is a business decision, and it's worth actually measuring rather than assuming — I've seen the assumed gap turn out to be smaller than the noise in the data.

Iframed hosted fields. The provider's fields are embedded in your page via iframes, so the card data goes directly from the customer's browser to the provider without passing through your JavaScript or your server. Same-origin policy prevents your page reading inside their iframe.

This is the pragmatic middle ground most merchants land on, and it's genuinely good — but it puts you in SAQ A-EP, because your page's integrity now matters. An attacker who can inject script into your checkout can overlay a fake form on top of the real iframe, and the customer cannot tell.

Tokenisation for anything stored. If you need repeat billing, subscriptions, or one-click checkout, store the provider's token rather than the card. A token is useless to an attacker and worthless outside your merchant account. There is essentially no good reason to store a PAN yourself in 2026.

What all three have in common: they're decisions made when the checkout is built, and they're expensive to retrofit. If you're replatforming, this is the moment to get it right.

5. What v4.0 Changed for Ecommerce

Version 4.0 arrived in 2022 with a long transition, and the future-dated requirements became mandatory on 31 March 2025. Two of them changed the engineering picture for storefronts specifically, and they are the reason PCI has recently started appearing in front-end tickets.

Requirement 6.4.3 — manage the scripts on your payment page

Every script loaded and executed in the consumer's browser on a payment page must be authorised, justified, and inventoried. Not a list someone wrote once. A maintained inventory with a reason for each entry and evidence that its integrity is assured.

This is a bigger ask than it reads. Most checkout pages I audit load somewhere between six and twenty scripts, and nobody can name an owner for all of them. The exercise of listing them, finding an owner, and asking what breaks if it's removed routinely deletes a third — which is a performance win and a compliance win from the same afternoon.

Start by finding out what's actually there, including the scripts loaded by other scripts:

// Run in the console on your live payment page
const origin = location.origin;
console.table(
  [...document.querySelectorAll('script[src]')].map(s => ({
    src: s.src,
    thirdParty: !s.src.startsWith(origin),
    integrity: s.integrity || '—',
    async: s.async,
    defer: s.defer
  }))
);

// And the ones injected at runtime, which the markup will not show you
const known = new Set([...document.querySelectorAll('script[src]')].map(s => s.src));
new PerformanceObserver(list => {
  for (const e of list.getEntries()) {
    if (e.initiatorType === 'script' && !known.has(e.name)) {
      known.add(e.name);
      console.warn('injected at runtime:', e.name);
    }
  }
}).observe({ type: 'resource', buffered: true });

The second block produces the surprises. Scripts in your HTML are the ones you know about; scripts those scripts load are the actual attack surface.

The awkward conversation this forces is about tag managers. A tag manager's purpose is to let people add code without a deploy, which is precisely what "authorised and inventoried" forbids. My recommendation is consistently to remove the tag manager from the payment page — not from the site, from the page where card data is entered — and fire conversion tracking from the confirmation page or server-side instead. That lands more often than you'd expect once a QSA finding is the alternative.

Requirement 11.6.1 — detect tampering

You must deploy a mechanism that detects unauthorised modification to the HTTP headers and the script content of payment pages, and alerts on it, evaluated at least weekly.

The word doing the work is detect. Prevention isn't enough; you need to know when something changed. In practice that means some combination of:

Subresource Integrity on the scripts that support it, so a changed file simply doesn't execute and an error handler tells you. Covered properly in the SRI guide, including why tag managers resist it.

A Content Security Policy in reporting mode alongside your enforcing one, so a script from an undeclared source generates a report even where it would otherwise be silently blocked.

An external check that fetches your payment page on a schedule, extracts the script tags and header set, and compares against a known-good baseline. This is the piece that satisfies "evaluated at least weekly" most directly, and it's not hard to build:

#!/usr/bin/env bash
# payment-page-baseline.sh — run nightly; diff against the committed baseline
set -euo pipefail
URL="https://shop.example.com/checkout"
OUT=$(mktemp)

{
  echo "== headers"
  curl -sI "$URL" | tr -d '\r' | grep -iE '^(content-security-policy|strict-transport|x-content-type|referrer-policy):' | sort
  echo "== scripts"
  curl -sS "$URL" | grep -oE '<script[^>]*src="[^"]+"' | grep -oE 'src="[^"]+"' | sort -u
} > "$OUT"

if ! diff -u baseline/payment-page.txt "$OUT"; then
  echo "PAYMENT PAGE CHANGED — investigate before approving" >&2
  exit 1
fi
echo "payment page matches baseline"

Commit the baseline. A legitimate change means updating it in a pull request, which turns "we monitor our payment page" from an assertion into an artefact with a review history — exactly the sort of evidence an assessor wants to see.

The other v4.0 changes worth knowing

Passwords lengthened. The minimum moved from seven characters to twelve for accounts with access to the cardholder data environment. Trivial to configure, occasionally awkward with legacy systems that cap length.

Multi-factor authentication broadened. Required for all access into the CDE, not only remote or administrative access. If your admin panel is in scope, everyone signing into it needs MFA.

Targeted risk analysis. Several requirements now let you set your own frequency for a control, provided you document a risk analysis justifying it and review it annually. This is genuinely useful flexibility and it is not a loophole — a documented, defensible analysis is more work than following the default, and assessors read them.

The customised approach. You may meet a requirement's objective by a different method than prescribed, with documentation and QSA validation. Powerful for organisations with mature security programmes and unusual architectures. Not a shortcut for anyone else.

6. Findings I See Most Often

Roughly ordered by how frequently they come up on ecommerce assessments.

Card data in logs. Discussed above. Check your logs today; it takes ten minutes and it's the highest-probability finding on this list.

# Crude but effective — run against a sample of recent logs
grep -rEo '\b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|3[47][0-9]{13})\b' /var/log/app/ | head

Unsegmented networks. A flat network means everything is in scope. Segmentation is the single most effective scope-reduction technique after not handling card data at all, and it needs to be tested — a firewall rule you believe in is not evidence.

Shared accounts. A deploy user that three engineers use, or a shared admin login. Requirement 8 wants individual accountability, and shared credentials also make incident investigation nearly impossible.

Missing or unreviewed logs. Requirement 10 asks for logging and daily review of security events. Most merchants have logs. Fewer have a defined review process, and "we look at them if something happens" is not one.

Unpatched systems. Requirement 6 requires critical patches within a month. On a Magento estate that means keeping current with security releases, which is a resourcing commitment rather than a technical one, and it's where I see teams fall behind quietly.

Third parties without a responsibility matrix. Requirement 12.8 wants a written record of which PCI requirements each service provider is responsible for and which are yours. Most merchants have the contracts and not the matrix, and building it usually reveals a requirement everyone assumed the other party was covering.

Test data in production. Test card numbers in a live database, or a staging environment with a copy of production data. The latter is worse than it sounds — a staging environment with real cardholder data is fully in scope, and it's usually the least hardened system you own.

7. Segmentation, Practically

Segmentation is how a large organisation keeps PCI scope small, and it is the requirement most often claimed and least often demonstrated.

The principle is straightforward: if a system cannot communicate with the cardholder data environment, it is out of scope. The difficulty is that "cannot communicate" is a stronger claim than most networks can support, and assessors test it rather than accepting it.

What counts as segmentation:

Network controls that deny by default. A firewall or security group whose default action is deny, with an explicit, documented allowlist of what may cross the boundary. An allow-by-default network with some deny rules is not segmentation; it is an aspiration.

Separate identity. A shared directory that authenticates both the CDE and the corporate network means a compromise of that directory reaches both. This is the segmentation gap I find most often in otherwise well-built environments, because network diagrams show the network and not the trust relationships layered on top of it.

Separate administrative paths. If the same jump host reaches both environments, the jump host is in scope and so is anything that can reach it. Dedicated access paths cost a little more and remove a great deal of scope.

What does not count, despite frequently being offered as evidence: VLANs without enforced filtering between them, application-layer separation on shared infrastructure, and "we don't have a route configured" without a control that prevents one being added.

In a cloud environment the same logic applies with different nouns. Separate accounts or subscriptions per environment give you a hard boundary that a security group in a shared account does not. Cross-account roles are the controlled crossing point, and they're auditable, which assessors like. The pattern that causes trouble is a single account with everything in it, separated by tags and good intentions.

Whatever you build, plan for it to be tested. The annual penetration test must attempt to cross the boundary from the out-of-scope side and document that it failed. Book that explicitly with your testers, because a general application pen test will not cover it and discovering the gap at report time means an unplanned engagement.

8. The Scan and Test Requirements

Two things get confused constantly.

ASV scans are quarterly external vulnerability scans performed by an Approved Scanning Vendor against your internet-facing addresses. Automated, relatively cheap, and required for most merchant levels. A passing scan means no vulnerabilities above the failing threshold; you may need to rescan after remediation to get a clean quarter on record.

The practical annoyance is that ASV scans flag things a WAF already mitigates, and disputing a finding requires evidence. Budget time for it; the first scan of a new environment always produces a list.

Penetration testing is a manual exercise by a skilled human, required annually and after significant infrastructure or application changes. It covers the network and application layers and, if you rely on segmentation to reduce scope, must specifically verify that the segmentation holds.

That segmentation test matters and is often skipped. If you claim your warehouse network cannot reach your payment environment, someone must attempt it and document the result. A firewall configuration is a claim; a tested boundary is evidence.

Also worth planning for: "significant change" triggers a retest. A replatform, a new payment provider, a move to a new cloud region — each can require testing outside your annual cycle. Building that into project budgets prevents an unwelcome discovery late in a migration.

9. What an Assessment Actually Involves

Demystifying this helps, because the anticipation is usually worse than the reality.

Scoping. The QSA works out what's in scope, and this is where you either save or spend a great deal of the engagement's effort. Come with an accurate data flow diagram and a network diagram. If you don't have them, the QSA will build them with you, at your expense and more slowly.

Evidence gathering. Configuration exports, policy documents, screenshots, sampled logs, change tickets. The volume surprises people. Most requirements are satisfied by a document plus evidence the document is followed — a patching policy is not enough; they want the patching policy and evidence of patches applied within its stated window.

Interviews. The QSA talks to engineers, support staff, and anyone in the card flow. This is where the phone-orders problem tends to surface, because someone in customer service describes their actual workflow rather than the documented one.

Testing. Sampled verification — they'll pick systems and check them rather than examining everything.

Remediation and reporting. Findings get fixed and re-evidenced, then the Report on Compliance is produced.

The pattern I'd encourage: treat the QSA as a collaborator rather than an examiner. The ones I've worked with are pragmatic and would much rather help you build a defensible position than catch you out. Asking "how would you like to see this evidenced" early saves weeks.

10. The Requirements Nobody Reads Until It Matters

Requirement 12 covers policy and process, and it is where merchants who are technically solid still lose weeks. Three parts deserve attention before an assessment rather than during one.

An incident response plan that names people. Requirement 12.10 wants a documented plan, tested annually, covering who does what when card data may have been exposed. The version that fails is a generic template with no names, no phone numbers, and no evidence anyone has read it.

The version that works is short and specific: who declares an incident, who contacts the acquirer and within what timeframe, who engages the forensic investigator, who talks to customers, and where the out-of-hours numbers are. One page, with real names, reviewed when people leave. Test it as a tabletop exercise once a year and write down that you did — that record is the evidence.

The detail worth knowing in advance: your acquirer contract almost certainly requires notification within a tight window, often measured in hours, and mandates using a PCI Forensic Investigator from an approved list. Finding that out during an incident is a bad time to find it out.

Security awareness training. Requirement 12.6 asks for it at hire and annually, covering phishing and social engineering specifically. Unexciting, and it addresses the route by which most merchants actually get compromised — not a clever browser attack but someone's credentials.

The service provider inventory and responsibility matrix. Requirement 12.8 wants a list of every third party with access to cardholder data or that could affect its security, their PCI status, and a written division of responsibility.

Building it is a genuinely useful exercise beyond compliance, because it surfaces the requirements everyone assumed someone else covered. A typical storefront's list is longer than expected: payment provider, hosting, CDN, fraud screening, tag manager, error tracking, session recording, email service, warehouse integration, and whichever agency has admin access. Each needs a line, and several will need a conversation.

11. Building Compliance Into Engineering

The merchants who find this manageable have moved the work into normal engineering practice rather than treating it as an annual event.

Automate the evidence. If a requirement asks for a quarterly check, script the check and store its output with a timestamp. Annual evidence gathering becomes a directory listing rather than an archaeology project.

Put the payment page baseline in CI. The script above, run on every deploy plus nightly. It satisfies a requirement and it catches real problems.

Fail builds on unpinned third-party scripts in payment templates. That's requirement 6.4.3 enforced by the build rather than by memory.

Keep the responsibility matrix in the repository. A markdown table listing each service provider and which requirements they cover, reviewed when contracts change. It's the artefact most often missing and among the easiest to maintain.

Log scrubbing at the framework level. Don't rely on developers remembering not to log request bodies. Redact at the logging layer so it's structurally impossible:

const SENSITIVE = /\b(?:card(?:_?number)?|pan|cvv|cvc|securityCode|expiry)\b/i;
const PAN = /\b(?:\d[ -]*?){13,19}\b/g;

function redact(value, key = '') {
  if (SENSITIVE.test(key)) return '[REDACTED]';
  if (typeof value === 'string') return value.replace(PAN, '[REDACTED-PAN]');
  if (value && typeof value === 'object') {
    return Object.fromEntries(
      Object.entries(value).map(([k, v]) => [k, redact(v, k)])
    );
  }
  return value;
}

logger.addFilter(entry => redact(entry));

That regex is deliberately broad and will occasionally redact an order number that looks like a card. That trade is correct: a false positive costs you a debugging session, a false negative costs you a finding.

12. Platform Notes

The general principles land differently depending on what you run.

Magento and Adobe Commerce

Self-hosted means the whole stack is yours: the servers, the patching, the segmentation, the logs. That is the heaviest position on this page, and it's the correct one for merchants who need the control.

The specifics I check first. Payment integration method, because a module that posts card data through your server puts you in SAQ D while an iframe-based one does not — and the module's marketing copy is not reliable evidence of which it is, so read the integration. Admin access, because the Magento admin is in scope if it can touch order data with card references, which means MFA and individual accounts rather than a shared login. Patch cadence, because security releases arrive on a schedule and requirement 6 gives you a month. And the extension estate, since every third-party module is code running in your environment with your privileges.

Adobe Commerce on cloud infrastructure shifts some responsibility to Adobe, and the responsibility matrix for that arrangement is published — read it rather than assuming, because the split is not intuitive in places.

Shopify

Shopify handles the payment environment and is itself compliant, which removes most of the heavy requirements. Merchants on Shopify Payments with standard checkout generally fall into the lightest category.

What remains yours: app hygiene, because every installed app has permissions and some can read order data; staff account discipline, including MFA and removing leavers promptly; and anything you build outside Shopify that touches order data — a custom ERP sync, a reporting warehouse, a support tool. Those are your systems and your scope.

The area where Shopify merchants get caught is a custom storefront. Building a headless front end against the Storefront API and handling checkout yourself changes the picture materially, and the assumption that "we're on Shopify so it's handled" stops being true at exactly that point.

Headless and composable architectures

More moving parts, and scope determined by where the payment step lives rather than by the architecture's name. A headless storefront that redirects to a hosted payment page is in a strong position. One that renders payment fields inside its own React application is squarely in A-EP territory, with the added complication that the front end is often deployed by a different team on a different cadence from everything else.

The practical advice for composable stacks: decide early which single team owns the payment page's contents, and give them a veto. The failure mode is a checkout page assembled from components owned by four teams, where nobody can answer the inventory question because no one person knows what ships.

13. What It Costs

Ranges rather than numbers, because they vary hugely by region and by scope.

A self-assessment with quarterly ASV scans is the cheap end — scanning is a modest annual subscription, and the cost is mostly internal time. A Level 1 assessment with a QSA is a substantial professional-services engagement, and the first year is always the most expensive because you're building documentation that subsequently only needs updating.

The costs people underestimate are internal. Evidence gathering across a first assessment consumes real engineering weeks. Remediation of findings is unplanned work. And segmentation projects, if you need one, are infrastructure programmes rather than tickets.

The cost that dominates everything, of course, is a breach: forensic investigation, card brand fines, mandatory upgrade to Level 1 assessment, remediation under time pressure, and the customer-trust consequences that don't appear on any invoice. Every hour spent on scope reduction is an hour that reduces that exposure, which is the argument I'd make to a finance director rather than the compliance one.

14. Questions That Come Up

"We use Stripe, so we're compliant, right?" Stripe is compliant. You are responsible for your own environment, and the SAQ you fall under depends on how you've integrated. Stripe Checkout as a full redirect is very different from Stripe Elements embedded in your page, even though both mean you never see a card number.

"Does PCI apply if we're small?" Yes. Transaction volume determines validation requirements, not whether the standard applies. A merchant doing two hundred orders a month still has obligations, and small merchants are targeted precisely because they're assumed not to be looking.

"Can we store the last four digits?" Yes — truncated PANs are permitted for display and reconciliation, and that's why receipts show them. Storing the full PAN requires strong encryption, key management, and puts you firmly in SAQ D. Storing the CVV after authorisation is prohibited outright, with no exceptions.

"Is a WAF enough for requirement 6.6?" A WAF is one of the permitted approaches for protecting public-facing web applications, the other being application code review or vulnerability assessment. A WAF you deployed and never tuned is weak evidence. Be able to show it's configured for your application and that someone reviews what it blocks.

"What about phone orders?" The route that most often expands scope unexpectedly. Options include pause-and-resume call recording, DTMF masking services where the customer types digits that agents never hear, or sending a secure payment link so the customer enters their own card. All are better than an agent typing a card into your admin.

"Our developers need production access to debug." Common and usually solvable. Better logging, better staging with realistic-but-synthetic data, and time-limited elevated access with an approval trail. Standing production access for developers in a CDE is a finding waiting to happen.

"Do we need to be compliant before we launch?" Your acquirer will usually want the SAQ before enabling live payments, so in a practical sense yes. The better question is when to do the architectural work, and the answer is during the build — choosing a redirect or hosted fields costs nothing at design time and is a substantial project to retrofit once a checkout is live and converting.

"How does this interact with GDPR?" They overlap and don't conflict. PCI cares about cardholder data specifically; GDPR cares about personal data broadly. A PCI-driven exercise to remove card data from logs usually improves your GDPR position too, since the same logs contain names, addresses and emails. Do them as one project.

15. Where I'd Start This Week

Find out which SAQ you're actually on, and check that it matches your architecture. If your checkout page is served by your servers and embeds a provider's fields, and you filled in SAQ A, that's the first thing to fix — and fixing it means either doing the A-EP work or moving to a full redirect.

Grep your logs for card numbers. Ten minutes, and it's the most common finding there is.

Run the script inventory on your live payment page, including the runtime-injected ones. Then find an owner for each. Expect not to find one for several, and delete those — that satisfies part of 6.4.3 and makes the page faster.

Write the payment page baseline check and put it in CI. That's 11.6.1 addressed with about thirty lines of shell.

Book the segmentation test explicitly with whoever does your penetration testing, if you rely on segmentation at all. It is the item most often assumed to be covered and most often isn't.

Then draw the data flow diagram, honestly, including phone orders and support email. That diagram determines your scope, your scope determines your effort, and everything else in this article is downstream of it.

One framing that helps when this competes with feature work for priority. Almost every item on that list is something you would want anyway if you had never heard of PCI. Card numbers in logs is a data-handling defect. An unowned script on the checkout page is a supply-chain exposure and a performance cost. A flat network is an incident waiting to spread. An untested incident plan is an incident you will handle badly. The standard is not asking you to do unusual things; it is asking you to do ordinary things and keep evidence that you did them. The evidence is the only part that is genuinely additional work, and automating it — which is most of what the engineering section above describes — reduces that to close to nothing.

The merchants who struggle with PCI are the ones who treat it as a questionnaire to be survived once a year. The ones who find it routine made a small number of architectural decisions — don't touch card data, segment the network, keep the payment page minimal — and then let normal engineering discipline carry the rest.