“I thought you were taking care of that.”
That’s not what teams want to be saying when they’re scrambling during an incident response. Across all industries and public sectors, being intentional about roles and responsibilities can decrease communication issues and improve incident response. To help teams make progress toward the latter, this article, the first in a series on the top 10 things to do if you’ve been breached, discusses RACI (responsible, accountable, consulted, informed), a framework for defining roles and responsibilities.
What RACI Is
RACI is a method of defining ownership, accountability, and interface points for a particular project or function. The acronym stands for:
- Responsible: the manager or team directly responsible for delivery
- Accountable: the person with final authority over the effort
- Consulted: a person or team that has unique insights and should be consulted to add value to the effort
- Informed: a person or team who isn’t directly involved but should be kept up to speed
There are other variations on this framework where an “S” for “supported” could be added.
By facilitating a consistent approach to incident response, the RACI framework enables teams to have mutually understood expectations of their interactions and also to understand their interface points with each other and across the organization, removing the danger of ambiguity and assumptions. I believe the RACI framework should be viewed as a guideline and a living document, leaving flexibility for adaptation and growth.
Who Needs to Be Engaged
The primary teams or people that need to be engaged in the incident response process and part of your RACI matrix should be those in the critical path of containment, investigation, and recovery efforts. Each of these RACI definition areas, and which ones are a priority, will depend on the initial splash zone of an incident; however, it always helps for the following teams to be prepared:
- The affected team: This is obvious, but the team or teams who were affected by a security incident should be heavily consulted for context, data, or more throughout and after the course of an incident.
- Senior leadership: In most cases, senior leadership desires (or needs) to be informed of updates. There are cases where they may need to play a more active role as well, such as serving in a particular communications role.
- Communications/PR: Somebody from a communications team will likely be taking on a responsible role for communicating outwardly and inwardly about the incident.
- Data stewards: Depending on the organization or regulatory environment, data stewards may exist and need to be consulted on the intricacies of impacted data.
- Legal: Legal teams are typically consulted from a breach notification standpoint. They should be managing liabilities around notices, credit monitoring, or handling other penalties that may arise as a result of a security incident.
- Infrastructure/Information technology (IT): Depending on an incident’s scope, engaging the broader IT team to pull more logs or expertise around particular parts of the environment may be necessary.
Secondary Teams or Functions
Effective coordination around an incident isn’t likely to stop solely with the teams outlined above. The following teams or functions may not be top of mind, but they are still necessary to consider in the RACI process.
- Sales or customer-facing teams: Working with teams that are directly engaging with customers (or prospects) to ensure that questions are answered correctly and the intended message is distributed is key. These relationships are built on trust; effective communication is a critical part of that.
- Finance: Finance teams usually have a part to play in contract management as well as liability insurance. Consulting with your finance team around areas such as service-level agreements, insurance claims, and expectations set out in technology or service contracts, etc. can be tremendously helpful.
- Product/project management: These roles are typically responsible for molding the roadmap for technology projects. Security incidents may very well throw a wrench into existing plans, and it’s important to begin conversations as early as is feasible to explore what changes in the roadmap may need to happen to balance the immediate security needs.
Retrospect and Review
I mentioned above that RACI definitions should ideally be living and adaptable. Following an incident, it’s important to set aside time for learning, retrospectives, and lessons learned. It’s natural to focus on process gaps or missing technical controls. Evaluating if the defined RACI structure for the incident team worked for or against a successful resolution is important. This is the time to get critical, re-evaluate, and re-establish as needed.
If you’re curious for more knowledge in this area, here is a fantastic resource from Atlassian that discusses broader functional roles and responsibilities in incident management.
Want more cybersecurity insights? Visit the Cybersecurity channel:
