Passing your PCI assessment feels like finishing something.
Everyone survived the evidence requests.
The interviews are over.
The screenshots have been uploaded.
The policies have been approved.
The QSA has stopped appearing on your calendar.
Somebody probably says:
"Great. PCI is done."
No.
The assessment is done.
PCI is still sitting there.
Your PCI assessment is not your PCI program.
That distinction is where a surprising amount of organizational pain begins.
An assessment is a validation exercise. It is a period when your organization demonstrates that applicable PCI DSS requirements are being met and provides the documentation, evidence, explanations, and testing necessary to support that conclusion.
Your PCI program is everything that has to keep happening after the assessment ends.
Controls still need to operate.
Evidence still needs to be retained.
Policies still need to describe reality.
Access reviews still need to happen.
Testing still needs to happen.
Vendors still need oversight.
Scope still needs to be understood.
Changes still need to be evaluated.
Gaps still need remediation.
People still need to know what they own.
None of that politely stops because the assessor closed the project.
PCI is one of those programs that looks like it belongs to one department until you actually examine how the company operates.
Security may own technical controls.
Engineering owns applications, infrastructure, configurations, deployments, and architecture.
Compliance may manage the assessment calendar and communication with the assessor.
Product changes payment flows.
Operations owns procedures.
Legal owns contracts and customer commitments.
Vendor management deals with service providers.
Human resources may own pieces of training and personnel processes.
Leadership ultimately owns the risk, resources, and decisions.
Everybody owns something.
Which sounds collaborative.
Until you ask one question:
Who owns the whole PCI program?
Sometimes the room gets suspiciously quiet.
That is the problem.
Distributed control ownership is normal.
Distributed program ownership is chaos wearing a responsibility matrix.
A company can successfully complete an assessment even when the operating model behind PCI is fragile.
Assessment season creates urgency.
People respond to requests.
Documents get updated.
Missing evidence gets hunted down.
Meetings suddenly become easy to schedule.
Old diagrams receive miraculous amounts of attention.
Compliance becomes everyone's favorite department for approximately three weeks.
Then the assessment ends.
Everyone returns to the work that normally feels more urgent.
Product has a roadmap.
Engineering has releases.
Security has actual threats to deal with.
Operations has customers.
Legal has contracts.
Somebody changes jobs.
Somebody adds a vendor.
Somebody launches a new payment flow.
Somebody modifies infrastructure.
And PCI quietly begins drifting away from the environment that was just assessed.
The next assessment arrives.
Now everyone has to reconstruct what happened during the previous year.
Where is the access review from February?
Who approved this policy?
Did we ever update the network diagram?
Was that vendor included in scope?
When did this system move to the cloud?
Who owns this control now?
Did we document that change?
Does anyone still have the screenshot?
Wasn't Steve handling that?
Steve left eight months ago.
Excellent.
This is how an assessment turns into an archaeological expedition.
People are digging through ticketing systems, shared drives, inboxes, spreadsheets, old Slack conversations, screenshots, and the institutional memory of whoever has been around longest.
That is not governance.
That is reconstruction.
The reason programs drift is rarely because nobody cares.
Usually the opposite is true.
The people involved are busy doing legitimate work.
Engineering is shipping products.
Security is managing risk.
Operations is keeping customers alive.
Legal is negotiating agreements.
Compliance is managing multiple obligations.
Leadership is running the business.
PCI gets squeezed between everything else.
And because responsibility is fragmented, no single person necessarily sees that five individually reasonable delays have collectively created a program problem.
The access review is late.
A policy has not been updated.
A new vendor has not been evaluated.
Evidence is missing.
An old remediation item is still open.
A product change may have affected scope.
Each problem belongs to somebody.
The combined problem belongs to nobody.
Until assessment season.
Then suddenly it belongs to everybody.
This distinction matters.
The person responsible for operating a firewall does not necessarily need to run the PCI program.
The engineer responsible for secure software development does not need to coordinate every PCI requirement.
Legal does not need to track quarterly security activities.
Compliance should not have to personally perform every technical control.
What organizations need is centralized coordination.
Someone has to maintain the calendar.
Someone has to know who owns each responsibility.
Someone has to follow up when evidence is missing.
Someone has to notice when a control owner changes jobs.
Someone has to connect business and technical changes back to PCI scope.
Someone has to track remediation.
Someone has to escalate issues while there is still time to fix them.
Someone has to maintain the story of the program from one assessment to the next.
The work can remain distributed.
The accountability for keeping the program coordinated cannot disappear with it.
One of the biggest problems with treating PCI as an annual event is that your environment probably does not remain frozen for a year.
Companies launch products.
They change processors.
They introduce new payment channels.
They adopt new cloud services.
They replace systems.
They add vendors.
They reorganize teams.
They change administrative access.
They acquire companies.
They modify APIs.
They change how cardholder data moves through the environment.
Every one of those decisions can potentially affect the assumptions underneath the previous assessment.
A functioning PCI program asks the PCI question while those changes are happening.
Not eleven months later when someone notices the diagram still shows a system that disappeared before Thanksgiving.
Evidence management is another place where assessment thinking and program thinking look very different.
Assessment thinking says:
The QSA wants evidence. Go find it.
Program thinking says:
The activity happened. Store the evidence now.
That sounds painfully obvious.
Yet huge amounts of assessment effort are spent trying to prove that something happened months ago.
Screenshots disappear.
Reports get overwritten.
Tickets are difficult to find.
Employees leave.
Systems change.
Context disappears.
The evidence that would have taken thirty seconds to retain in March now requires three meetings and a minor investigation in September.
PCI has enough requirements already.
There is no reason to add digital archaeology to the list.
One of the most dangerous assumptions in compliance is:
"We passed last year."
Good.
What happened since then?
Did your systems change?
Did your staff change?
Did your vendors change?
Did your products change?
Did your data flows change?
Did your policies change?
Did your controls continue operating?
Can you still produce the evidence?
Do the people currently responsible for the controls even know they are responsible?
Passing an assessment tells you something important about the environment and evidence that were evaluated.
It does not freeze the company in amber.
A mature PCI program should be surprisingly boring.
Activities happen when they are scheduled.
Evidence is stored when it is produced.
Owners know what they own.
Policies stay reasonably aligned with reality.
Changes are evaluated when they occur.
Gaps are documented.
Remediation is tracked.
Leadership hears about meaningful problems before the deadline becomes an emergency.
And when the next assessment begins, the organization is not reconstructing the previous year.
It is presenting it.
That is a very different experience.
The assessment becomes confirmation that the program has been operating.
Which is exactly what it should be.
PCI will always be cross-functional.
It should be.
The requirements touch too many different systems, processes, people, and business activities for one department to perform everything.
But cross-functional does not mean ownerless.
Security can own controls.
Engineering can own systems.
Operations can own procedures.
Compliance can own requirements.
Legal can own contracts.
Vendors can own their obligations.
Leadership can own risk decisions.
Somebody still needs to connect all of it.
Because if everyone owns a piece of PCI and nobody owns the program, the annual assessment eventually becomes the moment when the organization discovers everything that happened while nobody was watching.
Your PCI assessment is not your PCI program.
It should simply be the part where you prove the program has been there all along.