Research brief: how control frameworks end up making the architecture

TL;DR

• Compliance scope boundaries (the PCI cardholder data environment, the FedRAMP authorization boundary, the SOC 2 system description, the HIPAA business-associate/designated-record-set line, the DORA ICT register) function as architecture decisions: they dictate network segmentation, cloud account and VPC separation, data residency, and how finely teams split services. The dominant design driver is cost, because in-scope infrastructure carries a large, recurring per-unit tax.
• "Reduce audit scope" is now an openly stated architectural objective. Tokenisation, point-to-point encryption (P2PE), hosted iframes, and isolated payment microservices are pitched primarily on descoping. Moving from PCI SAQ D (roughly 300-plus controls) to SAQ A (about 31 controls) is the clearest example of architecture chosen to shrink an audit.
• The nuance: descoping can move risk rather than remove it. Hosted payment pages and iframes did not stop Magecart e-skimming (British Airways, Ticketmaster, Newegg), which is exactly why PCI DSS v4 added Requirements 6.4.3 and 11.6.1. Certification cycles also freeze architectures: FedRAMP significant change requests have historically taken 3 to 4 months, and SOC 2 Type II observation windows penalise mid-window changes. ^[1]

Key findings (strongest evidence for a post)

• SAQ A has about 31 requirements; SAQ D for merchants has roughly 300-plus. (Sources vary: one cites SAQ A at 31 questions versus SAQ D at 251, or 269 for service providers; another cites SAQ D at "approx. 329 requirements" and SAQ A-EP at "approx. 190"; a payments vendor puts SAQ A nearer 22 controls.) The integration architecture (hosted page versus an API that touches card data) decides which one you file, so an architecture choice directly sets audit size.
• PCI SSC's own scoping guidance: "start with the assumption that everything is in scope until verified otherwise", and segmentation is the method to pull systems out. Segmentation is not required by PCI DSS but is "highly recommended as a method that can reduce the scope and costs of the PCI DSS assessment." ^[2][3]
• FedRAMP costs: Moderate authorisation is commonly quoted at roughly $500k to $2M initial, with continuous monitoring around $200k to $500k a year; High can exceed $3M. FedRAMP 20x, announced by GSA on 24 March 2025, explicitly aims to cut cost and time; per GSA's 11 August 2025 release, average agency authorization review time was cut to "approximately five weeks" (from over a year), with 114 authorizations in FY2025 versus 49 in FY2024. ^[4]
• Compliance-grade cloud premium: AWS GovCloud runs roughly 10 to 30 percent more than commercial (a clean example: m5.large Linux at $0.0960/hr commercial versus $0.1210/hr GovCloud, a 26 percent premium). Google Assured Workloads Premium tier adds an explicit 5 to 20 percent surcharge on all in-folder spend (IL4 = 20 percent), per Google's own pricing page. ^[5][6]
• DORA: per Deloitte's DORA Wave 3 survey (March 2025, 36 entities across 28 countries), "96 per cent of financial institutions have estimated their DORA compliance costs, with most falling between EUR2 million and EUR5 million"; 46 percent cited the Register of Information as the single most challenging requirement. The European Supervisory Authorities estimate 22,000-plus financial entities in scope; fines can reach 2 percent of global annual turnover. ^[7][7]
• Descoping does not remove client-side risk: per SecurityMetrics (2,000-plus e-commerce forensic investigations, 2025), "in 100% of the cases where card data skimming was occurring, the security failure was present on the merchant's referring page and not because of a malicious script on the 3rd party hosted payment page"; 46 percent of detected malicious activity occurred on pages using iframe redirect. British Airways was fined £20M by the ICO on 16 October 2020 (reduced from the £183.39M Notice of Intent of 4 July 2019) over a Magecart attack; Ticketmaster was fined £1.25M on 13 November 2020 over a compromised third-party chatbot script. ^[8]

Details

1. The core pattern: scope boundaries drive concrete architecture

Network segmentation (PCI DSS). The PCI SSC's "Guidance for PCI DSS Scoping and Network Segmentation" is the primary source. It states the best-practice approach is to "start with the assumption that everything is in scope until verified otherwise", and that "when properly implemented, network segmentation is one method that can help reduce the number of system components in scope." The Cardholder Data Environment (CDE) includes not only systems that touch card data but "connected-to" and "security-impacting" systems: the management plane, jump hosts, directory services, monitoring tools. Segmentation works by cutting those paths. PCI DSS v4.0.1 requires segmentation controls to be tested at least every six months for service providers (annually for others). AWS publishes a dedicated whitepaper, "Architecting for PCI DSS Scoping and Segmentation on AWS", whose stated aim is that its networking "can significantly reduce the number of systems and services within your cardholder data environment (CDE)", which "contributes to minimizing your compliance cost and effort." This is a cloud vendor selling architecture on scope reduction. ^[2]

