PCI DSS Compliance,
Reimagined.

When small and medium-sized businesses struggle with PCI DSS, the assumption is usually that their security controls are weak.

In my experience, that's rarely the real issue.

Most SMEs don't fail PCI DSS because they lack firewalls, antivirus, or encryption. They fail because they lack structure.

PCI DSS is not simply a technical standard. It is an operational governance framework. And governance requires clarity, ownership, and repeatability.

Over the years, I've seen organisations with strong technical controls unravel during assessment. Not because they were insecure, but because they couldn't demonstrate:

• Clear scope definition
• Assigned control ownership
• Consistent evidence
• Repeatable processes

Security tools don't create compliance. Managed process does.

One of the biggest weaknesses I see is undefined scope. If you cannot clearly articulate where cardholder data enters, flows, and exits your environment, everything becomes uncertain. Teams overcompensate, undercompensate, or contradict each other.

Another common issue is delegation. PCI DSS is often handed to IT as "a security thing." But PCI DSS touches HR (background checks), operations (process handling), finance (service providers), legal (contracts), and senior leadership (governance accountability).

Without cross-functional responsibility, compliance becomes fragmented.

Then there's the annual panic cycle. Twelve months of minimal attention. Two weeks of chaos before SAQ submission. Screenshots gathered. Policies hastily updated. Staff coached to "answer correctly."

That's not compliance maturity. That's firefighting.

PCI DSS 4.0.1 makes this even clearer. The introduction of targeted risk analyses and greater emphasis on documented reasoning means organisations must understand their own environments in depth. You can't outsource understanding anymore.

The SMEs that succeed treat PCI DSS as an operational discipline. They:

• Define scope carefully and revisit it regularly
• Assign named owners to each requirement
• Track evidence throughout the year
• Validate controls before assessment

Compliance then becomes predictable. And predictability reduces stress.

The irony is that SMEs actually have an advantage. Unlike large enterprises, they can move faster. They can clarify responsibility quickly. They can embed compliance thinking directly into daily operations without navigating layers of bureaucracy.

But leadership must reframe the conversation. If PCI DSS is treated as a technical nuisance, it will always feel burdensome. If it's treated as structured risk management designed to protect revenue and customer trust, it becomes strategic.

Focus only on tools, and you'll struggle. Focus on clarity, ownership, and repeatability, and PCI DSS becomes manageable. And once it's manageable, it stops being intimidating.

When businesses are asked to prove they're handling cardholder data securely and in line with the PCI DSS, there are two main ways to do it: through a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC).

Both serve the same purpose of demonstrating PCI DSS compliance, but they are very different in terms of effort, process, and who's involved. Knowing which one applies to your business can save a lot of time, money, and headaches.

SAQ or ROC: What's the Difference?

An SAQ is exactly what the name suggests: a questionnaire you complete yourself. It's effectively a self-check where you confirm how your business measures up against the PCI DSS requirements. There's no external review, so you're responsible for being accurate and honest. The benefit is that it's straightforward, doesn't involve outside auditors, and mainly costs you time.

A ROC is a different story. This is a full audit carried out by a Qualified Security Assessor (QSA), a professional certified by the PCI Security Standards Council. The QSA digs into every requirement, gathering evidence such as policies, screenshots, firewall configs, and interview notes. Because of the level of detail, a ROC is resource-intensive, both in terms of staff time and financial cost.

When Is a ROC Required?

For merchants, the short answer is: when your acquiring bank tells you to. Once you're processing card volumes that place you in the Level 1 merchant category, expect to complete a ROC. Even if you don't hit that threshold, a bank may still insist on a ROC if it sees your business as high-risk or if you've been breached in the past.

Service providers face slightly different dynamics. If you're storing, processing, or transmitting significant amounts of card data, your customers may ask for a ROC rather than accepting an SAQ.

So, Which SAQ Do I Need?

If you're completing an SAQ, the next challenge is figuring out which version applies. The PCI Council has created several, each designed for different payment setups:

• SAQ A: for merchants who fully outsource card processing to a PCI-compliant third party, with no electronic storage of cardholder data.
• SAQ A-EP: for e-commerce merchants whose websites influence how payment data is entered, even if a third party ultimately processes it.
• SAQ B: for merchants using standalone payment devices without electronic storage of card data.
• SAQ D: the most comprehensive version, applying if your business doesn't neatly fit into the other categories.

The right SAQ depends on how you accept payments, what systems you use, and whether you store, process, or transmit cardholder data. Picking the wrong one isn't just a paperwork issue; it can leave you exposed to compliance gaps.

Wrapping Up

The choice between an SAQ and a ROC isn't really a choice; it depends on your merchant level, your role in the payment process, and sometimes simply what your bank or clients demand. What you can control is making sure you understand which option applies and being prepared for what it involves.

ComplyB4 has decades of experience in the PCI DSS space and is available to guide and assist you in making the right choice.

We're excited to announce that QIA, ComplyB4's PCI DSS assessment platform, is now production ready and officially available.

QIA has been built to remove friction, reduce cost, and dramatically simplify how PCI DSS assessments are delivered and maintained, whether you're a Merchant, ISA or QSA.

Why QIA?

At a high level, QIA helps you:

• Complete your PCI DSS assessments faster with guided, structured workflows
• Dramatically reduce time and manual effort by automating evidence capture and assessment mapping
• Improve consistency and quality across ROCs, SAQs and AOCs

Key Features & Functionality

• Intuitive, web-based PCI DSS assessment journeys
• Centralised evidence collection and reuse
• Automated population of PCI DSS ROCs, SAQs and AOCs
• Designed for collaboration between merchants, consultants, and assessors
• Built to scale across multiple clients and assessments

Who It's For

• Merchants looking to simplify PCI DSS and regain control
• Consultancies wanting to deliver PCI DSS more efficiently and profitably
• QSACs seeking a modern platform to support assessments and client engagement

We're proud to announce that ComplyB4 is now a PCI SSC Participating Organisation.

This is a significant milestone for us and for the organisations we serve. Participating Organisation status places ComplyB4 alongside the leading names in global payment security — a community of vendors, assessors, and technology providers who are shaping the future of PCI DSS.

For our customers, this means one thing above all else: you are working with a platform that is directly embedded in the standards process. We don't interpret PCI DSS from the outside. We're part of the ecosystem that defines and evolves it.

What Participating Organisation Status Means

The PCI Security Standards Council is the global body responsible for developing and maintaining the PCI Data Security Standard. Participating Organisations are companies that actively contribute to that work — providing feedback on new standards, engaging in working groups, and helping ensure the standard remains relevant and practical for the industry.

By becoming a Participating Organisation, ComplyB4 gains early visibility into standards evolution, a direct line to the PCI SSC, and the credibility that comes with formal recognition from the body that sets the standard our platform is built around.

What This Means for You

If you're a QSA, QSAC, merchant, or acquirer using ComplyB4, this status reinforces what we've always stood for: building a platform that doesn't just meet PCI DSS requirements today, but stays ahead of where those requirements are heading tomorrow.

As PCI DSS v4.0.1 continues to roll out and the next iteration of the standard begins to take shape, ComplyB4 will be informed, engaged, and ready — so that you are too.

We are grateful to our customers, partners, and the wider compliance community for their trust as we've grown to this point. This milestone belongs to all of you as much as it does to us.

More QSACs and ISAs are wiring AI into their assessment work, and it's easy to see why. Version 4 of the PCI standard piled more evidence handling onto assessors, much of it mundane and fatiguing, and AI can lift that load. The demo always looks great. It's what happens after the demo that most firms haven't priced.

Can you defend and assure it?

A QSAC's product is assurance, and you can only assure work you actually control. The moment an uncontrolled third-party AI service sits in the middle of an assessment, that control — and full assurance — is gone. The PCI SSC is explicit that AI is a tool, not an assessor: the human QSA and the assessing organisation hold final responsibility, and the lead assessor must sign off on anything AI-assisted. So the tool has to keep a named human in the decision, produce a retained log of who reviewed and approved each output, and be able to explain how the model reached its conclusion. Most homegrown tools capture none of that. And a reassuring "we tested it, it's accurate most of the time" is the wrong frame entirely: in compliance, the small share the model gets wrong is a set of missed or invented findings sitting inside signed assessments — which is exactly what a QA review exists to catch.

