New QSA. Fist time writing a non-compliant ROC. Several issues, the assessment started in September. Evidence took forever to be provided, much was just not provided. Segmentation test just failed. No interviews or observations conducted. Basically every single requirement not in place. Has anyone ever gone about writing a ROC this bad before. Unfortunately, I was not a QSA when this started.

Hi,

I am a PCI DSS ISA and has been given a task to come up with a script to extract pci dss hardening related parameters on Windows/Linux/Network (firewalls,routers,switches) and Database and some agent using AI to analyse the script results and come up with a dashboard to show the findings..so that remediation tickets can be raised against those finding.

Any one has something of this sort in place already? Will be great to have some suggestions or some readily available stuff to use with some edits etc.

Please help!! Thanks in advance.

Hey everyone,

Just wanted to get a quick sanity check from fellow QSAs/assessors on how you would look at a few specific network security control scenarios during an assessment.

1. An environment has Ubuntu servers in-scope (including some critical systems). All of them have an outbound rule permitted to 0.0.0.0/0 on the firewall, with the client's business justification stating it is strictly required to fetch internet patch updates. How would you handle this? Is this acceptable under v4.0.1?
2. Regarding segmentation boundaries: Is it permissible to allow an outbound rule from an in-scope server to an out-of-scope server? Or is the rule strictly that out-of-scope systems cannot have inbound access to the in-scope environment?
3. If there is an inbound rule originating from an out-of-scope proxy traveling to an in-scope proxy, tightly restricted to only specific ports and protocols, is this considered acceptable architecture under PCI DSS?

Curious to hear how others would write these up or evaluate them. Thanks!

This has been an absolute brain scramble and I just wanted to get an idea as to other peoples thoughts.

For context, I work in the industry but this is something that has come up recently and I'm struggling to find the line to follow.

Let me give you an example...

A small merchant that is eligible for SAQ A now appears to no longer need to be applicable for Requirement 6.4.3 and 11.6.1. These requirements have now been completely removed from the SAQ A so there is no expectation to do these requirements.

However, a larger merchant that is maybe aligned to SAQ A appears to still have to implement controls to satisfy 6.4.3 and 11.6.1.

The PCI DSS Requirements and guidance for 6.4.3 and 11.6.1 states the following:

PCI DSS Requirements 6.4.3 and 11.6.1 are included in Self-Assessment Questionnaire (SAQ) A-EP, SAQ D for Merchants, and SAQ D for Service Providers. These requirements are also included in the PCI DSS Report on Compliance (ROC) Template.

SAQ A does not include PCI DSS requirements 6.4.3 or 11.6.1. However, SAQ A does include the following Eligibility Criteria for e-commerce merchants “The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”

How can a merchant confirm their site is not susceptible? Requirements 6.4.3 and 11.6.1 still clearly state they are applicable when a PSP is used and an iframe or full redirect are in place. Yet if the merchant simply says "we aren't susceptible" then they can be ignored? Isn't the whole point of these controls to ensure they aren't susceptible?

Hi all,

Found this sub when looking for answers. There is a merchant who I will not disclose the name of who heavily promotes sale of adult content on his site on YouTube and various platforms. The setup even includes an alternative for "Model/AI model" referring to the main customer base.

The site has:
– No Age Gate
– Instant public availability of content
– No CSAM/Consent checks
– No KYC face match for sellers content
– Non functional contact email (bounces) and no functional DMCA.

I naturally used Google Console to see what payment systems they are using to find that they use "NUVEI PAYMENTS LTD". I emailed them multiple times with proof, as did others affected, but alas, no response.

I also emailed VISA/MASTERCARD both BRAM/IP divisions. I emailed Vercel (their hosting provider) and dont know what else to do.

Anyone here dealt with similar problems and got a good solution?

Hi, we are the start-up based in South Korea.

We recently collaborated with Korean payment processing companies to develop a hosted payment processing product for users of no-code builders (such as Bubble, Webflow, and Framer).

However, the systems of existing payment processing companies are outdated, and while they require customers to install "security software", these programs actually offer lower security. Therefore, we developed our own UI and system capable of securely processing card information. Although we developed this system entirely in-house, it integrates with the payment processing companies' backend systems.

