Vendor Management Policy — Third-Party Service Provider (TPSP) Management

1. Purpose

This policy establishes the requirements for managing third-party service providers (TPSPs) that store, process, or transmit cardholder data (CHD) or that could affect the security of the Cardholder Data Environment (CDE) for Gatelithix Gateway. It ensures Paylithix Inc. meets PCI DSS 4.0.1 Requirements 12.8 and 12.9 and maintains appropriate oversight of all service provider relationships.

As a Level 1 Service Provider, Paylithix Inc. has a dual obligation: we must manage our own TPSPs (Req 12.8) and we must support our merchants’ PCI DSS compliance efforts (Req 12.9).

2. Scope

This policy applies to all third-party service providers that:

• Store, process, or transmit cardholder data on behalf of Paylithix Inc.
• Could affect the security of the CDE (e.g., infrastructure providers, authentication services)
• Provide services that are within or connected to the PCI DSS assessment scope

This includes payment processors, cloud infrastructure providers, identity providers, DNS/CDN providers, and source code/CI platforms.

2.1 Exclusions

The following are out of scope for this policy:

• Vendors that provide only general office productivity tools with no access to CHD or CDE systems
• Vendors whose services are entirely isolated from the CDE and connected systems

3. TPSP Classification

All TPSPs are classified into tiers based on their level of access to cardholder data and their potential impact on CDE security.

Tier 1 — Direct CHD Access

TPSPs that directly store, process, or transmit cardholder data. These represent the highest risk and require the most rigorous oversight.

Characteristics:

• Receive raw or tokenized PAN during payment processing
• Must maintain their own PCI DSS compliance
• A compromise at this TPSP could directly expose cardholder data

Current Tier 1 TPSPs: Stripe, NMI, FluidPay (deprecation track). TSYS planned (next connector — Transnox REST API).

Tier 2 — CDE Infrastructure

TPSPs that provide infrastructure or services within or directly connected to the CDE. They do not handle raw PAN in the clear but host systems that do.

Characteristics:

• Provide compute, storage, networking, or security services for CDE components
• Have access to encrypted cardholder data at rest or provide the encryption infrastructure
• A compromise could affect CDE availability or integrity

Current Tier 2 TPSPs: Google Cloud Platform, Auth0 (Okta)

Tier 3 — Indirect / Supporting Services

TPSPs that provide services connected to the assessment scope but do not directly access CHD or CDE infrastructure.

Characteristics:

• Provide edge networking, DNS, source code hosting, or CI/CD services
• No direct access to cardholder data (encrypted or otherwise)
• A compromise could indirectly affect security posture (e.g., code integrity, DNS hijacking)

Current Tier 3 TPSPs: Cloudflare, GitHub

4. TPSP Inventory

The Information Security Officer (ISO) maintains the authoritative inventory of all TPSPs. This inventory is reviewed and updated at least annually and whenever a new TPSP is engaged or an existing one is terminated. (PCI DSS 12.8.1)

4.1 Current TPSP Inventory

4.2 Inventory Maintenance

The inventory must be updated within 5 business days when:

• A new TPSP is engaged
• A TPSP’s services, tier classification, or CHD access changes
• A TPSP is terminated or replaced
• A TPSP’s compliance status changes (e.g., AOC expires, breach disclosed)

5. Onboarding — Due Diligence Process

Before engaging any new TPSP that will be in scope for PCI DSS, the following due diligence must be completed. (PCI DSS 12.8.3)

5.1 Due Diligence Checklist

5.2 Approval Process

1. The requestor (typically Engineering Lead) identifies the need for a new TPSP and completes the due diligence checklist.
2. The ISO reviews the completed checklist and compliance documentation.
3. For Tier 1 and Tier 2 TPSPs, the CEO must approve the engagement.
4. For Tier 3 TPSPs, the ISO may approve the engagement.
5. Once approved, the TPSP is added to the inventory and a written agreement is executed.

6. Written Agreements

Every TPSP must have a written agreement in place that includes the following clauses. (PCI DSS 12.8.2)

6.1 Required Contract Clauses

All TPSP agreements must include:

1. PCI DSS Responsibility Acknowledgment — The TPSP acknowledges in writing that it is responsible for the security of account data it possesses or otherwise stores, processes, or transmits on behalf of Paylithix Inc. (PCI DSS 12.8.2)
2. Scope of Services — Clear description of services provided and data accessed.
3. Compliance Obligations — Requirement to maintain PCI DSS compliance (Tier 1) or equivalent security standards (Tier 2/3) for the duration of the agreement.
4. Breach Notification — Obligation to notify Paylithix Inc. within 72 hours of discovering any security incident that could affect our data or CDE security.
5. Right to Audit — Paylithix Inc. retains the right to request compliance evidence, including AOC, SOC 2 reports, and penetration test summaries.
6. Evidence Provision — The TPSP will provide updated compliance evidence (AOC, SOC 2) annually or upon request.
7. Data Return/Destruction — Upon termination, the TPSP will securely destroy or return all Paylithix data within an agreed timeframe.
8. Subprocessor Notification — The TPSP will notify Paylithix of any material changes to subprocessors handling our data.

6.2 Agreement Tracking

For each TPSP, the ISO maintains a record of:

• Agreement effective date and renewal date
• PCI responsibility acknowledgment (signed or incorporated into terms of service)
• Key contact for compliance inquiries
• Date of last compliance evidence received

7. Compliance Evidence Requirements

7.1 Evidence by Tier

7.2 Evidence Storage

All TPSP compliance evidence is stored in:

• Primary: compliance/evidence/tpsp/ directory, organized by TPSP name
• Naming convention: {tpsp-name}-{document-type}-{YYYY}.{ext} (e.g., stripe-aoc-2026.pdf)
• Retention: Current year plus 3 prior years (matching PCI evidence retention requirements)

