Drafting and Negotiating PCI Clauses in ICT Contracts

1. Setting the Scene: Why PCI Clauses Matter in ICT Contracts

In 2022, PCI DSS 4.0 was released, and since then organizations have been transitioning from 3.2.1 to 4.0/4.0.1. As of early 2026, most serious merchants and service providers expect PCI 4.0‑aligned language in their contracts.

For ICT vendors (SaaS providers, cloud platforms, managed services, payment gateways):

• PCI compliance is not just a security issue – it is a contractual risk issue.
• Customers will try to push PCI obligations downstream into MSAs, SaaS agreements, DPAs/processing agreements, and security addenda.

In this module we focus on:

• Translating PCI DSS 4.0/4.0.1 requirements into contract clauses.
• Understanding who is responsible for what (scope, segmentation, integration points).
• Drafting evidence and audit provisions (ROC, AOC, SAQ, pen tests).
• Handling PCI changes over time (new versions, future‑dated requirements like those that became mandatory in March 2025).
• Negotiating so that obligations match your actual role and capabilities, not an idealized or unrealistic standard.

Keep in mind:

• PCI DSS is a private standard managed by the PCI Security Standards Council, not a law.
• But card brands and acquirers effectively make it mandatory via their contracts.
• Your ICT contracts must align with your PCI reality (what you actually do, your assessed scope, and your attestation type).

2. Map the PCI Role Before Drafting Clauses

You cannot draft or negotiate PCI clauses intelligently until you know what PCI role the company plays and what the assessed scope is.

Key questions to answer up front:

1. Are we a merchant, service provider, or both?

• Merchant: Accepts card payments for its own goods/services.
• Service provider: Stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD) on behalf of another entity.
• Many SaaS/ICT vendors are service providers if they touch CHD/SAD, but not if they are clearly out of scope (e.g., HR SaaS with no CHD).

1. What is our PCI validation method?

• ROC + AOC (Report on Compliance + Attestation of Compliance) – for larger or higher‑risk providers.
• SAQ (Self‑Assessment Questionnaire) – for smaller or lower‑risk environments.
• No PCI validation – if you are truly out of scope (no CHD/SAD, no security‑relevant connectivity to cardholder data environment (CDE)).

1. What is our PCI scope?

• Systems storing, processing, transmitting CHD/SAD.
• Systems connected to those systems (e.g., admin networks, logging systems).
• Any segmentation controls (firewalls, VLANs, proxies) that keep PCI and non‑PCI environments separate.

Once you know this, you can:

• Avoid signing clauses that overstate your role (e.g., calling you a PCI Level 1 service provider when you are not).
• Tailor clauses so that responsibilities map to your real scope.
• Decide what evidence (ROC, AOC, SAQ, pen test summary) you can realistically provide.

3. Example: Scoping and Role in Different ICT Deals

Consider three ICT vendors and how their PCI role shapes their contracts.

Example A – Payment Gateway (High PCI Involvement)

• Offers APIs that directly process card numbers.
• Maintains a cardholder data environment (CDE).
• Undergoes annual ROC + AOC.

Contract implications:

• Strong PCI compliance warranties.
• Detailed segmentation and integration clauses.
• Customer gets AOC and possibly ROC summary annually.

---

Example B – E‑commerce SaaS Platform (Redirect Model)

• Hosts storefront and checkout UI.
• Uses hosted payment page from a third‑party gateway; card data is entered directly on the gateway’s page.
• The platform never stores or transmits CHD.

Contract implications:

• Clauses clarifying that the platform is out of PCI scope for CHD, but may have security obligations (e.g., no injection of malicious scripts).
• Customer remains responsible for PCI compliance for its own systems and payment provider choice.
• Avoids pure "PCI DSS compliant" label; instead references security controls and no CHD handling.

---

Example C – Logging/Monitoring Provider Connected to CDE

• Collects logs and metrics from systems that are in the customer’s CDE.
• Provider’s systems are therefore in PCI scope (connected systems).
• Uses SAQ D for service providers.

Contract implications:

• Must acknowledge PCI scope in the agreement.
• Provides SAQ and external pen test summary instead of ROC.
• Segmentation and access control clauses specify limited access, encryption, and no CHD storage in logs.

Use these examples as patterns when you analyze your own or a hypothetical company’s role before drafting clauses.

4. Core PCI Contract Clauses: Warranties, Reps, and Covenants

Most PCI language falls into three buckets:

1. Representations (what is true today)