Data residency and geographic placement. GDPR, UK data protection, and FedRAMP's US-persons and US-soil model push placement decisions. FedRAMP GovCloud restricts access to US persons only. Microsoft completed its EU Data Boundary in February 2025, a multi-year effort across Microsoft 365, Azure, Dynamics 365 and Power Platform to keep customer data within EU/EFTA regions; Microsoft states there is "no extra charge or price increase" for it. A caveat worth flagging: storing data in an EU region of a US hyperscaler does not by itself satisfy data sovereignty, because the US CLOUD Act can still reach it, which is why AWS launched its European Sovereign Cloud (first region in Brandenburg, Germany, went live January 2026, operated by EU-resident staff under a separate legal entity). ^[9]

Environment separation. FedRAMP requires a clearly defined authorization boundary; the boundary diagram and its minimisation are core to cost. FedRAMP's new "Minimum Assessment Scope" (optional wide release from 12 January 2026) lets Rev5 providers replace the traditional boundary with a minimised one. AWS's PCI guidance recommends multi-account architecture with Organizational Units and Service Control Policies that "restricts PCI DSS scope, supports separation of duties, and enforces least privilege", and SCPs can prohibit provisioning non-PCI-compliant services in in-scope OUs. ^[10][11]

Service granularity and the "compliance microservice" pattern. Teams isolate PHI/PCI/PII handling into small in-scope components. Stripe's own material describes the pattern: "modern digital commerce isolates sensitive financial data" via iframe interception, tokenisation, and storing only tokens; using Stripe's vault "keeps you out of PCI scope for data storage". Practitioner writing is explicit about engineering for descoping: one guide describes "using tokenization, isolated payment microservices, and serverless patterns to minimize PCI scope" so that "fewer systems ever fall into the Cardholder Data Environment (CDE) in the first place." Stripe Terminal is described so that the merchant point-of-sale app "cannot handle card data and is thus out of scope for PCI compliance." ^[12]

2. Audit scope reduction as a stated design goal

Descoping is openly the goal, not a side effect. Vendors write it down:

• IXOPAY: "Descoping a data environment by decreasing the amount of CHD traversing is one of the simplest and most effective ways of complying with the PCI DSS", and tokenisation "has emerged as a simpler scope-reducing alternative." It notes that even after removing all card data, Requirements 2, 8, 9, and 12 (people and process) still apply. ^[13][13]
• Paytia: describes descoping as "an asymmetric move" where "one control, applied at the right point, removes dozens of secondary control obligations", and cites the industry's "up to 96% scope reduction" figure. It gives a worked example: a merchant flagged for phone payments lands on SAQ D (about 250 controls, external scan, five-figure annual budget); after a descoping conversation the same business moves to SAQ A (about 22 controls, no scan, no pen test), "Same business, same payment volume, completely different compliance footprint." ^[14][14]
• The SAQ A versus SAQ D gap is the cleanest quantified example: SAQ A about 31 requirements/questions; SAQ D for merchants roughly 300-plus (sources vary). Eligibility turns on whether you embed an iframe/hosted page or handle card data on your servers.

For other frameworks: HIPAA decisions turn on the "designated record set" and the Business Associate Agreement (BAA) boundary; FedRAMP publishes boundary-minimisation guidance; SOC 2 scope is set by the system description and the choice of Trust Services Criteria.

3. Cost differential between in-scope and out-of-scope

FedRAMP. Estimates cluster (all vendor or consultancy sourced, with wide ranges):

• Moderate (most common): roughly $500k to $1.5M initial; $200k to $500k per year continuous monitoring. Some benchmark sets put Moderate at $800k to $2M with about $260k a year in ConMon. ^[15][16]
• Low: about $250k to $500k initial; $100k to $200k a year. ^[17]
• High: $1M to $3M-plus initial; $500k to $1M a year. ^[15]
• One firm's realistic personnel-cost framing: $1M to $3M annually in personnel during authorisation, $600k to $2M annually in ConMon; and a warning that teams budget ConMon at 10 to 15 percent of initial cost when the actual is 25 to 35 percent. ^[18][18]
• FedRAMP 20x (GSA, 24 March 2025) is explicitly designed "to reduce the cost and time of achieving and maintaining FedRAMP Authorization." Early industry estimates put 20x Low and Moderate initial authorisation at $100k to $300k, "still firming up." Per GSA's 11 August 2025 release, average agency review time fell to about five weeks and authorizations rose to 114 in FY2025 from 49 in FY2024. ^[19]

