Security working group meeting 6 – April 18, 2023

This discussion guide is provided to assist working group members in preparing for their final meeting.

For questions or comments, please contact obbo@fin.gc.ca.

On this page:

• Discussion guide
• Outcomes

Discussion guide

Ongoing reporting requirements

Just as business evolves, so does an organization's risk profile. While security requirements are addressed during entry into the system, whether as part of accreditation requirements or otherwise as part of the common rules, these obligations should not remain static in the face of evolving and emerging threats. Ongoing security reporting is an essential tool for ensuring the continued safety of an open banking system. For system participants, it creates an obligation to continue monitoring risks to ensure that they are identified, assessed, and mitigated with appropriate controls. This also instills trust in the system as it provides consumers with confidence that organizations which hold their data continue to monitor and report on critical elements of their risk management programs.

Ongoing security reporting obligations are common features of financial services frameworks. In Canada, the Retail Payment Activities Act (RPAA) provides an example of this. It mandates the Bank of Canada (the Bank) with supervision of payment service providers (PSPs) and outlines the requirement for PSPs to, among other things, implement and maintain an operational risk management and incident response framework. PSPs are required to submit annual reports to provide the Bank with up-to-date registration information as well as information regarding operational risk management, incident response and safeguarding practices for end-user funds. This annual reporting is complemented by requirements to report a significant change and incidents that have a material impact on end users, other PSPs, or certain clearing and settlement systems^{Footnote 1}.  

Australia's Consumer Data Right (CDR) also outlines ongoing information security reporting obligations as a condition to participants maintaining membership in the system. Two requirements are imposed on accredited participants. The first is an attestation issued by management which (1) must be in a prescribed form^{Footnote 2} relating to controls and system description and (2) detail changes, if any, to the CDR data environment since the last assurance report was submitted to the accreditation body, the Australian Competition and Consumer Commission. In addition, accredited participants must provide an assurance report on the design, implementation and operating effectiveness of controls. The scope varies depending on the accreditation tier and certification frameworks used to demonstrate compliance with the CDR security rules. In both cases, the reports are due in a prescribed period with intervals ranging from approximately one year to every second year^{Footnote 3}.

Similar obligations exist in the United Kingdom. Under the Payment Services Regulations 2017, account information service providers^{Footnote 4} must provide the Financial Conduct Authority an assessment of the operational and security risks relating to its services and on the adequacy of the mitigation measures and control mechanisms implemented in response to those risks^{Footnote 5}. The assessment is provided on an annual basis and in a prescribed form^{Footnote 6}.

Discussion

1. Once the initial security requirements of the common rules are met, how often should an organization re-attest to the soundness of their security requirements?
2. What should be the extent of the attestation? For example, should it be limited to a self-attestation, a third-party assurance report, or otherwise?
3. Should the ongoing security reporting obligations apply equally to all system participants?
4. How should the system address instances where a participant reports a finding in the context of its ongoing reporting obligations? For instance, should the participant be automatically suspended or be given the opportunity to remediate the situation?

Outcomes

Ongoing reporting requirements

Discussion 1

Once the initial security requirements of the common rules are met, how often should an organization re-attest to the soundness of their security requirements?

• There was consensus that an organization should attest to the soundness of its security requirements on an annual basis.  
• Participants added that this requirement should apply uniformly, regardless of the service provided.

Discussion 2

What should be the extent of the attestation? For example, should it be limited to a self-attestation, a third-party assurance report, or otherwise?

• There was consensus that organizations can self attest on an annual basis with third-party assurance provided at intervals thereafter.
• Participants drew parallels with the SWIFT model of attestation and third-party assurance.

Discussion 3

Should the ongoing security reporting obligations apply equally to all system participants?

• There was consensus that security reporting should apply uniformly to all system participants. Participants highlighted the need for transparency, visibility, and the communication of information to build trust among ecosystem participants.

Discussion 4

How should the system address instances where a participant reports a finding in the context of its ongoing reporting obligations? For example, should the participant be automatically suspended or be given the opportunity to remediate the situation?

• There was consensus that automatic suspension may be an overly strict response.
• Participants discussed the need to assess instances on an individual basis before making a decision on suspension or revocation, with consideration for the severity of the issue, speed of response to address it, the status of containment, and remediation plans in place.

Security working group attendees