• Example: "Service Provider represents that, as of the Effective Date, it has implemented security controls aligned with PCI DSS version 4.0 for all systems in scope of its PCI assessment."

1. Warranties (promises about quality/compliance)

• Example: "Service Provider warrants that, during the Term, it will maintain PCI DSS compliance for those services identified as in-scope in Exhibit X."

1. Covenants/Obligations (ongoing actions)

• Example: "Service Provider shall undergo an annual PCI DSS assessment and provide Customer with a current Attestation of Compliance within 30 days of issuance."

---

Drafting Tips

• Be precise about scope
• Bad: "Service Provider shall be PCI DSS compliant."
• Better: "Service Provider shall maintain PCI DSS compliance for the in-scope services and systems described in Exhibit X (PCI Scope Description)."

• Tie obligations to actual assessment type
• If you only have SAQ D, don’t promise a ROC.
• State exactly what you will provide: "current SAQ D and passing external ASV scan reports".

• Avoid absolute guarantees
• Replace "will at all times be in full compliance" with

"will maintain controls reasonably designed to achieve and maintain PCI DSS compliance and will promptly remediate any identified gaps."

• Connect to change management (PCI 4.0 has ongoing change expectations)
• Include a clause that you will adapt controls as PCI requirements evolve, but avoid open‑ended, unlimited commitments (we’ll handle this more in Step 7).

5. Drafting Practice: Tightening an Overbroad PCI Warranty

You are counsel for a SaaS provider that does not store card data, but its app is integrated into customers’ e‑commerce flows. A customer proposes this clause:

> "Vendor shall at all times be fully PCI DSS compliant and guarantees that its services will ensure Customer’s PCI compliance."

Task

1. Identify two problems with this clause.
2. Rewrite it into a more realistic version that:

• Reflects that the vendor does not handle CHD directly.
• Commits to reasonable security and PCI‑relevant controls without guaranteeing the customer’s overall PCI compliance.

Write your improved clause in your own words. Then compare it with the sample answer below.

Sample answer (one possible approach):

> "Vendor does not store, process, or transmit cardholder data on behalf of Customer. Vendor shall maintain administrative, physical, and technical safeguards for the Services that are consistent with industry‑standard security practices and are reasonably designed to support Customer’s PCI DSS compliance for those portions of Customer’s cardholder data environment that interact with the Services. Vendor makes no representation or warranty regarding Customer’s overall PCI DSS compliance, which remains Customer’s responsibility."

Check whether your version:

• Avoids saying "fully PCI DSS compliant" when the vendor is not in direct PCI scope.
• Avoids guaranteeing the customer’s overall compliance.
• Still provides a meaningful security commitment.

6. Allocating PCI Scope, Segmentation, and Integration Responsibilities

PCI DSS 4.0 emphasizes clear responsibility assignment, especially for service providers. Contracts should mirror this.

Key areas to cover:

1. Scope Definition Clause

• Describe which components are in scope for each party.
• Example structure:
• Customer: POS terminals, internal networks, payment pages.
• Vendor: Hosted checkout module, card tokenization API.
• Out of scope: Vendor’s HR systems, generic marketing site.

1. Segmentation Responsibilities

• Who is responsible for network segmentation between CDE and non‑CDE systems?
• Typical pattern:
• Customer: Segmentation inside its own environment.
• Vendor: Segmentation within its own cloud/VPC and between PCI and non‑PCI tenants.

1. Integration Points (APIs, Webhooks, iFrames)

• Clarify who is responsible for secure integration:
• Secure API keys and secrets (often customer’s responsibility).
• Secure coding, authentication, and logging for the API (often vendor’s responsibility).
• Content Security Policy (CSP), iframe isolation, or redirect flows (shared, but must be spelled out).

1. Data Handling and Storage

• Explicitly state whether vendor stores CHD/SAD.
• If only tokens are stored, say so: "Vendor stores only tokens and transaction identifiers; no primary account numbers (PANs) are stored by Vendor."

These clauses help:

• Prevent customers from assuming the vendor is responsible for entire PCI scope.
• Show auditors that roles and responsibilities are documented, which aligns with PCI expectations for third‑party management.

7. Quick Check: Who Owns What in PCI Scope?

Test your understanding of scope and responsibility allocation.

8. Evidence, Attestation, and Audit Rights (ROC, AOC, SAQ, Pen Tests)

Customers often ask for broad audit rights and lots of PCI evidence. Your goal is to:

• Provide enough transparency for their PCI third‑party risk obligations.
• Avoid overly intrusive or operationally impossible commitments.

Common Evidence Types

• AOC (Attestation of Compliance) – summary form signed by QSA or self‑assessment signatory.
• ROC (Report on Compliance) – detailed report; often sensitive.
• SAQ (Self‑Assessment Questionnaire) – for smaller environments.
• ASV scan reports – external vulnerability scans.
• Penetration test summary – high‑level results, not full exploit details.

Sample Evidence Clause

> "Upon Customer’s written request no more than once annually, and subject to reasonable confidentiality obligations, Service Provider shall provide Customer with a copy of its then‑current PCI DSS Attestation of Compliance (and, if applicable, a high‑level executive summary of its most recent Report on Compliance), as well as a summary of any material PCI DSS findings that remain unresolved."

Audit Rights – Narrow but Effective

• Prefer document‑based audits first (AOC, policies, summaries).
• On‑site audits only if serious issues or regulatory requests arise.

Example limitation:

> "Customer may, no more than once per calendar year and upon thirty (30) days’ prior written notice, conduct a security audit limited to reviewing documents and facilities relevant to the Services’ PCI DSS in‑scope environment. Any on‑site audit shall be conducted during normal business hours, shall not unreasonably interfere with Service Provider’s operations, and shall be subject to Service Provider’s security and confidentiality requirements."

This balances customer assurance with operational practicality and confidentiality.

9. Managing PCI Changes and Future-Dated Requirements

PCI DSS 4.0 introduced many future‑dated requirements (some became mandatory in March 2025). Contracts need to handle evolving standards without creating impossible obligations.

Risks of Static PCI Clauses

• Hard‑coding a specific version (e.g., "PCI DSS 3.2.1") can make the clause obsolete.
• Open‑ended language (e.g., "all future PCI requirements, immediately") can be unrealistic and costly.

Balanced Versioning Clause

> "Service Provider shall maintain controls reasonably designed to comply with PCI DSS version 4.0, as updated from time to time by the PCI Security Standards Council. Service Provider shall implement new or revised PCI DSS requirements applicable to the Services within the timelines designated by the PCI Security Standards Council, taking into account any future‑dated effective dates."

Change Coordination

Add language about communication and impact:

> "If changes to PCI DSS result in material new obligations or significant cost increases for Service Provider, the parties shall in good faith discuss appropriate adjustments to the Services, timelines, or fees. Service Provider shall notify Customer of any material PCI DSS non‑compliance affecting the Services without undue delay upon becoming aware of such non‑compliance."

This approach:

• Commits you to stay aligned with PCI DSS.
• Links implementation to official PCI timelines (e.g., when future‑dated controls become mandatory).
• Builds in a mechanism to renegotiate if costs or obligations change dramatically.

10. Negotiation Strategy Scenarios: Pushing Back Without Saying No

Imagine you are negotiating on behalf of a cloud‑based payment service provider.

Scenario 1 – Overbroad Audit Rights

Customer’s draft:

> "Customer may audit all systems, facilities, and records of Vendor and its subcontractors at any time, with 5 days’ notice, to verify PCI DSS compliance."

Your task:

• Identify two risks with this language.
• Propose at least one limiting change (in your own words).

Sample considerations:

• Unlimited access to all systems, including non‑PCI environments.
• Ability to audit subcontractors directly, which you may not control.
• High operational burden and security risk.

Possible response:

> Limit audits to PCI‑in‑scope systems for the Services, no more than once per year, and require audits of subcontractors to be done through you, not directly.

---

Scenario 2 – Unrealistic Breach Notification

Customer’s draft:

> "Vendor shall notify Customer of any security incident within one (1) hour of occurrence."

Your task:

• Why might this be unrealistic in a PCI context?
• Suggest a more practical standard.

Sample considerations:

• You often don’t know about an incident the moment it happens.
• PCI DSS focuses on timely detection and response, but even regulators usually use language like "without undue delay" or "within 24–72 hours of confirmation".

Possible response:

> "Vendor shall notify Customer without undue delay and in any event within 24 hours of confirming a security incident that has resulted in unauthorized access to Customer Data within the PCI in‑scope environment."

Use these scenarios to practice reframing customer demands into commitments that are specific, feasible, and aligned with PCI reality.

11. Key PCI Contract Terms Review

Flip through these cards to reinforce the most important terms and ideas for drafting and negotiating PCI clauses.