Circular RUNOR 1-1910: Cyberincident Response and Recovery (RRCI) Guidelines - Adaptations

"Year of the Reconstruction of the Argentine Nation" COMMUNICATION “A” 8280 17/07/2025 TO FINANCIAL ENTITIES, TO PAYMENT SERVICE PROVIDERS, TO FINANCIAL MARKET INFRASTRUCTURES:
Ref.: Circular RUNOR 1-1910:
Guidelines for Cyberincident Response and Recovery (RRCI). Adaptations.
___________________________________________________________________________ We address you to inform that this Institution has adopted the resolution which, in its relevant part, establishes:
“1- Replace points 1.1. and 1.2. of the consolidated text on Guidelines for Cyberincident Response and Recovery (RRCI) with the following:
“1.1. Objective.
These guidelines are intended for the entities covered in point 1.2., and consist of a series of effective response and recovery practices regarding cyberincidents, aimed at limiting risks to financial stability and promoting the cybersecurity resilience of the ecosystem as a whole. Due to their general nature, they may also be adapted and adopted by any institution within the financial system, information technology and/or communication service providers, and other sectors. Response refers to the activities initiated in reaction to a detected or reported cyberincident, while recovery covers the activities executed to restore systems, services, or operations adversely affected by the cyberincident. The Central Bank of the Argentine Republic (BCRA) considers the guidelines established in Section 2. as a best practice in incident response and recovery, with Section 3. being mandatory.
1.2. Covered Entities.

• Financial entities.
• Payment service providers (PSP) included in the BCRA PSP Registry.
• Financial market infrastructures known as systemically important payment systems.
  The covered entities will effectively analyze the implementation of the guidelines, being able to choose practices suitable for their business models, taking into account their size, complexity, or risks relative to the financial ecosystem. A written record of the rationale for the adopted implementation criteria will be maintained, which must be made available to the Superintendence of Financial and Currency Entities (SEFYC) upon request.” 2- Add as Section 3. Cyberincident Notification to the consolidated text on Guidelines for Cyberincident Response and Recovery (RRCI) the following:
  “Section 3. Cyberincident Notification.
  3.1. Scope.
  Obligated entities must notify cyberincidents that affect the normal provision of services to clients or pose a risk to the availability, integrity and/or confidentiality of information. For the purposes of this regulation, incidents affecting at least the following must be reported to the External Systems Audit Department of SEFYC:
• The normal provision of services provided to clients by any means.
• The execution of transactions that must be carried out within a specific time window.
• The exchange of information with other obligated entities and their associated service providers regarding client operations.
• Client data or information due to unauthorized or fraudulent loss or disclosure.
  Incidents originating from third parties and throughout their provider chain linked to obligated entities must also be reported when they affect the availability for normal service provision to clients, or pose a risk to information integrity and confidentiality.
  3.2. Categorization.
  3.2.1. Critical Incidents.
  3.2.1.1. Those affecting the availability of client funds for any operation.
  3.2.1.2. Those related to the obligated entity's function in payment schemes, clearing systems, or securities settlement, including any function or technology that contingently supports such services, whether own or provided by third parties.
  3.2.1.3. Those that impact the operations of other participants in one or more payment schemes, as defined in the consolidated text on Payment Service Providers.
  3.2.2. Important Incidents.
  3.2.2.1. Those having a partial impact on client or entity operations, at least in one service or product.
  3.2.2.2. Those causing non-critical service interruptions, but involving the activation of contingency actions to restore them.
  3.2.2.3. The unauthorized or fraudulent loss or disclosure of critical or confidential client data.
  3.2.3. Non-relevant Incidents.
  All incidents that do not imply an alteration in the normal provision of services and products to clients or other obligated entities shall not be reported.
  3.3. Reporting Timeframes.
  Obligated entities must report important and critical incidents to the External Systems Audit Department, respecting the following communication timeframes:
  3.3.1. Initial Notification.
  Within the first hour after the incident occurs or is detected; all available information regarding it must be included.
  3.3.2. Subsequent Reports.
  From the initial notification until the incident is resolved, updates on its status must be provided, including applied remediation tasks and plans. If the incident extends beyond one hour, obligated entities must frequently inform the External Systems Audit Department about actions taken until normalization.
  3.3.3. Closure Report.
  Following containment, recovery, and resolution of the incident, within a period not exceeding 5 (five) calendar days, obligated entities must submit a final report, indicating the analysis and progress in resolving the originating cause or root cause. All communications must be sent by email to audext.incidente@bcra.gob.ar, respecting the indications in point 3.6. Notification Format.
  3.4. Additional Considerations.
  In accordance with these guidelines and the consolidated text on Minimum Requirements for Technology and Information Security Risk Management and Control, obligated entities must align their incident response and recovery processes with the requirements established for business continuity management, and consider lessons learned to update the entire incident management lifecycle. The notification requirements are complementary and do not replace the rest of the mentioned and currently effective provisions.
  3.5. Reporting Modality.
  3.5.1. Initial Notification.
  The report must maintain the established format and location of each item listed in point 3.6. Notification Format, and include at minimum the following information:
• Entity code.
• Incident ID.
• Notification type.
• Detection date and time.
• Description.
• Criticality.
• Event class information (internal or generated by a third party).
• In case of third-party origin, specify which one.
• Systems and services involved.
• Affected service channels.
• Alternative service for affected clients.
• Contact details.
  When specific details are not available at the time of initial notification, information still pending must be indicated in the corresponding fields.
  3.5.2. Subsequent Reports.
  Must be sent as indicated in point 3.5.1., and contain an update of the information presented in the initial report, indicating the original incident ID.
  3.5.3. Closure Report.
  Must include at minimum the following information:
• Entity code.
• Original incident ID.
• Affected service.
• Categorization.
• Volume of affected clients.
• Chronology, including: detected events, steps and actions executed for containment and recovery, and provisional measures taken to mitigate the impact, along with their justification and approvals requested for execution.
• In case of critical incidents where continuity plans are not activated, include a description justifying the decision taken.
• Internal sectors involved.
• Internal sectors affected.
• Third parties and their service providers involved, and mitigating actions to be implemented.
• Root cause analysis result.
• Provisional mitigation measures and reasons for their application.
• If applicable, measures taken to:
• notify authorities.
• notify potentially affected third parties.
• inform the general public.
• Action plans to prevent recurrence.
• Resolution date.
  The External Systems Audit Department may request additional information regarding measures adopted for resolving reported incidents. The Superintendence of Financial and Currency Entities is also authorized to request from obligated entities a compliance plan to avoid or minimize the occurrence of similar incidents in the future.
  3.6. Notification Format.
  3.6.1.Initial Notification and Subsequent Reports.
  3.6.1.1. Email Subject. Incident Reported by: XXXXX – ENTITY NAME (only one space must be left after the two dots. XXXXX is the five-digit entity number padded with zeros to the left; after the hyphen, provide the name).
  3.6.1.2.Email Body. Incident ID: XXXXXX (only one space must be left after the two dots. Assign a unique identification number for each incident. For notification type 02, indicate the original ID). Notification Type: XX (specify only the numeric code according to the following table):
  01 - Initial (see details in point 3.3.1.).
  02 - Subsequent (see details in point 3.3.2.).
  Incident Description: (free text).
  Date and time: dd/mm/yyyy hh:mm (respect date format, do not include parentheses).
  Affected Service: (free text with description of affected service or systems).
  Affected Channel: XX (specify only the numeric code according to the following table – if more than one channel applies, separate with semicolons):
  01 - Point of Sale (POS, WebPOS, QR code, among others).
  02 - Internet Banking.
  03 - Mobile Applications or Digital Wallets.
  04 - Automated Teller Machines (ATMs).
  05 - Branch or service center.
  06 - All customer services.
  07 - None of the above.
  Event Criticality: XX (specify according to the following table - indicate only the number):
  01 - Critical: (see details in point 3.2.1.).
  02 - Important: (see details in point 3.2.2.).
  Event Class: XX (specify according to the following table - indicate only the number):
  01 - Internal (originated within the entity).
  02 - Third Parties (originated by a third party).
  Originating Third Party: (free text - specify only if event class is 02, otherwise indicate not applicable).
  Service Alternative: (free text - specify alternative service for affected clients).
  Contact Details: (free text – provide at minimum: full name, position or sector, email address, and phone number).
  3.6.2.Closure Reports.
  3.6.2.1.Email Subject. Incident reported by: XXXXX – ENTITY NAME (only one space must be left after the two dots. XXXXX is the five-digit entity number padded with zeros to the left; after the hyphen, provide the name). 3.6.2.2.Email Body. ID: XXXXXX (leave only one space after the two dots, indicate the original ID). Notification Type: 03 (the code 03 must always be reported). Incident Description: (free text). Affected Service: (free text as indicated in point 3.5.3.). Categorization: (free text as indicated in point 3.5.3.). Volume of Affected Clients: (free text as indicated in point 3.5.3.). Chronology: (free text as indicated in point 3.5.3.). Critical Incident without Continuity Plan: (free text as indicated in point 3.5.3). Internal Sectors Involved: (free text as indicated in point 3.5.3.). Internal Sectors Affected: (free text as indicated in point 3.5.3.). Service Providers: (free text as indicated in point 3.5.3.). Root Cause Analysis: (free text as indicated in point 3.5.3.). Mitigation Measures: (free text as indicated in point 3.5.3.). Notifications: (free text as indicated in point 3.5.3.). Action Plans to Prevent Recurrence: (free text as indicated in point 3.5.3.) Date and Time of Resolution: (dd/mm/yyyy hh:mm) (respect date format, do not include parentheses).” 3- Establish that Payment Service Providers (PSP) included in the Registry of PSP of the Central Bank of the Argentine Republic, excluding payment service providers that offer payment accounts (PSPCP), will have a period of 60 (sixty) business days from the publication of this communication to implement the consolidated text on Guidelines for Cyberincident Response and Recovery (RRCI).” Furthermore, it is clarified that these provisions repeal Communication B 11847. In this regard, we provide the sheets that, in replacement of those previously provided, should be incorporated into the consolidated text of reference. In this sense, it is recalled that on this Institution's website www.bcra.gob.ar, accessing “Financial System - LEGAL AND REGULATORY FRAMEWORK - Consolidations and Summaries - Consolidated General Regulatory Texts”, the modifications made with specially highlighted text (strikethrough and bold) will be found. We remain, respectfully yours.

-7-
CENTRAL BANK OF THE ARGENTINE REPUBLIC
Héctor D. Domínguez Roberto A. Boccardo
Deputy General Manager of Analysis and Audit
Deputy General Manager of Systems and Organization
ANNEX

• Index -
  Section 1. Introduction.
  1.1. Objective.
  1.2. Covered Entities.
  Section 2. Guidelines.
  2.1. Governance.
  2.2. Planning and Preparation.
  2.3. Analysis.
  2.4. Mitigation.
  2.5. Restoration and Recovery.
  2.6. Coordination and Communication.
  2.7. Continuous Improvement.
  Section 3. Cyberincident Notification.
  3.1. Scope.
  3.2. Categorization.
  3.3. Reporting Timeframes.
  3.4. Additional Considerations.
  3.5. Reporting Modality.
  3.6. Notification Format.
  Correlation Table.
  B.C.R.A.
  CONSOLIDATED TEXT ON
  GUIDELINES FOR CYBERINCIDENT RESPONSE AND RECOVERY (RRCI) Version: 2nd. COMMUNICATION “A” 8280 Effective Date:
  18/07/2025 Page 1

1.1. Objective.
These guidelines are intended for the entities covered in point 1.2., and consist of a series of effective response and recovery practices regarding cyberincidents, aimed at limiting risks to financial stability and promoting the cybersecurity resilience of the ecosystem as a whole. Due to their general nature, they may also be adapted and adopted by any institution within the financial system, information technology and/or communication service providers, and other sectors. Response refers to the activities initiated in reaction to a detected or reported cyberincident, while recovery covers the activities executed to restore systems, services, or operations adversely affected by the cyberincident. The Central Bank of the Argentine Republic (BCRA) considers the guidelines established in Section 2. as a best practice in incident response and recovery, with Section 3. being mandatory.
1.2. Covered Entities.

• Financial entities.
• Payment service providers (PSP) included in the BCRA PSP Registry.
• Financial market infrastructures known as systemically important payment systems.
  The covered entities will effectively analyze the implementation of the guidelines, being able to choose practices suitable for their business models, taking into account their size, complexity, or risks relative to the financial ecosystem. A written record of the rationale for the adopted implementation criteria will be maintained, which must be made available to the Superintendence of Financial and Currency Entities (SEFYC) upon request. B.C.R.A. GUIDELINES FOR CYBERINCIDENT RESPONSE AND RECOVERY (RRCI)
  Section 1. Introduction.
  Version: 2nd. COMMUNICATION “A” 8280 Effective Date:
  18/07/2025 Page 1

