IT and cloud providers with access to systems or data are listed, and their contracts carry security requirements

The entity must keep a list of every TPSP that receives account data from it or that could influence how safe that data is, and must describe the services each one provides. Applicability: using a PCI DSS compliant TPSP neither makes the entity compliant nor removes its own responsibility for compliance. Customized approach objective: records of TPSPs and the services they supply are kept.

evidence an assessor asks for TPSP inventory with service descriptions; Procedure for maintaining the TPSP list; Procurement or contract register reconciled to the list; Records of additions and removals

The entity must hold written agreements with every TPSP that receives its account data or could influence CDE security, and each agreement must contain the TPSP's acknowledgment that it answers for protecting the account data it holds, stores, processes or transmits for the entity, or to whatever extent it could affect the entity's sensitive authentication data or cardholder data. Applicability: exact wording depends on the service and allocated responsibilities and need not match the requirement text. An AOC, website declaration, policy statement, responsibility matrix or other evidence outside a written agreement does not count as a written acknowledgment. Objective under the customized approach: records exist of every TPSP's acknowledgment of its duty to protect account data.

evidence an assessor asks for Executed contracts or addenda with each in-scope TPSP; Security responsibility acknowledgment clauses; Contract review procedure; Tracker linking each listed TPSP to its agreement

Keep an inventory of service providers that lists every known provider, gives its classification or classifications, and names an enterprise contact for each. Revisit the inventory each year, or sooner when a major change in the enterprise could affect this Safeguard.

evidence an assessor asks for Service provider inventory listing each provider, its classification and the named enterprise contact; Record of the annual inventory review, with providers added, reclassified or removed; Accounts payable vendor list reconciled to the service provider inventory to find providers missing from it; Change or restructuring records that triggered an out-of-cycle inventory update, such as an acquisition or new cloud platform; Named contact entries checked against the HR directory, with leavers replaced

Make sure contracts with service providers carry security requirements, for example minimum requirements for the security programme, notification of and response to security incidents and/or data breaches, encryption of data, and commitments on data disposal. The requirements must align with the enterprise service provider management policy. Check the contracts each year to confirm no security requirement is missing.

evidence an assessor asks for Sample of service provider contracts with clauses on minimum security programme requirements, incident and breach notification, encryption and data disposal; Contract review checklist showing security clauses verified before signature; Annual contract review log listing each contract checked, missing security clauses found and the amendment raised; Standard security schedule or addendum template aligned to the service provider management policy; Amendment or side letter records adding breach notification timeframes to older contracts

Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties

evidence an assessor asks for Standard supplier security requirements catalog; Contract clause library with cyber obligations; Requirements tailoring guide by supplier tier; Negotiation log capturing accepted deviations; Contract management workflow with security review gate

The institution takes reasonable steps to select and retain service providers capable of maintaining appropriate safeguards for the customer information at issue.

evidence an assessor asks for Due diligence records for service providers with access to customer information

Service providers are required by contract to implement and maintain such safeguards.

evidence an assessor asks for Contract clauses requiring safeguards for customer information

The contract or other arrangement required by 164.308(b)(3) must meet the requirements of paragraph (a)(2)(i), (a)(2)(ii), or (a)(2)(iii) of this section, as applicable.

evidence an assessor asks for BAA template addressing all required 164.314(a)(2) elements; Government arrangement documentation where applicable; Special arrangement records (group health plan, plan sponsor); Subcontractor BAAs flowing down requirements; Legal review records for BAAs; Inventory of BAAs by type (BA, subcontractor, government); Procedures for negotiating BAA exceptions; Termination provisions evidence

Implement written policies and procedures for security of information systems and Nonpublic Information accessible to or held by Third Party Service Providers. Address identification and risk assessment, minimum cybersecurity practices, due diligence, periodic reassessment, and contractual representations on MFA, encryption, breach notice, and representations.

