What Is a Security Program?

What is a security program? That is the first question we must answer. My definition is this: It consists of projects, activities, processes, policies and technologies that combine to achieve a shared objective. All of these are operated by people, some of whom are in roles across different security programs, as was previously defined in the 4×4 security program organizational model.

Thus, we need common practices across all security programs. By unifying these team members with essential program management practices, the security service is born.

The Essentials

There are six essential program management practices for a security program. All six of these are required for each of the four security programs. Some of these are frequent events, others less so. Some can be jointly conducted across multiple security programs while others must operate alone. But most importantly, they all have a scheduled cadence and specific owners.

1. Business Liaison and Engagement

Business liaison and engagement includes direct interaction with the business owners, IT representatives and other groups who consume the security service. This is ideally a structured cadence to keep a pulse on the business. If your organization were a software company, the business analysts who perform this are your account managers.

2. Demand Management, Intake and Prioritization

The second stage involves the initial review, analysis and acceptance or rejection of requests from the security service. There are both mathematics and art in managing a portfolio of projects and activities. Cost certainly plays a part (you do have a charge-back model, don’t you?), but resource availability, dependencies and other factors are also evaluated. Look up the definition of a project charter in your PMBOK Guide and Standards for what you’ll need to manage this activity.

3. Security Integration Life Cycle

The security integration life cycle is like a software development life cycle but specific to your technology and process landscape. It defines how solutions are designed, tested and implemented. This is more than a project management or change management methodology; it is tailored to your security organization.

4. Program Reporting

Program reporting is different from project or service reporting, but it encapsulates both of them in addition to other factors. This report for stakeholders is done monthly by the program leader, and it is designed to establish two-way accountability. The format, metrics, timing and audience should be specific and narrowly focused on the security program.

5. Risk, Issue and Decision Management

These three factors are near and dear to every project manager’s heart. Since the security programs are so closely related and typically share resources, timelines and funding, it’s important to manage risks, issues and decisions at the project and program level. The relationship is simple, with the project rolling up to the program.

6. Strategic Roadmapping

Strategic roadmapping sounds like fun and glamorous work — and sometimes it is. To make this successful, your team needs to walk a fine, gray line between the clouds and the weeds. Here is what I mean: The strategic initiatives have to be driven by long-term objectives, but they have to be detailed enough that you can hand each item off to a project or operations manager with the confidence that they can succeed because they have the right level of detail.

Tailoring Program Management Practices

These are not new concepts, but they need to be tailored and commonized to the security service. Generic versions of these processes provide a good baseline, and outputs (i.e., a portfolio of projects) might be the same format. In order to really achieve the highest value to the business, there are a number of organization- and security-specific changes that should be made.

For example, the calculation of business value is different for security because risk reduction, which is a relative measurement, is a major driver and nearly impossible to mathematically calculate. Furthermore, most security technologies are packaged products that are difficult to implement using an agile approach and necessitate a different change management process than custom development.

Few companies can build the perfect security program and implement program management practices immediately, so it is essential to take a long-term view of the effort, iterate and solicit external input. It sounds like recursion, but it’s true: Building strong program management should be on the program road map, measured constantly and reported as an essential metric of maturity.