What Is a Security Portfolio?

Every one of the 4×4 security programs I previously described should have a healthy list of activities, projects, communications, education and cadence of activities. These may be internal to the program or driven by external demands. All of these combine to collectively form the security portfolio. With limited resources, it’s important to select which program activities get attention, which are less important and which are denied.

Often, But Not Too Often

The process to receive requests and generate projects or activities is an ongoing activity. It can be as simple as an application owner walking over to the desk of the program lead and asking, “Can your team change the integration of my application with the security solutions?” That intake process is the subject of another conversation, but when and how you prioritize requests is relevant to this.

The security prioritization process is collaborative, so I typically recommend a structured meeting, facilitated by the security program lead and held biweekly. If it’s more frequent than this, the administrative burden is excessive. If it’s less frequent, the IT and business stakeholders will lose patience.

Prioritization Criteria

Keeping with the 4×4 theme, there are four areas, with four criteria each, that need to be prioritized. Not all of these will be relevant for every organization, but these 16 items should cover everything in a security portfolio.

Risk Reduction

1. What was the cost impact of the risks avoided or issues remedied?
2. Is there a reputation impact of the risks avoided or issues remedied?
3. What is the likelihood of the risk becoming an issue (i.e., a vulnerability becoming a hack)?
4. What is the impact on regulatory compliance?

Cost

1. What was the internal cost of resources, materials and time (typically hours and internal fully loaded cost of resources)? This should include opportunity cost for time not spent on other things.
2. What was the cost of external resources such as consulting and staffing services?
3. What about software, hardware and other nonhuman costs?
4. What was the savings achieved per year? This is one factor in an ROI calculation that will be evaluated separately.

Timing

1. What was the duration of the project? If it is an ongoing activity, the value may be zero. In this case, the resource costs will likely capture the effect instead.
2. What is the timing of the risk becoming an issue (e.g., resolve the significant deficiency before the next audit cycle)?
3. What is the time to value, or when the project will begin to have the desired effect? ROI calculations will evaluate this separately.
4. What is the duration of value received, or the length of time the activity or project will provide the desired effect? This is another factor in an ROI calculation that will be measured separately.

Dependencies and Drivers

1. How many external dependencies are there?
2. What is the complexity of the activity or project? This should not include items from the other criteria.
3. What are the risks, issues and obstacles to project success?
4. Is this related to a crisis or event?

Objective or Subjective?

I’m teaching my eight-year-old daughter the difference between objective and subjective. I knew she understood the concept when she explained it like this: “These are beautiful leaves; that is a subjective sentence,” and, “There are four yellow leaves; that is an objective sentence.” I could have tried a security portfolio example, but I think the nuance would have been lost on her!

Unfortunately, many measures of security value are subjective. People believe so strongly in their perceptions of value that it’s easy to miss the nuance and impact of objective versus subjective evaluations of the security portfolio. So how do you evaluate those subjective elements? That is an art. It is gained by experience and requires a specific leadership trait: the ability to listen to others’ ideas for different perspectives.

The easiest way to evaluate subjective factors is to use relativity with a forced distribution. I’m not talking about anything like Einstein’s theory of relativity. I’m referring to something like high, medium and low or a numeric scale. Unfortunately, the inevitable situation is that everything is high-priority.

Forcing an even distribution avoids this. There are times, however, when the items in a security portfolio are interconnected, causing other activities and projects to be higher priority due to dependencies. While this can often be avoided by adjusting objective or subjective factors, it may become necessary to use the executive discretion measurement.

Executive Discretion

If your organization is like most, its executives are opinionated. They have specific interests in mind and (gasp!) favorite projects. Executives also control funding, have political capital and can direct resources. Their support is an indicator of whether an initiative is funded. So it is important to capture and evaluate their input within the prioritization and rationalization processes.

A word of warning: The purpose of security portfolio prioritization and rationalization processes is to avoid the heavy sway of individuals, so this should only be used as a tiebreaker — an add-on criterion if the others fail to help prioritize your security portfolio.

What About ROI?

ROI is essential in business; security is not exempt from this. However, ROI calculations are different for security because not everything is intended to create additional business revenue or affect the bottom line. Many aspects of security are an insurance policy against loss (of value, data, reputation, etc.). In my opinion, ROI is scrutinized too heavily by most companies because they haven’t adapted their calculations to put value on risk avoidance. The topic of security-specific ROI calculations is beyond the scope of this article, but it is important to decide if and how ROI is evaluated.

Weigh Them Carefully

Once you have identified the criteria, both subjective and objective, you have to weigh them. Not all criteria are equally important. Weighing criteria requires collaboration and consensus among the security organization. Each of the 4×4 security programs will have different priorities. For example, identity and access management can show a significant savings (criterion 2.4), whereas policy management likely won’t.

I have found the best way to reflect this weighting using a scaling multiplier, with the sum of the multipliers equaling 100. An example of this, in a simple priority calculator, is shown below.

Another option includes using a tollgate approach, wherein each criterion is ordered. During the evaluation process, if an activity does not meet a threshold for each criteria, it is rejected.

In closing, portfolio prioritization and rationalization is a complex topic. It is an art and a science. It requires leadership to blend all the competing factors to successfully deliver a security program.