Being on-call is already a demanding and sometimes very unforgiving responsibility. If you are working in a regulated industry, however, the demands that incident management places on your organization are likely to be even greater and even less forgiving. In this article, we’ll discuss some of the basic principles of software-related incident management in regulated industries.

Incidents, Regulations, and Compliance

First, however, let’s take a quick look at what a software-related incident means in a regulated industry. If you were to ask most people in software development or IT to define “incidents”, they may talk about them in terms of downtime or poor application response time. Another important factor could be security — break-ins, data theft, failure to protect sensitive data, etc. 

But in regulated industries, the term “incident” has a scope that goes far beyond downtime and security issues; it can be anything which places the organization or its products or services out of compliance with regulations. For a water company, that might be the presence of E. Coli bacteria in the water supply. For a bank, it could be the loss of customer financial data. For a hospital, it could be the failure of critical life-support systems. Incidents involving public safety, the loss of crucial data, or interruption of key services, when regulatory compliance is at stake, may be at least as important as those involving ordinary downtime.

Compliance — What’s at Stake

One of the most fundamental issues for any organization involved in a regulated industry is the need to stay in compliance with applicable regulations. Depending on the industry and the nature of the incident, being out of compliance can result in:

• Fines, fees, or other civil or administrative penalties
• Lawsuits or other legal action by organizations or individuals affected by the incident
• Suspension or loss of licenses or other certification required to work in the industry
• Loss of reputation within the industry or in the eyes of the general public
• In extreme cases, criminal charges, conviction, and jail time for the responsible individuals

In other words, the stakes can be very high; you do not want to be in the position of explaining your incident management procedures to a judge.

Necessary and Best Practices

How do you manage incidents under such strict conditions? The best incident management is prevention — to take care of all potential incidents before they become compliance issues. That isn’t always possible under real-world conditions, so it is important to have incident-response plans which meet both legal requirements and practical necessities. To do this, it’s important to take into account the following factors:

• Regulatory requirements and guidelines. Always follow regulatory agency requirements with regard to incident management, prevention, and response. These vary, depending on the industry and the agency involved, but they will often include a formal incident response plan, an IT incident response team, and formal documentation of incident response procedures and actions. 

Organizations operating under the Health Insurance Portability and Accountability Act (HIPAA) or the Payment Card Industry Data Security Standard (PCI DSS), for example, must have a documented security-response plan and a response team; the Federal Information Security Management Act (FISMA) likewise includes detailed incident management and response guidelines for federal agencies. Find out which agencies and which requirements your organization is subject to, if you do not already know, and make sure that you are in complete compliance with all requirements.

• Industry guidelines and best practices. These also vary, depending on the industry. An industry-wide professional organization will often be able to provide a set of recommended practices.

If there are no specific guidelines for your industry, the Common Criteria and Common Evaluation Method documents provide a useful framework for understanding general IT security and public-safety issues.

General Considerations

There are some basic considerations which apply to all regulated industries and all regulatory frameworks:

Identification

Identify all sensitive systems (applications, networks, services, etc.) in which a failure or other malfunction could lead directly or indirectly to a compliance problem. A database containing client medical records, for example, or a program that manages the distribution of power for a public utility, is likely to fall under this heading. Your company’s bookkeeping software, as important as it may be, is probably not a sensitive system in this context.

Prevention

Your first line of incident management defense is to prevent any of the systems which you have identified as sensitive from even approaching a state of failure. This means that your incident response team should be alerted not only for any failure in these systems, but for any condition which has the potential to lead to a failure. For security-sensitive systems, this might be any activity which suggests an attempted break-in, or any degradation in performance of the security software itself. For systems where public safety is at stake, this could include any anomalous behavior in any key metric. Needless to say, prevention includes full backups of data, and where necessary, full backup systems on standby.

Catching problems before they turn into regulatory compliance failures also requires an incident response team completely in sync, armed with full context from all information sources. In these situations, every second counts! For that reason, it’s vital to have responders defined ahead of time, clear escalation policies, and access to metrics from multiple systems pulled together into a unified view of the issue.

Priority

You will in effect need to add another level of priority to your existing incident management triage, giving all compliance-related incidents overriding priority. This means that if your bookkeeping and inventory systems both crash completely, and at the same time, your medical records database starts to act like it’s just a bit under the weather, your accounting staff and warehouse crew may need to stand around until your emergency response team takes care of the database if you don’t have enough IT people on hand to attend to everything. And if public safety is involved, your response team may need to be ready to keep crucial systems going in the immediate aftermath of a major disaster.

All of this may sound formidable, and expensive as well. But the cost of a major incident can be much higher, particularly if a regulatory agency or a judge determines that your company has failed to adequately comply with regulations. The bottom line for you and your company is that preventative incident management is by far the best protection you can have.

If you’re looking for a resource to improve your incident response processes and workflows, check out our open-sourced incident response documentation as well as our financial services solutions brief for an example of how PagerDuty helps regulated industries.