For several weeks I've been writing about Data Valuation with a goal of considering any impacts on IT infrastructure.
I introduced the table below as a framework for discussing data insurance from the perspective of people and processes. Insuring data is an example of data valuation, and much can be learned by diving into the potential underwriting process depicted below.
In a recent post I mentioned that it is already common for an insurance agent to visit a data center for the purpose of insuring against disaster.
What is uncommon, however, is the role of a data insurer. This role would specifically focus on data set insurance (as opposed to data center insurance).
In this post I'd like to focus on the next step in the table below and discuss the need for a data insurer to carry out trust inspections.
I have already spent a good deal of time discussing scenario #1: the data set identification process. I have also proposed a set of people that would likely work with a data insurer. In general:
- The insurer would begin the process by asking Where's The Data.
- The insured would share their Data Audit and Inventory System (DAIS) in response. If they don't have one, they should consider building a super-set of a DAIS known as a Metadata Lake.
I reasoned that a Data Architect would be a great candidate to participate in this initial phase of the data insurance process. I also reasoned that a Chief Data Officer could be another appropriate liaison; they could either oversee the effort or work closely with corporate Data Architects.
With an identified data set, the next step in the data underwriting process would be to assess the level of risk by understanding the current data protection level.
This "trust inspection" process, like the role of data insurer itself, is emerging. There are a few things that stand out as being important in terms of generating a risk profile for a data set.
- The faster that a data insurer can associate a data protection level to a data set, the more efficient the whole process becomes.
- It would be helpful to flag the data set as "insured" or "considered for insurance".
- The association of data protection level and data set needs to be bound together and audit-able for the life of the insurance policy.
- Migration of insured data sets would need to take into account the (a) data protection level of the target, and (b) the data protection level of any insurance policy.
The topic of trust inspections has strong ties to new definitions of trusted infrastructure. In an upcoming post I will explore these ties and consider their relevance to next generation data center architectures.