Since we developed and operate the system ourselves, the scope is not very large, but we anticipate needing PCI-DSS A-EP or D certification. Given that we are a very small startup with limited available funds, is it unreasonable to expect to obtain PCI-DSS certification?

trying to figure out tokenization strategy for a multi-region setup where each region is on a different PSP and we want customer cards to feel portable without dragging us out of SAQ-A.

we're on Stripe for US, Adyen for EU, and Worldpay for UK. each PSP gives us their own token vaulting, but customers expect to move between regions without re-entering card details, and our merchant agreements with our acquirers limit how creatively we can pass tokens around.

network tokenization through Visa/mastercard looks cleanest but coverage across PSPs is uneven and it's more work than the vendors say.

saved a thread on this sub a while back where some folks recommended a few options worth checking, i think it was a mix of network tokens, PSP-agnostic vault providers like Basis Theory and Spreedly, and going with a commerce backend that handles the tokenization layer natively (i remember SCAYLE came up because they apparently handle this for multi-PSP fashion brands), but i can't find the thread now.

what's working in practice for brands juggling 3+ PSPs at this point, particularly on whether the commerce-backend approach holds up or if it just shifts the integration burden somewhere else?

I work for a start up. We’re looking to become SAQ C-VT compliant. We have agents that take credit card numbers and input them into carrier portals, this is all done in the browser.

My question is, would a secure browser actually make us compliant?

The secure browser will prevent copy/paste, sensitive information masking, enforce conditional access, 2FA, and introduce water marks over sensitive data.

These users work from home, on their own ISP, on a workgroup windows device, using a local account.

The alternative is a VDI. I’ve used Omnissa in the past and had an awful experience with it and the MSP providing the desktops, plus I’d like to avoid spinning up a ton of infrastructure if possible. Curious if anyone is in the same boat utilizing a secure browser or might have some insight into what auditor might say about it.

Next Week, Wednesday and Thursday in Salt Lake. Just curious. Ill be there!

Now that PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1 have been in effect for over a year, I’m curious how others are seeing them play out in practice.

For organizations managing payment-page script inventory, script authorization, integrity validation, and change/tamper detection: are these controls proving effective in reducing e-commerce skimming risk, or are they becoming more of a compliance exercise?

Do you expect PCI SSC to continue refining these requirements, or could advancements in automation and AI-assisted monitoring change how these controls are implemented or assessed in the future?

I’m also interested in thoughts on the SAQ A update. My understanding is that Requirements 6.4.3 and 11.6.1 were removed as explicit SAQ A testing requirements and replaced with an eligibility confirmation that the merchant’s site is not susceptible to script-based attacks that could affect the merchant’s e-commerce systems. Do merchants and signers feel comfortable attesting to that statement? Is that approach actually more effective, or does it create more ambiguity?

I am looking for insight from credit union compliance officers, auditors, IT personnel, records managers, examiners, e-discovery professionals, and anyone familiar with Jack Henry’s Synergy Enterprise Content Management (ECM) platform.
Assume the following scenario:
A credit union employee claims that during a single branch visit, a member requested beneficiary (POD) changes on multiple accounts. According to the employee, several beneficiary forms were generated, information was entered on the forms, the forms were printed, handwritten annotations were added, the member signed each form, and the forms were then scanned individually into Synergy and indexed under a document category such as “POD Form” or “Beneficiary Form.”
Years later, litigation arises concerning the authenticity, timing, and handling of those documents.
From a compliance, records-management, audit, and governance standpoint, I am trying to understand what electronic information would ordinarily exist within Synergy or related systems.
Questions:
When a document is scanned into Synergy, what metadata is normally captured?
Scan date/time?
User ID?
Workstation ID?
Scanner ID?
Batch information?
Import method?
Document creation date?
Indexing date?
If an employee later views the document, prints it, exports it, emails it, reindexes it, or changes metadata, are those actions ordinarily logged?
Does Synergy maintain audit trails showing:
who scanned the document;
who indexed it;
who modified index values;
who viewed the document;
who printed the document;
who exported the document?
If a document was allegedly scanned on a particular date, what system-generated records would typically exist to corroborate that claim?
Are there administrator logs, database records, audit tables, workflow logs, retention logs, or imaging logs separate from the document image itself?
If a credit union produces only PDF copies of scanned forms, would the underlying Synergy metadata ordinarily still exist somewhere within the ECM environment?
For institutions using Jack Henry products, what records would an examiner, auditor, regulator, or forensic examiner typically request to validate the provenance of a scanned document?
If multiple forms were allegedly printed, completed, signed, and scanned during a very short period of time, what electronic records would normally exist to establish the timing of each step?
Does Synergy maintain any unique document identifiers, object IDs, image IDs, GUIDs, hash values, audit references, or database keys that can be used to trace a document’s lifecycle?
From a compliance perspective, would producing only image copies without the associated audit information generally be sufficient to validate the history of a disputed document?
I am not seeking legal advice or opinions on any specific litigation. I am interested in understanding industry standards, ECM functionality, audit capabilities, document provenance, records-retention practices, and what electronic evidence typically exists when a financial institution relies upon scanned documents maintained in Jack Henry Synergy.
I would especially appreciate responses from current or former credit union employees, Jack Henry users, ECM administrators, NCUA examiners, compliance officers, auditors, digital forensics professionals, and e-discovery practitioners.