7.3 Acceptable Evidence Forms

• PCI DSS AOC: Official Attestation of Compliance signed by QSA or internal assessor
• SOC 2 Type II: Report from accredited CPA firm covering the most recent 12-month period
• Contractual Acknowledgment: Signed agreement clause acknowledging PCI responsibility (acceptable when AOC is not available, primarily for Tier 3 TPSPs)
• Card Brand Registry Listing: Active listing on Visa Global Registry or Mastercard SDP list (supplementary evidence for Tier 1)

8. Annual Review Process

All TPSP relationships are reviewed at least once every 12 months. (PCI DSS 12.8.4)

8.1 Annual Review Checklist

For each TPSP, the ISO completes the following during the annual review:

8.2 Review Schedule

• Annual review window: April of each year (aligned with policy review cycle)
• Interim reviews: Triggered by TPSP breach disclosure, material service change, or compliance status change
• Documentation: Review results are recorded in compliance/evidence/tpsp/annual-review-{YYYY}.md

9. Responsibility Matrix

This section documents which PCI DSS requirements are managed by each TPSP versus Paylithix Inc. (PCI DSS 12.8.5)

9.1 Google Cloud Platform

9.2 Payment Processors (Stripe, NMI, FluidPay; TSYS planned)

9.3 Auth0 (Okta)

9.4 Cloudflare

9.5 GitHub

10. Incident Notification

10.1 TPSP Breach Notification Requirements

All TPSP agreements require notification to Paylithix Inc. within 72 hours of the TPSP discovering any security incident that:

• Involves unauthorized access to cardholder data processed on behalf of Paylithix
• Affects the security, integrity, or availability of systems in our CDE
• Results in unauthorized access to Paylithix credentials, tokens, or API keys
• Involves a TPSP subprocessor that handles our data

10.2 Paylithix Response to TPSP Incidents

Upon receiving notification of a TPSP security incident:

1. Immediate (0-4 hours): ISO assesses the incident and determines if Paylithix cardholder data is affected. Activate the Incident Response Plan (POL-005) if warranted.
2. Short-term (4-48 hours): Determine scope of exposure. Rotate any potentially compromised credentials (API keys, webhook secrets). Notify affected merchants if required.
3. Medium-term (48 hours - 2 weeks): Monitor for indicators of compromise. Work with TPSP to understand root cause. Assess whether the TPSP should be suspended or replaced.
4. Long-term: Update risk assessment. Re-evaluate TPSP tier classification. Document lessons learned.

10.3 Proactive Monitoring

The ISO monitors the following sources for TPSP security information:

• TPSP status pages and security advisories
• Security news outlets (e.g., Krebs on Security, BleepingComputer)
• PCI SSC bulletins and alerts
• TPSP compliance status changes on Visa/Mastercard registries

11. Termination Criteria

A TPSP must be evaluated for termination or replacement when any of the following occur:

11.1 Mandatory Review Triggers

• The TPSP’s PCI DSS AOC expires and is not renewed within 90 days
• The TPSP discloses a breach involving cardholder data
• The TPSP refuses to provide compliance evidence upon request
• The TPSP fails to execute or renew the required written agreement
• The TPSP’s services are no longer needed

11.2 Termination Process

1. Assessment: ISO evaluates the risk and impact of continuing vs. terminating the relationship.
2. Notification: Provide written notice per the agreement terms.
3. Migration Plan: For Tier 1 and Tier 2 TPSPs, develop a migration plan before termination (these are critical services).
4. Data Handling: Confirm the TPSP will destroy or return all Paylithix data per the agreement.
5. Credential Rotation: Rotate all API keys, tokens, and credentials associated with the TPSP.
6. Inventory Update: Remove the TPSP from the inventory and update all documentation.
7. Post-Termination Verification: Confirm no residual data access or connectivity exists.

12. Our Obligations as a Service Provider

As a PCI DSS Level 1 Service Provider, Paylithix Inc. has specific obligations to our merchant customers. (PCI DSS 12.9)

12.1 Written Acknowledgment to Merchants (PCI DSS 12.9.1)

Paylithix Inc. provides written acknowledgment to each merchant that we are responsible for the security of cardholder data we possess, store, process, or transmit on behalf of that merchant. This acknowledgment is:

• Included in the merchant services agreement
• Available upon request from the merchant
• Updated when our PCI DSS scope or responsibilities change materially

12.2 Supporting Merchant PCI Compliance (PCI DSS 12.9.2)

Paylithix Inc. supports merchants’ PCI DSS compliance efforts by:

• Providing our current AOC upon request (within 10 business days)
• Providing information about which PCI DSS requirements we manage on the merchant’s behalf
• Responding to merchant inquiries about our security practices relevant to their PCI assessment
• Notifying merchants of any security incidents that may affect their cardholder data (per Section 10)

Contact for merchant PCI inquiries: compliance@gatelithix.com

13. Compliance and Enforcement

1. Compliance with this policy is mandatory for all personnel involved in TPSP selection, management, or oversight.
2. Engaging a TPSP without completing the required due diligence process is a policy violation and must be reported to the ISO.
3. The ISO reports TPSP compliance status to the CEO as part of the quarterly PCI compliance review (PCI DSS 12.4.2).

14. Related Documents

• Information Security Policy (POL-001) — Parent policy
• Incident Response Plan (POL-005) — Activated for TPSP security incidents
• PCI DSS v4.0.1 Control Matrix — Requirements 12.8 and 12.9 tracking
• PCI Compliance Architecture Guide  — CDE architecture and shared responsibility model
• PCI DSS v4.0.1 Standard, Requirements 12.8 and 12.9 (PCI Security Standards Council)

15. Document History