evidence an assessor asks for Third Party Service Provider policy; Vendor inventory with risk tiering; Due diligence questionnaires and evidence; Contract clauses for MFA, encryption, breach notice, and representations; Periodic vendor reassessment schedule and outputs; Termination and offboarding procedures; Subcontractor (fourth party) review evidence

The entity must keep a list of every TPSP that receives account data from it or that could influence how safe that data is, and must describe the services each one provides. Applicability: using a PCI DSS compliant TPSP neither makes the entity compliant nor removes its own responsibility for compliance. Customized approach objective: records of TPSPs and the services they supply are kept.

evidence an assessor asks for TPSP inventory with service descriptions; Procedure for maintaining the TPSP list; Procurement or contract register reconciled to the list; Records of additions and removals

The entity must hold written agreements with every TPSP that receives its account data or could influence CDE security, and each agreement must contain the TPSP's acknowledgment that it answers for protecting the account data it holds, stores, processes or transmits for the entity, or to whatever extent it could affect the entity's sensitive authentication data or cardholder data. Applicability: exact wording depends on the service and allocated responsibilities and need not match the requirement text. An AOC, website declaration, policy statement, responsibility matrix or other evidence outside a written agreement does not count as a written acknowledgment. Objective under the customized approach: records exist of every TPSP's acknowledgment of its duty to protect account data.

evidence an assessor asks for Executed contracts or addenda with each in-scope TPSP; Security responsibility acknowledgment clauses; Contract review procedure; Tracker linking each listed TPSP to its agreement

The entity must keep a list of every TPSP that receives account data from it or that could influence how safe that data is, and must describe the services each one provides. Applicability: using a PCI DSS compliant TPSP neither makes the entity compliant nor removes its own responsibility for compliance. Customized approach objective: records of TPSPs and the services they supply are kept.

evidence an assessor asks for TPSP inventory with service descriptions; Procedure for maintaining the TPSP list; Procurement or contract register reconciled to the list; Records of additions and removals

The entity must hold written agreements with every TPSP that receives its account data or could influence CDE security, and each agreement must contain the TPSP's acknowledgment that it answers for protecting the account data it holds, stores, processes or transmits for the entity, or to whatever extent it could affect the entity's sensitive authentication data or cardholder data. Applicability: exact wording depends on the service and allocated responsibilities and need not match the requirement text. An AOC, website declaration, policy statement, responsibility matrix or other evidence outside a written agreement does not count as a written acknowledgment. Objective under the customized approach: records exist of every TPSP's acknowledgment of its duty to protect account data.

evidence an assessor asks for Executed contracts or addenda with each in-scope TPSP; Security responsibility acknowledgment clauses; Contract review procedure; Tracker linking each listed TPSP to its agreement

The organization is to define and run processes and procedures that manage the information security risks arising from using suppliers' products or services. Purpose (stated in ISO/IEC 27002:2022): keeps security in supplier dealings at the level agreed with the supplier. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 5.19.

evidence an assessor asks for Statement of Applicability entry for control A.5.19, showing inclusion or justified exclusion, implementation status and the risks it treats; The topic-specific supplier relationship policy and its communication record; A supplier inventory categorized by type and by the information, services and infrastructure each can access; Supplier due diligence and selection records such as questionnaires, certifications, references and on-site assessment reports, scaled to sensitivity; Supplier risk assessments covering misuse of organizational assets and product or component vulnerabilities

The information security requirements that matter for each supplier are to be set and agreed with that supplier, depending on the type of relationship. Purpose (stated in ISO/IEC 27002:2022): makes the agreed security level for each supplier binding through written terms. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 5.20.

evidence an assessor asks for Statement of Applicability entry for control A.5.20, showing inclusion or justified exclusion, implementation status and the risks it treats; Supplier agreements containing security clauses proportionate to the relationship, such as classification mapping, agreed controls, incident notification, subcontracting, right to audit and termination terms; A register of contracts, memoranda and information-sharing arrangements with outside parties showing what information each covers and when it was last reviewed; Minimum security requirement templates per information type and access type used as the basis for individual contracts; Supplier-provided attestations or independent control effectiveness reports and records of issues raised and corrected