PayPal welcomes the EBA’s work to harmonize and streamline requirements on ICT and security risk management. This is important to preserve a level-playing field for all financial institutions, to ensure a consistent and robust approach across the European Union, and to maintain the security of financial institutions against external and internal threats. We welcome the approach in the Guidelines, which are based on internationally-recognized best practices. We would however like to raise several concerns and points where clarifications would be appreciated:

Section 4.4.3, paragraph 34e: We agree that access rights should be granted and removed in a timely manner. We are however looking for clarity on the definition of “information asset owner. Depending on circumstances, it is possible to define the "information asset owner" as a person, a tool, or a system. Will the EBA accept any of these definitions? In addition, is the EBA’s definition consistent with the definition used in the GDPR? In order to make it easier to understand and create relationships and controls at scale, it is important that standardized terminology is used across legislation (e.g. GDPR and PSD2).

Section 4.5, paragraph 58: We acknowledge and agree that financial institutions should maintain an up-to-date inventory of ICT assets. However, we feel that the requirement in this section should specify desired outcomes rather than specific features of an asset management system. Financial institutions that maintain very large systems may choose to keep asset, configuration, change, and dependency information in systems specifically optimized for each use, rather than in a single monolithic asset inventory system. We would like the EBA to clarify the objective behind a requirement to have a single system to carry this information, as the goal of enabling a proper configuration and change management process can be achieved in other ways, including by using a suite of tools.
Additionally, we believe that the requirement of interdependency management is unclear. While it is reasonable to require ICT professionals to understand the components and/or systems on which an application or system depends, this is not true in the opposite direction. For example, while the operating system version on which a particular application relies is an important dependency to understand, it would not be practical for an operating system vendor to know all of the software packages that may at some point run on that operating system.
For these reasons, we suggest that the EBA specify desired outcomes in asset, configuration, or change management to which ICT professionals can adhere using verifiable and commercially reasonable means.

Section 4.5, paragraph 63: We agree that data and backups should be “sufficiently remote” from the primary site. This is done to ensure fast recovery of service in the event of a disaster scenario/event. We are however unsure about the EBA’s understanding of “sufficiently remote”. Can the EBA further clarify? In addition, what is the desired outcome, a Recovery Point Objective (RPO) or Recovery Time Objective (RTO)?

Section 4.6.1, paragraph 69: We concur that the independent review of security requirements is desirable. Can the EBA provide further clarity on the definition of “independent” in this case? Can the independent reviewer be from another project? Another development team? In addition, we would like to point out that in a DevOPS development scenario, this method may slow down the delivery of security fixes, which seems contradictory to the requirement to push security patches as fast as possible. What is the desired outcome in this case?

Section 4.6.2, paragraph 74: We agree that functional and non-functional requirements should be clearly defined by ICT professionals. However, we believe that the proposed methodology suggests following a one-solution model. In DevOPS product development scenarios, other methods should be considered. Risk can be mitigated by breaking the changes into classes of risk and automating testing batteries for defined risk levels. For example, lower risk issue testing can then be automated, thereby focusing development resources on critical issues. This method serves to focus attention of the critical levels and meet the EBA's requirement of patching security fixes as fast as possible.

Section 4.6.2, paragraph 79: We agree and acknowledge that source code integrity is critical to the success of any ICT. However, many of these system components require specialized knowledge and may be intellectual property. Could the EBA provide clarity surrounding the desired outcome of this requirement? Is the desired outcome to assist in knowledge transfer from departing employees? Or to enable existing employees an easier path to information discovery?

Section 4.6.2, paragraph 80: We would appreciate further clarity on the desired outcome of this measure. We would argue that financial institutions' processes for acquisition and development of ICT systems should not necessarily apply to systems developed outside of the organization. For instance, if telephone systems are outsourced to a provider, the ICT function should manage the performance of the outsourced telecommunications service via an SLA and understand the risks and controls surrounding this outsourcing. In addition, can the EBA provide clarity on the suggested "risk-based manner"?

Section 4.6.2, paragraph 81: While it is reasonable and prudent to require approval of changes through a process that accounts for risks to the environment, this requirement appears to be overly prescriptive as to the process to assess such risk and ensure approval. For example, some recurring changes deemed to be low risk changes may be undertaken by automated systems. Under such a model, a risk assessment is performed for the class of changes and automated procedures are developed and tested, but each individual change is not independently authorized or formally accepted (though each change would be independently logged for traceability). Such a mechanism allows for a repetitive activity to be undertaken over time in a consistent and scalable manner. We would urge the EBA to adopt outcome-based requirements that allow organizations to demonstrably meet the EBA’s goals without necessarily imposing a specific deployment process.
Similarly, in paragraph d), the requirement seems to indicate that the proper recourse in the event of a malfunction is to rollback a change. However, in some circumstances, a lower risk option may be to fix-forward rather than to roll back. Again, it may be helpful to separate the requirement into an outcome statement (such as in the first, unlettered paragraph) and additional informative statements that help to clarify the EBA’s intent without being overly prescriptive as to the approach.

Section 4.8, paragraph 100: While it is reasonable to allow the PSU to disable specific functionalities related to payment services, where functionality permits, this requirement appears to be onerous from a merchant's point of view. In many payment instances PayPal is integrated into the merchant application via an API call (white label service). This is done to facilitate a simple integration with the business. This will require many businesses to re-write applications. What is the desired outcome for this approach?"