Who is accountable when third-party vendors mishandle cardholder data retention or masking requirements?

Why This Matters for Security Teams

When a vendor mishandles cardholder data retention or masking, the immediate failure is often technical, but the accountability is operational and contractual. PCI DSS expectations do not disappear because a processor, managed service provider, or SaaS platform is involved. The organisation that stores, processes, or transmits cardholder data still has to prove that retention limits, masking rules, and access controls are enforced, not merely promised. The PCI Security Standards Council makes this ownership model explicit in its PCI DSS v4.0 — PCI Security Standards Council materials.

Security teams commonly get this wrong by assuming a vendor attestation, contract clause, or certification shifts the compliance burden away from the cardholder data environment. It does not. The business remains responsible for scoping, monitoring, and validating that the vendor’s controls are aligned with the organisation’s retention and masking requirements. That includes reviewing how data is stored, how long it persists, who can re-identify it, and whether logs, exports, or backups are covered by the same rules. In practice, many security teams encounter the breach in accountability only after an audit finding or incident has already exposed the gap between policy and vendor reality.

How It Works in Practice

Accountability works best when it is assigned across three layers: policy ownership, control operation, and evidence production. Policy ownership defines what the organisation expects for retention periods, masking format, exception handling, and deletion. Control operation determines which team or vendor actually enforces those requirements in systems, APIs, exports, backups, and support workflows. Evidence production proves the controls are working through configuration reviews, logs, test results, and periodic access checks.

For cardholder data, this usually means the organisation must confirm that vendors can:

• mask primary account numbers wherever full values are not operationally required
• limit retention to the minimum approved period
• prevent unauthorized re-identification of masked data
• apply the same protections to replicas, backups, and analytics copies
• provide audit evidence that retention and masking rules are actually enforced

From a control perspective, NIST guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for translating this into assignments around access control, data minimization, audit logging, and system integrity. That is especially important where third-party platforms introduce API keys, service accounts, automation tokens, or other non-human identities that can move sensitive data at scale. The OWASP Non-Human Identity Top 10 is relevant here because many masking failures are not caused by a person bypassing policy, but by an over-privileged integration account, pipeline, or agent with broad data access.

The practical test is simple: if the vendor cannot show where cardholder data lives, who can access it, and how masking is enforced across every copy, the organisation has not transferred risk, only outsourced part of the execution. These controls tend to break down in multi-tenant SaaS environments because retention defaults, backup retention, and shared support access often exceed the buyer’s approved data handling rules.

Common Variations and Edge Cases

Tighter masking and retention controls often increase operational overhead, requiring organisations to balance compliance assurance against supportability, analytics value, and incident response needs. That tradeoff becomes visible in environments where fraud teams need partial visibility, customer service teams need selective reveal workflows, or legal holds override deletion schedules.

Current guidance suggests treating those exceptions as explicitly approved, time-bound, and logged rather than as informal workarounds. If the business needs tokenised or partially masked card data for legitimate operations, the exception should be narrowly scoped and reviewed against PCI DSS v4.0 requirements, not left to vendor discretion. Teams should also confirm whether the vendor’s subcontractors, backup providers, and managed support channels are inside the same control boundary, because compliance gaps often appear in those downstream dependencies.

There is no universal standard for every edge case, especially when retention interacts with cross-border processing, shared platforms, or product analytics. In those cases, the safest approach is to define the minimum retained dataset, the exact masking standard, the system of record for deletion, and the evidence required to prove enforcement. Where vendors use autonomous tooling to move, classify, or redact cardholder data, the accountability question expands into non-human identity governance: the organisation still owns the outcome, even if a machine identity executed the action.

Related resources from NHI Mgmt Group

• Who is accountable when a third-party verification provider mishandles identity data?
• Why do third-party vendors increase healthcare data security risk?
• Who is accountable when third-party access to personal data persists too long?
• Who is accountable when third-party SaaS mishandles company data?