Fact of life: Data and the processing and transactional functionality that makes use of that data has to reside in a secure environment. Given the number of data breaches that have occurred this year alone, that’s self-evident. So, when the organizations with which you work are reported to be compliant with SOC and other data-security requirements, that compliance is not to be taken lightly. Here’s why:

Who’s Watching?

Compliance indicates the processes and practices within the organization have required levels of oversight. Monitoring is in place for unusual activity, configuration changes are authorized, and access is granted only to approved users. Normal activity is baselined to make deviations readily apparent and to determine the presence of potential threats.

Compliance also indicates adequate alerts and audit procedures are in place to:

1. Ensure awareness aberrant activity and to initiate a corrective response.
2. Identify the root causes of aberrant activity to ensure appropriate remediation.
3. Trace aberrant activity forensically to determine its source, its path in the system, the parts of the system affected, the nature of the affect, where it might go or what it might affect next.

But Who’s Accounting?

Compliance with SOC and other data-security requirements also means personnel within compliant organizations are accountable to their customers and to each other for upholding the terms of compliance. From preventing breaches to identifying potential weaknesses, from shoring up potential weaknesses to remediation if it’s required, the appropriate people in audited organizations are on notice and on the hook. They should also be responsible for conducting regular assessments on patch management, vulnerability management, and overall system-security management — and reporting the results of those assessments to all of their data- and system-security peers in the organization.

If you’re not sure if the organizations with which you work are compliant with data-security requirements, here are a few things you should do:

• Ask if the organization has any data-security policies or procedures in place.
• If so, ask what they are.
• If not, worry … a lot … and find a new home for your data.

Some things are worth worrying about more than others. The security of your data is one of them.

We love the periodic notices we get from various entities with which we work in our personal lives, entities like banks, mortgage companies, auto-finance companies, credit-card companies, and others. They typically go something like this:

PLEASE NOTE: Our system will be shut down for the Holidays. As a result, it will be offline from New Year’s Day to Christmas Day, during which time you’ll be unable to check anything, schedule anything, pay anything, or withdraw anything. We apologize for any inconveniences this may cause you, including but not limited to headaches, bouts of anxiety, defaults, foreclosures, repossessions, liens, derogatory credit reports, or Nasty-Grams from any of your creditors. Have a nice day.

We’re a software shop. We get the fact that software and systems upgrades are necessary and always will be. But does their timing have to be arbitrarily predetermined? And if we extend the necessity of upgrades from our personal lives to our businesses, what does that timing actually have to do with your business and its needs?

Everything.

It’s About Time

Every provider of every kind of software or system to any kind of business in any industry has to provide things on occasion — upgrades, updates, patches, bug-fixes, new versions, and whatever else might be necessary. If those providers ask you anything at all (sometimes they don’t), they usually ask just two questions:

1. Are you ready?
2. How ‘bout now?

We think a few other questions might be in order:

• Do you need it?
• Do you need it now?
• Do you have other, more important operational considerations right now?
• Do you know when the upgrade will help you the most or be most advantageous?
• Will you let us know?

That might not be the best way to go about things, but it seems to be the most beneficial.

Common Sense

We don’t know why common sense seems to be so uncommon. But we do know it makes sense to let customers have upgrades at the right time and to let them determine the right time.

Upgrades on your time. That seems pretty common-sensible.

According to dictionary.com, infrastructure is defined as:

1. The basic, underlying framework or features of a system or organization
2. The fundamental facilities and systems serving a country, city, or area, as transportation and communication systems, power plants, and schools.

The insurance industry typically considers infrastructure to mean the technological architectures within which hardware and software are purchased, deployed, run, and maintained.

Considering the fact that we couldn’t find any people in that definition — and since we haven’t reached the point at which AI and RPA enable hardware to purchase and install itself or software to program and implement itself — we think it’s a little narrow. Nor does it allow for the fact that software enables people to contribute to their organizations intellectually, as opposed to menially and mechanically, by automating menial, repetitively mechanical processes.

Infrastructure v2

We think we can (and should) give infrastructure a broader, more all-encompassing definition. Something more like this:

The resources, human, financial, and technological, by which the enterprise constitutes, operates, and sustains itself.

If we choose to define infrastructure that way (life is about choices), a number of productively beneficial things will happen:

• We’ll define requirements for hardware and software more completely and accurately because we won’t forget the people who have to use the hardware and software we procure and deploy.
• We’ll be more likely to procure the hardware and software that will be most beneficial their respective organizations because we won’t forget the people who have to use the hardware and software we procure and deploy.
• We’ll achieve more favorable outcomes because we won’t forget the people who have to define, procure, and use the hardware and software we procure and deploy.

One More Thing