Hai Guyz,

​

I know about PCI compliance since I've worked at multiple call centers. I have recently started working at an accounting firm. The accounting firm uses Onvio, where they store card information, including the 3 digit security codes. I emailed my boss a screenshot as well as a link that explicitly lists storying CVV as a violation. She simply responded, "Don't worry about it." The same boss asked me to give her my Windows password in case anyone needs to access my files when I am not around.

Is there anywhere I can report them?

Hi everyone,
I’m currently working on PCI DSS 4.0 requirement 11.6.1 validation for a payment page that contains payment buttons and client-side scripts.
Our objective is to verify that both F5 Distributed Cloud Client-Side Defense and Radware Client-Side Protection are able to detect:
Unauthorized modifications to HTTP headers or script delivery.
Client-side tampering attacks affecting payment page components.
Changes to JavaScript resources that should trigger an alert from the monitoring solutions.
I’m specifically looking for practical testing methodologies, lab guides, or Burp Suite techniques that can be used to simulate these scenarios in a controlled environment.
For tampering tests, I’ve found some basic Burp Suite examples, but I’d like to know:
How do you typically test PCI DSS 11.6.1 in real assessments?
What client-side modifications have successfully triggered F5 or Radware detections?
Are there recommended attack scenarios for validating script integrity monitoring?
Have you used Burp Suite, browser developer tools, MITM proxies, or custom JavaScript injections to simulate unauthorized changes?
Any guidance, test cases, references, or lessons learned would be greatly appreciated.

Environment: Payment page with hosted payment buttons, testing performed in a non-production environment. Goal is to generate valid PCI DSS 4.0 Requirement 11.6.1 evidence and confirm detection capabilities of both F5 Client-Side Defense and Radware Client-Side Protection.

Thanks!

My company is migrating a BI tool connected to our CDE to the cloud and the current vendor in the lead is not PCI-DSS compliant. I spoke with the vendor today and they said would be willing to complete and provide us with an SAQ of their BI software to demonstrate compliance.

Setting aside the issue of whether the vendor could be trusted to properly scope their own merchant-level, my understanding is SAQ completion does not imply compliance. A completed AOC (whether over a full ROC or SAQ) conducted by a QSA is the only path to compliance. Therefore, a SAQ not validated by a QSA would not satisfy 12.8.4 for my org.

Is my understanding correct?

Fair warning, this one is definitely "outside the box" when it comes to PCI compliance. To start off, with the general rule of PCI compliance obligations being "any organization that can process, transmit, or store payment card information" how does that apply to a password manager that provides the capability to store card details for the user?

Obviously this is outside of the traditional scope of PCI because the password manager isn't accepting the card info for the purpose of completing a transaction, but it is still saving the information for long term storage. A potentially complicating factor is that based on the platforms I looked into, many platforms allow the CVV/CVC to be saved as well, which is definitely against the rules.

The only thing I can come up with is that because the password manager isn't being used for the purpose of accepting a payment, that PCI rules aren't applicable but I am hoping someone with authoritative knowledge sees this and can weigh in.

Looking for opinions from PCI DSS assessors, security architects, and vulnerability management teams.

We have an in-scope PCI DSS environment that uses a vendor-managed secure access appliance to control administrative access into the CDE. The appliance is managed entirely by the vendor, and the customer does not have OS-level administrative credentials.

