Defined Roles in PCI

Audit season starts, and someone asks the dangerous question: "Who owns PCI?"

Silence. Then three people raise their hands. Or worse — nobody does, and the owner list still names someone who left eighteen months ago.

That's how mid-sized companies lose months on PCI DSS: not because the requirements are mysterious, but because roles are fuzzy. Merchants assume the processor "handles PCI." Processors assume the merchant owns scope. Control owners think the QSA will invent evidence. And the ISA is buried in unrelated tickets.

PCI gets clearer when you define who owns what — before the assessor opens a sample.

Why Role Clarity Beats More Spreadsheets

PCI DSS is a shared-responsibility standard. Merchants, service providers, assessors, and control owners all touch the same cardholder data environment (CDE). Requirement 12.8.5 expects you to document which PCI requirements each third-party service provider (TPSP) manages, which you manage, and which are shared.

If those lines aren't written down, gaps hide in the middle. Your QSA will find them — and your team will argue about ownership instead of producing evidence.

For mid-sized companies, the fix isn't a 40-page RACI nobody reads. It's a short map of five roles — merchant, service provider, QSA, ISA, and control owners — plus a matrix that matches contracts and reality.

The Merchant: Still Accountable for the Outcome

If you accept payment cards, you're the merchant (or the entity in scope). You own the compliance outcome even when vendors do most of the technical work.

That means you define and defend scope, maintain operating policies and people, inventory TPSPs that can affect account data or CDE security, keep written agreements and a current responsibility matrix, monitor provider compliance at least annually, and produce evidence for requirements you still own.

Outsourcing payment processing does not outsource accountability. If your gateway patches the OS but you configure application access, you still own the access-control story. Write that split down.

The Service Provider: Owns What It Touches — Explicitly

A service provider stores, processes, or transmits cardholder data for others — or can affect the security of that data. Processors, gateways, hosting providers, and managed security firms land here.

Their job is to secure the services they operate, tell customers which requirements they manage versus what remains with the customer, provide compliance status (typically an AOC) when asked, and acknowledge responsibility in contracts.

Treat every provider AOC like a scope document, not a participation trophy. Confirm the services you buy are inside their assessed scope. If a control you thought they owned disappeared from their latest assessment, it just became yours.

The QSA: Independent Validation, Not Your Program Manager

A Qualified Security Assessor works for a PCI SSC–qualified company and performs external assessments. QSAs validate scope, test controls, interview people, and produce the ROC and related AOC when an on-site assessment is required.

What a QSA is not: your control owner, your evidence librarian, or the person who invents compensating controls the week before sign-off.

Bring a defined CDE, a TPSP inventory, and a responsibility matrix. Point them at named control owners and current evidence. Expect challenge on scope. Keep remediation ownership inside your company. A strong QSA relationship speeds assessments — it does not replace an internal PCI program.

The ISA: Your Internal Assessment Muscle

An Internal Security Assessor is a trained employee who improves how your organization understands and self-assesses PCI DSS. ISAs raise internal review quality and make QSA engagements less chaotic.

They help with SAQs, ROC prep, and translating PCI for engineering and finance. They are not a substitute for independence when your acquirer requires an external QSA — and they shouldn't be the only person who "knows PCI."

Give an ISA time for scoping, sampling, and coaching owners — not last-minute evidence chasing.

Control Owners: Where Compliance Actually Lives

This is the role mid-sized companies under-define.

A control owner operates a specific requirement or control — access reviews, logging, key management, change control, vendor diligence, vulnerability management. They don't need to be a PCI expert. They do need to know what the control requires in plain language, how often it runs, what evidence proves it ran, and who covers them when they're out.

Without named owners, PCI becomes a GRC-only project. Assessors interview "the compliance person," who then forwards Slack messages to six teams who all thought someone else was collecting screenshots.

Map owners at the control level, not just "IT owns security." If two teams share a control (provider ships logs; you review them), document the handoff and the evidence each side keeps.

Build a Responsibility Matrix People Will Use

PCI's TPSP documentation requirement is, in practice, a responsibility matrix. Keep it boring and useful:

1. List every TPSP that can affect your CDE or account data
2. For each relevant requirement, mark Entity, TPSP, or Shared
3. For shared rows, write the split in one sentence (who implements, who evidences, who reviews)
4. Tie rows to contract language and the provider's current AOC
5. Review when services change — and at least annually

Then name a control owner and backup for every Entity or Shared cell. That artifact answers the assessor's first questions and stops the hallway debate about who rotates the keys.

How Mid-Sized Teams Keep Roles Alive

Roles decay. People change jobs. Vendors add features that expand scope.

Make role hygiene part of the program: reconfirm merchant vs. provider splits at contract renewal; refresh the TPSP matrix when onboarding or offboarding a vendor; reassign control owners in the same change ticket that moves system ownership; and brief the QSA or ISA with an owner map before fieldwork starts.

If you track controls in a platform like episki, attach owners, cadence, and provider responsibility tags to the same records you use for evidence. Ownership that lives only in a policy PDF won't survive the first sick day.

Key Takeaways

• The merchant remains accountable for PCI outcomes even when providers do the heavy lifting
• Service providers must clarify — in contracts and AOCs — which requirements they actually manage
• QSAs validate; they do not run your control program
• ISAs strengthen internal assessment quality; they are not automatic independence
• Control owners make compliance real — name them per control, with backups and evidence expectations
• A living responsibility matrix (Entity / TPSP / Shared) turns shared responsibility into an operating model

Defined roles won't make PCI easy. They will make it finishable — with fewer surprises, cleaner evidence, and a team that knows who owns the next action when something breaks.

Do you know who owns each PCI control in your program — or is ownership still a hallway debate? episki helps mid-sized teams attach owners, cadence, and provider responsibility to the same records they use for evidence. Get started free