Third Party Risk Management in the Financial Sector
Gramm Leach Bliley Act
The Gramm Leach Bliley Act (GLBA) was enacted on November 12, 1999. The GLBA addresses consumer financial concerns such as issues related to financial privacy. The Federal Trade Commission (FTC) promulgated the Privacy Rule and Safeguards Rule implementation regulations to carry out the GLBA’s privacy and security provisions. Under these rules, financial institutions must “oversee service providers” by:
- taking reasonable steps to select and retain service providers that are capable of maintaining appropriate safeguards for the customer information at issue;
- requiring service providers by contract to implement and maintain such safeguards.
With the passage of the Dodd-Frank Act in 2011, the Consumer Financial Protection Bureau(CFPB) assumed rule-making and enforcement authority for the GLBA Privacy and Security Rules.
For additional details on the GLBA, click here.
The New York Department of Financial Services (“NYDFS” or “DFS”) Cybersecurity Regulation (“the Regulation”) is intended to promote the protection of customer information as well as the information technology systems of financial services companies. The regulation became effective on March 1, 2019, after a two-year implementation period.
The Regulation defines “Third Party Service Provider(s)” as “a Person that (i) is not an Affiliate of the Covered Entity, (ii) provides services to the Covered Entity, and (iii) maintains, processes or otherwise is permitted access to Non-public Information through its provision of services to the Covered Entity.” (500.01(n))
The Regulation also provides that Covered Entities may utilize Third Party Service Providers to fulfil cybersecurity roles. See 500.04(a) and 500.10(a)(1), (b)
Specifically, Covered Entities must do the following, with respect to third-party risk management:
- Address “vendor and Third Party Service Provider management” in a written cybersecurity policy (500.03(l));
- where using a Third Party Service Provider as an external Chief Information Security Officer (CISO) under 500.04(a), “designate a senior member of the Covered Entity’s personnel responsible for direction and oversight of the Third Party Service Provider” (500.04(a)(2));
- “require the Third Party Service Provider to maintain a cybersecurity program that protects the Covered Entity in accordance with the requirements of [the Regulation]” (500.04(a)(3)); and
- implement a “Third Party Service Provider Security Policy” that is based on the periodic Risk Assessment required under 500.09, and that addresses the following (to the extent applicable) under 500.11:
- “the identification and risk assessment of Third Party Service Providers;
- minimum cybersecurity practices required to be met by such Third Party Service Providers in order for them to do business with the Covered Entity;
- due diligence processes used to evaluate the adequacy of cybersecurity practices of such Third Party Service Providers; and
- periodic assessment of such Third Party Service Providers based on the risk they present and the continued adequacy of their cybersecurity practices.” (500.11(a)).
Finally, the “Third Party Service Provider Security Policy” must include “relevant guidelines for due diligence and/or contractual protections relating to Third Party Service Providers”:
- the Third Party Service Provider’s policies and procedures for access controls, including its use of Multi-Factor Authentication as required by section 500.12 […], to limit access to relevant Information Systems and Nonpublic Information;
- the Third Party Service Provider’s policies and procedures for use of encryption as required by section 500.15 […] to protect Nonpublic Information in transit and at rest;
- notice to be provided to the Covered Entity in the event of a Cybersecurity Event directly impacting the Covered Entity’s Information Systems or the Covered Entity’s Nonpublic Information being held by the Third Party Service Provider; and
representations and warranties addressing the Third Party Service Provider’s cybersecurity policies and procedures that relate to the security of the Covered Entity’s Information Systems or Nonpublic Information.” (500.11(b)).
For additional details on NYDFS CSR, click here.
Colombia Statutory Law 1266 0f 2008
Statutory Law 1266 0f 2008 (December 31) lays down general Habeas Data provisions and Regulates the management of information contained in personal databases, especially financial, credit, commercial services, among others. This law was intended to be a general regulation on data protection. However, the Law focuses on the processing of data concerning financial, credit, commercial and services, as well as breaches of such obligations, and it applies not only to data from individuals but also to data from legal entities. The Law seeks to protect individuals’ right to intimacy and a private life and companies’ right to a good name, as well as providing dispositions regarding the appropriate ways to report debts to risk management entities.
The processing of personal data for the purpose of financial or securities transactions is allowed without obtaining the specific consent of data subjects. It is important to note that in these cases, financial entities would be allowed to perform the transfer of information from data subjects to any third party only where a banking transaction takes place. Therefore it is necessary to record and report account details and an account holder’s name and other details in order to perform the transaction.
It is worth noting that, the information protected by the Data Protection Act may not be transferred or transmitted to third parties who are not parties to the transaction if no explicit consent from the data subjects is obtained. This prohibition also applies to the transmission of information to risk management centres.
For additional details on the Colombian Privacy Act, click here.
The Bank of Thailand imposes specific procedures and standards related to data protection and data privacy upon financial institutions pursuant to the Financial Institutions Business Act B.E. 2551 (‘FIBA’) and which are not dependent on any general data protection/privacy legislation. Once the Draft PDPA is enacted, such procedures and standards of the Bank of Thailand will still be enforceable, except where expressly superseded by the Draft PDPA.
In the case where financial institutions engage third parties, including cloud computing service providers, Notification No. 19/2559 requires financial institutions to manage third-party risks as follows:
- there must be a written policy as to the management of IT outsourcing risks and the “implementation of those guidelines and practices must be assessed regularly and the results must be reported to the board of senior management with delegated authority in a timely manner;”
- there must be an assessment of the “severity of possible risks of IT outsourcing and must have in place a system to assess, control, and manage key related IT outsourcing risks, such as strategic risk, operational risk, legal risk, and IT risk. The system should be commensurate with the size and volume of transaction, and complexity of the outsourced IT activities, as well as associated risks […] the assessment of risks of IT outsourcing, including the use of cloud computing, should cover risks associated with the control and protection of personal data and degree of reliance on service providers that may limit any further chance or cancelation (vendor lock-in), and impact on critical systems of the financial institutions. Furthermore, for financial institutions that outsource IT activities to overseas service providers, especially activities related to data storage/processing or any arrangement with respect to data, they must also assess risks of outsourcing those activities to the overseas service providers, such as risk of being unable to access the data due to a disruption or blocking of cross-border communication network or system (information access risk) and legal risk associated with compliance with overseas regulation (cross-border compliance);”
- there must be a framework for “monitoring the effectiveness of service providers on a regular basis, a framework for monitoring any alteration made by service providers, as well as a framework for monitoring day-to-day incidents relating to service providers;” and
- there must also be a business continuity plan in place, which covers IT outsourcing. Furthermore, “there must be an IT disaster recovery plan to accommodate problems or incidents from IT outsourcing and to mitigate the severity of impact. Financial institutions must ensure that they have information available within the country to maintain the continuity of business operations and services provided to customers.”
Financial Institutions may fall under two or more sets of obligations in relation to the collection, processing and transfer of personal data: the general Data Protection Obligations under the PDPA, and sector-specific information protection obligations as the regulatory authorities may prescribe.
In relation to sector-specific regulations and guidelines on data transfers, it is worth noting that the engagement of a service provider in a foreign country may expose a Financial Institution to certain local risks, e.g. economic, social and political conditions and events in a foreign country that may adversely affect processing operations and security of the personal data. In order to mitigate this Financial Institutions should be proactive in identifying and specifying requirements for confidentiality and security in the outsourcing arrangement. A very important step in complying with the law in Singapore is to clearly define the responsibilities of each actor involved and the corresponding liabilities for a breach.
The same data protection and security obligations that apply in general also apply to financial services organisations (‘FSOs’) established in Australia. Of course, given the amount and increased risk factor of the personal information usually collected and processed by FSOs, compliance with relevant requirements and regulations is often more onerous for FSOs.
GENERAL DATA PROTECTION REGULATION
The EU General Data Protection Regulation (GDPR) came into force on May 25, 2018. The GDPR offers a new framework for personal data protection with increased obligations for organisations as well as a far and wide reach. The regulation aims to strengthen and harmonise data protection law in the EU while providing strong new rights to data subjects located in the EU. Under the GDPR, health data, genetic data, and biometric data are classified as sensitive personal data. In addition, a key difference between the old European Data Protection Directive and the GDPR is that now the engagement of data processors is governed by a more stringent regulatory framework. One clear example of this is the number of times we find the word processor in the old Data Protection Directive (11 times) compared with the 238 references to a data processor in the GDPR. moreover, under the GDPR both controllers and processors are jointly liable for complying with data protection regulations. Therefore, it is critical to analyse 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.
The GDPR outlines vendor management responsibilities specifically in Articles 24, 28, 29, and 46. There is shared liability for companies using vendors to process data, and organisations should look to have the correct protections in place. In addition, the GDPR has an extraterritorial scope whereby controllers established in Europe (or abroad but who target data subjects in Europe) have to make sure that their processors are able to comply with all GDPR obligations, regardless of whether they (the processors) are located in the EU/EEA.
For additional details on GDPR, click here.
EU DIRECTIVE ON PAYMENT SERVICES IN THE INTERNAL MARKET
The EU has adopted two directives concerning payment services: PSD 1 (2007) and PSD 2. The former (1) introduced a new category of non-bank payment service provider; (2) established and implemented a set of rules concerning electronic payments across the EEA, covering all types of electronic and non-cash payments; and, (3) laid the groundwork for the single euro payments area (SEPA), covering services such as:
- fund transfers
- direct debit
- card payments
- mobile and online payments
The aim was for this system to result in a cheaper, faster and safer single system for accounts to be used domestically and cross-border. The system can be used for (e.g.) paying bills or salaries and is subject to transparent pricing (with appropriate payment schemes and standards).
PSD 2 was later adopted as part of a legislative package which aim is to consolidate the foundations laid down in the PSD 1. The legislative package includes the PSD 1 and a Regulation on multilateral interchange fees (Regulation (EU)2015/751). The Regulation — in general terms — sets a cap on interchange fees charged between banks for card-based transactions. The PSD 2, on the other hand, consolidates and further expands the set of rules (initially laid down in PSD 1) that apply both to already existing, and to new providers of payment services, thus ensuring that all actors compete on equal terms. This is expected to result in
- greater efficiency, choice and transparency;
- strengthening consumer’s trust.
To this end, the PSD 2 sets of rules concerning:
- strict security requirements;
- enhanced protection of consumer’s financial data;
- transparency conditions;
- information requirements that payment services have to comply with;
- specific conditions for granting authorisation to organisations who want to become payment institutions;
- enhanced rights for users of payment services:
- reduced liability;
- unconditional refund rights; and,
- the removal of surcharges.
A key term in this context is “Payment Services”. These are services enabling cash to be deposited in or withdrawn from (e.g.) a bank account, as well as all the actions required to operate the account (transfers, direct debit, credit transfers, card payments, etc.). In this context, when payment service providers apply for authorisation, applicants must provide assurance of the protection to personal, sensitive, and financial data of users, including:
- procedures to be implemented for security incidents;
- security policy;
- a description of the measures to be implemented to file, monitor, track, and restrict access to sensitive payment data;
- payment institutions offering account information services are required to have professional indemnity insurance as a condition for authorisation.
(The list of conditions is lengthy and strict, however, for the purpose of this summary we have only taken those that are relevant for the protection of personal data.)
Moreover, the European Banking Association has issued a set of Guidelines on Major Incidents Reporting under PSD2.
The interplay between the GDPR and the PSD-2 is evident from the multiplicity of actors involved and the severity of the risks posed to the personal financial data of customers.
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.
Third Party Risk Management in the Financial Sector
Sector Specific Processing
Due to the nature of the personal data processed in the financial sector, heightened obligations to ensure the lawful processing and security of the personal data are needed to prevent and mitigate the risks involved and potential harms to users of financial services. These risks must be managed internally and externally.
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 PbD 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 for the financial sector, 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
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 OneTrust.com or connect on LinkedIn, Twitter and Facebook.