PCI DSS. Cost scales with SAQ type and Level 1 Report on Compliance (ROC). P2PE validated terminals carry a premium of roughly £100 to £300 per device plus a per-transaction fee (Paytia, vendor-sourced). Level 1 merchants get a QSA-led ROC; smaller merchants self-assess by SAQ. ^[20]

SOC 2. Type I is typically cheaper than Type II. Representative figures: audit fee $15k to $45k for a startup with security-only scope; $30k to $75k mid-market with two to three criteria; $100k-plus for Big Four multi-criteria engagements. Each additional Trust Services Criterion can raise auditor fees by 15 to 30 percent; adding Privacy is the expensive one. First-year all-in $30k to $150k; year two 30 to 50 percent less. One auditor's counsel: keep to security-only unless a customer specifically requires more, because each added criterion and each added in-scope system multiplies audit effort. ^[21]

HIPAA. Small to mid-sized organisations are commonly cited at $30k to $120k a year; small practices at $4k to $15k initial and $3k to $10k a year; HHS's own historical estimates ($1,040 per organisation in the 2013 Omnibus rulemaking) are widely regarded as unrealistic.

DORA. Deloitte: 96 percent had estimated costs, most €2M to €5M; McKinsey: 70 percent expect permanently higher run costs; nearly 40 percent dedicate more than seven full-time employees to DORA. Rubrik Zero Labs: many firms spent over €1M over 24 months (47 percent of UK, 38 percent of EU respondents). ESAs: 22,000-plus entities in scope. Fines up to 2 percent of global annual turnover; up to €1M personal penalties for senior managers. ^[7]

Compliance-grade cloud premium.

• AWS GovCloud: roughly 10 to 30 percent over commercial. Clean example: m5.large Linux at $0.0960/hr commercial versus $0.1210/hr GovCloud = 26 percent. EC2 around 20 to 25 percent; S3 around 20 percent; data egress dramatically higher. ^[5][22]
• Google Assured Workloads: Premium tier adds 5 to 20 percent on all in-folder spend; the FedRAMP Moderate package is free (0 percent), IL4 is 20 percent. This is a primary-source figure from Google's pricing page.
• Azure Government: generally "a bit more"; Vanta estimates most CSPs apply "roughly a 30% markup" to FedRAMP or government offerings. ^[23]
• Microsoft 365 GCC High: an independent consultancy cites 2 to 3 times commercial M365 pricing.
• HITRUST: 44 controls (e1 assessment) to about 182 (i1) to 375-plus (r2); about 1,900 requirement statements; certification commonly cited at $70k to $160k (assessor estimates).

Per-node cost of being in scope. The recurring tax on each in-scope system: logging, vulnerability scanning (PCI v4 internal scans every 90 days), annual penetration testing (FedRAMP pen tests $20k to $60k), file integrity monitoring, and evidence collection. This is the mechanism that makes descoping financially rational: every system you keep out of scope is one you do not pay the recurring tax on. ^[24][15]

4. Certification cycle lock-in

• FedRAMP significant change request (SCR): historically a bottleneck. Industry sources put SCR approval at 3 to 4 months, and unapproved major changes can void authorisation. FedRAMP's own RFC-0007 states the existing SCR standard "creates a devastating bottleneck that slows government adoption of new cloud technology and features... and encourages the operation of separate service instances for government customers." The new Significant Change Notification process (optional from 27 February 2026) lets providers make most changes first and notify after. This is a regulator admitting the change process froze architectures. ^[1]
• SOC 2 Type II: observation window typically 3 to 12 months (first audit often 3 to 6 months, subsequent windows 12). If a control breaks mid-window (MFA disabled, a scan missed) you can fail the audit; the practical effect is teams avoid changing the control environment mid-window. Tooling vendors now sell "control drift detection" precisely to catch a broken control inside the window rather than at fieldwork. ^[25]
• ISO 27001: annual surveillance audits; recertification every three years.
• PCI DSS: annual assessment cycle; significant changes trigger reassessment.
• Healthtech comparison: NHS DTAC compliance requires re-evidencing on product change (Clinical Safety Case updates under DCB0129, DPIA revisions, certificate renewals). Medical device software change control (MHRA/FDA) is a stricter analogue in the same industry.
• Evidence of deferral: practitioner writing describes teams deferring migrations and re-platforming because of pending audits and the documentation burden of keeping System Security Plans (SSPs) synced with engineering change.

