Compliance-Driven Web Development: What GDPR, PCI DSS, and WCAG Add to Your Build Cost

Every engineering estimate for a customer-facing web build starts in roughly the same place: pages, features, integrations, sprints. Design, front end, back end, QA, hosting. The number that comes out the other end is the number the business plans around.

Then legal reads the spec.

What follows is familiar to anyone who has shipped a regulated product. Consent handling turns out to need a real architecture. The payment page can no longer load third-party scripts the way it did. The design system has contrast ratios that fail audit. None of this is in the estimate, because published benchmarks for the average cost of web development are built around functionality — pages, features, hours — and treat regulatory conformance as a checkbox at the end rather than a workstream that runs through the whole build.

It isn't a checkbox. For a company operating in the EU, taking card payments, or selling to a public-sector buyer, compliance is a design constraint that touches data modelling, authentication, logging, third-party script policy, and the component library. Scoped upfront, it's a manageable percentage of the budget. Discovered in UAT, it's a rebuild.

Here's where the money actually goes.

Compliance is a scope problem before it's a legal problem

Security teams tend to encounter compliance as an audit artifact — evidence to be collected, controls to be attested. Development teams encounter it as unplanned work in week fourteen.

The gap between those two views is where budget overruns live. A DPO signs off on a privacy policy; nobody costs the engineering required to honour it. A merchant assumes their payment provider "handles PCI"; nobody checks which self-assessment questionnaire actually applies. A procurement team accepts an accessibility statement; nobody audits the component library it describes.

The three regimes below behave differently in a build, so it's worth separating them.

GDPR: the cost isn't the cookie banner

The consent banner is the cheapest part of GDPR compliance and the part everyone budgets for. The expensive parts are structural.

Consent as infrastructure

A compliant consent model needs granular purposes, proof of what was consented to and when, propagation of that state to every downstream system, and a withdrawal path that actually stops processing. That means a consent record store, an API other services can query, and event handling so that a withdrawal reaches your analytics pipeline, your CRM, and your email platform — not just the browser.

Teams that buy a CMP (consent management platform) still have to integrate it. Teams that build one are writing a small product. Either way this is engineering time, not a legal deliverable.

Data subject rights need endpoints

Articles 15 through 20 give individuals the right to access, correct, delete, and port their data. Honouring that at scale means knowing where personal data lives across every service, having a way to assemble it, and having a delete path that survives foreign key constraints, backups, replicas, and analytics warehouses.

Most teams discover during the first access request that personal data has leaked into log files, support tickets, and a denormalised reporting table nobody owns. Retrofitting a data inventory after launch costs multiples of building the schema with data classification in place from the start.

Retention, logging, and residency

Retention policies have to be enforced by something — a scheduled job, a lifecycle rule, a TTL. Access to personal data has to be logged in a way that distinguishes it from ordinary application logging. If your controller obligations or a customer contract require EU data residency, that's an infrastructure decision that constrains region selection, CDN configuration, backup topology, and vendor choice.

None of these are large individually. Together they routinely add ⚠ [VERIFY: internal estimate — typical uplift range for GDPR-scoped work on a mid-size build] to a build that was scoped without them.

The enforcement ceiling is well documented — up to €20 million or 4% of global annual turnover, whichever is higher. But for most organisations the realistic cost of getting this wrong isn't a headline fine. It's the remediation project, the enterprise deal that stalls in security review, and the DPA renegotiation.

PCI DSS: v4.0 changed what the front end has to do

For years, e-commerce teams operated on a comfortable assumption: outsource the payment page to a hosted iframe or redirect, qualify for SAQ A, and PCI scope stays small.

PCI DSS v4.0 narrowed that comfort. The standard's future-dated requirements became mandatory on 31 March 2025, and two of them — requirement 6.4.3, covering management and authorisation of scripts loaded on the payment page, and 11.6.1, covering detection of unauthorised changes to payment page HTTP headers and content — reach merchants who previously assumed script governance wasn't their problem.

That's a direct engineering cost:

• A script inventory and authorisation process. Every script executing on a payment page needs to be justified, approved, and tracked. In practice that means removing the tag manager free-for-all that marketing has enjoyed, and putting a change process around what remains.
• Integrity monitoring. Detecting unauthorised changes to page content and headers means either buying a client-side monitoring tool or instrumenting Content Security Policy reporting and alerting on it. Both need somewhere for the alerts to go and someone to triage them.
• A stricter CSP. Tightening CSP on a page that previously loaded analytics, chat widgets, A/B testing, and affiliate pixels is not a config change. It's a negotiation with three other departments, followed by regression testing.

Beyond the payment page, PCI's requirements around change management, secure development practices, vulnerability scanning (ASV scans quarterly for internet-facing systems), and penetration testing all imply recurring spend that belongs in the total cost of ownership, not just the build.

The cheapest PCI outcome is still the one where cardholder data never touches your infrastructure — but "never touches" now includes governing what runs alongside the payment form, and that has to be designed in.

WCAG: retrofitting accessibility means rebuilding the design system

Accessibility is the clearest example of the cost curve, because the remediation work is so visibly the same work done twice.

