All the hard work put into mastering the details of SS1/21 and SS2/21, understanding their processes, how their technology stack supports them, impact tolerances, and much more will have finally paid off.

Ideally, they can now report to management and their regulators that they have demonstrably robust systems and processes in place to manage all manner of disruptions. However, despite now finally complying with the Operational Resilience framework, financial institutions will be far from relieved as the hard work is only about to start.

That is not to say that SS1/21 and SS2/21 are challenging regulations. In comparison to complying with Basel III or Solvency II, they are more straightforward. In many cases, complying has - hopefully - meant capturing, consolidating, and reviewing all the information and data points institutions needed to show their compliance.

Adapting to new regulations

As many risk and compliance hands will recognise, complying with a set of regulations and maintaining that compliance are two very different things. Banks, insurers and asset managers have long proven themselves adept at adapting and improvising changes to business processes to accommodate the slew of new and updated regulations that regularly come their way.

These adaptations often involve manual processes, such as cutting and pasting information from one system to another, or the use of 'temporary' spreadsheets, which somehow stay far longer than originally planned. The list of workarounds is endless, but they all expose institutions to reputational, audit, and compliance risks should any of these ad-hoc processes fail. The overhead of managing these manual processes will likely be significant, too, especially as the business changes to meet new demands.

It is pretty standard for initial compliance with a new set of regulations, to signal the start of new projects that aim to streamline and automate the critical compliance processes institutions must now need to put in place. The key question is: how can we best achieve this?

From working with customers and industry practitioners, many institutions are taking an innovative look at implementing systems and processes that will provide automation capabilities that will manage the visibility of operational resilience.

Looking at SaaS solutions

Rather than opting for legacy enterprise applications to solve these issues, many are looking at SaaS solutions. These allow companies to swiftly implement governance, risk, and compliance (GRC) capabilities desirable in order to meet SS1/21 and SS2/21 regulations. Choosing the right alternative, capable of offering speed and flexibility for business users, and one which doesn't hold back the capacity for innovation in the business is the key to success.

GRC capabilities are essential in helping risk, compliance, and operational teams keep tabs on the issues they need to monitor as part of their Operational Resilience BAU. Traditional approaches to managing GRC typically require risk and compliance teams to work closely with business project teams in order to align business processes with an institution's GRC requirements. This often means risk and compliance specialists engage in a regular cycle of meetings and emails, educating and informing operational teams about their GRC obligations and responsibilities, this is not only incredibly time-consuming, but generates enormous cost for the business.

What SaaS GRC capabilities can do

SaaS GRC capabilities allow companies to turn this approach on its head. They offer users across teams the ability to understand their responsibilities and obligations by applying embedded expertise within SaaS-based systems that detail what they need to demonstrate against a range of standards and requirements. Project teams can work at their own pace and engage with their risk and compliance team when they need clarification or guidance as needed. Attestation and education capabilities can help with ongoing compliance requirements and feed into the wider GRC and regulatory reporting processes.

Alongside the GRC requirement of SS1/21, there are the Third-Party Risk Management (TPRM) requirements of Operational Resilience, detailed in SS2/21. Banks have invested heavily in their supply chains to help accelerate the scale and scope of their service innovations, to the point where the division between a bank's responsibilities and the responsibilities of its supply chain has become blurred. SS2/21 is clearly designed to address this issue and requires banks to have robust, flexible, and dynamic TPRM capabilities in place that mirror their own internal GRC capabilities.

Learn more about Mitratech here