5. Healthcare-specific angle (UK relevant)

• NHS DTAC (national baseline since 2021) bundles five areas: clinical safety (DCB0129/0160 with a registered Clinical Safety Officer), data protection (DSPT), technical security (Cyber Essentials/Cyber Essentials Plus), interoperability, and usability/accessibility. It is mandatory for NHS procurement of patient-facing technology.
• DSPT is NHS England's self-assessment, now aligning to the Cyber Assessment Framework (CAF), required annually if you process patient data.
• The UK stack is cumulative: a vendor selling to the NHS in 2026 typically needs DTAC technical security, current Cyber Essentials (usually Plus), an annual CAF-aligned DSPT, DCB0129/0160 clinical safety, and a recent CREST penetration test mapped to OWASP and scored with CVSS. A first DTAC submission can take 3 to 6 months (faster, six to eight weeks, if Cyber Essentials and clinical-safety groundwork already exist).
• HITRUST is the US healthcare heavyweight (see costs above); HIPAA turns on BAAs and the designated record set; ISO 27001 underpins much of the control set.
• DORA applicability for healthtech: DORA covers 20 categories of financial entity plus their ICT third-party providers. A healthtech that provides ICT services to an in-scope EU financial entity, or that operates payment or e-money functions, can be pulled into DORA's third-party oversight regime even though it is nominally "healthtech". ^[26]

6. Counterpoints and nuance

Compliance-driven segmentation can produce genuinely better architecture. The "forcing function" argument has real support. AWS's PCI guidance ties segmentation to least privilege and separation of duties; its EKS guidance ties PCI to namespace-scoped RBAC "to minimize blast radius" and disabling hostPath/hostNetwork to block lateral movement. Elisity argues microsegmentation "makes the boundary easier to prove... because least-privilege policy between workloads gives the penetration tester far fewer paths to attempt, and gives the assessor a precise, auditable map." A well-segmented network limits the blast radius of an intrusion and gives you clearer data flows. ^[27][28]

But scope minimisation can move risk rather than reduce it. This is the strongest counter-narrative and it is well evidenced:

• PCI SSC's own e-skimming guidance states that third-party service providers "cannot fully address skimming risks on the merchant's website, given that they do not fully control the merchant's website." ^[29]
• SecurityMetrics forensic data (2,000-plus e-commerce investigations, 2025): "in 100% of the cases where card data skimming was occurring, the security failure was present on the merchant's referring page and not because of a malicious script on the 3rd party hosted payment page." 46 percent of detected malicious activity occurred on pages using iframe redirect. ^[8]
• HUMAN Security demonstrated a Magecart technique that bypasses "hosted fields" iframe protection (on a Braintree form), skimming data while the transaction still succeeds. Braintree hosted fields is exactly the mechanism used to qualify for SAQ A. ^[30]
• Named breaches at merchants that had "outsourced" the card handling. British Airways: Magecart altered the third-party Modernizr JavaScript library on the payment pages between 22 June and 5 September 2018; per the ICO Penalty Notice about 500,000 customers were affected and payment-card data of 244,000 customers (including CVV) was compromised. The ICO issued a final £20M fine on 16 October 2020, reduced from the £183.39M Notice of Intent of 4 July 2019 (which equated to 1.5 percent of BA's 2017 worldwide turnover). Ticketmaster: a compromised Inbenta third-party chatbot running on the payment page; the ICO fined it £1.25M on 13 November 2020 (reduced from £1.5M in the Notice of Intent) for breaches of GDPR Articles 5(1)(f) and 32, with up to 9.4 million European customers affected (1.5 million in the UK) and 66,000 cards compromised, and "the Commissioner rejected arguments that only malicious actors and a third party supplier should be held responsible." Newegg: about 15 lines of skimmer JavaScript injected into the checkout page between 14 August and 18 September 2018. Recorded Future's 2024 report found over 11,000 e-commerce domains running skimmers. ^[31]
• This is precisely why PCI DSS v4 added Requirement 6.4.3 (authorise, inventory and integrity-check every payment-page script) and Requirement 11.6.1 (tamper and change detection on payment pages and HTTP headers), mandatory from 31 March 2025. The standard added controls because descoping to a hosted page did not remove the client-side risk. Note also that under the January 2025 SAQ A revision, even fully outsourced SAQ A merchants must now attest that their site "is not susceptible to attacks from scripts that could affect [their] e-commerce system(s)." ^[32]

Compliance is not the same as security. Per the Verizon 2017 Payment Security Report, in all of the nearly 300 payment-card data breaches Verizon investigated from 2010 to 2016, none were fully PCI DSS-compliant at the time of the breach; only 55.4 percent of organisations remained fully compliant one year after their initial assessment. (The widely repeated "89 percent never compliant" and "11-plus years" phrasings are not confirmed by that report and should be avoided.) Target was certified PCI compliant in September 2013 shortly before its breach; compliance is "a snapshot in time." The 2013 Target breach (attackers entered via a stolen HVAC-vendor credential, moved laterally to point-of-sale systems, exposed 40 million cards and the personal information of up to 70 million people, at $200M-plus total cost including an $18.5M multi-state settlement) is the canonical case that a compliant-but-flat network is a highway for lateral movement. ^[33][34]

7. Governance angle: who actually draws the boundary

The boundary is frequently drawn by compliance teams, QSAs, external auditors, and legal, not by the architecture function, yet it dictates architecture. This is a Conway's Law style observation: the system's structure ends up mirroring the compliance organisation's communication and scoping decisions rather than a clean technical design. Practitioner writing on Conway's Law notes that in "highly regulated environments" architecture changes must be "carefully planned and aligned with regulatory standards", so regulation constrains the organisation-to-architecture mapping. Critiques of traditional GRC (for example Fusion, citing Forrester) argue GRC systems were "built to support governance and compliance, but have not evolved to support real-time enterprise decision-making", which is the disconnect between GRC and engineering/architecture functions. There is thin published survey data directly measuring "where architecture decisions originate" versus who owns GRC; this is an area where the evidence is anecdotal and is best framed as observed practice rather than hard statistics. ^[35][36]

Recommendations (how to use this in a post, and what to verify)

1. Lead with the SAQ A (about 31 controls) versus SAQ D (roughly 300-plus) contrast: it is the single most concrete "architecture sets audit size" datapoint and is easy to verify against PCI's own SAQ documents. Verify the exact current v4.0.1 control counts against the official SAQ PDFs before publishing, because secondary sources disagree (31 versus 22; 251 versus 329).
2. Pair one cost number with one lock-in number: for example FedRAMP Moderate at roughly $500k to $2M plus an SCR that historically took 3 to 4 months, and note FedRAMP itself called the change process "a devastating bottleneck" (RFC-0007). That quote is a regulator conceding the point.
3. Use the descoping-moves-risk trio (PCI SSC's own words, plus the SecurityMetrics 100 percent finding, plus British Airways and Ticketmaster) to make the nuanced point that scope boundaries are not the same as security boundaries.
4. For the healthtech audience, anchor in the UK stack (DTAC, DSPT/CAF, Cyber Essentials Plus, DCB0129, CREST pen test) and note DORA can reach healthtech that touches payments or serves financial entities.
5. Thresholds that would change the story: FedRAMP 20x (if it holds the roughly five-week review time and the $100k to $300k range) materially weakens the "certification freezes architecture" argument for new entrants; watch the phase rollout through FY27. The Significant Change Notification process (from 27 February 2026) similarly loosens lock-in.

Caveats

• Almost all FedRAMP, SOC 2, HIPAA, HITRUST and DORA cost figures are vendor or consultancy sourced (Vanta, Secureframe, Drata, Sprinto, Paramify, Deloitte, Rubrik) with wide ranges; treat them as indicative, not audited. The Google Assured Workloads 5 to 20 percent surcharge and the specific AWS GovCloud instance prices are the closest to primary-source figures.
• PCI SAQ control counts differ across secondary sources; use the official PCI SSC SAQ documents for exact numbers before publishing any specific figure.
• The Deloitte and McKinsey DORA figures are surveys of intent and estimate (Deloitte Wave 3, 36 entities, March 2025), not realised spend.
• The governance and Conway's Law section is largely qualitative; there is little hard survey data on where architecture decisions originate versus GRC ownership, so present it as observed practice.
• Some breach-related figures (for example British Airways group-litigation settlement values) circulate in secondary sources and are not all independently confirmed; the ICO fine amounts (£20M for British Airways, £1.25M for Ticketmaster) and the affected-customer counts in the ICO penalty notices are the reliable numbers.
• The Verizon compliance-at-time-of-breach point is drawn from the 2017 Payment Security Report (nearly 300 breaches, 2010 to 2016); more recent DBIR/PSR editions shift emphasis toward credential abuse and reduced payment-data exposure, so cite the 2017 figure specifically rather than as an evergreen fact.

1. Ignyte — https://www.ignyteplatform.com/blog/fedramp/fedramp-significant-change-request/
2. Pcisecuritystandards — https://listings.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf
3. PCI DSS GUIDE — https://pcidssguide.com/scoping-and-segmentation-for-pci-dss/
4. General Services Administration — https://www.gsa.gov/about-gsa/newsroom/news-releases/gsa-announces-fedramp-20x-03242025
5. CapLinked — https://www.caplinked.com/blog/govcloud-pricing-in-2026-understanding-costs-and-maximizing-roi/
6. google — https://cloud.google.com/assured-workloads/pricing?authuser=1
7. The Next Web — https://thenextweb.com/news/dora-compliance-european-financial-firms-not-ready
8. SecurityMetrics + 3 — https://www.securitymetrics.com/blog/why-you-need-know-about-pci-requirements-643-1161-eskimming-findings-securitymetrics-investigations
9. Alpha Bravo + 2 — https://blog.alphabravo.io/aws-govcloud-vs-commercial-aws-understanding-the-capabilities-and-differences/
10. fedramp — https://www.fedramp.gov/docs/rev5/minimum-assessment-scope/
11. AWSstatic — https://d1.awsstatic.com/whitepapers/compliance/architecting-pci-dss-segmentation-scoping-aws.pdf
12. Stripe + 3 — https://stripe.com/resources/more/how-to-store-customer-card-information-a-quick-guide-to-staying-compliant
13. IXOPAY — https://www.ixopay.com/reports-and-guides/pci-descoping-the-ultimate-guide-to-pci-compliance
14. Paytia — https://www.paytia.com/resources/blog/meaning-of-descoped
15. Paramify — https://www.paramify.com/blog/fedramp-cost
16. Fedrampcost — https://fedrampcost.com/
17. Workstreet — https://www.workstreet.com/blog/fedramp-cost
18. GR IT Services — https://www.cisguard.io/blog/fedramp-authorization-cost-timeline-realistic-guide
19. Winvale + 2 — https://info.winvale.com/blog/gsa-announces-revamped-fedramp-20x
20. Paytia — https://www.paytia.com/resources/blog/p2pe-vs-tokenization
21. SOC 2 Auditors + 4 — https://soc2auditors.org/insights/soc-2-type-2-audit-cost/
22. Atonement Licensing — https://atonementlicensing.com/blog/aws-govcloud-pricing/
23. Vanta — https://www.vanta.com/collection/fedramp/fedramp-cost
24. CompassMSP — https://compassmsp.com/resources/articles/pci-dss-v4.0.1-is-fully-in-effect-and-your-checkout-page-may-already-be-non-compliant
25. Thoropass — https://www.thoropass.com/blog/soc-2-audit-cost-a-guide
26. EIOPA — https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en
27. AWS — https://aws.amazon.com/blogs/containers/building-pci-dss-compliant-architectures-on-amazon-eks/
28. Elisity — https://www.elisity.com/blog/pci-dss-4-0-network-segmentation-requirements
29. Scott Helme — https://scotthelme.co.uk/content/files/2025/03/Guidance-for-PCI-DSS-Requirements-6_4_3-and-11_6_1.pdf
30. HUMAN Security — https://www.humansecurity.com/learn/blog/new-stealth-magecart-attack-bypasses-payment-services-using-iframes/
31. Clifford Chance + 10 — https://www.cliffordchance.com/insights/resources/blogs/talking-tech/en/articles/2020/10/ico-announces-significantly-reduced-gdpr-fine-for-british-airway.html
32. Medium + 3 — https://medium.com/@sangeet_joy/exploring-pci-dss-v4-0-with-implementation-guide-section-6-4-3-11-6-1-60a7c3555f48
33. Dark Reading — https://www.darkreading.com/endpoint-security/verizon-report-businesses-hit-with-payment-card-breaches-not-fully-pci-compliant
34. eWEEK — https://www.eweek.com/security/victims-of-payment-card-breaches-not-fully-pci-dss-compliant/
35. Learning Loop — https://learningloop.io/glossary/conways-law
36. Fusion — https://www.fusionrm.com/blogs/the-future-of-grc-why-compliance-driven-approaches-fall-short-of-resilience/