PCI DSS v4.0 compliance consulting for merchants and service providers.
Independent PCI DSS v4.0.1 readiness, scoping, and Self-Assessment Questionnaire support for SAQ A through Level 1 merchants and service providers. Card-present, e-commerce, call center, and mid-market multi-channel environments. We help you scope the Cardholder Data Environment, complete the right SAQ, coordinate your Approved Scanning Vendor, and prepare for a Report on Compliance with a partnered Qualified Security Assessor.
Important - the consulting boundary we operate inside
Petronella Technology Group is not a Qualified Security Assessor (QSA). We are independent PCI DSS compliance consultants. For a merchant or service provider that needs a formal Report on Compliance signed by a QSA, we coordinate with a partnered Qualified Security Assessor while we handle the engineering, scoping, evidence collection, and remediation workstreams that produce a clean ROC outcome.
For merchants on the Self-Assessment Questionnaire path (the path most North Carolina merchants and SMB e-commerce operators use), we run the whole engagement end to end - scoping, SAQ selection, gap analysis, remediation, Approved Scanning Vendor coordination, segmentation testing, and Attestation of Compliance support - without involving a QSA at all.
Being a consultant rather than a QSA lets us focus on outcomes instead of audit fee economics. The honest framing matters. Card brand acquirers do not care who scoped your environment - they care that the SAQ is accurate, the ASV scans are passing, and the AOC is signed by an authorized officer of the merchant.
Scope. Remediate. Attest.
Every PCI DSS engagement at Petronella Technology Group runs through three stages mapped to the v4.0.1 standard effective March 31, 2025. Each stage produces auditable artifacts your acquiring bank, card brand program, or contracted Qualified Security Assessor can examine on demand.
CDE definition + SAQ vs ROC determination
We open every engagement with a Cardholder Data Environment scoping workshop. PCI DSS v4.0 Requirement 12.5.2 makes this an annual obligation, not a one-time exercise. The output is the document every downstream control hangs from.
- Cardholder data flow diagram (capture, transmit, process, store)
- System component inventory inside the CDE plus connected-to systems
- Network segmentation map and trust zones
- SAQ eligibility determination (A, A-EP, B-IP, C-VT, D-Merchant, D-Service Provider, P2PE)
- Customized Approach (Req 12.3.2) feasibility analysis
Gap closure + Targeted Risk Analysis under Req 12.3
We close gaps in priority order driven by the Targeted Risk Analysis required by Requirement 12.3.1 and the specific frequency-driven requirements at 12.3.x. The 64 new and changed sub-requirements in v4.0 get triaged against your current control baseline, not a generic template.
- Targeted Risk Analysis documentation for every Customized Approach control
- MFA on all non-console administrative access (Req 8.4.2)
- Password policy uplift to 12-character minimum (Req 8.3.6)
- Change-and-tamper detection on payment pages (Req 11.6.1)
- Anti-phishing controls (Req 5.4.1) and authenticated penetration testing (Req 11.4.x)
ASV scans, AOC, and annual recertification
PCI DSS is an annual cadence with quarterly Approved Scanning Vendor obligations layered on top for any internet-facing component. We coordinate the entire attestation cycle so the executive signing your AOC has actual evidence behind every box ticked.
- ASV approved scanning vendor selection and quarterly scan coordination
- Segmentation testing per Req 11.4.5 (annual merchant, six-monthly service provider)
- Authenticated internal and external penetration testing per Req 11.4.x
- SAQ completion or ROC preparation with partnered QSA
- AOC executive sign-off with auditable evidence binder
What PCI DSS actually is
The Payment Card Industry Data Security Standard is a contractual security baseline maintained by the PCI Security Standards Council and enforced by the five participating card brands (Visa, Mastercard, American Express, Discover, JCB) through their acquiring-bank and program-manager contracts. PCI DSS is not federal law in the United States, but the contractual obligation to comply is binding on every entity that stores, processes, or transmits cardholder data, and several state statutes (Nevada NRS 603A.215, Washington RCW 19.255.020) reference PCI DSS by name. Failing PCI DSS does not get you fined by the federal government - it gets you fined by your acquirer, raises your interchange rates, exposes you to chargeback liability for fraudulent transactions, and in the worst case ends with your acquirer terminating your merchant account.
The standard runs on a roughly three-year revision cycle. The current version is PCI DSS v4.0.1, published in June 2024 and replacing v4.0 as the only recognized version on January 1, 2025. The full set of v4.0 future-dated requirements becomes mandatory on March 31, 2025 - meaning every entity validating compliance after that date must meet the full v4.0.1 control set, including 64 new or substantively changed sub-requirements that did not exist in v3.2.1. A handful of payment-page integrity requirements (6.4.3 and 11.6.1) have been clarified in v4.0.1 and remain effective on the same March 2025 date. Read our complete PCI DSS guide for businesses for the executive-friendly version of the same material.
The Cardholder Data Environment - the single most important PCI term
Everything in PCI DSS hangs from the definition of the Cardholder Data Environment, or CDE. The CDE is the people, processes, technology, and connections that store, process, or transmit cardholder data or sensitive authentication data. Anything inside the CDE is fully in scope for all 12 PCI DSS requirements. Anything outside the CDE but connected to it ("connected to" or "security impacting" systems) is in scope for a narrower set of segmentation, access control, and monitoring requirements. Anything fully isolated from the CDE through documented segmentation and validated by segmentation testing (Req 11.4.5) is out of scope.
This is where most PCI engagements get expensive. A merchant who assumes "we are SAQ A because we use Stripe Checkout" but actually has a hosted iframe loading a script from their own domain has dragged the parent web server into the CDE. A merchant whose call center agents read card numbers over a recorded VoIP line has put the entire phone system into the CDE. A merchant whose backup vendor stores unencrypted database snapshots that contain truncated PAN data has put the backup repository into the CDE. Real CDE scoping requires looking at the data, not the marketing assumption.
The four merchant levels (and service-provider levels)
Card brands classify merchants into four levels based on annual transaction volume per brand. The level determines validation effort and reporting cadence:
- Level 1 - more than 6 million Visa or Mastercard transactions per year, or any merchant compromised within the past 12 months, or any merchant the card brand has designated Level 1 at its discretion. Validation requires an annual Report on Compliance (ROC) signed by a Qualified Security Assessor and quarterly ASV scans.
- Level 2 - 1 million to 6 million transactions per year (Visa, Mastercard, Discover) or 50,000 to 2.5 million (American Express). Most Level 2 merchants validate via SAQ, but some acquirers require a ROC. Quarterly ASV scans required.
- Level 3 - 20,000 to 1 million e-commerce transactions per year. Validation via SAQ plus quarterly ASV scans.
- Level 4 - fewer than 20,000 e-commerce transactions per year, or up to 1 million total transactions per year across all channels. Validation via SAQ at acquirer discretion. Quarterly ASV scans required for any internet-facing system in the CDE.
Service providers (any entity that stores, processes, or transmits cardholder data on behalf of merchants - payment gateways, payment processors, hosted call centers, managed firewall providers serving the CDE) have a separate two-level classification. Level 1 service providers (more than 300,000 transactions per year processed on behalf of merchants) require an annual ROC by a QSA and six-monthly segmentation testing per Req 11.4.5. Level 2 service providers (under 300,000 transactions) typically validate via SAQ D for Service Providers.
The Self-Assessment Questionnaires - knowing which one applies
There are nine SAQs in v4.0.1, each scoped to a specific acceptance channel. Picking the right one is the single highest-leverage decision in a PCI engagement, because every SAQ is a different number of requirements:
- SAQ A - card-not-present merchants whose payment processing is fully outsourced to a PCI DSS validated third party. The merchant never touches PAN data. Roughly 30 sub-requirements. This is the smallest SAQ and the goal scope for most e-commerce merchants.
- SAQ A-EP - e-commerce merchants who partially outsource payment processing but whose website affects security of the payment transaction (for example, a hosted iframe loaded from the merchant's own domain). Approximately 150 sub-requirements. Larger than many merchants expect because the web server is in scope.
- SAQ B - merchants using imprint machines or standalone dial-out terminals, no electronic cardholder data storage. Very narrow scope, declining usage.
- SAQ B-IP - merchants using standalone IP-connected payment terminals (no electronic cardholder data storage) with the terminals isolated from any other system. The most common SAQ for small card-present retailers.
- SAQ C - merchants with payment application systems connected to the internet, no electronic cardholder data storage. Around 160 sub-requirements.
- SAQ C-VT - merchants using a virtual terminal on a single isolated computer, no electronic cardholder data storage. Useful for low-volume call centers and back-office charge-entry workflows.
- SAQ D for Merchants - any merchant that does not qualify for any of the above. This is the full PCI DSS control set as a self-assessment - over 300 sub-requirements.
- SAQ D for Service Providers - the service-provider analog of SAQ D-Merchant, plus the service-provider-specific requirements (Req 12.8.x, 12.9.x).
- SAQ P2PE - merchants using a validated PCI P2PE point-to-point encrypted payment solution. The smallest SAQ - around 35 sub-requirements - because the P2PE solution removes the merchant from the CDE.
Picking the wrong SAQ is one of the most common findings in acquirer reviews. SAQ A-EP merchants who self-attested as SAQ A frequently get reclassified during a breach investigation, which makes the breach response materially more expensive and exposes the merchant to higher fines under the card-brand assessment regime.
ROC, AOC, ASV - the three letters every PCI engagement produces
A Report on Compliance (ROC) is the full PCI DSS audit report produced annually by a Qualified Security Assessor for Level 1 merchants and Level 1 service providers. It documents every PCI DSS requirement, the testing procedures performed, and the evidence reviewed. A ROC runs hundreds of pages.
An Attestation of Compliance (AOC) is the cover-page summary signed by an authorized merchant or service-provider officer attesting that the SAQ or ROC results are accurate. The AOC is the document that gets sent to acquirers, card-brand programs, and B2B customers conducting vendor due diligence. AOCs come in different flavors matched to each SAQ and ROC type.
An Approved Scanning Vendor (ASV) is a vendor approved by the PCI Security Standards Council to perform external network vulnerability scans against internet-facing components of the CDE. Quarterly passing scans are mandatory for any merchant or service provider with internet-exposed CDE infrastructure. The ASV produces its own attestation that gets bundled into the AOC.
Three ways to handle PCI - here is the side-by-side
Every business that accepts cards faces the same fork in the road. Some merchants try to self-attest using whatever SAQ they can get away with. Others bolt PCI onto an existing managed-IT relationship. The honest comparison, criterion by criterion, looks like this.
The new and changed requirements you have to handle now
PCI DSS v4.0 introduced 64 new or substantively changed sub-requirements over v3.2.1. v4.0.1 (June 2024) clarified several of them and is the only recognized version since January 1, 2025. The future-dated requirements became effective on March 31, 2025 - here are the ones we see merchants miss most often.
Client-side payment page script integrity
Authorized-script inventory, integrity assurance (SRI or equivalent), and justification for every script loaded by the payment page. Mandatory March 2025.
Password minimum length 12 characters
All user passwords and passphrases must be at least 12 characters, up from 7 in v3.2.1. Where the system cannot support 12, document the technical constraint and implement the highest length the system allows.
MFA on all non-console access to the CDE
Multi-factor authentication required for all non-console access into the CDE, for all users (not just administrators). Expanded scope from v3.2.1.
Change-and-tamper detection on payment pages
A mechanism to detect and alert on unauthorized modification (including indicators of compromise) of HTTP headers and the script contents of payment pages received by the consumer browser.
Targeted Risk Analysis
For every requirement that allows the assessed entity to define its own frequency or approach, a documented Targeted Risk Analysis is required showing the analysis behind the chosen frequency. New in v4.0.
Customized Approach option
For each control implemented under the Customized Approach (rather than the Defined Approach), a Targeted Risk Analysis, a written control objective, and documented monitoring procedures.
Annual scope verification
The PCI DSS scope must be confirmed and documented at least annually and on significant change. The output is the cardholder data flow diagram plus the system component inventory.
Incident response plan for PAN exposure
Incident response procedures for unexpected stored PAN discovered outside the CDE - including immediate containment, scope re-evaluation, and remediation. New in v4.0.
Anti-phishing mechanisms
Mechanisms in place to detect and protect personnel against phishing attacks. Email security, link analysis, and workforce training tied to the security awareness program.
User access reviews
All user accounts and related access privileges (including third-party and vendor accounts) reviewed at least every six months. Access appropriateness validated, inappropriate access remediated.
Segmentation testing cadence
For merchants relying on segmentation to reduce scope, segmentation testing required at least annually and after any change to segmentation controls. Service providers must test every six months.
Designated Entity Supplemental Validation
Additional control set applied at acquirer discretion for entities that have suffered a breach, are large, or process complex environments. Mostly Level 1 territory.
PCI DSS overlap with HIPAA, CMMC, SOC 2, and cyber-insurance underwriting
The fastest path to PCI DSS compliance for an organization already running another security regime is to extend the existing control set rather than build a parallel program. The overlap is genuine and the savings are substantial when planned correctly.
HIPAA and PCI DSS
Any healthcare practice that accepts card payments - which is essentially every healthcare practice - lives under both regimes simultaneously. HIPAA's audit-controls standard at 164.312(b) maps cleanly to PCI DSS Requirement 10 (logging and monitoring). HIPAA's access-control standard at 164.312(a) maps to PCI DSS Requirement 7 and 8 (access control and authentication). Encryption at rest and in transit under HIPAA maps to PCI DSS Requirement 3 and 4. A practice that has built a proper HIPAA program already has 60-70% of the technical controls PCI DSS requires - what remains is the CDE-specific scope work and the cardholder-data-flow analysis.
CMMC and PCI DSS
Defense contractors that also accept card payments (for example, a federal training contractor selling courses to government employees, or a defense supplier accepting purchase-card transactions) run PCI DSS alongside CMMC. NIST SP 800-171 controls map heavily to PCI DSS requirements. The cleanest dual-regime path is to use the CMMC enclave as the PCI CDE boundary - the segmentation work has already been done, the access control is already enforced, and the audit logging is already retained.
SOC 2 Type II and PCI DSS
SaaS providers pursuing SOC 2 Type II as their primary B2B trust signal often discover that their customers (especially payment-adjacent customers) also require PCI DSS validation. SOC 2 Type II's Trust Services Criteria for Security, Availability, and Confidentiality map to PCI DSS Requirements 1 through 12 with material gaps - SOC 2 does not specifically address payment-card data flows, ASV scanning, or segmentation testing. The unified approach is to scope SOC 2 broadly and PCI DSS narrowly to the payment-handling subsystem.
Cyber-insurance underwriting and PCI DSS
Every cyber-insurance carrier in the US market now asks PCI-related questions on the renewal questionnaire. Some carriers will not renew a merchant policy without proof of current PCI DSS compliance. Several carriers offer premium reductions for merchants who can produce a Petronella-style evidence binder. Carriers care most about MFA enforcement, encryption posture, incident response readiness, and ASV scan results - all of which PCI DSS requires. A properly executed PCI program is, in practice, the strongest renewal case a merchant can make.
What the overlap actually saves
For a healthcare practice already running HIPAA, adding PCI DSS as a SAQ B-IP terminal-isolation program is typically a four-to-six-week engagement rather than a four-to-six-month one. For a CMMC Level 2 defense contractor adding PCI to handle purchase-card transactions, the engagement runs eight to twelve weeks because the CDE scoping has to be done explicitly even though the underlying control set already exists. For a SaaS provider with a clean SOC 2 Type II report, adding PCI DSS as a SAQ A-EP web-tier program is typically six to ten weeks - the security work is done, the documentation work is new.
Which SAQ applies to your business?
Pick the SAQ that matches how you actually accept card payments. The honest answer about your scope is what protects you in a breach investigation - not the shortest form you can self-attest to.
Fully outsourced e-commerce (Stripe Checkout, Shopify, PayPal redirect)
Card-not-present merchants whose payment processing is fully outsourced. The merchant's website redirects to the payment provider's domain, or embeds a fully managed payment-provider iframe with no merchant-side scripting touching the iframe. Roughly 30 sub-requirements.
Petronella role: scope verification, SAQ A completion, AOC drafting, ASV coordination if any internet-facing infrastructure remains.
E-commerce with merchant-controlled payment-page scripting
E-commerce merchants who partially outsource payment processing but whose website affects security of the payment transaction. Custom JavaScript on the payment page, hosted iframes loaded from the merchant's own domain, or any direct PAN handoff between the merchant web tier and the processor. Around 150 sub-requirements.
Petronella role: full engagement with web tier hardening, change-and-tamper detection per Req 11.6.1, authenticated penetration testing, SAQ A-EP completion.
Card-present retail with IP-connected payment terminals
Brick-and-mortar merchants using standalone IP-connected payment terminals, no electronic cardholder data storage, with the terminals isolated from any other system on a dedicated network segment. The most common SAQ for small card-present retailers.
Petronella role: terminal isolation verification, network segmentation design, SAQ B-IP completion, ASV scan coordination for any internet-exposed segment.
Call center virtual terminal on isolated workstation
Merchants using a web-based virtual terminal on a single dedicated workstation, no electronic cardholder data storage. Useful for low-volume call centers, back-office charge entry, and B2B invoice payment workflows.
Petronella role: workstation isolation, browser hardening, network segmentation, SAQ C-VT completion. Call recording scope analysis if applicable.
Storing cardholder data or complex multi-channel
Any merchant that does not qualify for one of the narrower SAQs - typically because they store cardholder data, accept payments through multiple channels, or have integrated payment systems with their broader infrastructure. Over 300 sub-requirements. Effectively the full PCI DSS as a self-assessment.
Petronella role: full engagement equivalent to a ROC-prep program. Most SAQ D-Merchant clients eventually move to ROC validation as transaction volume grows.
Service providers handling cardholder data on behalf of merchants
Payment gateways, payment processors, hosted call centers, managed firewall providers serving the CDE, hosted-cart providers. Service providers carry additional requirements (Req 12.8.x and 12.9.x) plus six-monthly segmentation testing per Req 11.4.5.
Petronella role: service-provider-specific scoping, six-monthly segmentation testing, service-provider AOC for distribution to downstream merchant customers.
Validated point-to-point encryption solution merchants
Merchants using a PCI P2PE Validated Solution (look it up on the PCI SSC website). P2PE encrypts cardholder data at the terminal, removing the merchant from most of the CDE. Around 35 sub-requirements - the smallest SAQ available.
Petronella role: P2PE solution selection, deployment verification, terminal management procedures, SAQ P2PE completion.
Level 1 merchants and Level 1 service providers
Annual Report on Compliance signed by a Qualified Security Assessor. Required for Level 1 merchants (more than 6 million transactions per year per brand) and Level 1 service providers (more than 300,000 transactions per year). Around 300 sub-requirements assessed with formal testing procedures.
Petronella role: pre-assessment engagement, gap closure, evidence preparation, partnered QSA coordination, ongoing program management between annual ROC cycles.
Penny answers the phone. Petronella scopes your CDE the same week.
We are headquartered at 5540 Centerview Dr., Suite 200, Raleigh, NC 27606. Penny - our front-line AI agent - answers before the third ring, asks three qualifying questions, and books your free 15-minute PCI readiness consult on Craig's calendar. From signed engagement to CDE scoping workshop is typically the same week. PCI is geography-agnostic - we serve merchants nationwide.
Industries that need PCI DSS the most
Every business accepting card payments needs PCI DSS. These are the verticals where the scoping nuance, the operational pressure, and the audit visibility make professional consulting pay for itself.
Healthcare practices accepting card payments
Dental, primary care, behavioral health, ambulatory surgery, and specialty practices that take copays, deductibles, and self-pay charges. Dual-regime engagement with HIPAA - PCI scope sits inside the HIPAA Security Rule control set.
See HIPAA + PCI dual-regime →Retail and restaurant
Brick-and-mortar merchants with IP-connected terminals (SAQ B-IP) or integrated POS systems (SAQ C or SAQ D). Network segmentation between the POS network and guest Wi-Fi is the most common gap we close.
SAQ selection guide →SaaS handling payments
Subscription-billing SaaS providers and B2B platforms that store or process card data on behalf of customers. Typically SAQ D for Service Providers with six-monthly segmentation testing under Req 11.4.5.
Service-provider PCI engagement →Membership organizations and nonprofits
Associations, faith-based organizations with online giving platforms, fitness studios, and member-services nonprofits running recurring card billing. Usually SAQ A or SAQ A-EP depending on the donation-page implementation.
Nonprofit PCI scoping →Professional services with billing platforms
Law firms, accounting firms, consultancies, and trust-and-estates practitioners using practice-management systems with embedded card payment. Often dragging the file server into scope inadvertently.
Professional services PCI →Defense contractors with purchase-card flows
CMMC Level 2 contractors accepting card payments for training, services, or product sales. Dual-regime with the existing CMMC enclave as the PCI CDE boundary - the cleanest path we see in regulated environments.
CMMC + PCI dual-regime →Petronella Technology Group
5540 Centerview Dr., Suite 200
Raleigh, NC 27606
Mon - Fri, 9:00 AM - 5:00 PM ET (Penny answers 24/7)
PCI DSS is geography-agnostic. We serve merchants and service providers across the United States. Remote engagement is the default. On-site CDE walk-throughs available for North Carolina and Mid-Atlantic clients on request.
Related from Petronella Technology Group: PCI DSS Compliance: Complete Guide for Businesses, automating CMMC/HIPAA/PCI compliance evidence with AI, and for hybrid-cloud merchants, zero trust for hybrid cloud PCI.
PCI DSS v4.0, answered
The questions every merchant and service provider asks before scoping a real PCI engagement. Answers grounded in PCI DSS v4.0.1, recent card-brand bulletins, and 23 years of payment-environment engagements.
What is the difference between SAQ A and SAQ A-EP?
SAQ A applies when payment processing is fully outsourced to a PCI DSS validated third party and the merchant's website does not affect the security of the payment transaction at all. This means the payment page is fully owned by the processor - typically a redirect to the processor's domain, or a fully managed iframe with no merchant scripting interaction.
SAQ A-EP applies when payment processing is partially outsourced but the merchant's website does affect the security of the payment transaction. The classic SAQ A-EP scenario is an iframe hosted on the processor's domain but loaded from the merchant's web tier, with merchant-controlled JavaScript on the parent page. Around 150 sub-requirements vs roughly 30 for SAQ A. Misclassifying SAQ A-EP as SAQ A is one of the most common findings in acquirer reviews.
Do I need a QSA or can I self-attest?
Level 1 merchants (more than 6 million transactions per year per card brand) and Level 1 service providers (more than 300,000 transactions per year) require an annual Report on Compliance signed by a Qualified Security Assessor. Everyone else can self-attest via the appropriate Self-Assessment Questionnaire, although some acquirers require a QSA-led assessment at Level 2 as well.
Petronella Technology Group is not a QSA. We are independent PCI compliance consultants. For SAQ-path merchants we run the entire engagement. For ROC-path merchants we coordinate with a partnered Qualified Security Assessor while we handle scoping, gap closure, and evidence preparation.
How long does a PCI v4.0 readiness engagement take?
Timing depends on the SAQ scope and the gap profile. SAQ A or SAQ P2PE engagements where the merchant is genuinely out of the CDE typically run four to six weeks from kickoff to AOC. SAQ A-EP or SAQ B-IP engagements run six to ten weeks. SAQ D-Merchant programs run three to six months. ROC programs run six to twelve months counting pre-assessment, gap remediation, and QSA fieldwork.
The single biggest variable is the state of the existing control set. Merchants who have already executed a HIPAA or SOC 2 program typically cut PCI engagement time roughly in half because the access control, encryption, logging, and incident response infrastructure already exists.
What is a Targeted Risk Analysis and when do I need one?
A Targeted Risk Analysis (TRA) is a new artifact required by PCI DSS v4.0 Requirement 12.3.1. It is a documented risk analysis specific to a single requirement where the assessed entity is allowed to define its own implementation frequency or approach. The TRA documents the threat being addressed, the likelihood and impact of the threat materializing, the effectiveness of the chosen control, and the justification for the chosen frequency.
You need a TRA for every requirement that uses the phrase "periodic" or "at a frequency defined by the entity's Targeted Risk Analysis." You also need a TRA for every control implemented under the Customized Approach (Req 12.3.2) rather than the Defined Approach. Generic boilerplate TRAs are a common assessor finding - the TRA has to be specific to the actual control in the actual environment.
Do we need penetration testing for PCI v4.0?
Yes. PCI DSS v4.0 Requirement 11.4 mandates external and internal penetration testing at least annually and after any significant change. The testing must include external penetration testing (Req 11.4.3), internal penetration testing (Req 11.4.4), and segmentation testing (Req 11.4.5) for merchants relying on segmentation to reduce CDE scope. Service providers must perform segmentation testing every six months instead of annually.
The penetration test methodology must be defined and consistent across engagements - Req 11.4.1 specifically calls out NIST SP 800-115, OWASP, or equivalent industry-recognized methodology. Our in-house penetration testing team delivers PCI-suitable external, internal, and segmentation testing with no third-party markup, and the reports are written for v4.0.1 attestation.
What is the Customized Approach option in v4.0?
The Customized Approach is a new v4.0 option that lets an assessed entity meet the control objective of a requirement using a control of its own design, rather than implementing the Defined Approach exactly as the standard describes. It is intended for mature security programs that have alternative controls genuinely equivalent to or stronger than the Defined Approach.
Using the Customized Approach requires a documented Targeted Risk Analysis (Req 12.3.2), a written control objective, documented monitoring procedures, and assessor validation that the customized control actually meets the objective. This is not a back door to skip controls - in practice it is more work than the Defined Approach. We use it selectively when the Defined Approach is operationally awkward and the entity has a genuinely better way to meet the objective.
What if our payment provider fails the segmentation test?
This question usually comes up when a merchant has assumed network-based segmentation between the CDE and the rest of the corporate network, and the segmentation test (Req 11.4.5) demonstrates that traffic actually flows where it should not. The remediation depends on the cause - misconfigured ACLs, missing VLAN isolation, shared management infrastructure, or shared authentication tied to a flat directory.
If a merchant's payment provider (acquirer, payment gateway, or P2PE solution vendor) is the failing party - for example, a P2PE solution that turns out not to be PCI P2PE validated as claimed - the merchant has a contractual remedy with the provider, but the CDE scope expands until the issue is resolved. We have walked merchants through this exact scenario, including the acquirer notification and the temporary scope expansion. The fix is almost always cheaper than the alternative.
Does PCI DSS cover ACH and Zelle?
No. PCI DSS scope is specifically payment card data - the Primary Account Number (PAN) and the associated Sensitive Authentication Data (SAD) for the five participating card brands (Visa, Mastercard, American Express, Discover, JCB). Automated Clearing House (ACH) transactions, Zelle transfers, wire transfers, and direct bank-to-bank settlement are out of scope for PCI DSS.
That said, the underlying customer financial data is still sensitive under state privacy laws (California CCPA, Massachusetts 201 CMR 17, New York SHIELD Act, others). Many merchants build a single broader financial-data protection program that covers both PCI scope and adjacent ACH workflows. We help scope that broader program when it makes operational sense.
What does PCI compliance cost?
From $X - the actual figure depends on SAQ scope, current gap profile, transaction volume, and whether you need ROC validation. We publish "From" pricing because the variation between a small SAQ A engagement and a large SAQ D-Merchant or ROC program is genuinely large, and a fair quote requires the CDE scoping workshop as input.
For SAQ A or SAQ P2PE engagements, our typical engagement is in the low five-figure range. For SAQ A-EP, SAQ B-IP, or SAQ C-VT engagements, the engagement is in the mid five-figure range. For SAQ D-Merchant, SAQ D-Service Provider, or ROC pre-assessment programs, engagements are in the low-to-mid six-figure range. There are no card-brand-driven license fees we add on - the ASV pass-through cost is the only third-party fee in our pricing.
How do we keep PCI ongoing, not just one-time?
PCI DSS is an annual validation cadence with quarterly ASV scans, six-monthly access reviews (Req 7.2.4), and continuous control operation in between. Our continuous-program clients are on a managed retainer covering quarterly ASV coordination, semi-annual access reviews, annual segmentation testing, annual penetration testing, the Targeted Risk Analysis refresh on every TRA-driven control, and the AOC re-attestation at renewal.
The continuous program is materially cheaper per-year than a fresh engagement every year because the control set, the evidence binder, and the documentation baseline are already in place. The most expensive PCI program is the one that goes dormant after attestation and has to be reconstituted from scratch twelve months later.
PCI is one regime - here is the rest of the program
Most merchants needing PCI also need an underlying cybersecurity program, monitoring, incident response, and another regulatory regime layered on top. Here is how PCI sits inside the broader Petronella program.
Cybersecurity Program (parent pillar)
The Petronella cybersecurity pillar - threat detection, vulnerability management, monitoring, and the broader security operations layer that sits under every compliance regime including PCI.
Open cybersecurity pillar →Compliance Frameworks (parent pillar)
The full compliance frameworks pillar - PCI alongside HIPAA, CMMC, SOC 2, NIST CSF, ISO 27001, FTC Safeguards, and the cross-walk between them. Where dual-regime planning starts.
Open compliance pillar →HIPAA Compliance
For healthcare practices accepting card payments - the dual-regime engagement that scopes PCI inside the HIPAA Security Rule control set. Saves 30-50% on dual-regime program time.
See HIPAA pillar →CMMC Compliance
For defense contractors with purchase-card flows - the CMMC enclave doubles as the PCI CDE boundary. The cleanest dual-regime path in regulated environments.
See CMMC pillar →Penetration Testing (Req 11.4.x)
In-house authenticated penetration testing - external, internal, application layer, and segmentation. NIST SP 800-115 methodology, reports usable for PCI DSS v4.0.1 attestation.
See penetration testing →Pen Test Methodology Detail
The detailed methodology page - scope intake, reconnaissance, vulnerability identification, exploitation, post-exploitation, reporting, and remediation validation cycle.
Read methodology →Managed XDR (Req 10 + 11.5.x)
Continuous monitoring and file-integrity monitoring covering PCI DSS Requirement 10 (logging) and 11.5.x (change detection). Audit-log retention meeting the one-year-minimum / three-month-online requirement.
See Managed XDR →Digital Forensics + Incident Response
For confirmed cardholder data exposure - PCI Forensic Investigator coordination, evidence preservation, chain-of-custody, and the post-breach reporting cadence required by the card brand.
See digital forensics →PCI depth library
Every related spoke, blog, framework reference, and adjacent service. Expand any section to navigate.
PCI DSS v4.0.1 reference - requirements, SAQs, and supporting artifacts
- Requirements families
- Complete PCI DSS guide for businesses
- PCI DSS - what businesses must know
- Cross-regime architecture
- Zero trust for hybrid cloud HIPAA + PCI
- AI-powered zero trust HIPAA + PCI
- Zero trust unifying cloud identity HIPAA + PCI
- Secure AI for growth - CMMC + HIPAA + PCI
- HIPAA + PCI + CMMC compliant conversational AI
- AI-powered DLP HIPAA + PCI + GDPR
- AI compliance automation CMMC + HIPAA + PCI
Related Petronella compliance pillars and spokes
- Compliance pillars
- Compliance frameworks pillar
- CMMC compliance pillar
- HIPAA compliance pillar
- CMMC overview
- SOC 2 compliance
- ISO 27001
- CCPA compliance
- SOX compliance
- AI compliance automation
- Cybersecurity program
- Cybersecurity pillar
- Managed XDR
- Penetration testing
- Pen test methodology
- Digital forensics + IR
- vCISO services
- Dark web monitoring
- Cybersecurity audit services
Verticals and adjacent service lines
- Healthcare
- Healthcare IT and cybersecurity
- Healthcare cybersecurity vertical
- Healthcare IT services
- Dental practices
- Other verticals
- Engineering firms
- Clinical trials and research
- AI and automation
- AI services pillar
- AI compliance automation
- Guides and resources
- HIPAA implementation guide
- Digital forensics guide
Ready to talk PCI DSS v4.0?
Free 15-minute readiness consult, CDE scoping workshop the same week as engagement, and a Targeted Risk Analysis as the first deliverable. Penny will route you to Craig.