The operational-resilience, BCDR, and crisis-handling obligations that most likely apply to insurers — by regulator, domain, and compliance status. Filter and search the full set below.
insurer · 234 likely-applicable · 0 excluded by asset sizeHow this persona’s 234 applicable obligations distribute across cross-cutting themes. For the full lens (what each requires), run python3 -m regwatch.theme <theme> --persona insurer.
| Theme | Obligations | of which proposed |
|---|---|---|
| Third-Party / Vendor Risk Management | 86 | 2 |
| Cybersecurity × Resilience | 72 | 12 |
| Incident Reporting & Notification | 103 | 3 |
| Resilience Testing & Exercises | 47 | 2 |
| ID | Country | Regulator | Domain | Size trigger | Obligation (with source quote) | Citation | Status | Suggested evidence to comply |
|---|---|---|---|---|---|---|---|---|
OBL-00885 | European Union | EU_ESA | business continuity | Establish and maintain a sound, comprehensive and well-documented ICT risk management framework as part of the overall risk management system. “Financial entities shall have in place a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system” | Art. 6(1) Regulation (EU) 2022/2554 | final | Board-approved ICT risk management framework document; annual review records; integration evidence within overall risk management system | |
OBL-00886 | European Union | EU_ESA | business continuity | Identify, classify and document all ICT-supported business functions, roles, dependencies, assets and information assets critical to operations. “Financial entities shall identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions” | Art. 8(1) Regulation (EU) 2022/2554 | final | Asset inventory and classification register; mapping of ICT assets to critical business functions; documented dependencies | |
OBL-00887 | European Union | EU_ESA | business continuity | Continuously monitor and manage all sources of ICT risk, including risks posed by third-party ICT service providers, and implement protection and prevention measures. “Financial entities shall continuously monitor and control the security and functioning of ICT systems and tools and shall minimise the impact of ICT risk” | Art. 9(1)-(2) Regulation (EU) 2022/2554 | final | Continuous monitoring logs; vulnerability management records; evidence of preventive controls; third-party risk monitoring reports | |
OBL-00888 | European Union | EU_ESA | business continuity | Implement ICT business continuity policy and plans to ensure continuity of critical or important functions through ICT disruptions. “As part of the ICT risk management framework referred to in Article 6(1), financial entities shall put in place a comprehensive ICT business continuity policy” | Art. 11(1) Regulation (EU) 2022/2554 | final | Board-approved ICT BCP document; list of critical functions covered; activation criteria; defined RTO/RPO; annual review records | |
OBL-00891 | European Union | EU_ESA | business continuity | Develop and implement crisis communication plans to ensure effective communication to staff, stakeholders and public during ICT-related crises. “Financial entities shall have in place crisis communication plans enabling a responsible disclosure of, at least, major ICT-related incidents or vulnerabilities to clients, counterparts and the public” | Art. 14(1) Regulation (EU) 2022/2554 | final | Documented crisis communication plan; defined roles and spokespersons; internal/external notification templates; activation records | |
OBL-00892 | European Union | EU_ESA | business continuity | Designate a crisis communication manager responsible for managing communications during ICT-related incidents. “Financial entities shall designate a person responsible for implementing the communication strategy for ICT-related incidents and fulfil the public and media function for that purpose” | Art. 14(2) Regulation (EU) 2022/2554 | final | Named crisis communication manager; role description; evidence of appointment; escalation pathway documentation | |
OBL-00893 | European Union | EU_ESA | business continuity | Establish and maintain an ICT-related incident management process to detect, manage and notify major ICT-related incidents, including classification criteria. “Financial entities shall define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents” | Art. 17(1) Regulation (EU) 2022/2554 | final | Incident management process documentation; classification criteria; incident log; escalation procedures; evidence of regular review | |
OBL-00894 | European Union | EU_ESA | business continuity | Classify ICT incidents and cyber threats using prescribed criteria (clients affected, duration, data loss, criticality, economic impact) and report major incidents to competent authorities. “Financial entities shall classify ICT-related incidents and shall determine their impact based on the following criteria: the number of clients, counterparts or financial transactions affected” | Art. 18(1) Regulation (EU) 2022/2554 | final | Classification methodology aligned to RTS criteria; incident registers with classification evidence; major incident reports submitted to authorities | |
OBL-00895 | European Union | EU_ESA | business continuity | Submit initial, intermediate and final reports on major ICT-related incidents to the relevant competent authority within prescribed timeframes. “Financial entities shall submit: an initial notification; an intermediate report after the initial notification, as soon as the status of the original incident has changed significantly; a final report” | Art. 19(3) Regulation (EU) 2022/2554 | final | Templates for initial/intermediate/final reports; submission records with timestamps; evidence of authority acknowledgement | |
OBL-00896 | European Union | EU_ESA | business continuity | Perform a basic digital operational resilience testing programme annually, covering ICT tools, systems and processes supporting critical or important functions. “Financial entities shall establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk management framework” | Art. 25(1) Regulation (EU) 2022/2554 | final | Annual resilience testing plan and results; coverage of critical/important functions; gap remediation records; sign-off by management | |
OBL-00897 | European Union | EU_ESA | business continuity | Conduct threat-led penetration testing (TLPT) at least every three years on critical or important live production systems. “Financial entities shall carry out at least every 3 years advanced testing by means of TLPT. Based on the risk profile of the financial entity and taking into account operational circumstances” | Art. 26(1) Regulation (EU) 2022/2554 | final | TLPT scope documentation; testers' credentials (TIBER or equivalent); test results and remediation plans; authority notification records | |
OBL-00898 | European Union | EU_ESA | business continuity | Adopt a strategy on ICT third-party risk, including a policy for use of ICT services supporting critical or important functions, and review it annually. “As part of their ICT risk management framework, financial entities shall adopt and regularly review a strategy on ICT third-party risk, taking into account the multi-vendor strategy” | Art. 28(1) Regulation (EU) 2022/2554 | final | Board-approved third-party ICT risk strategy; annual review records; multi-vendor strategy documentation; concentration risk assessment | |
OBL-00899 | European Union | EU_ESA | business continuity | Before entering into ICT third-party arrangements for critical or important functions, assess concentration risk and risks of ICT service provider failure or unavailability. “Prior to entering into a contractual arrangement on the use of ICT services, financial entities shall: identify and assess all relevant risks in relation to the ICT third-party service provider” | Art. 28(4) Regulation (EU) 2022/2554 | final | Pre-contract due diligence reports; concentration risk analysis; risk registers; sign-off documentation before contract execution | |
OBL-00900 | European Union | EU_ESA | business continuity | Maintain and update a register of all contractual arrangements with ICT third-party service providers and report it to competent authorities upon request. “Financial entities shall maintain and update at entity level, at sub-consolidated and at consolidated level, a register of information in relation to all contractual arrangements on the use of ICT services” | Art. 28(3) Regulation (EU) 2022/2554 | final | Centralised ICT third-party contract register; evidence of regular updates; submission records to competent authority | |
OBL-00901 | European Union | EU_ESA | business continuity | Ensure contractual arrangements with ICT third-party providers for critical/important functions include mandatory clauses on business continuity, availability, recovery and exit strategies. “Contractual arrangements on the use of ICT services shall include at minimum: the description of full service levels including updates and revisions thereof; the obligations of the ICT third-party service provider to provide assistance at no additional cost” | Art. 30(2) Regulation (EU) 2022/2554 | final | Contract clauses checklist aligned to Art. 30 requirements; contract review records; evidence of remediated legacy contracts | |
OBL-00902 | European Union | EU_ESA | business continuity | Establish exit strategies for ICT third-party arrangements on critical or important functions to ensure continuity if a provider fails or is discontinued. “Financial entities shall, taking into account the specificities of the ICT services to be provided, have exit strategies in order to be able to terminate, without detriment to their regulated activities, the relevant contractual arrangements” | Art. 28(8) Regulation (EU) 2022/2554 | final | Documented exit strategies per critical provider; portability assessments; alternative provider lists; transition plan templates | |
OBL-00903 | European Union | EU_ESA | business continuity | Include in ICT contracts with providers of critical/important functions rights to audit, access data, and require participation in incident response and recovery activities. “Contractual arrangements for the provision of ICT services supporting critical or important functions shall include: full cooperation of the ICT third-party service provider with the competent authorities and the resolution authorities of the financial entity” | Art. 30(3) Regulation (EU) 2022/2554 | final | Contract audit-right and cooperation clauses; evidence of audit execution; incident response cooperation records from providers | |
OBL-00904 | European Union | EU_ESA | business continuity | Implement protection measures including data integrity, encryption and access controls to safeguard ICT assets and ensure resilience of ICT infrastructure. “Financial entities shall develop, document and implement a policy on ICT security giving formal mandate to protect confidentiality, integrity, and availability of data” | Art. 9(3) Regulation (EU) 2022/2554 | final | ICT security policy; encryption and access control standards; evidence of implementation; penetration test results; periodic review records | |
OBL-00905 | European Union | EU_ESA | business continuity | Maintain backup systems and data restore procedures tested regularly, with backup systems physically and logically separate from primary systems. “Financial entities shall put in place backup policies and procedures. Financial entities shall have backup systems that can be activated without undue delay” | Art. 12(1) Regulation (EU) 2022/2554 | final | Backup policy; evidence of physical/logical separation; restore test records and success metrics; RTO/RPO alignment documentation | |
OBL-00906 | European Union | EU_ESA | business continuity | Detect anomalous activity, identify potential single points of failure, and implement measures to address ICT concentration risk in own infrastructure. “Financial entities shall identify all sources of ICT risk and shall assess cyber threats and ICT vulnerabilities relevant to their ICT supported business functions, information assets and ICT assets” | Art. 8(4) Regulation (EU) 2022/2554 | final | ICT risk assessment reports; single point of failure analysis; concentration risk register; remediation plans with target dates | |
OBL-00907 | European Union | EU_ESA | business continuity | Ensure the management body defines, approves, oversees and is accountable for the ICT risk management framework and digital operational resilience strategy. “The management body of the financial entity shall define, approve, oversee and be accountable for the implementation of all arrangements related to the ICT risk management framework” | Art. 5(1) Regulation (EU) 2022/2554 | final | Board resolution approving ICT risk framework; board-level oversight records; assigned accountability documentation; training completion records | |
OBL-00908 | European Union | EU_ESA | business continuity | Conduct post-incident reviews after major ICT incidents to identify root causes and implement corrective actions to prevent recurrence. “After a major ICT-related incident, financial entities shall perform a post-incident review to determine the root causes of disruptions and identify improvements to be applied to the ICT operations” | Art. 17(6) Regulation (EU) 2022/2554 | final | Post-incident review reports with root-cause analysis; corrective action plans with owners and deadlines; evidence of implementation | |
OBL-00909 | European Union | EU_ESA | business continuity | Share cyber threat intelligence and information on ICT vulnerabilities and incidents with other financial entities under appropriate confidentiality arrangements. [adjacent] “Financial entities may exchange amongst themselves cyber threat information and intelligence, including indicators of compromise, tactics, techniques, and procedures, cyber alerts and configuration tools” | Art. 45(1) Regulation (EU) 2022/2554 | final | Information-sharing agreements; records of threat intelligence shared/received; confidentiality controls; participation in sector ISACs | |
OBL-00982 | Canada | CA_OSFI | business continuity | Establish and maintain an Enterprise Disaster Recovery Program (EDRP) to support ability to deliver technology services through disruption and operate within risk tolerance. “FRFIs should establish and maintain an Enterprise Disaster Recovery Program (EDRP) to support its ability to deliver technology services through disruption and operate within its risk tolerance.” | OSFI B-13, Section 2.9, Principle 12 | final | Board/Senior Management approved EDRP document; RTO/RPO definitions; accountability matrix; data backup/recovery policy; evidence of alignment with BCM program. | |
OBL-00984 | Canada | CA_OSFI | business continuity | Align the disaster recovery program with the business continuity management program. “FRFIs should align the disaster recovery program with its business continuity management program.” | OSFI B-13, Section 2.9.1 | final | Documentation cross-referencing EDRP and BCM program; shared dependency analysis; integrated test plans; governance records showing joint oversight. | |
OBL-00985 | Canada | CA_OSFI | business continuity | Manage key EDRP dependencies including data security/storage requirements, locations of backup sites, service provider locations relative to primary data centres, and other critical technology assets. “FRFIs should manage key dependencies required to support the EDRP, such as: Information security requirements for data security and storage (e.g., encryption); and, Location of technology asset centres, backup sites, service provider locations and proximity to primary data centres.” | OSFI B-13, Section 2.9.2 | final | Dependency register with geographic/proximity analysis; encryption standards for backup data; inventory of backup and recovery sites; third-party location mapping. | |
OBL-00986 | Canada | CA_OSFI | business continuity | Regularly perform scenario testing on disaster recovery capabilities against severe but plausible scenarios to validate recovery strategies and confirm ability to meet pre-defined requirements. “FRFIs should regularly validate and report on their disaster recovery strategies, plans and/or capabilities against severe but plausible scenarios...The FRFI's backup and recovery capabilities and processes to validate resiliency strategies, plans and actions, and confirm the organization's ability ” | OSFI B-13, Section 2.9.3, Principle 13 | final | DR test schedule; scenario descriptions; test results and gap analysis reports; evidence of senior management reporting on test outcomes. | |
OBL-00987 | Canada | CA_OSFI | business continuity | DR scenario testing must include critical third-party technologies and integration points with upstream/downstream dependencies, both on- and off-premises. “Critical third-party technologies and integration points with upstream and downstream dependencies, including both on- and off-premises technology.” | OSFI B-13, Section 2.9.3 | final | DR test scope documentation listing third-party systems tested; test results for third-party recovery; evidence of joint testing with critical service providers. | |
OBL-00988 | Canada | CA_OSFI | business continuity | DR scenarios must be forward-looking and consider new/emerging risks, material changes to business/technology, situations causing prolonged outage, and prior incident history. “These scenarios should be forward-looking and consider, where appropriate: New and emerging risks or threats; Material changes to business objectives or technologies; Situations that can lead to prolonged outage; and, Previous incident history and known technology complexities or weaknesses.” | OSFI B-13, Section 2.9.3 | final | Scenario library with documented rationale; threat intelligence inputs; post-incident review records used as scenario inputs; refresh log. | |
OBL-00989 | Canada | CA_OSFI | business continuity | Define standards and implement incident/problem management processes including governance structure for timely identification, escalation, system restoration/recovery, and root cause investigation. “FRFIs should define standards and implement processes for incident and problem management. Standards should provide an appropriate governance structure for timely identification and escalation of incidents, restoration and/or recovery of an affected system, and investigation and resolution of incide” | OSFI B-13, Section 2.7.1 | final | Incident management standard/policy; escalation matrix; restoration procedures; RCA process documentation; incident logs. | |
OBL-00990 | Canada | CA_OSFI | business continuity | Implement incident response procedures including internal/external communication with escalation/notification triggers, and establish and periodically test incident management processes with third parties. “Developing and implementing incident response procedures that mitigate the impacts of incidents, including internal and external communication actions that contain escalation and notification triggers and processes...Establishing and periodically testing incident management processes with third part” | OSFI B-13, Section 2.7.2 | final | Incident response playbooks; communication plans with notification thresholds; third-party incident management agreements; joint test records. | |
OBL-00991 | Canada | CA_OSFI | business continuity | Conduct periodic exercises and testing of incident management processes, playbooks, and response tools to validate and maintain their effectiveness. “Performing periodic testing and exercises using plausible scenarios in order to identify and remedy gaps in incident response actions and capabilities; Conducting periodic exercises and testing of incident management process, playbooks, and other response tools (e.g., coordination and communication)” | OSFI B-13, Section 2.7.2 | final | Exercise schedule and after-action reports; playbook review logs; gap remediation tracking; evidence of lessons-learned integration. | |
OBL-00992 | Canada | CA_OSFI | business continuity | Develop problem management processes for detection, categorization, investigation and resolution of incident causes, including post-incident reviews and root cause/impact diagnostics to improve incident management. “FRFIs should develop problem management processes that provide for the detection, categorization, investigation and resolution of suspected incident cause(s). Processes should include post-incident reviews, root cause and impact diagnostics and identification of trends or patterns in incidents.” | OSFI B-13, Section 2.7.3 | final | Problem management process documentation; post-incident review records; trend analysis reports; evidence of process improvements driven by findings. | |
OBL-00993 | Canada | CA_OSFI | business continuity | Design and implement technology architecture using Resilience-by-Design and Availability-by-Design principles, commensurate with business needs. “Using a risk-based approach, systems and associated infrastructure should be designed and implemented to achieve availability, scalability, security (Secure-by-Design) and resilience (Resilience-by-Design), commensurate with business needs.” | OSFI B-13, Section 2.1.2 | final | Architecture framework documentation; design standards referencing resilience/availability requirements; architecture review records; sign-off on new systems against resilience criteria. | |
OBL-00994 | Canada | CA_OSFI | business continuity | Maintain a current comprehensive asset inventory cataloguing technology assets throughout their lifecycle, including documented interdependencies between critical assets to assist in response to security and operational incidents. “Documented interdependencies between critical technology assets, where appropriate, to enable proper change and configuration management processes, and to assist in response to security and operational incidents, including cyber attacks.” | OSFI B-13, Section 2.2.2 | final | Asset inventory system with criticality classification; interdependency maps; process for keeping inventory current; evidence of use during incident response. | |
OBL-00995 | Canada | CA_OSFI | business continuity | Continuously monitor technology currency and proactively implement plans to mitigate risks from unpatched, outdated, or unsupported assets; replace/upgrade assets before maintenance ceases. “FRFIs should continuously monitor the currency of software and hardware assets...It should proactively implement plans to mitigate and manage risks stemming from unpatched, outdated or unsupported assets and replace or upgrade assets before maintenance ceases.” | OSFI B-13, Section 2.2.5 | final | Technology currency monitoring reports; end-of-life asset register; remediation/upgrade plans with timelines; evidence of executive oversight. | |
OBL-00996 | Canada | CA_OSFI | business continuity | Ensure changes to technology assets in production are documented, assessed, tested, approved, implemented and verified in a controlled manner, with defined emergency change controls. [adjacent] “FRFIs should ensure that changes to technology assets in the production environment are documented, assessed, tested, approved, implemented and verified in a controlled manner...The standard should also define emergency change and control requirements to ensure that such changes are implemented in a” | OSFI B-13, Section 2.5.1 | final | Change management policy/standard; change logs; emergency change procedures; post-implementation review records. | |
OBL-00997 | Canada | CA_OSFI | business continuity | Define technology service management standards with performance indicators/service targets and remediation processes to ensure technology services support business continuity. “FRFIs should establish technology service management standards with defined performance indicators and/or service targets that can be used to measure and monitor the delivery of technology services. Processes should also provide for remediation where targets are not being met.” | OSFI B-13, Section 2.8.1 | final | Service management standards; KPI/SLA dashboards; remediation tracking logs; management reporting on service performance. | |
OBL-00998 | Canada | CA_OSFI | business continuity | Define and continuously monitor performance and capacity requirements with thresholds on infrastructure utilisation to ensure technology supports current and future business needs. “FRFIs should define performance and capacity requirements with thresholds on infrastructure utilization. These requirements should be continuously monitored against defined thresholds to ensure technology performance and capacity support current and future business needs.” | OSFI B-13, Section 2.8.2 | final | Capacity management plan; utilisation threshold documentation; monitoring tool outputs; alerts and breach records; capacity planning reports. | |
OBL-00999 | Canada | CA_OSFI | business continuity | Establish cyber incident response capabilities (team, tools, playbooks) available on a continuous basis to rapidly respond, contain and recover from cyber security events materially impacting technology assets. “FRFIs should establish a cyber incident response team with tools and capabilities available on a continuous basis to rapidly respond, contain and recover from cyber security events and incidents that could materially impact the FRFI's technology assets, customers and other stakeholders.” | OSFI B-13, Section 3.4.4 | final | Cyber incident response team charter; on-call rosters; tooling inventory; playbooks; 24/7 availability evidence; test exercise records. | |
OBL-01000 | Canada | CA_OSFI | business continuity | Maintain cyber security incident management process and playbooks to enable timely and effective management of cyber security incidents. “FRFIs should maintain a cyber security incident management process and playbooks to enable timely and effective management of cyber security incidents.” | OSFI B-13, Section 3.4.3 | final | Current cyber incident management process documentation; scenario-specific playbooks; version control records; evidence of regular review and update. | |
OBL-01001 | Canada | CA_OSFI | business continuity | Align and integrate cyber security, technology, crisis management and communication protocols, including capabilities for timely escalation and stakeholder coordination during major cyber events. “FRFIs should ensure the alignment and integration between their cyber security, technology, crisis management and communication protocols. This should include capabilities to enable comprehensive and timely escalation and stakeholder coordination (internal and external) in response to a major cyber ” | OSFI B-13, Section 3.4.1 | final | Integrated cyber-crisis management framework; escalation matrix linking cyber, technology and crisis teams; communication protocols; joint exercise records. | |
OBL-01002 | Canada | CA_OSFI | business continuity | Conduct forensic investigation for incidents where technology assets may have been materially exposed; perform detailed post-incident assessment including RCA for high-severity incidents. “FRFIs should conduct a forensic investigation for incidents where technology assets may have been materially exposed. For high-severity incidents, the FRFI should conduct a detailed post-incident assessment of direct and indirect impacts...including a root cause analysis to identify remediation acti” | OSFI B-13, Section 3.4.5 | final | Forensic investigation reports; post-incident assessment reports; RCA documentation; remediation action plans; tracking of lessons learned. | |
OBL-01003 | Canada | CA_OSFI | business continuity | Maintain continuous security logging for technology assets and defence layers; implement minimum log retention periods; ensure logs support timely forensic investigation of cyber events. [adjacent] “FRFIs should ensure continuous security logging for technology assets and different layers of defence tools...FRFIs should implement minimum security log retention periods and maintain cyber security event logs to facilitate a thorough and unimpeded forensic investigation of cyber security events.” | OSFI B-13, Section 3.3.1 | final | Log management policy with defined retention periods; SIEM configuration; log completeness audit results; evidence that logs were available and usable in recent incidents. | |
OBL-01004 | Canada | CA_OSFI | business continuity | Proactively identify, defend, detect, respond and recover from cyber security threats and incidents to maintain confidentiality, integrity and availability of technology assets. “FRFIs should proactively identify, defend, detect, respond and recover from external and insider cyber security threats, events and incidents to maintain the confidentiality, integrity and availability of its technology assets.” | OSFI B-13, Section 3.0 | final | Cyber resilience framework documentation; threat assessment records; detection tool evidence; response/recovery playbooks; post-incident recovery evidence. | |
OBL-01005 | Canada | CA_OSFI | business continuity | Implement enhanced controls to rapidly contain cyber threats, defend critical technology assets, and remain resilient against cyber attacks, including designing application controls to limit cyber attack impact. “FRFIs should employ enhanced controls and functionality to rapidly contain cyber security threats, defend its critical technology assets and remain resilient against cyber attacks...Designing application controls to contain and limit the impact of a cyber attack.” | OSFI B-13, Section 3.2.3 | final | Critical asset register with associated enhanced controls; containment control documentation; security hardening baselines; control testing results. | |
OBL-01006 | Canada | CA_OSFI | business continuity | Establish technology and cyber risk management framework including risk appetite, tolerance levels, and processes for identifying, assessing, managing and reporting technology/cyber risks including emerging threats. [adjacent] “Technology and cyber risk appetite and measurement (e.g., limits, thresholds and tolerance levels)...Management of unique risks posed by emerging threats and technologies...Reporting to Senior Management on technology and cyber risk appetite measures, exposures and trends.” | OSFI B-13, Section 1.3.2 | final | Approved RMF with risk appetite statements; tolerance thresholds; risk reporting dashboards; emerging risk process documentation; board/senior management reporting records. | |
OBL-01008 | European Union | EU_AI | artificial intelligence | Providers of high-risk AI systems must establish a quality management system ensuring the AI system meets robustness, accuracy and cybersecurity requirements throughout its lifecycle. [adjacent] “Providers of high-risk AI systems shall put a quality management system in place that ensures compliance with this Regulation.” | Art. 17(1) | final | Written QMS documentation covering robustness/cybersecurity controls; audit trail; version control records | |
OBL-01009 | European Union | EU_AI | artificial intelligence | High-risk AI systems must be designed and developed to achieve appropriate levels of accuracy, robustness and cybersecurity, and to perform consistently in those respects throughout their lifecycle. [adjacent] “High-risk AI systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness and cybersecurity, and that they perform consistently in those respects throughout their lifecycle.” | Art. 15(1) | final | Technical documentation showing robustness/cybersecurity design measures; test results; lifecycle maintenance records | |
OBL-01010 | European Union | EU_AI | artificial intelligence | High-risk AI systems must be resilient against attempts by third parties to alter their use or performance through adversarial attacks exploiting system vulnerabilities. “High-risk AI systems shall be resilient as regards attempts by unauthorised third parties to alter their use, outputs or performance by exploiting the system vulnerabilities.” | Art. 15(3) | final | Adversarial testing reports; penetration test results; vulnerability management log; incident response procedures | |
OBL-01011 | European Union | EU_AI | artificial intelligence | High-risk AI systems must have technical redundancy solutions, including backup or fail-safe plans, to ensure continuity of operation when failures occur. “The technical robustness and safety measures shall include redundancy solutions, which may include backup or fail-safe plans.” | Art. 15(4) | final | Documented backup/fail-safe architecture; failover test results; continuity runbooks | |
OBL-01012 | European Union | EU_AI | artificial intelligence | Providers of high-risk AI systems must establish post-market monitoring systems to proactively collect and review data on system performance and safety after deployment. [adjacent] “Providers of high-risk AI systems shall establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system.” | Art. 72(1) | final | Post-market monitoring plan; performance dashboards; incident/anomaly logs; periodic review reports | |
OBL-01013 | European Union | EU_AI | artificial intelligence | Providers must report serious incidents involving high-risk AI systems to market surveillance authorities immediately and in any event within prescribed timeframes. [adjacent] “Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred.” | Art. 73(1) | final | Incident reporting procedure; incident log with timestamps; regulatory notification records within required timeframes | |
OBL-01014 | European Union | EU_AI | artificial intelligence | Providers of high-risk AI systems must immediately take corrective actions, including withdrawal or recall, when the system presents a risk, and inform distributors, deployers and authorities accordingly. [adjacent] “Providers of high-risk AI systems which consider or have reason to consider that a high-risk AI system that they have placed on the market or put into service is not in conformity with this Regulation shall immediately take the necessary corrective actions to bring that system into conformity.” | Art. 20(1) | final | Corrective action log; recall/withdrawal procedures; communications to deployers and authorities | |
OBL-01015 | European Union | EU_AI | artificial intelligence | High-risk AI systems must enable human oversight including the ability to override, interrupt or shut down the system to prevent or minimise risks. [adjacent] “High-risk AI systems shall be designed and developed in such a way to enable the persons to whom human oversight is assigned to be able to … intervene on the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure.” | Art. 14(4)(e) | final | Technical design documentation showing stop/override functionality; human oversight procedures; operator training records | |
OBL-01016 | European Union | EU_AI | artificial intelligence | High-risk AI systems must automatically detect and flag failures, faults, or inconsistencies that may result in risks, and be able to operate in a safe state in the event of such failures. “High-risk AI systems shall be resilient as regards … errors, faults or inconsistencies that may occur within the system or the environment in which the system operates, in particular due to their interaction with natural persons or other systems.” | Art. 15(3) | final | Fault detection test records; safe-state design documentation; automated alerting configuration | |
OBL-01017 | European Union | EU_AI | artificial intelligence | Deployers of high-risk AI systems must monitor system operation on the basis of instructions of use and report to the provider any risks or incidents identified during use. [adjacent] “Deployers of high-risk AI systems shall monitor the operation of the high-risk AI system on the basis of the instructions for use and, where relevant, inform providers about serious incidents.” | Art. 26(5) | final | Operational monitoring logs; incident reports sent to providers; documented review cadence per instructions of use | |
OBL-01018 | European Union | EU_AI | artificial intelligence | Providers of general-purpose AI models with systemic risk must perform adversarial testing and red-teaming to identify and mitigate systemic risks including cybersecurity vulnerabilities. [adjacent] “Providers of general-purpose AI models with systemic risk shall … perform model evaluation in accordance with standardised protocols and tools … including adversarial testing of the model to identify and mitigate systemic risks.” | Art. 55(1)(a) | final | Red-team/adversarial test plans and results; risk mitigation records; model evaluation reports | |
OBL-01019 | European Union | EU_AI | artificial intelligence | Providers of general-purpose AI models with systemic risk must assess and mitigate systemic risks including risks to critical infrastructure and serious cyber threats. [adjacent] “Providers of general-purpose AI models with systemic risk shall … assess and mitigate possible systemic risks, including their sources, that may stem from the development, the placing on the market, or the use of general-purpose AI models with systemic risk.” | Art. 55(1)(b) | final | Systemic risk assessment report covering critical infrastructure and cyber threat scenarios; mitigation plan | |
OBL-01020 | European Union | EU_AI | artificial intelligence | Providers of general-purpose AI models with systemic risk must track, document and report serious incidents and possible corrective measures to the AI Office without undue delay. [adjacent] “Providers of general-purpose AI models with systemic risk shall … track, document and report, without undue delay, to the AI Office and, as applicable, to national competent authorities, relevant information about serious incidents and possible corrective measures.” | Art. 55(1)(c) | final | Incident tracking log; documented corrective measures; notification records to AI Office; timestamps of reports | |
OBL-01021 | European Union | EU_AI | artificial intelligence | Providers of general-purpose AI models with systemic risk must ensure adequate cybersecurity protection for the model and its physical infrastructure. [adjacent] “Providers of general-purpose AI models with systemic risk shall … ensure an adequate level of cybersecurity protection for the general-purpose AI model with systemic risk and the physical infrastructure of the model.” | Art. 55(1)(d) | final | Cybersecurity policy; infrastructure hardening records; penetration test results; access control documentation | |
OBL-01022 | European Union | EU_AI | artificial intelligence | Providers of high-risk AI systems must keep automatically generated logs for the period appropriate to the intended purpose, to enable incident investigation and monitoring. [adjacent] “High-risk AI systems shall technically allow for the automatic recording of events ('logs') over the lifetime of the system.” | Art. 12(1) | final | Log retention policy; automated logging configuration; sample logs demonstrating traceability of events | |
OBL-01023 | European Union | EU_AI | artificial intelligence | Providers must ensure high-risk AI systems have automatic logging capabilities that enable reconstruction of events over the period of the AI system's use to support post-incident investigation. “The logging capabilities shall ensure a level of traceability of the AI system's functioning throughout its lifetime that is appropriate to the intended purpose of the system.” | Art. 12(2) | final | Logging architecture documentation; evidence that logs capture sufficient events for incident reconstruction; retention schedule | |
OBL-01024 | European Union | EU_AI | artificial intelligence | Deployers of high-risk AI systems must retain logs automatically generated by the system for a minimum period as applicable, to support incident investigation and regulatory oversight. [adjacent] “Deployers of high-risk AI systems shall retain the logs automatically generated by that high-risk AI system to the extent such logs are under their control.” | Art. 26(6) | final | Log retention records; access controls on logs; documented retention periods; log inventory | |
OBL-01025 | European Union | EU_AI | artificial intelligence | Providers must include instructions for use with high-risk AI systems specifying the expected lifetime and maintenance/servicing measures required to ensure continued safe and accurate operation. [adjacent] “The instructions for use shall include … where relevant, a description of the maintenance and care measures … to ensure that the AI system continues to comply with the requirements set out in this Chapter.” | Art. 13(3)(b)(v) | final | Instructions for use document containing maintenance schedules and servicing requirements; evidence of provision to deployers | |
OBL-01029 | European Union | EU_AI | artificial intelligence | National competent authorities must conduct market surveillance of AI systems to detect, investigate and remedy non-conformities that present risks, including operational and cybersecurity risks. [adjacent] “Market surveillance authorities shall perform market surveillance of AI systems made available on the market, put into service or used in the Union in accordance with this Regulation.” | Art. 74(1) | final | Market surveillance programme documentation; investigation records; risk-based inspection plans; corrective action orders | |
OBL-01031 | European Union | EU_AI | artificial intelligence | Providers and deployers of AI systems used by critical infrastructure operators must ensure those systems meet all high-risk AI system requirements including robustness and continuity of safe operation. “High-risk AI systems referred to in Article 6(2) are the AI systems listed in any of the following areas: … 2. AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating or electricity.” | Annex III, point 2 | final | Classification assessment confirming critical infrastructure scope; conformity documentation; operational resilience test evidence | |
OBL-01032 | European Union | EU_AI | artificial intelligence | Providers of high-risk AI systems must systematically perform conformity assessments including evaluation of robustness and cybersecurity requirements before placing the system on the market or putting it into service. [adjacent] “For high-risk AI systems listed in Annex III, the conformity assessment shall be carried out by the provider … prior to placing it on the market or putting it into service.” | Art. 43(1) | final | Completed conformity assessment records; third-party audit reports where applicable; technical file cross-reference | |
OBL-01033 | United Kingdom | UK_FCA | business continuity | Identify important business services (IBS) — those whose disruption could cause intolerable harm to clients or risk to market integrity. “our rules only require firms to identify their important business services for the purposes of operational resilience” | SYSC 15A.2.1R–2R | final | Documented register of IBS with rationale; board or senior management sign-off; annual review records | |
OBL-01034 | United Kingdom | UK_FCA | business continuity | Review IBS at least annually or upon any material change to the business or market. “firms will need to review their important business services at least once per year, or whenever there is a material change to their business or the market in which they operate” | SYSC 15A.2.1R–2R | final | Annual review log with date, scope, and outcome; change-management trigger records | |
OBL-01035 | United Kingdom | UK_FCA | business continuity | Set an impact tolerance for each IBS at the first point at which disruption would cause intolerable harm to clients or risk to market integrity. “firms should set their impact tolerances at the first point at which a disruption to an important business service would cause intolerable levels of harm to consumers or risk to market integrity” | SYSC 15A.2.1R–2R; SYSC 15A.2.7G | final | Written impact tolerance statements per IBS, signed off by board; methodology documentation | |
OBL-01036 | United Kingdom | UK_FCA | business continuity | Use time/duration as a mandatory metric when measuring impact tolerances, supplemented by additional metrics as appropriate. “we are proceeding as consulted to require that firms use time/duration as a mandatory metric to measure their impact tolerances” | SYSC 15A.2.1R–2R | final | Impact tolerance documents specifying a time-based threshold (e.g. hours/days or end-of-day) per IBS, with any additional metrics | |
OBL-01037 | United Kingdom | UK_FCA | business continuity | Review impact tolerances at least annually or upon material change to the business or market. “firms should set and review their impact tolerances at least once per year or if there is a relevant change to the firm's business or the market in which it operates” | SYSC 15A.2.1R–2R | final | Annual tolerance review records; change-triggered review logs | |
OBL-01038 | United Kingdom | UK_FCA | business continuity | Remain within impact tolerances as soon as reasonably practicable, and no later than 31 March 2025. “Firms must be able to remain within their impact tolerances as soon as reasonably practicable, but no later than 3 years after the rules come into effect on 31 March 2022” | PS21/3 Chapter 1 para 1.32 | final | Board attestation that firm operates within all IBS tolerances; testing evidence; gap-closure roadmap | |
OBL-01039 | United Kingdom | UK_FCA | business continuity | Map each IBS by identifying and documenting the people, processes, technology, facilities and information that support it. “firms have a clear picture of the resources that enable an important business service to function... by identifying and documenting the people, processes, technology, facilities and information that support them” | SYSC 15A | final | IBS mapping artefacts (process maps, dependency registers, asset inventories) for each IBS | |
OBL-01040 | United Kingdom | UK_FCA | business continuity | Capture internal processes (e.g. payroll, IT services) that support IBS delivery within mapping exercises. “internal processes... which are necessary to the provision of important business services and should be captured by firms as part of their mapping exercises” | SYSC 15A | final | Mapping documentation that includes supporting internal processes with linkage to relevant IBS | |
OBL-01041 | United Kingdom | UK_FCA | business continuity | Conduct scenario testing of each IBS against severe but plausible scenarios to assess ability to remain within impact tolerances. “firms need to test their impact tolerances in a range of severe but plausible scenarios. This approach will give firms a clear idea when they initially test their impact tolerances of where such unexpected events may mean they cannot remain within tolerance” | SYSC 15A | final | Scenario testing plan; test results per IBS per scenario; remediation actions; board reporting | |
OBL-01042 | United Kingdom | UK_FCA | business continuity | Include cyber-attacks as a scenario category in scenario testing plans for IBS. “multiple important business services could be disrupted simultaneously due to an external factor directly affecting the service. For example, this could be due to a cyber-attack which hits a wide range of operational assets” | SYSC 15A; PS21/3 Chapter 3 para 3.12 | final | Scenario testing records explicitly including cyber-attack scenarios; test outcomes and remediation steps | |
OBL-01043 | United Kingdom | UK_FCA | business continuity | Consider the simultaneous disruption of multiple IBS in testing plans, including shared underlying systems, processes or people. “for substitute services which rely on the same systems, processes or people, firms should not assume, as part of their testing plans, that these services won't be affected in the event of disruption” | SYSC 15A; PS21/3 Chapter 3 para 3.12 | final | Multi-IBS disruption scenario plans; dependency analysis showing common assets; test results | |
OBL-01044 | United Kingdom | UK_FCA | business continuity | Identify key staff pivotal to delivering each IBS and maintain contingency plans for their incapacitation. “firms need to understand which staff are pivotal to delivering an important business service, with contingency plans if those staff become incapacitated” | SYSC 15A; PS21/3 Chapter 1 para 1.21 | final | Key-person register per IBS; documented contingency/succession plans; evidence of testing | |
OBL-01045 | United Kingdom | UK_FCA | business continuity | Report to the FCA any failure to remain within impact tolerances in line with SYSC 15A.2.11G. “if despite extensive scenario testing a firm finds itself not able to remain within impact tolerance for any reason, it should report the issue to the FCA in line with SYSC 15A.2.11G” | SYSC 15A.2.11G | final | Incident log; breach notification records submitted to FCA; internal escalation policy referencing SYSC 15A.2.11G | |
OBL-01046 | United Kingdom | UK_FCA | business continuity | Also report to the FCA where resuming a compromised service would cause further detriment (e.g. spreading a computer virus). “firms should consider such circumstances in their testing plans and report any issue with remaining in tolerance to the FCA in line with SYSC 15A.2.11G” | SYSC 15A.2.11G; PS21/3 Chapter 3 | final | Decision framework for safe resumption of compromised services; FCA notification records; board/SMF sign-off | |
OBL-01047 | United Kingdom | UK_FCA | business continuity | When outsourcing IBS to third parties, work effectively with those providers to set and remain within impact tolerances; responsibility remains with the firm. “When a firm is using a third-party provider in the provision of important business services, it should work effectively with that provider to set and remain within impact tolerances. Ultimately, the requirements... remain the responsibility of the firm” | SYSC 15A; PS21/3 Chapter 3 para 3.14 | final | Outsourcing contracts referencing impact tolerances; third-party assurance reports; joint testing records | |
OBL-01048 | United Kingdom | UK_FCA | business continuity | Identify and manage third-party dependencies (including cloud providers and technology vendors) within IBS mapping to address concentration and continuity risk. “the pandemic highlighted increasing dependence on third parties and outsourcing arrangements... some firms experienced challenges with offshore third-party providers... which affected continuity of service to UK consumers” | SYSC 15A; PS21/3 Chapter 1 para 1.19(b) | final | Third-party dependency register per IBS; concentration risk assessment; contingency plans for critical provider failure | |
OBL-01049 | United Kingdom | UK_FCA | business continuity | Ensure scenario testing incorporates third-party/outsourced service disruptions, including offshore provider lockdowns. “some firms experienced challenges with offshore third-party providers, particularly where providers were under lockdown in another geographical location, which affected continuity of service” | SYSC 15A; PS21/3 Chapter 1 para 1.19(b) | final | Testing scenarios covering third-party failure; offshore lockdown scenarios; test results and remediation plans | |
OBL-01050 | United Kingdom | UK_FCA | business continuity | Identify the users of each IBS so that impacts of disruption are clear and communications/alternative mechanisms can be targeted. “users of the service should be identifiable so that the impacts of disruption (through process, cyber security or technology failures) are clear” | SYSC 15A.2.4G(1); PS21/3 Chapter 2 para 2.21 | final | Service-user identification records per IBS; segmentation analysis including vulnerable consumers | |
OBL-01051 | United Kingdom | UK_FCA | business continuity | Consider the needs of vulnerable consumers when setting impact tolerances and design communications/alternative mechanisms to minimise their harm during disruptions. “Consideration of the needs of vulnerable consumers is central to a firm's setting of an impact tolerance, and firms should consider these groups when considering how much disruption could be tolerated. Firms should also construct communications and alternative mechanisms to minimise harms” | SYSC 15A.2.7G | final | Tolerance rationale documents referencing vulnerable consumer analysis; communications plan for disruption events | |
OBL-01052 | United Kingdom | UK_FCA | business continuity | Dual-regulated firms must set up to 2 impact tolerances per IBS — one aligned to FCA objectives and one aligned to PRA objectives. “For dual-regulated firms, we maintain the position that these firms should set up to 2 impact tolerances. This is to ensure that firms consider their impact tolerances in line with the statutory objectives of each authority” | SYSC 15A; PS21/3 Chapter 3 para 3.18–3.20 | final | Two documented impact tolerances per IBS with distinct FCA/PRA rationale; board approval records | |
OBL-01053 | United Kingdom | UK_FCA | business continuity | Dual-regulated firms' recovery and response arrangements must be viable for both shorter and longer impact tolerance periods. “its recovery and response arrangements are also appropriate for the longer tolerance (ie recovery and response arrangements must be viable for both shorter and longer time periods)” | SYSC 15A; PS21/3 Chapter 3 para 3.20 | final | Recovery/response plan documentation demonstrating viability across both tolerance periods; test evidence | |
OBL-01054 | United Kingdom | UK_FCA | business continuity | Where group-level impact tolerances differ from entity-level tolerances, the group Board must consider, approve and resource the entity's tolerance. “In situations where an entity sets an impact tolerance at a lower level than that set by the group, the group's Board should consider and approve... and ensure that the entity has appropriate resources to meet its identified tolerance” | PS21/3 Chapter 3 para 3.10 | final | Board minutes approving entity-level tolerances; resource allocation documentation; group vs entity tolerance comparison | |
OBL-01055 | United Kingdom | UK_FCA | business continuity | Assess, before resuming a degraded service, whether (a) it can safely resume without causing further detriment and (b) resumption benefits outweigh keeping the service unavailable. “firms should consider whether (a) the degraded service can safely resume without causing further detriment and (b) the benefits of resuming a degraded service outweigh the negatives of keeping the service unavailable until the issues have been remediated” | SYSC 15A.2.11G; PS21/3 Chapter 3 | final | Documented safe-resumption decision framework; incident records showing application of criteria; SMF sign-off | |
OBL-01057 | United Kingdom | UK_FCA | business continuity | Payments/e-money firms must apply operational resilience requirements only to their payments and/or e-money activities where other FSMA activities are not in scope. “payments firms only have to apply our operational resilience proposals to their payments and/or e-money activities. To clarify this, we have amended SYSC 15A.1 (Application)” | SYSC 15A.1 | final | Scoping documentation confirming which activities are subject to SYSC 15A; rationale for exclusion of any FSMA activities | |
OBL-01162 | United States (NY) | NYDFS | business continuity | Maintain a cybersecurity program that includes the ability to recover from Cybersecurity Events and restore normal operations and services. “recover from Cybersecurity Events and restore normal operations and services” | 23 NYCRR 500.2(b)(5) | final | Written cybersecurity program documentation showing recovery capabilities; incident response records demonstrating restoration of operations | |
OBL-01164 | United States (NY) | NYDFS | business continuity | Include systems availability concerns in the written cybersecurity policy. “systems operations and availability concerns” | 23 NYCRR 500.3(f) | final | Written cybersecurity policy containing systems availability section; review and approval records | |
OBL-01165 | United States (NY) | NYDFS | business continuity | Include incident response procedures in the written cybersecurity policy. “incident response” | 23 NYCRR 500.3(n) | final | Written cybersecurity policy with incident response section; board/Senior Officer approval documentation | |
OBL-01166 | United States (NY) | NYDFS | business continuity | Establish and maintain audit trail systems designed to reconstruct material financial transactions sufficient to support normal operations, retained for at least five years. [adjacent] “designed to reconstruct material financial transactions sufficient to support normal operations and obligations of the Covered Entity” | 23 NYCRR 500.6(a)(1), 500.6(b) | final | Audit trail system documentation; data retention policy; records proving 5-year retention; system architecture diagrams | |
OBL-01167 | United States (NY) | NYDFS | business continuity | Maintain audit trails designed to detect and respond to Cybersecurity Events that could materially harm normal operations, retained for at least three years. “audit trails designed to detect and respond to Cybersecurity Events that have a reasonable likelihood of materially harming any material part of the normal operations” | 23 NYCRR 500.6(a)(2), 500.6(b) | final | Audit log configurations; 3-year retention records; evidence of logs used in incident detection and response | |
OBL-01168 | United States (NY) | NYDFS | business continuity | Conduct a periodic Risk Assessment that considers availability and effectiveness of controls to protect Information Systems, updated as necessary to address changes in operations. “the availability and effectiveness of controls to protect Nonpublic Information and Information Systems” | 23 NYCRR 500.9(a) | final | Documented Risk Assessment reports; update history; written policies and procedures governing the assessment process | |
OBL-01169 | United States (NY) | NYDFS | business continuity | Ensure qualified cybersecurity personnel are sufficient to perform or oversee recovery from Cybersecurity Events (core cybersecurity function 500.2(b)(5)). “qualified cybersecurity personnel...sufficient to manage the Covered Entity's cybersecurity risks and to perform or oversee the performance of the core cybersecurity functions specified in section 500.2(b)(1)-(6)” | 23 NYCRR 500.10(a)(1) | final | Staffing records; roles and responsibilities documentation; training records; third-party service agreements if outsourced | |
OBL-01170 | United States (NY) | NYDFS | business continuity | Implement written policies and procedures governing Third Party Service Providers' cybersecurity practices, including periodic assessment based on risk they present. “periodic assessment of such Third Party Service Providers based on the risk they present and the continued adequacy of their cybersecurity practices” | 23 NYCRR 500.11(a)(4) | final | Written TPSP policy; periodic assessment records; risk-tiering documentation; vendor review schedule | |
OBL-01171 | United States (NY) | NYDFS | business continuity | Require Third Party Service Providers to provide notice to the Covered Entity upon any Cybersecurity Event directly impacting the Covered Entity's Information Systems or its Nonpublic Information. [adjacent] “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” | 23 NYCRR 500.11(b)(3) | final | Vendor contracts with notification clauses; incident notification logs from TPSPs; due diligence checklists | |
OBL-01172 | United States (NY) | NYDFS | business continuity | Establish a written incident response plan designed to promptly respond to and recover from Cybersecurity Events affecting availability or continuing functionality of business operations. “written incident response plan designed to promptly respond to, and recover from, any Cybersecurity Event materially affecting...the continuing functionality of any aspect of the Covered Entity's business or operations” | 23 NYCRR 500.16(a) | final | Written IRP document; approval records; test/exercise results; post-incident review reports | |
OBL-01173 | United States (NY) | NYDFS | business continuity | Ensure the incident response plan defines clear roles, responsibilities, and decision-making authority for responding to and recovering from Cybersecurity Events. “the definition of clear roles, responsibilities and levels of decision-making authority” | 23 NYCRR 500.16(b)(3) | final | IRP with named roles and decision matrix; organizational charts; contact lists | |
OBL-01174 | United States (NY) | NYDFS | business continuity | Ensure the incident response plan addresses external and internal communications and information sharing during a Cybersecurity Event. “external and internal communications and information sharing” | 23 NYCRR 500.16(b)(4) | final | IRP communication protocols; stakeholder notification templates; media/regulator communication procedures | |
OBL-01175 | United States (NY) | NYDFS | business continuity | Ensure the incident response plan addresses identification and remediation of weaknesses in Information Systems and controls following a Cybersecurity Event. “identification of requirements for the remediation of any identified weaknesses in Information Systems and associated controls” | 23 NYCRR 500.16(b)(5) | final | Post-incident remediation tracking logs; vulnerability remediation reports; control improvement documentation | |
OBL-01176 | United States (NY) | NYDFS | business continuity | Ensure the incident response plan requires documentation and reporting regarding Cybersecurity Events and incident response activities. “documentation and reporting regarding Cybersecurity Events and related incident response activities” | 23 NYCRR 500.16(b)(6) | final | Incident log/register; after-action reports; regulatory notification records; internal reporting templates | |
OBL-01177 | United States (NY) | NYDFS | business continuity | Evaluate and revise the incident response plan as necessary following a Cybersecurity Event. “the evaluation and revision as necessary of the incident response plan following a Cybersecurity Event” | 23 NYCRR 500.16(b)(7) | final | Post-incident review records; IRP version history showing updates triggered by events; lessons-learned documentation | |
OBL-01178 | United States (NY) | NYDFS | business continuity | Notify the Superintendent within 72 hours of determining a Cybersecurity Event with reasonable likelihood of materially harming normal operations has occurred. “no event later than 72 hours from a determination that a Cybersecurity Event has occurred...Cybersecurity Events that have a reasonable likelihood of materially harming any material part of the normal operation(s) of the Covered Entity” | 23 NYCRR 500.17(a)(2) | final | Incident notification log with timestamps; DFS portal submission records; internal escalation procedure tied to 72h clock | |
OBL-01179 | United States (NY) | NYDFS | business continuity | Notify the Superintendent within 72 hours of determining a Cybersecurity Event requiring notice to any government body or regulatory/self-regulatory agency has occurred. [adjacent] “no event later than 72 hours from a determination that a Cybersecurity Event has occurred...Cybersecurity Events impacting the Covered Entity of which notice is required to be provided to any government body, self-regulatory agency or any other supervisory body” | 23 NYCRR 500.17(a)(1) | final | Multi-regulator notification log; mapping of events to notification triggers; DFS submission timestamps | |
OBL-01180 | United States (NY) | NYDFS | business continuity | Include in the cybersecurity program monitoring and testing—including penetration testing and vulnerability assessments—to assess program effectiveness, supporting detection and response to threats that could disrupt operations. [adjacent] “monitoring and testing, developed in accordance with the Covered Entity's Risk Assessment, designed to assess the effectiveness of the Covered Entity's cybersecurity program...annual Penetration Testing...bi-annual vulnerability assessments” | 23 NYCRR 500.5 | final | Annual pen test reports; bi-annual vulnerability scan results; Risk Assessment linking tests to identified risks | |
OBL-01181 | United States (NY) | NYDFS | business continuity | Maintain a cybersecurity program designed to protect the availability of the Covered Entity's Information Systems. “maintain a cybersecurity program designed to protect the confidentiality, integrity and availability of the Covered Entity's Information Systems” | 23 NYCRR 500.2(a) | final | Written cybersecurity program documentation explicitly addressing availability; program review records | |
OBL-01182 | United States (NY) | NYDFS | business continuity | Include in the cybersecurity program the ability to detect and respond to Cybersecurity Events to mitigate negative effects on operations. “respond to identified or detected Cybersecurity Events to mitigate any negative effects” | 23 NYCRR 500.2(b)(4) | final | Cybersecurity program documentation covering response capabilities; SOC/detection tool evidence; response runbooks | |
OBL-01183 | United States (NY) | NYDFS | business continuity | Implement written TPSP policies that include minimum cybersecurity practices required of third parties, supporting resilience of systems accessible to or held by those 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” | 23 NYCRR 500.11(a)(2) | final | Written TPSP policy with minimum standards; vendor onboarding checklists; contract clauses referencing standards | |
OBL-01184 | United States (NY) | NYDFS | business continuity | Make available to the Superintendent upon request all documentation relevant to the cybersecurity program, including BCDR and incident response components. [adjacent] “All documentation and information relevant to the Covered Entity's cybersecurity program shall be made available to the superintendent upon request” | 23 NYCRR 500.2(d) | final | Document repository of cybersecurity program materials; index of BCDR/IRP documents; retrieval procedure | |
OBL-01185 | United States (NY) | NYDFS | business continuity | Maintain records supporting the annual compliance certification for five years, including documentation of remedial efforts for identified areas requiring improvement. [adjacent] “maintain for examination by the Department all records, schedules and data supporting this certificate for a period of five years...document the identification and the remedial efforts planned and underway” | 23 NYCRR 500.17(b) | final | Five-year archive of compliance records; remediation tracking logs; annual certifications filed with DFS | |
OBL-01186 | United States (NY) | NYDFS | business continuity | Include vendor and Third Party Service Provider management in the written cybersecurity policy to address resilience risks from third-party dependencies. “vendor and Third Party Service Provider management” | 23 NYCRR 500.3(l) | final | Cybersecurity policy with TPSP management section; board/Senior Officer approval; vendor risk register | |
OBL-01189 | United States (NY) | NYDFS | crisis management | Maintain cybersecurity programs, policies, and procedures based on Risk Assessments that account for AI-related risks including deepfakes, threats from TPSPs' AI use, and AI vulnerabilities affecting availability of Information Systems. “Covered Entities should address AI-related risks in the following areas: the organization's own use of AI, the AI technologies utilized by TPSPs and vendors, and any potential vulnerabilities stemming from AI applications that could pose a risk to the confidentiality, integrity, and availability of ” | 23 NYCRR §§ 500.2 and 500.3 | proposed | Written cybersecurity program/policies referencing AI risks; current Risk Assessment documenting AI threat analysis; policy update log. | |
OBL-01190 | United States (NY) | NYDFS | crisis management | Update Risk Assessments at least annually and whenever a material change in business or technology affects cybersecurity risk, ensuring new AI-related risks are assessed and reflected in updated policies and procedures. [adjacent] “The Cybersecurity Regulation requires Risk Assessments to be updated at least annually and whenever a change in the business or technology causes a material change to a Covered Entity's cybersecurity risk to ensure new risks, including those posed by AI, are assessed.” | 23 NYCRR §§ 500.2, 500.3, and 500.9 | proposed | Dated Risk Assessment records showing annual refresh; change-triggered reassessment logs; documented policy updates following each assessment. | |
OBL-01191 | United States (NY) | NYDFS | crisis management | Maintain TPSP policies and procedures including due diligence guidelines addressing AI-related cybersecurity risks posed by third-party service providers, including how TPSPs protect against AI-enabled threats that could impact the Covered Entity. [adjacent] “One of the most important requirements for combatting AI-related risks is to maintain TPSP policies and procedures that include guidelines for conducting due diligence before a Covered Entity uses a TPSP that will access its Information Systems and/or NPI.” | 23 NYCRR § 500.11(a) | proposed | Written TPSP policy with AI-risk due diligence criteria; vendor assessment questionnaires addressing AI use; contractual provisions on AI security. | |
OBL-01192 | United States (NY) | NYDFS | crisis management | Require TPSPs to provide timely notification of any Cybersecurity Event that directly impacts the Covered Entity's Information Systems or NPI held by the TPSP, including AI-related threats. “Covered Entities should require TPSPs to provide timely notification of any Cybersecurity Event that directly impacts the Covered Entity's Information Systems or NPI held by the TPSP, including threats related to AI.” | 23 NYCRR § 500.11(a) | proposed | TPSP contracts containing incident notification clauses; incident notification tracking log; SLA documentation for notification timelines. | |
OBL-01193 | United States (NY) | NYDFS | crisis management | Maintain a monitoring process to promptly identify new security vulnerabilities in Information Systems (especially those holding NPI) to enable rapid remediation, including monitoring relevant to AI-enabled attacks. [adjacent] “Covered Entities must have a monitoring process in place that can identify new security vulnerabilities promptly so remediation can occur quickly.” | 23 NYCRR § 500.5(b) | proposed | Documented vulnerability monitoring program; scan frequency records; remediation tracking log; evidence of AI-related threat monitoring coverage. | |
OBL-01194 | United States (NY) | NYDFS | crisis management | Monitor Authorized User activity and email/web traffic to block malicious content and protect against installation of malicious code, including monitoring for unusual AI-related query behaviors that may indicate NPI exfiltration. [adjacent] “Covered Entities must monitor the activity of Authorized Users as well as email and web traffic to block malicious content and protect against the installation of malicious code on their Information Systems.” | 23 NYCRR §§ 500.5(b) and 500.14(a)(1)-(2) | proposed | User activity monitoring logs; email/web filtering configuration; policies on blocking NPI queries to public AI systems; monitoring alert records. | |
OBL-01195 | United States (NY) | NYDFS | crisis management | Implement MFA for all Authorized Users attempting to access Covered Entities' Information Systems or NPI, including customers, employees, contractors, and TPSPs, using factors resilient to AI-enabled deepfake attacks. [adjacent] “As of November 2025, the Cybersecurity Regulation will require MFA to be in place for all Authorized Users attempting to access Covered Entities' Information Systems or NPI, including customers, employees, contractors, and TPSPs.” | 23 NYCRR § 500.12 | proposed | MFA configuration records covering all user categories; Risk Assessment justifying authentication factor choices; evidence of deepfake-resistant factors where appropriate. | |
OBL-01196 | United States (NY) | NYDFS | crisis management | Implement access controls limiting each Authorized User's access privileges to only those necessary for their job functions, limiting elevated permissions, and periodically (at minimum annually) reviewing and removing unnecessary access privileges. [adjacent] “The controls must limit an Authorized User's access privileges to only those necessary for that Authorized User's job functions, and limit the number of Authorized Users with elevated permissions and access to NPI.” | 23 NYCRR § 500.7(a)(1),(2),(4),(5),(6) | proposed | Access control policy; annual access review records; privilege de-provisioning logs; terminated-user access removal evidence. | |
OBL-01198 | United States (NY) | NYDFS | crisis management | Maintain and update a data inventory of all Information Systems, with priority on AI-related systems critical to ongoing business operations, to support breach response and continuity. “Covered Entities should maintain and update data inventories as they are crucial for assessing potential risks and ensuring compliance with data protection regulations. Data inventories further help entities track NPI so that if there is a breach, they know what NPI may have been exposed.” | 23 NYCRR § 500.13(a) | proposed | Asset/data inventory records including AI systems; inventory update procedures; evidence of prioritization of AI-critical systems. | |
OBL-01199 | United States (NY) | NYDFS | crisis management | Identify all Information Systems that use or rely on AI (including AI-enabled products/services), maintain an inventory of such systems, and prioritize implementing mitigations for systems critical to ongoing business operations. [adjacent] “Entities should identify all Information Systems that use or rely on AI, including, if applicable, the Information Systems that maintain, or rely on, AI-enabled products and services... and prioritize implementing mitigations for those systems that are critical for ongoing business operations.” | 23 NYCRR § 500.13 | proposed | Documented AI systems inventory; criticality classification; mitigation priority matrix; evidence of remediation actions for critical AI systems. | |
OBL-01200 | United States (NY) | NYDFS | crisis management | Implement data governance procedures covering collection, storage, processing, and disposal of data, including controls to prevent threat actors from accessing data maintained for AI functioning. [adjacent] “Entities should implement data governance procedures that include data collection, storage, processing, and disposal. Moreover, if an entity uses AI or relies on a product that uses AI, controls should be in place to prevent threat actors from accessing the vast amounts of data maintained for the ac” | 23 NYCRR § 500.3(b) | proposed | Data governance policy; controls documentation for AI data stores; access controls evidence for AI training/inference datasets. | |
OBL-01201 | United States (NY) | NYDFS | crisis management | Provide at least annual cybersecurity awareness training for all personnel that includes social engineering (including deepfake attacks), procedures for responding to unusual requests, and AI-related threats. [adjacent] “Covered Entities must now provide at least annual cybersecurity awareness training that includes social engineering. Training on social engineering, including on deepfake attacks, can be effectively delivered through simulated phishing, and voice and video impersonation exercises.” | 23 NYCRR § 500.14(a)(3) | proposed | Annual training completion records for all staff; training content showing AI/deepfake/social engineering coverage; simulated exercise results. | |
OBL-01203 | United States (NY) | NYDFS | crisis management | Train relevant personnel on how to secure and defend AI systems from cybersecurity attacks and how to design/develop AI systems securely, where the entity deploys or relies on TPSP-deployed AI. [adjacent] “If deploying AI directly, or working with a TPSP that deploys AI, relevant personnel should be trained on how to secure and defend AI systems from cybersecurity attacks, and how to design and develop AI systems securely.” | 23 NYCRR § 500.14(a)(3) | proposed | Training records for AI developers/operators; curriculum documenting secure AI development content; evidence of role-based assignment. | |
OBL-01204 | United States (NY) | NYDFS | crisis management | Ensure the Senior Governing Body has sufficient understanding of AI-related cybersecurity risks, exercises oversight of cybersecurity risk management including AI risks, and regularly receives management reports on AI-related cybersecurity matters. [adjacent] “The Cybersecurity Regulation requires the Senior Governing Body to have sufficient understanding of cybersecurity-related matters (including AI-related risks), exercise oversight of cybersecurity risk management, and regularly receive and review management reports about cybersecurity matters (includ” | 23 NYCRR § 500.4(d) | proposed | Board/committee meeting minutes showing AI cybersecurity risk discussions; management reports submitted to Senior Governing Body; board training records on AI risk. | |
OBL-01206 | United States (NY) | NYDFS | crisis management | Conduct due diligence on TPSPs that will access Information Systems or NPI, specifically assessing AI-related threats facing those TPSPs and how TPSP compromise could impact the Covered Entity's continuity and security. “DFS strongly recommends Covered Entities consider, among other factors, the threats facing TPSPs from the use of AI and AI-enabled products and services; how those threats, if exploited, could impact the Covered Entity; and how the TPSPs protect themselves from such exploitation.” | 23 NYCRR § 500.11(a) | proposed | Completed vendor due diligence questionnaires with AI risk sections; risk ratings; documentation of TPSP AI security controls evaluated. | |
OBL-01207 | United Kingdom | UK_PRA | business continuity | Identify and document important business services (IBS) — those whose disruption could pose risk to safety and soundness, financial stability, or policyholder protection. “firms must identify their important business services...defined as the services a firm provides which, if disrupted, could pose a risk to a firm's safety and soundness or...the financial stability of the UK.” | Operational Resilience 2.1; SS1/21 §2.2 | final | Board-approved written list of IBS with documented rationale referencing safety/soundness, financial stability and policyholder protection criteria; reviewed annually. | |
OBL-01208 | United Kingdom | UK_PRA | business continuity | Set an impact tolerance (including a mandatory time-based metric) for each identified important business service. “firms to set an impact tolerance for each of their important business services...An impact tolerance must, in all cases, include a time-based metric to measure the tolerable level of disruption.” | Operational Resilience 2.2, 2.4; SS1/21 §3.1, §3.6 | final | Documented impact tolerances per IBS with time-based metric (and supplementary metrics where applicable); board approval evidenced in board minutes. | |
OBL-01209 | United Kingdom | UK_PRA | business continuity | Set impact tolerances at the point beyond which further disruption would pose a risk to safety and soundness, financial stability, or policyholder protection. “require firms to set their impact tolerances at the point at which any further disruption to the important business service would pose a risk to the firm's safety and soundness...policyholder protection...financial stability of the UK.” | Operational Resilience 2.3; SS1/21 §3.2 | final | Written rationale for each tolerance threshold referencing quantitative/qualitative indicators per SS1/21 §3.8. | |
OBL-01210 | United Kingdom | UK_PRA | business continuity | Ensure ability to deliver each IBS within its impact tolerance in severe but plausible scenarios by 31 March 2025. “firms to ensure they are able to deliver their important business services within impact tolerances in severe but plausible scenarios...no later than Monday 31 March 2025.” | Operational Resilience 2.5, 2.6; SS1/21 §4.1, §4.14 | final | Prioritised remediation plan showing milestones; evidence of plan execution; scenario test results confirming IBS delivery within tolerance by 31 March 2025. | |
OBL-01211 | United Kingdom | UK_PRA | business continuity | Develop and implement effective remediation plans for IBS that cannot remain within impact tolerances, with timing proportionate to disruption impact. “firms to develop and implement effective remediation plans for the important business services that would not be able to remain within their impact tolerance...speed at which vulnerabilities are remediated should be commensurate with the potential impact.” | SS1/21 §4.3, §4.15 | final | Written remediation plans per at-risk IBS with timelines; progress tracking records; evidence of senior management ownership. | |
OBL-01212 | United Kingdom | UK_PRA | business continuity | Map the people, processes, technology, facilities, and information resources required to deliver each IBS, including resources provided by third parties. “require firms to identify and document the necessary people, processes, technology, facilities, and information...required to deliver each of their important business services...irrespective of whether the resources are being provided wholly or in part by a third party.” | Operational Resilience 4.1; SS1/21 §5.1, §5.5 | final | Documented mapping artefacts per IBS showing all resource dependencies including third-party/intragroup; updated annually or on material change. | |
OBL-01213 | United Kingdom | UK_PRA | business continuity | Update IBS mapping at least annually, or sooner following a significant change. “The PRA expects firms to update their mapping annually at a minimum, or following significant change if sooner.” | SS1/21 §5.9 | final | Version-controlled mapping documents with dated review records; change-triggered update log. | |
OBL-01214 | United Kingdom | UK_PRA | business continuity | Regularly test ability to remain within impact tolerances using severe but plausible disruption scenarios, with testing focused on recovery and response. “require firms to test regularly their ability to remain within impact tolerances in severe but plausible disruption scenarios...The PRA expects firms to focus on recovery and response arrangements.” | Operational Resilience 5.1; SS1/21 §6.1 | final | Written testing plan; scenario test reports; evidence of increasing scenario severity over time; lessons-learned log. | |
OBL-01215 | United Kingdom | UK_PRA | business continuity | Develop a written testing plan specifying scenario types, frequency, IBS coverage, and availability/integrity testing, proportionate to potential disruption impact. “firms to develop a testing plan that details how they will gain assurance that they can remain within impact tolerances...nature and frequency of a firm's testing should be proportionate to the potential impact that disruption could cause.” | SS1/21 §6.6 | final | Documented testing plan covering scenario types, frequency, IBS prioritisation, availability/integrity scenarios; board or senior management approval. | |
OBL-01217 | United Kingdom | UK_PRA | business continuity | Ensure ability to remain within impact tolerances irrespective of third-party use; effectively manage third parties so they do not cause tolerance breaches. “firms to be able to remain within impact tolerances for important business services, irrespective of whether or not they use third parties in the delivery of these services...effectively manage their use of third parties to ensure they can meet the required standard.” | SS1/21 §4.5 | final | Third-party contracts with resilience obligations; third-party assurance reports; evidence that third-party SLAs align with impact tolerance requirements. | |
OBL-01218 | United Kingdom | UK_PRA | business continuity | Understand and manage sub-outsourcing dependencies that may threaten operational resilience and IBS delivery. “Firms should understand the reliance placed on sub-outsourcing arrangements and if these arrangements pose a threat to their operational resilience.” | SS1/21 §5.6 | final | Sub-outsourcing register; materiality assessment; evidence that primary service providers maintain oversight of sub-contractors' resilience capability. | |
OBL-01219 | United Kingdom | UK_PRA | business continuity | Include third-party failure/disruption scenarios (including supply chain) as severe but plausible scenarios in operational resilience testing. “one of the severe but plausible scenarios that firms may select for this testing could involve a failure or disruption at a third party, or their supply chain, based on previous incidents or near misses.” | SS1/21 §6.13 | final | Testing plans and reports that include at least one third-party/supply-chain failure scenario per material outsourced IBS. | |
OBL-01220 | United Kingdom | UK_PRA | business continuity | Require contractual agreements for material outsourcing to include obligations for both parties to implement and test business contingency plans aligned to impact tolerances. “contractual agreements for material outsourcing arrangements to include 'requirements for both parties to implement and test business contingency plans. For the firm, these should take account of firms' impact tolerances for important business services.'” | SS1/21 §6.13 | final | Material outsourcing contracts containing explicit BCP testing obligations; evidence of joint or coordinated testing with third parties. | |
OBL-01221 | United Kingdom | UK_PRA | business continuity | Develop communication strategies for internal and external stakeholders as part of operational disruption response planning, including escalation paths and decision-maker identification. “firms to develop communication strategies for both internal and external stakeholders as part of their planning for responding to operational disruptions...plans should include the escalation paths they would use to manage communications during an incident.” | SS1/21 §4.7 | final | Written communications plan per IBS covering escalation paths, key contact lists (regulators, suppliers, operational staff), and decision-maker identification. | |
OBL-01222 | United Kingdom | UK_PRA | business continuity | Review IBS list at least annually, or sooner on significant change, to determine whether additions or removals are required. “The PRA expects firms to review their important business services annually at a minimum, or sooner if a significant change occurs, and to determine whether any changes are required to their list of important business services.” | SS1/21 §2.10 | final | Annual review records with board/senior management sign-off; change log documenting trigger-based reviews. | |
OBL-01223 | United Kingdom | UK_PRA | business continuity | Board must approve and regularly review: IBS list, impact tolerances, and written self-assessment, including scenario analyses of ability to remain within tolerances. “a firm's board must approve and regularly review the firm's important business services, impact tolerances, and written self-assessment...boards must regularly review assessments...and the scenario analyses of its ability to remain within the impact tolerance.” | Operational Resilience 7; SS1/21 §7.1 | final | Board meeting minutes evidencing approval and review of IBS, tolerances, self-assessment and scenario results; board MI packs. | |
OBL-01224 | United Kingdom | UK_PRA | business continuity | Assign overall responsibility for implementing operational resilience policies to the Chief Operations SMF24 (where it exists) with reporting to the board. “the Chief Operations Senior Management Function (SMF) 24 should hold overall responsibility for implementing operational resilience policies and reporting to the board.” | SS1/21 §7.4 | final | SMF24 appointment documentation; SMCR responsibilities map attributing operational resilience to SMF24; board reporting records. | |
OBL-01225 | United Kingdom | UK_PRA | business continuity | Produce and maintain a written self-assessment documenting compliance with the Operational Resilience Parts, approved by the board. “require firms to document a self-assessment of their compliance with the Operational Resilience Part...Firms' boards are accountable for and should approve the information provided in these documents.” | Operational Resilience 6; SS1/21 §8.1 | final | Board-approved written self-assessment document; version history; board approval minute. | |
OBL-01226 | United Kingdom | UK_PRA | business continuity | Self-assessment must document IBS list with rationale, impact tolerances with rationale, mapping methodology, testing strategy and scenarios, lessons learned, identified vulnerabilities with remediation plans, and group-related risks. “list their important business services...specify the impact tolerances...detail their approach to mapping...describe their strategy for testing...identify any lessons learned...identify the vulnerabilities that threaten their ability...identify any additional risks...from elsewhere in their group.” | Operational Resilience 6; SS1/21 §8.3 | final | Self-assessment containing all enumerated sections; board approval minute; evidence of annual updates. | |
OBL-01227 | United Kingdom | UK_PRA | business continuity | Set recovery time objectives and recovery point objectives for resources underpinning IBS so that the IBS can be delivered within its impact tolerance. “requirements might include capacity specifications, recovery time objectives, and recovery point objectives. These requirements should be set to enable the firm to deliver the important business service within its impact tolerance.” | SS1/21 §3.14 | final | Documented RTO/RPO per resource/system supporting each IBS; evidence RTO/RPO align to and are tested against impact tolerances. | |
OBL-01228 | United Kingdom | UK_PRA | business continuity | CRR consolidation entities and insurers must identify important group business services and set impact tolerances at group level to capture risks from non-individually-regulated group members. “CRR consolidation entities...or an insurer...to identify a proportionate number of important group business services and respective impact tolerances at the level of the group.” | Operational Resilience 8.6–8.13; SS1/21 §9.1 | final | Group-level IBS list with impact tolerances; board approval at group level; group self-assessment including subsidiaries outside the UK. | |
OBL-01229 | United Kingdom | UK_PRA | business continuity | CRR consolidation entities must maintain regular dialogue with group members so CRR firms can account for additional risks to safety and soundness when assessing ability to remain within impact tolerances. [adjacent] “the CRR consolidation entity would have regular dialogue with other members of its group so the CRR firm (or CRR firms) can take account of any additional risks to their safety and soundness when assessing their ability to remain within impact tolerance.” | Operational Resilience 8.8; SS1/21 §9.4 | final | Records of regular group resilience dialogue (e.g. meeting minutes); group risk reporting mechanisms feeding into individual firm self-assessments. | |
OBL-01230 | United Kingdom | UK_PRA | business continuity | Manage risks from intragroup third-party arrangements with the same rigour as external third parties to ensure ability to remain within impact tolerances. “firms to manage risk and make appropriate arrangements to be able to remain within impact tolerance, whether using third parties that are other entities within their group or external providers.” | SS1/21 §4.6 | final | Intragroup SLAs/contracts with resilience obligations; assurance evidence (audits, test results) for intragroup providers equivalent to external third-party oversight. | |
OBL-01231 | United Kingdom | UK_PRA | business continuity | Have a prioritised plan in place by 31 March 2022 setting out how the firm will achieve full within-tolerance capability, with the plan already being executed by that date. “Firms are expected to have a prioritised plan which sets out how they will comply with the requirement to be able to remain within their impact tolerances within a reasonable time...firms must have started putting the plan into effect by Thursday 31 March 2022.” | SS1/21 §4.14 | final | Dated, board-approved prioritised remediation/implementation plan; evidence of programme initiation (e.g. project kick-off, resource allocation) by 31 March 2022. | |
OBL-01237 | Canada | CA_OSFI | business continuity | Identify critical operations and assess their ability to withstand disruptions; map all internal and external dependencies end to end, covering people, technology, processes, information, facilities, and third parties. “Critical operations should be identified and assessed for their ability to withstand disruptions... Once identified, critical operations should be mapped for internal and external dependencies.” | Guideline E-21, Section 3.1 | final | Written inventory of critical operations; dependency maps reviewed and updated regularly; documented financial-loss estimates for disruption scenarios. | |
OBL-01238 | Canada | CA_OSFI | business continuity | Establish tolerances for disruption for each critical operation, setting the maximum level of disruption the institution can withstand across a range of severe but plausible scenarios. “Tolerances for disruption should set out the maximum level of disruption a financial institution can withstand across a range of severe but plausible scenarios.” | Guideline E-21, Section 3.2 | final | Board/senior-management-approved tolerance statements per critical operation; documentation showing tolerances exceed risk appetite limits; periodic review records. | |
OBL-01239 | Canada | CA_OSFI | business continuity | Conduct regular scenario testing of critical operations against severe-but-plausible disruptions, using tabletop exercises, simulations, and live-systems testing, to assess whether operations can persist within tolerances for disruption. “Regular scenario testing improves understanding of when tolerances for disruption would be breached... a variety of testing methodologies should be used, including table-top exercises, simulations, and live-systems testing.” | Guideline E-21, Section 3.3 | final | Scenario testing schedule; test plans and results; gap analyses; board/senior-management reporting of results; iterative improvement records. | |
OBL-01240 | Canada | CA_OSFI | business continuity | Conduct business impact analyses to assess risks and potential impacts of disruptive events, identify the impact of disruptions, and establish maximum recovery objectives; review and update the analyses regularly. “A business impact analysis assesses the risks and potential impacts of a range of disruptive events on operations. It should identify and measure: The impact of disruptions. The maximum limits on recovery objectives before severe consequences or losses occur.” | Guideline E-21, Section 4.1.1 | final | Current BIA documentation with RTO/RPO thresholds; evidence of periodic review; linkage to BCP and scenario-testing programme. | |
OBL-01241 | Canada | CA_OSFI | business continuity | Develop business continuity plans (BCPs) covering response and recovery actions for a range of threats, including protocols for plan invocation, roles and responsibilities, backup personnel, staff safety, recovery targets, workarounds, and internal/external communication plans. “Business continuity plans set out the response and recovery actions for a range of potential threats... This should include: Establishing protocols for invoking the plan... Defining roles and responsibilities... Setting targets for recovery levels and times.” | Guideline E-21, Section 4.1.2 | final | Documented BCPs per critical operation/business unit; invocation protocols; communication templates; staff training records. | |
OBL-01242 | Canada | CA_OSFI | business continuity | Regularly test business continuity plans using scenarios that include long-duration and simultaneous disruptions involving critical third parties; address gaps identified and maintain contingency plans for critical third parties. “Business continuity plan tests should provide reasonable assurance that plans are effective... Tests should consider a range of severe but plausible circumstances, including scenarios with disruptions that: Are long in duration. Are simultaneous in nature. Involve critical third parties.” | Guideline E-21, Section 4.1.3 | final | BCP test schedule and results; after-action reports; gap-remediation tracking; evidence critical third parties demonstrated BCP robustness. | |
OBL-01244 | Canada | CA_OSFI | business continuity | Establish a crisis management plan with escalation protocols to senior management and the board, plan invocation criteria, internal and external communications protocols, and conduct regular testing and lessons-learned exercises. “A crisis management plan should be established that ensures effective, coordinated, and timely responses to potential crises... It should include: Protocols for escalation to senior management and the board. Criteria for invoking the plan. Internal and external communications protocols.” | Guideline E-21, Section 4.3 | final | Documented crisis management plan; escalation matrix; communications templates; test records; lessons-learned reports incorporated into plan updates. | |
OBL-01245 | Canada | CA_OSFI | business continuity | Maintain a senior-level crisis management team responsible for decision-making, coordination, and oversight of strategies to address crises affecting operations. “A crisis management team can help ensure effective communication, expedited recovery, and an effective response to the crisis.” | Guideline E-21, Section A5 (definition) and Section 4.3 | final | Terms of reference for crisis management team; membership list with seniority documented; records of activation and decision logs during incidents. | |
OBL-01246 | Canada | CA_OSFI | business continuity | Integrate business continuity risk management with operational resilience, evolving its focus from business processes to critical operations end to end, and including business impact analyses and tested BCPs. “Business continuity risk management is the process of planning for, and recovering from, disruptions to operations. It should be integrated with and strengthen operational resilience. Over time, its focus should evolve from business processes to critical operations end to end.” | Guideline E-21, Section 4.1 | final | Evidence of BCP integration with operational resilience programme; roadmap showing evolution toward end-to-end critical operations coverage. | |
OBL-01247 | Canada | CA_OSFI | business continuity | Provide staff with training on business continuity plans, including plan activation and management of operations during disruption. “Staff should be provided with training on business continuity plans, including their activation and how operations will be managed during disruption.” | Guideline E-21, Section 4.1.2 | final | Training completion records; training materials covering BCP activation; periodic refresher training schedule. | |
OBL-01248 | Canada | CA_OSFI | business continuity | Obtain sufficient information about critical third parties to assess their resilience, and coordinate with them to conduct broader resilience exercises where possible. “Where a third party is identified as critical, sufficient information should be obtained to assess its resilience... The financial institution should also coordinate with critical third parties, where possible, to conduct broader exercises.” | Guideline E-21, Sections 3.1 and 3.3 | final | Third-party resilience assessments; evidence of information gathered (e.g., audit reports, questionnaires); joint exercise records with critical third parties. | |
OBL-01249 | Canada | CA_OSFI | business continuity | Require critical third parties to demonstrate robustness in their own business continuity plans and testing, and maintain contingency plans for critical third-party failures. “Critical third parties should also demonstrate robustness in their own business continuity plans and testing. There should be processes to address gaps identified during testing, as well as contingency plans for critical third parties.” | Guideline E-21, Section 4.1.3 | final | Contractual BCP requirements for critical third parties; evidence of third-party BCP review/testing attestations; documented contingency/exit plans per critical third party. | |
OBL-01250 | Canada | CA_OSFI | business continuity | Implement a data risk management framework including a strategy and programme covering data governance, architecture, classification, integrity/availability controls, and processes for escalating and responding to data breaches and data-related incidents. [adjacent] “It should also comprise a specific data risk management framework that includes a data risk management strategy and program... Processes for escalating and responding to data breaches and other data-related incidents.” | Guideline E-21, Section 4.7 | final | Documented data risk management framework; data governance policy with roles; data architecture documentation; incident-response procedures for data breaches; training records. | |
OBL-01251 | Canada | CA_OSFI | business continuity | Ensure data supporting critical operations is accurate, complete, timely, secure, and protected, using methodologies that maintain integrity, adaptability, confidentiality, and availability throughout the data lifecycle. “Effective data risk management ensures that data is accurate, complete, timely, secure, and protected... Methodologies for ensuring the integrity, adaptability, confidentiality, and availability of data throughout its lifecycle.” | Guideline E-21, Section 4.7 | final | Data quality and availability metrics; documented lifecycle management controls; classification and protection policies; testing evidence for data availability under disruption scenarios. | |
OBL-01252 | Canada | CA_OSFI | business continuity | Embed effective technology and cyber risk management as a foundation of operational resilience, aligned with Guideline B-13, to prevent wide-scale operational disruption from technology failure, infiltration, or data loss. “A critical technology failure, infiltration, or loss of data can result in wide-scale disruption impacting operations. Sound technology and cyber risk management is fundamental to bolstering operational resilience.” | Guideline E-21, Section 4.5 | final | Technology and cyber risk management programme aligned with B-13; cyber incident response plans; resilience controls documentation; testing records. | |
OBL-01253 | Canada | CA_OSFI | business continuity | Manage third-party operational resilience risks (including disruption at a third party or loss/corruption of critical data) as part of operational resilience, aligned with Guideline B-10. “Threats to operational resilience can arise from critical third-party arrangements, including disruption at the third party or the loss or corruption of critical data. Accordingly, effective third-party risk management is an important contributor to operational resilience.” | Guideline E-21, Section 4.6 | final | Third-party risk register identifying critical arrangements; resilience due-diligence records; concentration risk analysis; B-10-aligned oversight documentation. | |
OBL-01254 | Canada | CA_OSFI | business continuity | Conduct scenario analysis at both business-unit and enterprise-wide levels using a range of severe but plausible scenarios; use results to inform operational resilience scenario testing. “Scenario analysis should be conducted using appropriate techniques at both the business unit and enterprise-wide levels and incorporate a range of severe but plausible scenarios... Scenario analysis results may be used to inform operational resilience scenario testing.” | Guideline E-21, Section 2.3.4 | final | Documented scenario analysis results; evidence of business-unit and enterprise-wide coverage; linkage records showing how results fed into Section 3.3 scenario testing. | |
OBL-01255 | Canada | CA_OSFI | business continuity | Ensure senior management and the board receive timely reports on operational resilience scenario testing results, including analysis of deficiencies, assessment of whether critical operations can be maintained within tolerances, and plans to address shortcomings. “Senior management and the board of directors should also receive the results of scenario analysis... and scenario testing... This should include: Analysis of deficiencies. An assessment of operational resilience, and whether critical operations can be maintained within established tolerances for dis” | Guideline E-21, Section 2.4.2 | final | Board and senior-management reporting templates; documented scenario testing reports presented to board; remediation tracking logs. | |
OBL-01256 | Canada | CA_OSFI | business continuity | Ensure breaches of tolerances for disruption are appropriately escalated to senior management and addressed in a timely and sustainable manner. “Ensuring breaches of tolerances for disruption are appropriately escalated and addressed.” | Guideline E-21, Section 1.1 | final | Escalation policy and procedures; log of tolerance breaches with escalation records; evidence of corrective actions taken and closed. | |
OBL-01257 | Canada | CA_OSFI | business continuity | Perform change management assessments for significant operational changes (new products, acquisitions, new tech systems, process changes), including deploying tested contingency plans if a change fails and testing changes before implementation. “Deploy tested contingency plans in the event a change fails. Test the change on systems and processes before introducing it.” | Guideline E-21, Section 4.4 | final | Change management policy; operational risk assessments for significant changes; tested contingency/rollback plans; pre-implementation test results; post-implementation effectiveness metrics. | |
OBL-01258 | Canada | CA_OSFI | business continuity | Conduct ongoing monitoring of adherence to tolerances for disruption and operational risk limits, using comprehensive metrics; ensure key risk indicators include escalation protocols when risk levels approach or exceed limits. “Ongoing monitoring should be conducted to help prepare for, and respond to, changes in operational risks. It should assess adherence to the operational risk appetite statement and operational risk limits, as well as tolerances for disruption.” | Guideline E-21, Sections 2.4.1 and 2.3.2 | final | KRI dashboard including tolerance-for-disruption metrics; documented escalation thresholds; monitoring reports; records of management actions taken when thresholds breached. | |
OBL-01259 | Canada | CA_OSFI | business continuity | Capture and analyse operational risk event data (actual, potential, and near-misses) to determine root causes, contributing risk categories, and corrective measures; use findings to strengthen resilience controls. “Operational risk event data exceeding established limits should be captured to assess: What the root cause of the operational risk event is... What corrective measures ought to be taken to address deficiencies or control failures.” | Guideline E-21, Section 2.3.3 | final | Operational risk event database including near-misses; root-cause analysis records; corrective action logs; trend reporting to senior management. | |
OBL-01260 | Canada | CA_OSFI | business continuity | Ensure independent risk and compliance functions oversee and challenge resilience activities, including escalation channels for significant issues, and that internal audit provides independent assurance on operational risk management controls and systems. “The independent risk and compliance functions oversee and challenge the risk and resilience activities... Internal audit or a similar function should provide independent assurance to senior management and the board of directors that operational risk management controls, policies and procedures, and ” | Guideline E-21, Sections 1.3 and 1.4 | final | Internal audit plan covering ORM and resilience; audit reports; issue-tracking logs; documented escalation channels; second-line challenge records. | |
OBL-01261 | Canada | CA_OSFI | business continuity | Conduct lessons-learned exercises following a crisis and incorporate findings into the crisis management plan; share the plan with relevant business units and impacted external parties. “Lessons-learned exercises should be undertaken following a crisis and incorporated into the plan. The crisis management plan should be regularly tested and shared with the relevant business units in the financial institution and any impacted external parties, as appropriate.” | Guideline E-21, Section 4.3 | final | Post-crisis lessons-learned reports; evidence of plan updates; distribution records showing plan shared with business units and external parties; test schedules and results. | |
OBL-01625 | United States (CA) | CA_PRIVACY | cybersecurity | Establish and maintain a cybersecurity program consisting of policies, procedures, and practices that protect personal information from unauthorized access, destruction, use, modification, or disclosure, and protect against loss of availability of personal information. [adjacent] “"Cybersecurity program" means the policies, procedures, and practices that protect personal information from unauthorized access, destruction, use, modification, or disclosure; and protect against unauthorized activity resulting in the loss of availability of personal information.” | § 7001(k) | final | Written cybersecurity program documentation covering all enumerated protections; policies and procedures manual; evidence of implementation and periodic review. | |
OBL-01627 | United States (CA) | CA_PRIVACY | cybersecurity | Create a cybersecurity audit report documenting the required information for each completed annual cybersecurity audit. [adjacent] “"Cybersecurity audit report" means the document that every business must create as part of its cybersecurity audit. The cybersecurity audit report includes the information set forth in section 7123, subsection (e).” | § 7001(l) | final | Completed cybersecurity audit report containing all elements specified in § 7123(e); version history showing annual updates. | |
OBL-01629 | United States (CA) | CA_PRIVACY | cybersecurity | Conduct penetration testing of information systems by authorizing attempted circumvention or defeat of security features to identify vulnerabilities that could compromise availability or security of personal information. [adjacent] “"Penetration testing" means testing the security of an information system by attempting to circumvent or defeat its security features by authorizing attempted penetration of the information system.” | § 7001(bb) | final | Penetration testing authorization letters; test reports with findings and remediation tracking; schedule showing periodic conduct of testing. | |
OBL-01630 | United States (CA) | CA_PRIVACY | cybersecurity | Manage and control privileged accounts to prevent unauthorized configuration changes or unauthorized access that could affect availability and security of personal information. [adjacent] “"Privileged account" means any authorized user account or service account that can be used to perform functions that other user accounts are not authorized to perform, including but not limited to the ability to add, change, or remove other accounts, or make configuration changes to an information s” | § 7001(hh) | final | Privileged account inventory; access control policy; periodic access reviews/recertification records; audit logs for privileged account activity. | |
OBL-01631 | United States (CA) | CA_PRIVACY | cybersecurity | Scope the business's information system (including third-party-owned resources used for processing personal information) within the cybersecurity program and audit, addressing risks to all such resources. [adjacent] “"Information system" means the resources (e.g., network, hardware, and software) organized for the processing of personal information or that can provide access to personal information. The business's information system includes the resources organized for the business's processing of personal infor” | § 7001(t) | final | Asset inventory including third-party-hosted resources; contractual evidence of security requirements imposed on third-party providers; audit scope documentation. | |
OBL-01808 | United Kingdom | UK_FCA | business continuity | Establish sound, effective and comprehensive strategies, controls, processes and systems to enable compliance with all CTPS operational resilience rules. “A critical third party must have in place sound, effective and comprehensive strategies, controls, processes and systems that enable it to comply with the rules in CTPS.” | CTPS 4.1.1R | final | Written framework document; board/senior management approval; proportionality assessment per CTPS 4.1.2R; periodic review records. | |
OBL-01809 | United Kingdom | UK_FCA | business continuity | Establish governance arrangements that include a named regulator liaison, clear escalation channels, and an approach covering prevention, response, adaptation and recovery from CTP operational incidents. “A critical third party must ensure that its governance arrangements promote the resilience of any systemic third party service it provides, including by... establishing, overseeing and implementing an approach that covers... prevent, respond and adapt to, as well as recover from, any CTP operational” | CTPS 4.2.1R | final | Governance policy; named individual(s) with regulator contact details notified in writing; documented escalation and incident response governance structure. | |
OBL-01810 | United Kingdom | UK_FCA | business continuity | Implement lessons learned from CTP operational incidents and from testing and exercising into governance and operational arrangements. “implementing lessons learned from CTP operational incidents and any testing and exercising undertaken, including but not limited to that undertaken in accordance with CTPS 5.” | CTPS 4.2.1R(4) | final | Post-incident review logs; lessons-learned register; documented updates to playbooks, processes or controls with evidence of governance approval. | |
OBL-01811 | United Kingdom | UK_FCA | business continuity | Identify, monitor and manage risks to ability to deliver systemic third party services, and regularly update risk management processes using lessons from incidents, regulator engagement and testing. “A critical third party must manage effectively risks to its ability to deliver a systemic third party service including by: (1) identifying and monitoring relevant external and internal risks; (2) ensuring that it has in place risk management processes... (3) regularly updating its risk management p” | CTPS 4.3.1R | final | Risk register; risk management framework; evidence of regular reviews and updates; audit trail of changes triggered by incidents or testing. | |
OBL-01812 | United Kingdom | UK_FCA | business continuity | Identify and manage supply chain risks that could affect delivery of systemic third party services, including risks from key nth-party providers. “A critical third party must... identify and manage any risks to its supply chain that could affect its ability to deliver a systemic third party service.” | CTPS 4.4.1R | final | Supply chain risk register; documented mapping of key nth-party providers; risk assessments; contractual controls; periodic review records. | |
OBL-01813 | United Kingdom | UK_FCA | business continuity | Take reasonable steps to ensure key nth-party providers and connected persons in the supply chain are informed of CTP duties, cooperate in meeting them, and grant regulators access to relevant information. “A critical third party must take reasonable steps to ensure that its key nth-party providers and persons connected with a critical third party that are part of its supply chain: (1) are informed of the CTP duties... (2) cooperate... (3) provide the regulators with access to any information.” | CTPS 4.4.2R | final | Contractual clauses with nth-party providers; evidence of notifications issued; records of cooperation mechanisms; regulatory access provisions in contracts. | |
OBL-01814 | United Kingdom | UK_FCA | business continuity | Take reasonable steps to ensure the technology resilience of systemic third party services, including sound cyber resilience strategies and regular testing and exercising of those strategies. “A critical third party must... take reasonable steps to ensure the resilience of any technology that delivers, maintains or supports a systemic third party service, including by having: (1) sound, effective and comprehensive strategies... to adequately manage risks to its technology and cyber resili” | CTPS 4.5.1R | final | Technology and cyber resilience strategy; penetration test results; vulnerability management records; test schedules and outcomes; evidence of lessons-learned updates. | |
OBL-01815 | United Kingdom | UK_FCA | business continuity | Implement systematic change management for systemic third party services, including risk assessment, testing, verification and approval of all changes before implementation to minimise disruption risk. “A critical third party must ensure that it has a systematic and effective approach to dealing with changes to a systemic third party service... implementing any change... in a way that minimises appropriately the risk of any CTP operational incident occurring; and ensuring that prior to being implem” | CTPS 4.6.1R | final | Change management policy; change log with risk assessments, test results and approvals; evidence of pre-implementation verification for material changes. | |
OBL-01816 | United Kingdom | UK_FCA | business continuity | Within 12 months of Treasury designation, map and document all resources, persons, assets, supporting services, technology, and interdependencies used to deliver each systemic third party service; update regularly thereafter. “A critical third party must: (1) within 12 months of being designated by the Treasury, identify and document: (a) the resources... used to deliver, support and maintain each systemic third party service... and (b) any internal and external interconnections and interdependencies... and (2) thereafter” | CTPS 4.7.1R | final | Service mapping documentation per systemic service; asset and dependency register; dated version history showing regular updates. | |
OBL-01817 | United Kingdom | UK_FCA | business continuity | Implement measures to respond to and recover from CTP operational incidents, set a maximum tolerable level of disruption for each systemic service, and maintain an incident management playbook within 12 months of designation. “A critical third party must manage effectively CTP operational incidents including by: (1) implementing appropriate measures to respond to and recover from CTP operational incidents... (2) setting an appropriate maximum tolerable level of disruption... (3) maintaining and operating an incident manag” | CTPS 4.8.1R | final | Documented incident response and recovery measures; defined and documented maximum tolerable disruption level per service; completed incident management playbook with version control. | |
OBL-01818 | United Kingdom | UK_FCA | business continuity | The incident management playbook must set out plans and procedures to respond to and recover from CTP operational incidents and facilitate effective communication with regulators and affected firms. “maintaining and operating an incident management playbook... which sets out the plans and procedures to be followed by the critical third party in the event of a CTP operational incident in order to: (a) respond to and recover from the CTP operational incident; and (b) facilitate effective communica” | CTPS 4.8.1R(3) | final | Incident management playbook containing response/recovery procedures and communication protocols for regulators and affected firms; evidence of implementation. | |
OBL-01819 | United Kingdom | UK_FCA | business continuity | Cooperate and coordinate with regulators and affected firms in response to CTP operational incidents, including through collective incident response frameworks. “cooperating and coordinating with the regulators and affected firms in response to CTP operational incidents, including through collective incident response frameworks.” | CTPS 4.8.1R(4) | final | Records of participation in collective incident response frameworks; documented cooperation protocols; evidence of coordination during past incidents or exercises. | |
OBL-01820 | United Kingdom | UK_FCA | business continuity | Put in place measures for effective, orderly and timely termination of any systemic third party service, including transfer support and recovery/return of firm assets in an accessible format. “A critical third party must have in place appropriate measures to respond to a termination of any of its systemic third party services... including by putting in place: (1) arrangements to support the effective, orderly and timely termination of that service... (2) provision for ensuring access to, ” | CTPS 4.9.1R | final | Termination/exit plan per systemic service; data portability and return procedures; contractual provisions with firms covering asset recovery; evidence of testing. | |
OBL-01821 | United Kingdom | UK_FCA | business continuity | Be able to demonstrate to regulators the ability to comply with all CTPS requirements. [adjacent] “A critical third party must be able to demonstrate to the regulators its ability to comply with CTPS.” | CTPS 5.1.1R | final | Comprehensive compliance evidence pack; self-assessments; test results; governance sign-off; policies and procedures; records available for regulatory inspection. | |
OBL-01822 | United Kingdom | UK_FCA | business continuity | Carry out regular scenario testing of ability to continue providing each systemic third party service within its maximum tolerable disruption level under severe but plausible disruption scenarios covering varying nature, severity and duration. “a critical third party must carry out regular scenario testing of its ability to continue providing each systemic third party service within its appropriate maximum tolerable level of disruption... in the event of a severe but plausible disruption... identify an appropriate range of adverse circumst” | CTPS 5.2.1R, CTPS 5.2.2R | final | Scenario testing programme; test scenarios documented; test results reports; evidence of remediation actions taken; records showing frequency and coverage. | |
OBL-01823 | United Kingdom | UK_FCA | business continuity | Regularly assess effectiveness of the incident management playbook; conduct an incident management playbook exercise with a representative sample of firms within 12 months of designation and at least biennially thereafter. “a critical third party must assess the effectiveness of its incident management playbook regularly, including undertaking an appropriate incident management playbook exercise with a representative sample of the firms... within 12 months of the critical third party being designated by the Treasury an” | CTPS 5.3.1R | final | Playbook exercise schedule; exercise reports; list of participating firms; evidence of biennial frequency; post-exercise action plans. | |
OBL-01824 | United Kingdom | UK_FCA | business continuity | Prepare and submit to regulators a report of each incident management playbook exercise, including actions taken in light of results, as soon as practicable after the exercise. “A critical third party must, as soon as is practicable, prepare and submit to the regulators a report of the incident management playbook exercise undertaken under CTPS 5.3.1R (including any actions taken in the light of the results of that exercise).” | CTPS 5.3.2R | final | Submitted exercise reports to regulators; evidence of timely submission; records of follow-up actions. | |
OBL-01825 | United Kingdom | UK_FCA | business continuity | Provide regulators with an interim self-assessment within 3 months of designation and annual self-assessments thereafter on compliance with CTPS; retain copies for at least 3 years. [adjacent] “A critical third party must provide to the regulators: (1) within 3 months... an interim self-assessment; and (2) annually thereafter, an annual self-assessment, of the critical third party's compliance with CTPS... must keep a copy... for a period of at least 3 years.” | CTPS 6.1.1R, CTPS 6.1.2R | final | Submitted interim and annual self-assessments; regulator submission records; document retention logs showing 3-year retention. | |
OBL-01826 | United Kingdom | UK_FCA | business continuity | Maintain effective and secure processes to provide firms with sufficient and timely information—including test results, self-assessments and maximum tolerable disruption levels—to enable them to manage risks from using the CTP's systemic third party services. “A critical third party must have in place effective and secure processes and procedures to ensure sufficient and timely information is given to a firm... including... results of testing and exercising... the annual self-assessment... the appropriate maximum tolerable level of disruption.” | CTPS 7.1.1R, CTPS 7.1.2R | final | Information sharing framework/policy; evidence of information provided to each client firm; secure transmission records; disclosure logs. | |
OBL-01827 | United Kingdom | UK_FCA | business continuity | Submit an initial incident report to regulators and affected firms as soon as practicable after a CTP operational incident, covering nature/extent of disruption, detection time, affected services, geography, cause, recovery timeline and initial actions. “A critical third party must, as soon as is practicable after the occurrence of a CTP operational incident... submit the following information... (a) a description of the CTP operational incident... (d) the anticipated amount of time it will take to resolve the CTP operational incident, including the” | CTPS 8.1.1R | final | Initial incident report template; submitted reports to regulators and affected firms; submission timestamps; incident log. | |
OBL-01828 | United Kingdom | UK_FCA | business continuity | Submit intermediate incident reports to regulators and affected firms as soon as practicable after any significant change in circumstances, including when the incident is resolved. “A critical third party must, as soon as is practicable after any significant change in circumstances... provide the regulators and the affected firms with information further to that already disclosed in relation to the CTP operational incident, including... any steps taken to resolve the CTP operat” | CTPS 8.2.1R | final | Intermediate incident report records; submission logs to regulators and firms; documented triggers for issuing updates. | |
OBL-01829 | United Kingdom | UK_FCA | business continuity | Submit a final incident report to regulators and affected firms within a reasonable time of resolution, covering root causes, remedial actions, recurrence likelihood, long-term implications and improvement areas. “A critical third party must, within a reasonable time of the CTP operational incident being resolved, provide the regulators and the affected firms with the following information... (2) a description of the root causes... (3) a description of any remedial actions... (4) a description of the critical” | CTPS 8.3.1R | final | Final incident report template; submitted reports to regulators and affected firms; root cause analysis documentation; remediation action plans with timelines. | |
OBL-01830 | United Kingdom | UK_FCA | business continuity | Notify regulators immediately of any actual or potential circumstance that seriously and adversely impacts, or could impact, the CTP's ability to deliver systemic third party services or meet CTPS obligations. “A critical third party must notify the regulators immediately where there is an actual or potential circumstance or event that seriously and adversely impacts, or could seriously and adversely impact, the critical third party's ability to deliver any of its systemic third party services or meet any ” | CTPS 9.1.1R | final | Notification log; evidence of timely submissions; internal trigger criteria and escalation procedures for CTPS 9 notifications. | |
OBL-01831 | United Kingdom | UK_FCA | business continuity | Ensure all information provided to regulators and firms under CTP duties (including incident reports and notifications) is factually accurate, complete and fairly based; correct any inaccurate information immediately upon discovery. [adjacent] “A critical third party must take reasonable steps to ensure that all information it gives to the regulators and firms... is: (1) factually accurate or, in the case of estimates and judgements, fairly and properly based... (2) complete... If a critical third party becomes aware... that it has or may ” | CTPS 10.1.1R, CTPS 10.1.3R | final | Information quality control procedures; review and sign-off records for regulatory submissions; records of any corrective notifications made. | |
OBL-01832 | United Kingdom | UK_FCA | business continuity | When appointing a skilled person, contractually require and permit them to cooperate with regulators, report matters of material significance, comply with regulator instructions on reporting, and assist the skilled person with information and access. [adjacent] “When a critical third party appoints a skilled person, the critical third party must, in a contract with that person: (1) require and permit the skilled person during and after the course of their appointment: (a) to cooperate with the regulators in connection with the discharge of their oversight f” | CTPS 13.5.1R | final | Skilled person contracts containing required clauses; evidence of regulator cooperation and access provisions; records of skilled person engagements. | |
OBL-01868 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): All firms must submit a report to the FCA as soon as practicable (within 24 hours) after an operational incident meets any notification threshold (risk of intolerable consumer harm, safety/soundness, or market stability). “A firm must submit a report to the FCA in accordance with (2) or (3), as applicable, as soon as is practicable after the occurrence of an operational incident which the firm reasonably believes meets one or more of the notification thresholds” | SUP 15.18.6R(1) and SUP 15.18.7G | final | Incident log with timestamped detection and submission records; written threshold assessment; initial report submitted within 24 hours via FCA online portal | ||
OBL-01869 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Enhanced reporting firms must submit an initial phase report containing mandatory fields (Annex 15.1R cols 1 & 2) to the FCA as soon as practicable after an operational incident threshold is met. “For this initial phase of the report, an enhanced reporting firm must submit to the FCA, so far as it is aware, the information in accordance with columns (1) and (2) of the table in SUP 15 Annex 15.1R.” | SUP 15.18.6R(2) | final | Completed initial-phase report (SUP 15 Annex 15.1R cols 1&2) with all mandatory fields including incident description, detection time, recovery actions, third-party provider details | ||
OBL-01870 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Enhanced reporting firms must submit an intermediate phase report to the FCA as soon as practicable after any significant change in circumstances from those in the initial report, including resolution of the incident. “For the intermediate phase of the report, an enhanced reporting firm must, so far as it is aware, submit to the FCA the additional information in accordance with columns (1) and (3) of the table in SUP 15 Annex 15.1R, as soon as is practicable after any significant change in circumstances” | SUP 15.18.8R | final | Intermediate-phase update reports (Annex 15.1R cols 1&3) with timestamps showing submission promptly after material incident developments or resolution | ||
OBL-01871 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Enhanced reporting firms must submit a final phase report within 30 working days (or 60 working days if impracticable) of an operational incident being resolved. “For the final phase of the report, an enhanced reporting firm must submit to the FCA the additional information in accordance with columns (1) and (4) of the table in SUP 15 Annex 15.1R: (1) within 30 working days; or (2) where this is impracticable, as soon as is practicable but in any event within” | SUP 15.18.9R | final | Final-phase report (Annex 15.1R cols 1&4) including root cause, lessons learned, remedial actions, impact tolerance usage; dated within 30/60 WD of resolution | ||
OBL-01872 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Non-enhanced reporting firms must submit a standard report (Annex 15.2R) to the FCA as soon as practicable after an operational incident meets any notification threshold. “A firm other than an enhanced reporting firm must submit to the FCA, so far as it is aware, information in accordance with the table in SUP 15 Annex 15.2R.” | SUP 15.18.6R(3) | final | Completed standard report (Annex 15.2R) with mandatory fields including incident description, detection time, severity rating, recovery actions; submitted via FCA online portal | ||
OBL-01873 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): All firms required to report operational incidents must submit reports exclusively online through the appropriate systems accessible from the FCA's website. “A firm must submit the information required under this section to the FCA online through the appropriate systems accessible from the FCA's website.” | SUP 15.18.10R | final | Evidence of online portal registration; test submissions; documented escalation procedure if portal unavailable | ||
OBL-01874 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Payment service providers must submit the initial operational incident report to the FCA within 4 hours of first detecting a major operational or security incident. “A payment service provider must submit the report in SUP 15.18.6R to the FCA within 4 hours of first detecting a major operational or security incident.” | SUP 15.14.18DD | final | Incident log showing detection timestamp and FCA submission timestamp within 4 hours; 24/7 on-call escalation procedure | ||
OBL-01875 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Enhanced reporting firms must include in the final phase report the proportion of impact tolerance used, service downtime, number/percentage of affected customers, and transactions affected. “What proportion of an impact tolerance has been used?... Service downtime... Number of affected customers... Percentage of service users affected... Percentage of transactions affected... Value of transactions affected... Number of transactions affected” | SUP 15 Annex 15.1R (col 4, fields 24-30) | final | Final-phase report with populated impact tolerance, downtime, customer and transaction impact fields; internal methodology for calculating these metrics | ||
OBL-01876 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Enhanced reporting firms must include in the final phase report lessons identified and remedial actions being taken following an operational incident. “Describe the lesson identified... Not applicable... Not applicable... Mandatory... Describe the remedial action being taken... Not applicable... Not applicable... Mandatory” | SUP 15 Annex 15.1R (col 4, fields 41-42) | final | Post-incident review document; final-phase FCA report containing completed lessons learned and remedial action fields | ||
OBL-01877 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Where an operational incident originates from a third party, enhanced reporting firms must identify the third party provider name and LEI in both initial and intermediate phase reports. “Third party provider name (note 7)... Mandatory... Mandatory... -... Third party provider legal entity identifier (note 7)... Mandatory... Mandatory... -” | SUP 15 Annex 15.1R (fields 36-37) | final | Incident reports showing third-party provider name and LEI where origin is third party; internal register of critical third-party LEIs for rapid lookup | ||
OBL-01878 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): In-scope firms must notify the FCA before entering into, or making significant changes to, a material third party arrangement, at an early stage before internal or external commitments are made. ⚠ audit “A firm must give the FCA notice when entering into, or significantly changing, a material third party arrangement.” | SUP 15.19.6R and SUP 15.19.9G | final | Pre-commitment FCA notification records with submission timestamps; materiality assessment documentation; FCA online submission receipts | ||
OBL-01879 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): In-scope firms must submit material third party arrangement notifications to the FCA using the data fields in Annex 16.1R (cols 1 & 2), online via the FCA's website. ⚠ audit “A firm must submit the notice required in SUP 15.19.6R to the FCA: (1) by providing the information in accordance with columns (1) and (2) of the table in SUP 15 Annex 16.1R; and (2) online through the appropriate systems accessible from the FCA's website.” | SUP 15.19.8R | final | Completed Annex 16.1R notification templates with all mandatory fields; FCA portal submission confirmations; governance sign-off records (field 4.12) | ||
OBL-01880 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): In-scope firms must maintain a register of information relating to all their material third party arrangements and submit it annually to the FCA. [adjacent] “A firm must: (1) maintain a register of information relating to its material third party arrangements; and (2) submit the register of material third party arrangements annually to the FCA.” | SUP 16.33.6R | final | Live internal register with all Annex 16.1R fields populated; annual FCA submission records; evidence of ongoing register maintenance and updates | ||
OBL-01881 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): In-scope firms must submit the annual material third party arrangements register to the FCA using Annex 16.1R (cols 1 & 3) fields, online via the FCA's website. ⚠ audit “The firm must submit the register of material third party arrangements specified in SUP 16.33.6R(2) to the FCA: (1) by providing the information in accordance with columns (1) and (3) of the table in SUP 15 Annex 16.1R; and (2) online through the appropriate systems accessible from the FCA's website” | SUP 16.33.8R | final | Annual Annex 16.1R register submission via FCA portal; submission receipts; internal data governance records confirming completeness of mandatory fields | ||
OBL-01882 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Firms must record in the material third party register the substitutability of the service provider, ability to reintegrate the service, and impact of discontinuing the arrangement. “Substitutability of the service provider... Mandatory... Mandatory... Ability of reintegration of the service... Mandatory... Mandatory... The impact of discontinuing the contractual arrangement... Mandatory... Mandatory” | SUP 15 Annex 16.1R (fields 5.01-5.03) | final | Register entries with completed substitutability assessments; exit/reintegration analysis documentation; concentration risk assessments for critical providers | ||
OBL-01883 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Firms must record in the material third party register whether each arrangement supports an important business service and, if so, which service and whether the provider supports a core element of it. “Does the contractual arrangement support an important business service?... Mandatory... Mandatory... If yes, which important business service does the contractual arrangement support... Does the service provider support a core element of the important business service?” | SUP 15 Annex 16.1R (fields 3.04-3.06) | final | Register with mapped important business services per third-party arrangement; linkage to operational resilience important business service mapping documentation | ||
OBL-01884 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Firms must record FCA impact tolerances (client harm and market integrity) for each material third party arrangement in both the notification and the annual register. ⚠ audit “Impact tolerance - FCA - client harm... Mandatory... Mandatory... Impact tolerance - FCA - market integrity... Mandatory... Mandatory” | SUP 15 Annex 16.1R (fields 3.10-3.11) | final | Register and notification templates with impact tolerance fields completed; board-approved impact tolerance statements linked to third-party arrangements | ||
OBL-01885 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Firms must record the date and outcome of the most recent risk assessment and audit for each material third party arrangement in both the notification and annual register. ⚠ audit “Date of the most recent risk assessment... Mandatory... Mandatory... Outcome of the most recent risk assessment... Mandatory... Mandatory... Date of the most recent audit... Mandatory... Mandatory... Outcome of the most recent audit... Mandatory... Mandatory” | SUP 15 Annex 16.1R (fields 4.01-4.05) | final | Third-party risk assessment reports and audit reports with dates; register entries referencing these; schedule of upcoming reassessments | ||
OBL-01886 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Firms must record the date and outcome of cyber risk due diligence for each material third party arrangement in both the notification and annual register. ⚠ audit “Date of cyber risk due diligence... Mandatory... Mandatory... Outcome of cyber risk due diligence... Mandatory... Mandatory” | SUP 15 Annex 16.1R (fields 4.08-4.09) | final | Cyber risk due diligence reports for each material third party; register entries with dates and outcomes; evidence of periodic refresh | ||
OBL-01887 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Firms must record governance approval details (SMF/accountable-person sign-off or committee review) and the date of approval for each material third party arrangement. [adjacent] “Has this contractual arrangement been reviewed and signed off by an SMF holder or an accountable person of an FMI?... Mandatory... Mandatory... If not, which governance committee reviewed it?... Date of governance approval... Mandatory... Mandatory” | SUP 15 Annex 16.1R (fields 4.12-4.14) | final | Governance approval records (board/committee minutes or SMF sign-off) for each material third-party arrangement; dates recorded in register | ||
OBL-01888 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Firms must record where data is stored and where the service is delivered from for each material third party arrangement in both the notification and annual register. “Country where the data is stored... Mandatory... Mandatory... Country where the service is delivered from... Mandatory... Mandatory” | SUP 15 Annex 16.1R (fields 3.13-3.14) | final | Register entries showing data storage and service delivery countries; data flow mapping documentation; cloud deployment model records (field 2.06) | ||
OBL-01889 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Firms must maintain a permanent record of their material third party arrangements register (SUP 16.33.6R(1)) with no specified minimum retention period. ⚠ audit “SUP 16.33.6R(1) Material third party arrangements Register of information relating to material third party arrangements Not specified Not specified” | SUP 16.33.6R(1) and Sch 1.2G (SUP 16.33.6R(1) entry) | final | Documented register retention policy; version-controlled register records; audit trail of changes to register entries | ||
OBL-01890 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Enhanced reporting firms must report in the initial phase whether an affected service is classified as an important business service and, in the intermediate phase, must confirm this mandatorily. “Is the affected service classified as an important business service?... Optional (note 2)... Mandatory... -” | SUP 15 Annex 15.1R (field 23) | final | Incident reports with important business service classification; linkage to firm's important business service register under SYSC 15A | ||
OBL-01891 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Firms subject to both SUP 15.3.8G(1)(e) and SUP 15.19 notification requirements for material outsourcing must comply with SUP 15.19; a single notification satisfying SUP 15.19 discharges both obligations. [adjacent] “Any notification required under both SUP 15.3.8G(1)(e) and SUP 15.19 (Notification of material third party arrangements) must be made in accordance with SUP 15.19.” | SUP 15.3.10AR | final | Notification records showing SUP 15.19-compliant submissions for material outsourcing arrangements; policy documenting consolidation of dual notification obligations | ||
OBL-01892 | United Kingdom | UK_FCA | NOT YET IN FORCE (effective 2027-03-18): Firms must record in the material third party register the supply chain ranking and notice periods (for both firm and service provider) for each material third party arrangement. “Supply chain ranking... Mandatory... Mandatory... Notice period for the service provider... Mandatory... Mandatory... Notice period for the firm... Mandatory... Mandatory” | SUP 15 Annex 16.1R (fields 2.08, 2.12-2.13) | final | Register entries with supply chain tier/ranking, contractual notice periods for both parties; exit planning documentation referencing notice periods |
Knowing which rules bind you is step one. WSquare Advisory builds the operating capability behind compliance — the continuity, third-party, and recovery disciplines these regimes expect. If that's your challenge, let's talk.
Start with an Operating Survey · $5,000 →