The notion of people, product, process used to be so popular there were graphics and videos created to promote it. What happened? We don’t have any intentions of selling products short — ours or anyone else’s. But the idea of products without people to buy, use, and benefit from them is curious and shortsighted at best.

“The bots are coming! The bots are coming!” has become the latter-day equivalent of “The sky is falling.” We know the bots are coming. They’re inevitable. They’re even beneficial. But the activities they perform are programmed — by people. They’re not the result of spontaneous, inventive, electronic ingenuity.

We don’t have to broaden or our horizons all that much to make sure our definition of infrastructure is adequately inclusive. All we have to do is include people.

That’s just one more thing. But that one more thing is the most important element in the definition.

Let’s do it.

—
People, product, process image © videoblocks.com.

We’ve never conducted any kind of formal or official poll on this. But we’re willing to bet that if we asked most insurers and their employees if they considered their software to be an asset to their organizations and their people — or some kind of threat or liability — the majority would say the latter. Notwithstanding our own (hurt) feelings, that’s just not right. And vendors may be as much or more responsible for those sentiments as insurers.

What if, on the other hand, insurers considered their software to be an unconditional asset? And what if, rather than a threat of a liability, their people viewed the company’s software as helping them to make more valuable contributions to the organization? What if they saw the software, in fact, as a source of job security, helping them to make more valuable contributions to the organization, thereby increasing their value, their longevity, and their satisfaction? Would that be some kind of a pipedream? It shouldn’t be.

Higher Table Stakes

Insurance technology has advanced to the point at which configurability is an entry card. If their software doesn’t come with configuration tools, vendors won’t get a seat at the table, let alone be in the game. Those configurations tools free the people in IT departments to create business value — assess technologies, align IT with business goals, develop and maintain resilient, secure infrastructures. Given the rate at which configuration tools continue to advance, it’s not hard to imagine a day in which any BA can install any core-processing software in any insurance company. Another pipedream? Don’t be so sure.

The efficiencies enabled by software already reduce redundant data entry, while the portals provided by software allow increasing degrees of self-service and reduce the need for heavily staffed customer service departments. And if those efficiencies reduce the need for people to perform mundane, menial, and administrative tasks (they do), that means those same people can contribute more value to their organizations in higher-level, revenue-generating, risk-managing, and loss-mitigating positions. Call that a pipedream if you like. But it’s as inevitable as it is desirable.

Here It Comes

That sensation you feel is the rush of progress. The pipedreams are over. The future is here. And it brought reality with it.

Get ready, or get left behind.

In the insurance industry, which is highly regulated but stubbornly non-standard, we seem to spend a lot of time explaining ourselves, don’t we? Do you ever wonder why? We have a theory:

We think it’s because of human nature.

As human beings, we’re not terribly interested in smallest, slowest, oldest, least capable, or most common. Give us bigger, faster, newer, most powerful, and avant-garde and we’ll be there every time. And so it is we find ourselves having to explain terms like insurtech, innovation, and disruption.

Words Matter

The insurance industry has been using technology for decades — from the mainframes of the 1940s to the databases of the 1960s, from Univac to IBM, from COBOL to Java, from client/server networks to the cloud. Insurance may not have been the first industry to adopt it. But adopt it we did. In that context, insurtech is just another term for what has always been insurance technology.

And pardon us for saying so, but — while the insurance industry is gradually adopting technologies available to all industries (AI, robotics, machine learning, and telematics) — there hasn’t been any new processing technology to speak of in insurance for at least a decade. And even if there were, we wouldn’t know what to do with it yet, given the nature of technology adoption and the (justifiably) conservative nature of the insurance industry.

We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run. (Amara’s Law)

Give Us Our Change

And then we have innovation and disruption. We don’t mean to make light of this war of withering words. But in circumstances like these, we have to leave room for a little humor, don’t we? If not humor, at least a little curiosity. So, here’s an experiment you can try at the next conference you attend:

Walk into the session entitled, “Disruptive Innovation in InsurTech”. Let everyone in the room off the hook by not asking them to define insurtech. Give them the benefit of the doubt and presume their perspectives on disruption are positive; that is, they generally assume disruption to have a positive outcome, rather than a calamitous one. Then ask them if they can tell you how innovation and disruption are different from change.

In the ensuring silence, tell them you’d like your change back.

We Have Work To Do

Our facetious levity notwithstanding, there’s serious work to be done in the insurance industry. So, rather than trying to decide which came first — the chicken or the egg; insurtech or constructive pragmatism; innovation or change where it’s needed; disruption or calm, shared progress — maybe we should talk about what needs doing right now.

We have no idea what tomorrow’s jargon will be. But we’re positive insurers have to do business today.

Let’s put our faith in practical experience and plain language to get it done.