Who should own which cyber risks?
Assigning accountability MECE-ly.
Having lines drawn in the sand regarding cybersecurity risk ownership, regardless of how arbitrary they might seem, is almost always better than having none and just hoping “X will take care of this risk.”
Because he rarely is planning to.
Once you have a decision-making process in place (preferably following the steps laid out in my previous posts), the next step is to determine the scope of your organization’s cyber risk surface and assign accountability accordingly.
I would advise beginning with a brainstorm about every possible risk your organization might face and then pruning the tree from there. It might be tempting to dismiss certain items outright, thinking that “surely, another team is responsible” or “this risk isn’t relevant to the exercise.”
Unfortunately, I have seen many circumstances where these types of assumptions are unfounded.
For example, it’s quite conceivable that both the legal and information security teams might think that the other group will evaluate the risk of license infringement stemming from the use of third-party code libraries. Furthermore, managers of individual product lines which use such code might think that someone else already vets it when in fact no such process for doing so exists.
Placing accountability for a given risk on a single person’s shoulders is a step you cannot forgo. Promises that “we’ll work together on this” or “we’re both accountable” sound collaborative but often belie a lack of clarity with respect to who is in the driver’s seat, or even worse, an intentional desire to obfuscate.
It can also lead to decision paralysis.
It’s perfectly fine for senior business leaders to delegate development of these organizational models to their various advisors. Ensuring experts help draw the relevant dividing lines is a critical step. Once this is complete, however, the various business representatives need to sign off on the risk allocations explicitly (or have them assigned by someone higher up in the organization), as they will be the ones owning them - not the aforementioned advisors.
Formalizing these assignments can become challenging, so sometimes a senior-level executive (potentially the CEO or COO) will need to get involved to resolve any differences of opinion.
If your organization is large enough to have multiple teams focused on information security risk, this type of exercise is even more important. Having a clear charter for each one, an identified business unit which they are responsible for advising, and a formalized understandings of interrelationships between the various groups is critical to ensuring that you cover the range of conceivable issues.
The next step - actually documenting a clear framework for cyber risk accountability - can be quite challenging. For example, in Software-as-a-Service (SaaS) companies, where does the company’s internal information technology (IT) infrastructure end and where does the commercial software product begin (see Chris Hughes’ and my thoughts on how to depict this, if you are interested)?
Similarly, who is responsible for the open-source software upon which your product - and by extension, customers - rely, especially if it is up to the latter to install said software? It’s not always perfectly clear.
I am fond of many consulting frameworks, so will introduce another one in this article: MECE, which means “mutually exclusive and completely exhaustive” (see this article if you are interested in a deep dive into the topic and this one for the genesis and pronunciation).
MECE is a relatively simple concept, but using it will force you to make some hard decisions to categorize items in one and only one way. I would advise embracing this discomfort and making these tough calls; ambiguity will allow for gaps to emerge between functional groups and increase the overall risk to your organization. You can always adjust risk assignments later if they are awkward or inappropriate.
Also important is making accountability clear to parties outside of your company. For example, the biggest Infrastructure-as-a-Service (IaaS) providers (Amazon Web Services, Microsoft Azure, and Google Cloud Platform) all have their own “shared responsibility” frameworks that explain the duties of various parties operating software in their clouds. Based on this framework, I designed a similar model while working at PTC that is specific for Industrial Internet of Things (IoT) deployments (also see my broader thoughts on the matter, if interested).
As your security program matures, I would strongly recommend developing one of these frameworks for your specific company or product offering to make explicit who is responsible for what.
Examples of what these risk assignments should look like are below, although you will need to tailor these to the technologies and people you are dealing with. Please see this article for an explanation of what the various categories mean and this one for a definition of third (and greater) party code.
Manage information security risk from first-party codePerform/Recommend: Product Manager A
Input: Director of Engineering
Decide: General Manager
Ensure Consultation: Chief Information Security Officer
Manage license risk from third- (and greater) party code in applicationPerform/Recommend: Product Manager B
Input: Director of Engineering
Decide: General Manager
Ensure Consultation: VP of Legal
Manage information security risk from third- (and greater) party code in applicationPerform/Recommend: Product Manager C
Input: Director of Engineering
Decide: General Manager
Ensure Consultation: Chief Information Security Officer
Manage license and information security risk from third- (and greater) party code in infrastructurePerform/Recommend: Director of IT Infrastructure
Input: Director of DevOps, Director of Engineering
Decide: Chief Information Officer
Ensure Consultation: Chief Information Security Officer, VP of Legal
Manage information security risk from hosting product with IaaS providerPerform/Recommend: Director of IT Operations
Input: General Manager, Director of DevOps, Director of Procurement
Decide: Chief Information Officer
Ensure Consultation: Chief Information Security Officer
Manage information security risk from endpoint detection and response (EDR) toolPerform/Recommend: Director of Security Operations
Input: Director of Network Operations
Decide: Chief Information Security Officer
Ensure Consultation: Chief Information Officer
Manage information security risk of storing financial data in SaaS applicationPerform/Recommend: Director of IT Operations
Input: Director of Procurement
Decide: Chief Information Officer
Ensure Consultation: Chief Information Security Officer, Chief Financial Officer
Test and certify third-party software used in software product that is generally customer-managed Perform/Recommend: VP of Quality Assurance
Input: Director of Engineering
Decide: Product Manager A
Ensure Consultation: Chief Information Security Officer
Update third-party software used in actual customer-managed deployment of software productPerform/Recommend/Decide: Customer (the organization broadly can be assigned accountability contractually, but they will need to run this type of exercise internally to identify who will actually perform the task)
Input: Product Manager A, Technical Support Engineer
To develop a truly MECE framework, you’ll need to document accountability for all information security risks that you identified during your brainstorming. Furthermore, you’ll need to review and update these assignments regularly as the relevant technologies, partners, and organizations evolve. Doing so will be challenging and labor-intensive, but will set you up for success and save substantial amounts of time in the long run.
Instead of assembling every potential stakeholder to “discuss” a time-sensitive issue, you can instead run a tightly scripted process to achieve resolution quickly. Furthermore, assigning clear ownership for each type of risk will sharpen people’s minds and help to avoid dropped balls, which could take the form of a disastrous breach.