Defining who gets to make a decision is just as important as the act itself. Next up in our series is Role Definition. Prepare yourself, I'll use the term RACI a lot but don't let the fear of overhead distract from the goodness. The RACI is just a tool to facilitate debate early so you don't have to in the heat of battle. There's a ton of reference how to construct RACI's better than mine so I'll stick to why it's important, when, and how I use it.
Role definition is a tool that defines who's ultimately accountable for a task, who performs, contributes, informed, or is left out. It's better than leaving vague because security decisions are often made by people who don't make money for the business or own the service in question.
Roles are also another reason why the Service Catalog is a foundational document. You should have a RACI for every key security service and sup-process. We'll continue to leverage the catalog for capacity management in a future post. You should also have RACI's at the group level. These politics are much more interesting.
At the group level we often have a cast of risk characters: IT security, line of business managers, ops, audit, and other risk groups. As always, each character draws the world with them in the center. Thus, it's important to manage the roles to help the business manage risk.
Quick word on roles with audit
My opinion is a RACI with audit is very useful and seldom written. Write out the tasks associated with an audit and focus on the last steps where audit recommends controls. Obviously they're accountable for that. However you're accountable for the response. A good RACI makes it clear how disagreements will be decided. If you feel your audit organization tends to wag the dog, a good RACI and frank discussion does wonders to clear up disagreements. I appreciate audits' opinions but I don't always think their recommendations align perfectly with your risk management priorities. Sure you may have a finding that needs to be addressed. However you might have 20 other things more important. Please don't stop the roadmap and take a detour to address the lower priority finding. It's the path to the reactive dark side. Feel free to have the discussion in the front of the BoD. They'll appreciate the insight into who is accountable for managing risk...
Cousins of RACI
I can hear fellow process nuts asking why I don't include swimlanes and SIPOCs (source, input, process, output, customer) in the magnificent 7. I don't mean to slight them. They're just more useful at the process level. Please do keep in mind the relationship because they affect each other. For example, the tasks in the RACI may be the same as the process steps in the swimlane and process steps in the SIPOC. Thus, you might have a few seemingly redundant tasks in the RACI, however they might be important in the other docs. Together the puzzle looks pretty cool.
When to RACI
A good rule of thumb is if you have to ask... especially at the process level. Anytime your team interacts with another, a RACI's a good idea e.g. incident response, perimeter management, IAM, HR, eDisco, phy sec, architecture, control patterns, hardening standards, etc.
Another thing I love about RACI's is how fast they are to build. If you can describe the steps and players, you can whip up a RACI. Getting it right isn't important at the start. The value is in the discussion.
A customer recently asked me about their internal consulting/project support process. To prove the point how easy they are, I whipped up the following hypothetical. Note I added a few comments to highlight steps where ownership might be unclear.
The ability to proactively highlight points of contention is powerful. It puts you in the position to lead the discussion and shows you're ready to respect areas where you aren't accountable. It goes both ways.
It would be a fun exercise to collect anecdotes where one group thought they own the decision to accept|mitigate|ignore a risk or a design decision. My past is full of them. I'm guilty as the next person who tends to step in if there's a leadership void. It took me awhile to mature to the point where I stayed within my role and simply helped the accountable owner walk the right path. I picked on audit earlier, here's a few more common examples:
- project managers taking responsibility for design decisions
- architects prioritizing functional needs vs. the customer
- assessment team deciding which risks should be accepted|mitigated
- IT security asserting accountability for a line of business control e.g. ecomm authentication
Even if you don't run to the whiteboard every time there's confusion, the mindset of clearly understanding everyone's role in the process is awesome. I think it's liberating to know my bounds. I know when to defend them and can see where I need to reach out to build bridges and formalize relationships. People will trust you more when they know you're not out to run them over or take credit for their work. And trust is the foundation for leadership.