Where does the evidence actually go?

Send assessment evidence to an external AI service and you've taken on a third-party processor and a data question you've almost certainly never formally assessed. Which region processes it, and whose laws can reach it there? Residency and sovereignty aren't the same thing: data can sit on a server in Frankfurt or Toronto and still be reachable by a foreign government if the provider is subject to its lawful-access laws. US providers can be compelled under the CLOUD Act regardless of where data sits, and neither GDPR, Canada's PIPEDA, nor Australia's Privacy Act overrides that — each instead makes you accountable for the data wherever it goes. Is it retained, or used to train someone's model? Was any of it checked against the supplier due diligence policy you apply to your own clients? For most firms, the honest answer is: we don't know. That's the kind of gap a QSAC would write up as a finding in a client. In your own tooling it's a live exposure — and for an ISA it's closer to home still: that's your own employer's cardholder data environment going into a service nobody vetted.

It costs more than it saves

The first eighty percent of an AI tool is cheap; the last twenty — the part that makes it safe to rely on — is where the effort and accountability live, and it never ends because the standard keeps moving. There's also a skill nobody prices: wiring in a model isn't the same as the competence to keep it grounded and stop it hallucinating, and a hallucinating model is more dangerous than broken software, because it looks authoritative and hides its errors until a QA review or a breach finds them.

None of this means building is always wrong. The line isn't homegrown versus bought — it's whether the tool is properly governed and someone has the resources and the full range of skills — PCI, software, and AI — to sustain it. So the test to hold your own tool to, whoever built it: can it explain its working, keep a named human accountable, tell you exactly where your evidence goes, and catch the model when it's confidently wrong? If you're not sure, that's the question to chase down now, before a QA audit or a client does it for you.

This piece is written by ComplyB4, built by people who spent 20-plus years in PCI DSS and payments before bringing in the software and AI skill to build what assessors actually need. Its QIA platform was built to meet the standard described here, keeping the human QSA accountable for every determination in the way the PCI SSC requires. We're glad to help any assessor think these questions through, whether or not it ends with us.

Sources: PCI SSC, "Integrating Artificial Intelligence in PCI Assessments," 2025; US CLOUD Act 2018; PIPEDA (Canada); Australia's Privacy Act 1988 (APP 8, as amended 2024); GitClear and Veracode research on AI-generated code, 2025.

Executive Summary

Across the PCI DSS industry, QSACs and ISAs are turning to AI to take on assessment work, and the instinct makes sense. Version 4 of the standard has piled more evidence handling onto assessors than ever, and a great deal of it is repetitive, mundane, and exactly the kind of work that drains hours and invites fatigue-driven error. AI can lift that load. Used well, it reviews evidence, surfaces the anomalies a tired human might miss, and lets the assessor spend their judgment where it actually belongs.

That is the opportunity. The risk is that most homegrown tools grab it without pricing what comes with it, and the gaps go deeper than the people building them have stopped to consider. This paper works through them in order of how sharply they bite. First is defensibility and assurance: the moment an uncontrolled third-party service is in the loop, a QSAC can no longer fully stand behind its own work or prove a named human made the call. Second is data governance: sending assessment evidence to an external AI service hands a third-party processor a map of exactly where a client is weakest, and raises residency and sovereignty questions the builder has almost certainly never formally assessed. Third is cost — not just the maintenance that lands long after the build, but the specialist AI skill these tools quietly assume and the running costs nobody forecast.

There is a subtler point running through all of it. As AI moves from fetching documents to reviewing evidence, flagging anomalies, and shaping what the assessor sees, it stops being a clerical aid and starts touching the assessment itself. Every one of the risks below gets sharper as the tool reaches deeper, which is precisely the direction these tools are heading.

The Trend: From Speeding Up Evidence to Doing the Assessment

AI has made it genuinely cheap to prototype something useful. A QSAC with one technically minded assessor or a part-time developer can put together a tool that scans evidence, flags gaps, and speeds up first-pass review in a matter of days. The demo looks great. It handles the evidence types the team sees most often, in the format they're used to, and it does it faster than the manual process it replaces.

It rarely stops there. Evidence gathering is only the first stage of an assessment, and once a tool is fetching and reading evidence, the temptation to let it do more is immediate and reasonable: have it review the evidence, flag anomalies, draft observations, pre-populate findings. Each step is a small, sensible extension of the last, and each one moves the tool a little further from clerical support and a little closer to the assessment judgment itself.

That first version is genuinely useful, and that's exactly why it's risky. It works well enough, fast enough, that it becomes part of the workflow — and then quietly part of the judgment — before anyone has asked what happens when a requirement changes, when a new evidence format appears, or when a client asks for proof of how the tool reached its conclusion.

Risk One: Can You Defend It, and Can You Assure It?

The most immediate risk is also the most personal. A QSAC's product is assurance. When it signs an assessment, it is vouching that the work was done to the standard, and that vouching is only worth something if the QSAC actually controls how the work was done. The moment an uncontrolled third-party AI service sits in the middle of the assessment, that control is gone — and with it the ability to give full assurance. You cannot stand behind reasoning you cannot see, from a service you do not govern, on data you cannot fully account for.

A QSAC's work is subject to quality assurance review, and its assessments have to hold when a client, an acquirer's due diligence team, or the Council itself asks how a determination was reached. Explainability and traceability are not nice-to-haves here. They are the difference between an assessment you can defend and one you can only hope holds up.

The PCI SSC's own position is explicit: AI is a tool, not an assessor. The human QSA or ISA holds final responsibility for every finding, and the lead assessor must review and approve anything AI-assisted. In practice, the tool must keep a named human in the decision — not merely a person somewhere in the loop — and must produce a clear, retained log showing which human reviewed and signed off on the AI-assisted output. Most homegrown tools do not capture it, because they were built to speed the work up, not to prove who was accountable for it.

A failed QA review or a challenged assessment doesn't just cost time and money. It touches the one thing a QSAC actually sells: the reliability and defensibility of its judgment. That reputational damage travels fast in a small industry — a far more expensive thing to put at risk than a subscription fee.

Risk Two: Where Does the Evidence Actually Go?

The second risk gets the least thought before a build starts, and it is the one most likely to become someone else's problem to clean up. When a homegrown tool uses an external AI service to read evidence — whether a general chatbot, an API, or a model wired in by whoever built the tool — the evidence leaves the building. Assessment evidence is some of the most sensitive material a QSAC handles: it describes how a client protects cardholder data, which is a map of exactly where that client is weakest.

Ask the questions a QSAC would ask of any client's third-party processor, and turn them on the AI tool the QSAC built for itself. In which region is the data processed? Is it retained after the request, and for how long? Is it used to train the provider's models? Was a data processing agreement ever signed? For a tool built quickly in-house, the answer to most of these is "we don't know," and to several it is "nobody checked."

Residency, sovereignty, and third-party processing are not the same protection, and the gap between them is exactly where assessment evidence gets exposed. US providers can be compelled under the CLOUD Act to produce data regardless of where it is physically stored. PIPEDA does not require data to stay in-country — it holds the transferring organisation accountable for what happens to it wherever it goes. Australia's Privacy Act (APP 8, as amended 2024) keeps the organisation legally responsible once data passes to an overseas recipient. The pattern is the same across regions: accountability travels with the evidence.

Risk Three: The Bill Nobody Forecast

The first twenty percent of the effort builds eighty percent of the tool, and the last twenty percent takes the other eighty percent of the effort. In a weekend you can build something that wows an internal team on a screen share. Because it looks finished, people assume the last stretch is another afternoon's work. In reality it is the demanding part — often several times the effort of everything that came before — and for a compliance tool it is the part that decides whether the thing is safe to rely on.

The second cost is literal, and it arrives monthly. AI services are metered by token consumption, and token usage is notoriously hard to predict. A tool that looked cheap in a pilot can generate startling bills once it is used at real volume across a full assessment. Teams across the industry have watched unpredictable inference costs balloon to the point of stalling the very projects that were meant to save money.

And none of this is a one-off. A PCI DSS tool is judged every assessment cycle, against whatever the current standard requires, so someone — a human — has to keep translating each update into changed logic and keep hardening the tool, or it slowly rots. Most firms building internal tools haven't resourced that: no named owner, no maintenance budget, no plan for when the builder moves on. The tool doesn't fail loudly; it just drifts out of alignment and nobody notices until an assessment is challenged.

The Skill You're Buying Isn't the One You Have

A hospital does not build its own MRI machine. Its radiologists are world-class at reading a scan, but reading a scan is not the same skill as building, calibrating, and certifying the scanner and keeping it compliant with medical device regulation as that regulation changes.

Wiring an AI service into a workflow gives you a model; it does not give you the competence to control it. Grounding output in approved evidence, controlling hallucination, designing retrieval so the model sees the right context, building guardrails, and recognising when the model is confidently wrong are a discipline in their own right, distinct from both software engineering and PCI knowledge. Broken software looks broken. A hallucinating model looks authoritative — it hands you fluent, citation-shaped output on day one, and hides its errors until a QA reviewer or a breach finds them.

And If You're an ISA, the Exposure Is Closer to Home

Everything above applies to QSACs, but Internal Security Assessors sit in a position that is in some ways more exposed, not less. An ISA assesses their own organisation's compliance, which means the evidence a homegrown or general-purpose AI tool ingests isn't a client's — it's their own employer's: the cardholder data environment, the network diagrams, the segmentation, the known weaknesses. That is the organisation's own security blueprint.

The oversight that would normally catch this is often lighter internally than it is on a client engagement. There is no external procurement gate, no client data-processing agreement forcing the question. An ISA reaching for AI to lighten the assessment load can move from prototype to routine use without anyone in security, legal, or procurement ever assessing where the data goes.

The Real Variable Is Governance, Not Who Typed It

The dividing line is not homegrown versus bought. A homegrown tool can be properly governed, and some are; a bought tool can be governed badly, and some are. End-to-end governance is the variable: whether the tool is built on clear principles, held to a defined standard, and wrapped in a framework that keeps it compliant, continuous, and consistent as everything around it changes.

The honest test to apply to any tool: When PCI DSS changes, does someone whose job this is update it, or does it wait for a spare afternoon? When a client asks how a determination was reached, can the tool explain its reasoning and show a human signed it off? When the QA audit asks where your evidence went, do you have an answer that survives scrutiny? If the answers make you uneasy, that unease is worth following.

Conclusion

The firms turning AI loose on their assessment work today are solving a real problem, under a real shortage of time, made worse by everything v4 added to the assessor's load. But moving faster on the build is not the same as thinking harder about the consequences. A working prototype is not a platform, and a fluent demo is not assurance. The part it skips — the defensibility, the governance, the AI skill, the maintenance that never ends — is precisely the part that carries the weight of a compliance obligation.

Most of the firms building these tools have not fully looked into this, and they should, before it is looked into for them. If reading this has raised a question you can't immediately answer about your own tool, that's not a reason for alarm. It's a reason to look — and to look now rather than after a QA audit or a client does it for you.

References: PCI Security Standards Council, "Integrating Artificial Intelligence in PCI Assessments — Guidelines, Version 1.0," March 2025. GitClear, "AI Copilot Code Quality: 2025 Research on Code Cloning, Churn and Reuse," 2025. Veracode, "State of Software Security: AI-Generated Code Security Findings," 2025. Clarifying Lawful Overseas Use of Data (CLOUD) Act, 2018; Office of the Privacy Commissioner of Canada guidance on cross-border transfer accountability under PIPEDA; Australia's Privacy Act 1988 (Cth), as amended by the Privacy and Other Legislation Amendment Act 2024 (APP 8).

First Name

Last Name

Work Email

Company Name

How can we help? Select a topic… General Enquiry Pricing & Custom Quote Platform Demo Partnership / Reseller Technical Support Data Sovereignty / Hosting

Message

Send Message →

We'll respond within one business day. No spam, ever.

Our journey began when our founders recognised that traditional compliance tools were no longer sufficient for today's dynamic business landscape. Through innovation, expertise, and a commitment to customer success, we have consistently delivered measurable results, transforming compliance from a burden into a competitive advantage.

Meet the Team