Structured data

Structured data is a way to capture key details about incidents, in a structured way, that can be specific to your organization. For example, you could use structured data to track customer impact such as which product has been affected or how many customers.

This data can be used to improve communication during incidents, drive automation, and support analysis after the incident is over.

The importance of structured data

Improving communication

Incidents can be chaotic, but in the same way incident severities can improve communication, so too can other structured data specific to your organization or workflow. This data helps us to pull important information out of the chaos, such as customer impact, or the technologies involved. Structured information like this is easier to scan and interpret, especially in incident updates, so everyone gets on the same page as quickly as possible.

Powering automations

With structured data attached to your incident, it’s possible to define processes and actions to be followed when certain values are set. For example, if an incident is identified and tagged as a data breach, let the data privacy team know. Whether this process is manual or fully automated, it’s helpful to use data like this to determine a sensible course of action.

Tailored automations can improve your incident response There's lots to do during an incident, so anything that can be done to automate steps can be hugely helpful. Automating away key actions based on objective facts and data about the incident means responders and incident leads can focus on what they know, rather than what they need to do.

Delivering insights

Structured data is a powerful tool for gaining high-level insights into the incidents happening at your organization. Whilst they don’t replace the kind of insight you’ll find by debriefing and analyzing incidents individually, they are great as a way to model incidents over time and pull out common themes.

Collecting the right data

When you're asking someone to input structured data, you're creating additional work for your responders. It's important to prioritise collecting the data that you really need. Here are some examples of types of data that can be useful to collect:

Customer impact

Some common and practically useful data to collect on incidents is external customer impact. Understanding and defining the customer impact can help you to respond proportionally, and to keep customer-facing teams like PR and customer success all on the same page. Helpful fields to track include:

• The total number of affected customers - This can help you decide how you want to communicate: for example whether you want to open a communication channel with a specific customer, or should instead post in a public form such as a status page. It also helps add context to an incident name or summary, to help stakeholders judge the severity.
• Specific customers that are affected - Particularly for B2B products, knowing exactly who is impacted can be important to drive your response. They could be high value customers, or customers who are the responsibility of a particular account manager.
• How customers are impacted - Again, this helps you communicate what the impact of your incident is. Perhaps this is a rarely used feature that is only occasionally being slow, or there’s an easy workaround. Or alternatively, your entire system is down and it will have terrible consequences for your customers.

Technologies or services involved

Collecting data on the technologies or services involved is useful for anyone tasked with supporting a particular service. Technologies involved could be quite high level, such as databases, DNS, mobile apps, or it could be more specific such as a particular backend service.

This data useful during an incident, as domain experts can jump in to provide their context about the particular service.

It’s also valuable after the incident: it enables you to analyze the most common technologies involved in your incidents, or the technologies involved in your worst incidents. This allows you to then target your efforts on the most impactful areas of your organization.

Regulatory considerations

In regulated industries, there can be regulatory requirements around incidents; for example under GDPR you must report certain data breaches to the ICO.

Structured data can be used to record whether or not an incident is ‘reportable’ under that regulator’s rules, alongside fields that these regulators are interested in.

For example:

• Is any customer’s personal data at risk? (Yes/No)
• Does this need to be reported to the ICO? (Yes/No)