ソフトウェア・アズ・ア・サービスへの投資で長期的な持続可能性に備える

Life insurers are used to owning systems for decades. It’s certainly not a stretch to think that some of you reading still have Life70 running! And it’s certainly understandable that many of you have begun replacing those and other systems with Software as a Service (SaaS) platforms. SaaS is a software distribution model in which a cloud provider hosts (or contracts a third-party cloud provider to host) applications and makes them available to end users over the internet. The goal is to reduce costs and alleviate cumbersome system upgrades. However, what does this mean in terms of longevity of these SaaS platforms? What must an insurer consider when considering SaaS as a long term proposition in terms of data, knowledge transfer, and security?

This question was posed to Celent recently. It is triggering a lot of discussions and will become a future report. But to get the conversation started, let’s lay out some things insurers should consider when working with a SaaS provider to protect themselves tomorrow and into the future.

SaaS has the potential to fundamentally change how a business operates and insurers are increasingly relying on 3rd party vendors for delivery of mission critical services, and, as a result, the insurer is not always in complete control like when they own the software themselves. It is therefore important to make sure you select the right SaaS provider which entails considering three major areas: provider reliability, suitability of an offering to meet your needs, and security. And we suggest adding a fourth consideration -- this concern about the longevity of the platform.

Business reliability considers system availability which demonstrates whether the provider has some level of fault tolerance or disaster recovery in place to help guarantee availability in the event of a major disaster. Availability measures should also include scheduled maintenance, internet routing issues, how many times users were unable to access data and applications. Knowing all is important to understand how your business may be impacted in the future by any downtime.

Reliability can be enforced through Service Level Agreements (SLAs). SLAs should consider definitions of availability and downtime, services provided, required availability for each service and acceptable downtime limits, methods used to report any loss of service and downtime, and notification requirements. Determine which are important to your business and add more as needed.

SaaS capabilities are advancing rapidly so an insurer must determine which will meet their business, operational and technical requirements today and hopefully in the future, across more than one business area, and for the long haul.

In a SaaS model, an insurer’s data is hosted by a third party and accessed through the Internet. This brings up a series of security and privacy concerns that require careful planning around the data they hold for the insurers today and will hold in the future. When researching a prospective SaaS provider, insurers should dig deep into the SaaS provider’s security features like adequate redundancy for data storage and fault tolerance, technical security safeguards as well as physical security safeguards, and what data their staff can access. Security requirements vary greatly depending on the organization and industry so it’s important to consider which security features matter and ensure the prospective SaaS provider can satisfy them.

But what happens when you have done all of this, and the relationship fails and you need to unwind the it? Or the vendor fails or is compromised? Or there is something else that requires you to have full access to your data and IP for which the vendor was responsible as your SaaS provider? This is where you need to build proactive measures into contracts like including clauses for data ownership transfer, scrutinizing SLAs and availability clauses, and reviewing force majeure clauses. There are also some architectural implications of building and maintaining technology infrastructure and partners.

One aspect to consider is including Business Continuity Planning (BCP) in contracts with vendors. BCP outlines the steps and measures that will be taken in the event of a disruption or termination of the vendor's services. These can include data transfer provisions, ownership, and knowledge preservation.

Other options include an escrow agreement. An escrow agreement can help address concerns regarding the long-term sustainability of SaaS platforms and the future governance of data. It is a legal arrangement where a third party holds and manages certain assets, such as source code, data, or documentation, on behalf of the parties involved. With an escrow agreement in place, an insurer can have the assurance that critical assets, such as source code and documentation, would be accessible if needed. Law firms can provide advice on data, IP ownership, and SaaS escrow ageements.

Insurers in North America should take time to understand regulations impacting other regions, especially the EU. While guidelines related to cloud computing risk management and digital operations like FFIEC in the US and DORA in the EU may not affect insurers today, similar practices that ensure compliance with those regulations could be implemented even if they are not mandated.

There will be challenges related to data migration and compatibility between systems if an insurer tries to leave their SaaS provider, but if the data model is governed well, the risk of data loss or leakage can be minimized. The regulations and frameworks related to data security and best practices used in other regulated industries can also help minimize the risk. Of course, we can’t emphasize enough the importance of SaaS data security. Keeping customer data secure requires encryption, privacy policies, customer education, data backups, consulting with cybersecurity firms, among other things.

It is critical that an insurer is protected today and in the future and for any chance that their vendor, platform , or data is not around for the long haul.