Third Party Risk Management in the Retail Sector

    Third Party Risk Management in the Retail Sector

    Sector Specific Processing

    Retailers are subject to numerous regulations around the globe covering security and privacy of customers’ data. The exact steps to retail compliance will vary depending on what organizations sell and where. Regardless of the products offered, where there are electronic payments and multiple parties are involved in the dissemination of services within a value chain, Vendor Risk Management is a crucial aspect for global compliance.


    The current capabilities for the digital design of business ecosystems allow for a group of various providers to interact and offer services simultaneously, creating what has been dubbed an “ecosystem” of providers where the dissemination of interconnected service systems contain several organisations in the value chain. Actors in the ecosystem can interact in at least three different ways. They can engage horizontally (e.g. multiple actors provide different services to a controller or group of controllers), they can engage vertically (e.g. where a controller has engaged a processor – or several – who, in turn, has contracted sub-processors for certain operations), and the more complex scenarios involve a network of actors so intertwined that can blur the line dividing the obligations and responsibilities of each one.


    In this ecosystem, the security of financial information and obligations for the lawful processing of personal data are inextricably linked. One way to cope with Vendor Risk Management activities in complex digital retail ecosystems is to embed Privacy by Design into the architecture, business processes, Information Systems used, and so on. Embedding Privacy by Design means observing 7 interrelated principles (being proactive, embedding privacy into the design, set Privacy as a default setting, full functionality, implementation of end-to-end security, visibility and transparency, and respect for the user).


    Below we detail some of the most prominent laws governing third-party risk review and management in the digital retail ecosystem, as well as How OneTrust Helps in successfully addressing the challenges posed.

    Please bear in mind that throughout this entry we use the terms “contractor”, “vendor” and “third party” interchangeably.

    Last Updated: July 8, 2019

  • Global Compliance

    U.S. Payment Card Industry Data Security Standard (PCI DSS)

    The Payment Card Industry Data Security Standard (PCI DSS) was founded in the U.S. by American Express, Discover Financial Services, JCB International, MasterCard and Visa. PCI DSS is one of the six PCI Security Standards published by the PCI Council. The PCI Security Standards aim to cover every aspect of the payment card industry including the manufacture of PIN entry devices, payment application software development, as well as the secure environment when payment card services are provided. It applies globally to any entity or third-party service providers that store, process or transmit cardholder, regardless of the organization’s size or the number of transactions.

    Under PCI DSS, a service provider (third-party) is defined as a “business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of transactions and cardholder data. Examples include managed service providers that enable firewalls, IDS and other services as well as hosting providers and other entities.”

    The Third Party Security Assurance (TPSA) published by the PCI Council provides guidance on the way entities that engage third-parties can identify, evaluate, and manage risks. The TPSA recommends developing clear policies and procedures between an entity and third-party service providers to satisfy security and reporting requirements under the PCI DSS. Service providers can ensure a third-party’s resource and sufficient security controls through external validation documents or payment card brands that have pre-approved a third-party. Validation documents include Report of Compliance (ROC), Attestation of Compliance (AOC) or Self-Assessment Questionnaire (SAQ) along with Attestation of Compliance, ASV Scan Report Attestation of Scan Compliance (AOSC).

    For additional details on PCI DSS, click here.

  • North America

    Canada PIPEDA

    The Personal Information Protection and Electronic Documents Act (PIPEDA) applies to the collection, use, or disclosure of personal information in the course of a commercial activity which includes personal health information. PIPEDA applies 1) organizations that collect, use, or disclose personal information in the course of commercial activities; or 2) organizations that collect personal data of employees of, or applicants for employment, and which the organization uses or discloses in connection with the operation of a federal work, undertaking or business.

    PIPEDA defines “personal information” as any “information about an identifiable individual.” Financial information that customers provide (e.g.) to merchants, will fall under this definition.

    Although PIPEDA does not distinguish between general third-parties (e.g. individuals gaining access, processors, and vendors, in the strict sense (such as the GDPR does), there are several obligations that must be observed when the processing operations are carried out by third parties. According to Principle 1 (Accountability), the organization is responsible for personal information in its possession or custody, including information transferred to a third party. The organization must use contractual or other means to provide a comparable level of protection while the information is being processed by a third party. The contractual instrument governing the processing of personal data by third parties should include policies and practices required to operationalize the principles laid down in PIPEDA.

    In addition, organizations engaging third-parties to process financial information should also be mindful of the requirements under the PCI DSS as it applies globally to any controller or third-party service provider that stores, processes or transmits cardholder information.

    For additional details on PIPEDA, click here.

  • European Union

    The European Union (EU) created the Single Euro Payment Area (SEPA) to harmonize payments across the European Economic Area. There are several intertwined laws that operationalize SEPA. These include Directive Directive 2015/2366 on EU-wide payment services, SEPA Regulation No 260/2012 on establishing technical and business requirements for credit transfers and direct debits in euro, Regulation (EC) No 924/2009 on uniform fees for processing of cross-border payments. In particular, Directive 2015/2366 (the Directive) lays down requirements for entities providing payment services in the European Economic Area, including registration with the appropriate authority, security control requirements for the entity and its agents, and incident reporting requirements.

    Directive 2015/2366 interacts with the GDPR because the transactions foreseen in the Directive involve the processing of personal data. The interplay of both laws addresses security and data protection requirements for entities that intend to engage third-party service providers (“Agent”) in payment services. An “Agent” under the Directive is “a natural or legal person who acts on behalf of a payment institution in providing payment services.” Effectively, a processor in the light of Article 28 of the GDPR.

    Under Directive 2015/2366, a payment service provider is required to register with the competent authority by filing an application with various information about its establishment, activity, and information about agents it intends to use. The entity is also required to include information about the agent’s internal controls imposed by laws regulating money laundering and the funding of criminal or terrorist organizations.  When a payment institution engages an “Agent”, the security and data protection requirements imposed by both the Directive and the GDPR requirements have to be observed by the third party. The onus is on the payment institution to make sure that “Agents” comply with all data protection and security requirements.

    The GDPR outlines vendor management responsibilities in Articles 24, 28, 29, and 46. There is shared liability for companies using vendors (processors) to process data, and organizations should look to have the correct protections in place. To be more specific, the GDPR holds companies and their vendors (controllers and processors) jointly liable. Therefore, it is critical to analyze vendor data transfers and contractual obligations with the same level of diligence as internal processing activities to have a defensible posture in the unfortunate event that a supplier or vendor has a breach.

    In addition, the payment institution should also be mindful of the requirements under PCI DSS if it uses one of the payment card brands such as Visa, MasterCard. In that case, payment institutions may be required to use mechanisms such as AOC or SAQ to ensure agents have adequate security controls.

    For additional details on GDPR, click here.

  • South America

    Brazil LGPD

    The Brazilian General Data Protection Law (‘lei geral e única de proteção de dados pessoais’ – “LGPD”) becomes effective on August 14, 2020, and is the first omnibus comprehensive Brazilian privacy legislation. The LGPD adopts a number of principles coming from the EU privacy laws. The LGPD aims to provide a strong uniform level of protection to the personal information of data subjects located in Brazil and to ensure implementation of safeguards for the processing and international transfers of personal data. Under LGPD, personal data means “information related to an identified or identifiable natural person.” This definition of personal data would include personal information that is provided to financial institutions, payment processors and merchants.

    In general terms, the LGPD requires controllers to verify that their contractors adhere to the controller’s data processing instructions and that they comply with the rules governing the processing of personal data. Strictly speaking, until LGDP becomes effective, there are no specific laws and regulations for the protection of consumers data when financial institutions engage third-parties for processing electronic payment. However, there are processors that provide payment processing services and solutions to merchants that comply with the PCI DSS.

    For additional details on LGPD, click here.

  • Africa

    South Africa POPIA

    South Africa signed the Protection of Personal Information Act (POPIA) into law on 19 November 2013. The purpose of the Act is to elevate the level of data protection and privacy standards in South Africa. Under the POPIA, financial information relating to a natural person falls under the definition of “personal information.”

    Among other common obligations, POPIA indicates that, by means of a binding contract, controllers must ensure that processors implement and maintain security measures. In addition, processors can only process personal data with the knowledge or authorization of the controller, and such data ought to be treated confidentially. These obligations also have to be stipulated in a contract.

    Although there are no specific laws and regulations for the protection of consumer data when financial institutions engage third-parties to process electronic payments. In addition, controllers and merchants should also be mindful of the requirements under the PCI DSS as it applies globally to any organization or third-party service providers that store, process or transmit cardholder, regardless of the organization’s size.

    For additional details on POPIA, click here.

  • Asia Pacific

    Singapore PDPA

    The Singapore Personal Data Protection Act (PDPA) sets a baseline standard of protection for personal data across Singapore’s economy by complementing sector-specific legislative and regulatory frameworks. This means that organizations will have to comply with the PDPA as well as the common law and other relevant laws that are applied to the specific industry that they belong to when handling personal data in their possession. There are, however, no sub-set regulation for the financial industry that compliments the PDPA.

    Processing of personal data in the financial industry is regulated solely by the PDPA. Under PDPA, personal data is defined as any data that can identify a person. Financial information of a person provided to financial institutions, payment processors and merchants will fall under this definition.

    Although there is no explicit mention of the obligation of organizations (controllers) to engage their vendors with a legally binding instrument (e.g. a contract), Section 4.2 stipulates that data processors (“data intermediaries”) processing personal data on behalf of a controller will be subject to the security obligations (“protection obligation”) and to the retention limitation obligation. The interpretation of this provision could be stretched understand that there is an implicit obligation of controllers and interest of their processors to be engaged by means of a written agreement because, if there is no contract the vendor could be regarded as a controller and/or the controller could be liable for a vendor’s non-compliance with the security and retention limitation obligations.

    In addition, controllers engaging processors to process financial information should also be mindful of the requirements under the PCI DSS as it applies globally to any organization or third-party service providers that store, process or transmit cardholder, regardless of the size of the organization.

    For additional details on PDPA, click here.

    Hong Kong PDPO

    In Hong Kong, the main legislation on data protection is the Personal Data (Privacy) Ordinance (the “PDPO”). The PDPO regulates the collection, use and handling of personal data. The PDPO is a principle-based law. Schedule 1 of the PDPO sets out the six data protection principles (“DPPs”), which govern the collection, use, processing, security, retention/destruction and access to personal data. The PDPO underwent major reform in 2012. The PDPO defines personal data as “information which relates to a living person and can be used to identify that person.” Financial information of a customer provided to financial institutions, payment processors and merchants will be covered under this definition.

    The third data protection principle (DPP3) addresses third-party risk.  This principle covers how personal data is to be used and processed, including the criteria under which personal data can be transferred and disclosed to third parties. Although there are no specific provisions for the payment of digital retail, entities engaging third-parties to process financial information should be mindful of the requirements under the PCI DSS as it applies globally.

    For additional details on Hong Kong’s PDPO, click here.

    Australia Privacy Act of 1998

    The Privacy Act 1988 is the foundation of Australia’s national privacy regulatory regime as it regulates how personal information is handled. The Privacy Act 1988 includes thirteen Australian Privacy Principles (APPs), which apply to some private sector organizations, as well as most Australian Government agencies (collectively “APP entities”).

    The Privacy Act lays down a broad definition of personal data. It includes any information about an “identified individual or an individual who is reasonably identifiable.” Financial information of a person provided to financial institutions, payment processors and merchants will be covered under this definition.

    When organizations outsource any of their processing operations to a third party (including to a cloud service provider), and they continue to control that information as it is defined under the act, they will still be subject to the restrictions laid down in the Privacy Act 1988. For this reason, it is important to conduct appropriate due diligence on the services to be provided (particularly data storage services such as cloud services) and to engage in the ongoing monitoring of vendors.

    In addition, entities engaging third-parties to process financial information should also be mindful of the requirements under the PCI DSS as it applies globally.

    For additional details on Privacy Act 1998, click here.

  • How OneTrust Helps

    OneTrust Vendorpedia simplifies third-party risk management by combining automation with aggregated vendor research to streamline the vendor engagement lifecycle, from onboarding to offboarding. The platform helps organizations conduct faster and more in-depth security and privacy reviews. This feature helps organizations leverage external research to make their onboarding process more efficient.

    Vendorpedia is backed by the world’s largest and most up-to-date database of privacy and security laws, frameworks, and standards, which directly power and enrich OneTrust Vendorpedia. Research is generated by 30 in-house security and privacy experts and a network of 500 lawyers across 300 jurisdictions.

    In addition, our vendor-chasing and ongoing monitoring systems allow controllers to regularly assess their vendors and any changes that they may include throughout their processing operations (such as sub-contracting their own vendors). In essence, our vendor risk management module allows businesses to automate the Vendor engagement lifecycle, from onboarding to offboarding with 360° third-party visibility.

Want to learn more? Login to the full DataGuidance platform.

About OneTrust

OneTrust is the #1 most widely used privacy, security and third-party risk technology platform trusted by more than 3,000 companies to comply with the CCPA, GDPR, ISO27001 and hundreds of the world’s privacy and security laws. OneTrust's three primary offerings include OneTrust Privacy Management Software, OneTrust PreferenceChoice™ consent and preference management software, and OneTrust Vendorpedia™ third-party risk management software and vendor risk exchange. To learn more, visit or connect on LinkedIn, Twitter and Facebook.