WCAG 2.2 became a W3C Recommendation in October 2023. The regulatory pull is now real on both sides of the Atlantic: the European Accessibility Act's requirements applied from 28 June 2025 for in-scope products and services, and in the US, the Department of Justice's Title II rule published in 2024 sets WCAG 2.1 Level AA as the technical standard for state and local government web content, with compliance deadlines phased from 2026. Private-sector exposure comes mostly through ADA litigation, which has run at high volume for several years.

The scale of the problem is well measured. WebAIM's 2026 Million report, published on 30 March 2026, scanned the home pages of the top one million websites and found detectable WCAG 2 A/AA failures on 95.9% of them — up from 94.8% the year before, reversing six consecutive years of gradual improvement. The average page carried 56.1 detected errors, a 10.1% increase on 2025. Since automated tooling only catches a subset of WCAG criteria, actual conformance is lower still.

The reason WebAIM gives for the reversal is the part that matters to anyone estimating a build: page complexity. The average home page in the sample contained 1,437 elements, a 22.5% jump in a single year, which WebAIM attributes to heavier reliance on third-party frameworks and libraries and to AI-assisted coding. More generated markup, less deliberate markup. Low contrast alone appeared on 83.9% of pages.

That is a compliance risk arriving through the front door of a modern stack. If your team is shipping component-heavy interfaces assembled quickly from a library, the baseline you inherit is failing, and nobody will tell you until an audit or a demand letter does.

Here's why the timing matters so much to cost. Accessibility failures cluster in three places:

1. Design tokens — colour contrast, focus indicators, text sizing, spacing.
2. Component behaviour — keyboard operability, focus management in modals and menus, correct semantics and ARIA.
3. Content structure — heading hierarchy, form labelling, error identification, alt text.

Fix these while the design system is being built and they're a set of constraints on decisions you were making anyway. Fix them after 200 pages have been assembled from the components and you're changing the components, retesting every page that consumes them, and reworking content.

The practical rule: an accessibility specialist reviewing the design system before component build costs a fraction of an audit-and-remediate cycle after launch, and produces a better result.

What this looks like on a real budget

Consider a mid-size regulated e-commerce build — EU and US customers, card payments taken on-site through a hosted field integration, a public-sector reseller in the customer list.

A conventional estimate covers discovery, UX, front end, back end, CMS, integrations, QA, and infrastructure. The compliance-driven additions to that scope look roughly like:

• Data classification and mapping during discovery, not after
• Consent management integration and a consent event pipeline
• DSR tooling — export and deletion paths across all data stores
• Retention enforcement jobs and personal-data access logging
• Payment page script governance, CSP hardening, and client-side integrity monitoring
• Accessibility review of design tokens and components, plus assistive-technology testing in QA
• Documentation and evidence: records of processing, DPIA where triggered, SAQ, accessibility statement
• Recurring: ASV scans, penetration testing, annual re-attestation, accessibility regression testing

Two things stand out. First, most of these are architecture and process items, which is exactly why they're expensive to add later. Second, several of them are ongoing — they change the run-rate, not just the build.

Five questions to settle before the estimate is approved

1. Which regimes actually apply, and to which parts of the product? Scope creep in compliance usually comes from ambiguity, not from regulators.
2. Which PCI SAQ applies to our integration pattern — and does v4.0 change it? Confirm this with the acquirer, not with an assumption about the payment provider.
3. Where does personal data end up outside the primary database? Logs, analytics, support tooling, and warehouses are where deletion requests go to die.
4. Is accessibility a constraint on the design system, or a QA phase? The answer determines whether it costs one budget line or three.
5. What is the ongoing cost? Scans, tests, re-attestation, and regression coverage are annual, and they belong in the TCO the business signs off on.

Conclusion

None of this makes regulated builds cheap. It makes them predictable — and a predictable number that includes compliance is worth considerably more to a business than an attractive number that doesn't.

The pattern across all three regimes is the same. GDPR, PCI DSS, and WCAG each add relatively little to a build when they are treated as constraints on architecture, and a great deal when they are treated as a phase that happens after the architecture is set. Consent handling is cheap as a data model and expensive as a retrofit. Payment page script governance is cheap as a CSP policy written alongside the page and expensive as a negotiation with four departments six weeks before an assessment. Accessibility is cheap as a set of design tokens and expensive as a remediation programme across 200 assembled pages.

The WebAIM data makes the last one concrete. Failure rates went up in a year when page complexity went up 22.5% — meaning teams are not getting less capable, they are shipping more machine-generated surface area than their review processes were built to cover. That gap between delivery speed and review capacity is exactly where compliance debt accumulates now, and it is only going to widen.

The practical move is unglamorous: name the applicable regimes during discovery, translate each one into specific engineering line items, and put the recurring costs — scans, penetration tests, re-attestation, accessibility regression coverage — into the number the business signs off on rather than discovering them in year two. That is a harder conversation to have at estimate stage. It is a much easier one than explaining a remediation project.

The teams that get burned aren't the ones who spent more on compliance. They're the ones who found out what it cost after the architecture was already set.