A service provider can support thousands of merchants without directly handling sensitive card data—and still have PCI DSS work to do.
I saw this firsthand with a company I already worked with through Field39.
The company became responsible for a PCI DSS project after the company’s acquirer asked it to address requirements from the standard, with particular attention to Requirement 12.
The company had not previously used a dedicated compliance tool. I helped it get started with PCI DSS Dashboard and supported the onboarding and setup. They acquired the AOC.
The absence of card data was not the end of the conversation
When it comes to PCI DSS the first question to ask would be whether it stores, processes or transmits card data.
But PCI SSC also recognizes service providers whose services could affect the security of payment account data, even without directly handling it. Whether that applies depends on what the service actually does. [PCI SSC FAQ 1579]
In this engagement, the acquirer’s request made the need to address PCI DSS concrete. The company was advised to engage a QSA firm and subsequently entered a ROC assessment process with what was described to me as a reduced scope.
What mattered operationally was that the company now had work to understand, assign and support with evidence.
Scope needed an explanation
A limited service does not automatically mean that only a short list of requirements matters.
The applicable requirements must be determined from the service and its environment, and exclusions need a documented basis. PCI SSC explains this distinction in its guidance for providers that can affect payment-data security. [PCI SSC FAQ 1580]
For another CTO in this position, I would start with a written description of the service, the systems involved, the organization’s responsibilities and the requested assessment deliverables. Those give the internal team, acquirer and assessor something concrete to work from. The scoping process is the initial one, and it lays the foundation for what will become the program later on. It gives the clear picture on the requirements that apply.
They also make the next stage easier: organizing the requirements that apply rather than debating scope every time a task comes up.
The Prioritized Approach Tool was the beginning
The company initially worked through the PCI DSS v4.0.1 Prioritized Approach Tool before moving further into the assessment process.
That distinction is useful. The tool provides a way to organize progress toward PCI DSS; it does not replace the standard or the assessment. PCI SSC describes the approach as a roadmap with six milestones, rather than a shortcut to compliance. [PCI SSC: the Prioritized Approach]
My practical takeaway is that a starting roadmap needs an operating process behind it. Someone still needs to understand the next action, gather the supporting material and keep track of what remains unresolved.
The tool requires you to outline what is your plan towards the completion.
It looks like this:
- Outlines the requirements
- Current status
- Stage of implementation
- Estimated Date for Completion of Milestone
These obviously cannot be made up, and the team needs to understand the gaps before setting realistic completion dates as someone will need to do the implementation and be aware of the company's capabilities to produce something within a defined time frame.
That was the part of the engagement where a dedicated workspace became useful.
What the dashboard helped organize
PCI DSS Dashboard helped us keep the requirements and supporting work organized as the project developed. I was closely involved in onboarding because the team was new to PCI DSS.
That matters when describing the outcome honestly. This was a combination of software and hands-on help. The application gave us a structure; getting that structure set up for the company’s work required attention and discussion. We also got the clear insight into where we are, and how far away are we from the completion. The compliance status feature came in handy as we managed to adjust the pace through the process.
The value I saw was practical: keeping the PCI work coherent as the company moved from an initial request into the assessment process.
For a person carrying this responsibility alongside other work, that is an important job for a tool to do. A requirement needs context, the supporting material needs to be findable, and the next action needs to be clear.
Google Drive worked well in the process
One part of the setup that worked particularly well was the Google Drive integration.
The dashboard supports linking evidence and policy files from Drive to the relevant compliance work. That connects the documents with the requirements they support, while allowing the team to keep working with Drive.
A file link alone does not establish that a requirement is met. The document still needs to be relevant, current and supported by what the organization actually does. But connecting the material to its purpose makes the review conversation more useful.
That is the distinction I would look for in any evidence-management workflow: can the team explain what a document demonstrates, not just where it is stored?
What I would suggest to another service-provider CTO
If an acquirer has asked your company for PCI DSS evidence, clarify the expected deliverable early. Record the agreed scope and who is responsible for the work. Then establish a place where the requirements, supporting evidence and follow-up actions can stay connected.
Do not assume that avoiding direct card-data handling settles the question. Equally, do not assume that another provider’s assessment scope is the right template for your business.
Our experience showed me how useful an organized workspace can be for a team starting this process. It also reinforced the value of helping the team establish a workable routine around the software.
Working through a similar PCI DSS request? [Explore PCI DSS Dashboard] or email sales@pcidss-dashboard.com to arrange a walkthrough of the requirements, evidence and Google Drive workflow.