Under PCI DSS v4.0.1 Requirement 11.3.1.2, authenticated internal vulnerability scanning is required. However:

• The customer does not have access to the underlying operating system.
• The vendor does not support creation of temporary scan accounts.
• The appliance is fully vendor-managed.
• Unauthenticated scanning can be performed, but authenticated scanning by the customer or assessor is not possible.

In this scenario:

1. Would you consider the appliance as a system that is "unable to accept credentials for authenticated scanning" under PCI DSS 11.3.1.2?
2. Would a vendor PCI DSS AOC be sufficient evidence, or would it only be considered supplementary evidence?
3. Would you require the vendor to perform an authenticated vulnerability assessment and provide the scan results?
4. What evidence would you consider sufficient to satisfy the intent of authenticated vulnerability scanning for a vendor-managed security appliance where customer credentials are not available?

Curious how much people ended paying for level 2 PCI compliance as a service provider. Who did you use, and are you happy with them?

does anyone have have ppts or slides via which I can study myself and teach my fellow colleagues? kindly help!

How do you guys handle requirement 3.5.1.2 for files that are fetched by VCX? Visa provides the files with CHD in cleartext, but the requirement says disk encruption is not enough...

I've been building AI pipelines that touch compliance workflows, and I keep hitting the same wall.

A prompt instruction is not a control. "Don't output cardholder data" in a system prompt is a policy. PCI has never accepted policy without enforcement — Req 8 doesn't say "ask users not to share passwords," it says enforce complexity and rotation. Nobody seems to be making that connection on the AI side.

Here are some things I'd actually ask about any AI deployment in or near a CDE:

Does it have access to data it doesn't need? Req 7 says least privilege. Most implementations I've seen are wide open by default, locked down later only if someone notices.

Are you logging what the model received, what it returned, and what decision it made? Not that it ran. What it actually did? Req 10 wants a record of what happened, not confirmation that a process fired.

If the AI is writing code or config that touches your CDE, is anyone reviewing that output before it lands? That's Req 6.3. It doesn't stop being secure development just because a model wrote it instead of a developer.

The one that catches people completely off guard is: if a model is fine-tuned or RAG-indexed on your internal documents do you realize its a data exposure surface? Most teams aren't framing it that way yet, but they will be.

The risk isn't the model. It's the distance between what your AI policy says and what your environment actually enforces.

Are QSAs asking about this in assessments yet?

Over the past several months we ran automated browser-layer scans across a large sample of e-commerce and merchant domains to understand how widespread client-side security exposure actually is post-March 2025 deadline.

Key findings:

• 37% of scanned domains showed active browser-layer security exposure indicators relevant to Requirements 6.4.3 and 11.6.1
• Most common finding: No Content Security Policy with a script-src directive on payment-related pages — present on the majority of flagged domains
• Second most common: Third-party scripts executing without Subresource Integrity controls — including Google Tag Manager, Meta Pixel, and analytics scripts loading directly on checkout pages
• Most alarming: Keystroke event listeners (keyup, keydown, input) attached to form fields by third-party scripts — the exact technical pattern Magecart-style skimmers use to intercept card data

A few things that stood out:

1. Platform compliance (Shopify, WooCommerce, Magento) does not equal browser-layer compliance. The exposure exists at the script layer, not the server layer.
2. Google Tag Manager was present on checkout pages in the majority of flagged domains — and in every case was loading additional scripts dynamically, none with SRI controls.
3. The gap between a clean homepage and a risky checkout page was significant. Many domains that looked fine on the surface had serious exposure on their payment flows.

We built a free browser-layer scanner at clientsideintel.com if anyone wants to check their own domain — no account needed, instant results. It checks the same indicators: third-party scripts, CSP, TLS, security headers, and overall risk rating tied to Req 6.4.3 and 11.6.1.

Happy to answer questions about methodology or share more specific findings.

I have been slowly building a PCI QSA portal and web app. Mainly just to help streamline and improve the flow of work for myself and colleagues. The portal is designed to onboard clients, request various documents/policies and hopefully just reduce some of the more mundane tasks of helping clients achieve compliance.

I would love to know what anyone working in the industry would personally like implemented in a solution like this. Any thoughts or suggestions would be appreciated. Any really frustrating processes or sticking points you get with clients for instance.