3.1. Scope.
Obligated entities must notify cyberincidents that affect the normal provision of services to clients or pose a risk to the availability, integrity and/or confidentiality of information. For the purposes of this regulation, incidents affecting at least the following must be reported to the External Systems Audit Department of SEFYC:

• The normal provision of services provided to clients by any means.
• The execution of transactions that must be carried out within a specific time window.
• The exchange of information with other obligated entities and their associated service providers regarding client operations.
• Client data or information due to unauthorized or fraudulent loss or disclosure.
  Incidents originating from third parties and throughout their provider chain linked to obligated entities must also be reported when they affect the availability for normal service provision to clients, or pose a risk to information integrity and confidentiality.
  3.2. Categorization.
  3.2.1. Critical Incidents.
  3.2.1.1. Those affecting the availability of client funds for any operation.
  3.2.1.2. Those related to the obligated entity's function in payment schemes, clearing systems, or securities settlement, including any function or technology that contingently supports such services, whether own or provided by third parties.
  3.2.1.3. Those that impact the operations of other participants in one or more payment schemes, as defined in the consolidated text on Payment Service Providers.
  3.2.2. Important Incidents.
  3.2.2.1. Those having a partial impact on client or entity operations, at least in one service or product.
  3.2.2.2. Those causing non-critical service interruptions, but involving the activation of contingency actions to restore them.
  3.2.2.3. The unauthorized or fraudulent loss or disclosure of critical or confidential client data.
  B.C.R.A.
  GUIDELINES FOR CYBERINCIDENT RESPONSE AND RECOVERY (RRCI)
  Section 3. Cyberincident Notification.
  Version: 1st. COMMUNICATION “A” 8280 Effective Date:
  18/07/2025 Page 1

3.2.3. Non-relevant Incidents.
All incidents that do not imply an alteration in the normal provision of services and products to clients or other obligated entities shall not be reported.
3.3. Reporting Timeframes.
Obligated entities must report important and critical incidents to the External Systems Audit Department, respecting the following communication timeframes:
3.3.1. Initial Notification.
Within the first hour after the incident occurs or is detected; all available information regarding it must be included.
3.3.2. Subsequent Reports.
From the initial notification until the incident is resolved, updates on its status must be provided, including applied remediation tasks and plans. If the incident extends beyond one hour, obligated entities must frequently inform the External Systems Audit Department about actions taken until normalization.
3.3.3. Closure Report.
Following containment, recovery, and resolution of the incident, within a period not exceeding 5 calendar days, obligated entities must submit a final report, indicating the analysis and progress in resolving the originating cause or root cause. All communications must be sent by email to audext.incidente@bcra.gob.ar, respecting the indications in point 3.6. “Notification Format”.
3.4. Additional Considerations.
In accordance with these guidelines and the consolidated text on Minimum Requirements for Technology and Information Security Risk Management and Control, obligated entities must align their incident response and recovery processes with the requirements established for business continuity management, and consider lessons learned to update the entire incident management lifecycle. The notification requirements are complementary and do not replace the rest of the mentioned and currently effective provisions. B.C.R.A. GUIDELINES FOR CYBERINCIDENT RESPONSE AND RECOVERY (RRCI)
Section 3. Cyberincident Notification.
Version: 1st. COMMUNICATION “A” 8280 Effective Date:
18/07/2025 Page 2

3.5. Reporting Modality.
3.5.1. Initial Notification.
The report must maintain the established format and location of each item listed in point 3.6. “Notification Format”, and include at minimum the following information:

• Entity code.
• Incident ID.
• Notification type.
• Detection date and time.
• Description.
• Criticality.
• Event class information (internal or generated by a third party).
• In case of third-party origin, specify which one.
• Systems and services involved.
• Affected service channels.
• Alternative service for affected clients.
• Contact details.
  When specific details are not available at the time of initial notification, information still pending must be indicated in the corresponding fields. 3.5.2.Subsequent Reports. Must be sent as indicated in point 3.5.1., and contain an update of the information presented in the initial report, indicating the original incident ID.
  3.5.3. Closure Report.
  Must include at minimum the following information:
• Entity code.
• Original incident ID.
• Affected service.
• Categorization.
• Volume of affected clients.
• Chronology, including: detected events, steps and actions executed for containment and recovery, and provisional measures taken to mitigate the impact, along with their justification and approvals requested for execution.
• In case of critical incidents where continuity plans are not activated, include a description justifying the decision taken.
• Internal sectors involved.
• S