There is no custom code to display.

How to Validate Your Security Program: Part Four

Print Friendly, PDF & Email

By Ray Bernard PSP, CHS-III

Note: This is the fourth of a multi-part series that provides 15 important perspectives from which to validate your Security Program. If this is the first article you have seen in this series, please read the WHY VALIDATE? introductory article before launching into the validation steps.

An attribute is a quality or feature regarded as a characteristic of something. What we are calling the “15 Validation Attributes” are 15 characteristics that you can use to both validate and strengthen your security program.

Validation Attribute: Justifiable


  1. able to be shown to be right or valid
  2. proven to be working or effective

The second validation attribute we’ve looked at—defensible—addressed having a solid rationale for each element of a security program. Justifiable goes beyond simply having a good reason.  Justifiable deals with results and evidence of good results.

The overall mission of security is to reduce security risks to acceptable levels, at an acceptable cost. Management has the responsibility for determining acceptable levels of risk and cost. Security has the responsibility to put reasonable risk reduction measures in place and maintain them.

The key question is: Does the information we give to management justify our security program?

Whether in meetings, formal reports, answering questions, or casual conversation—what is the story that we tell?

We’re Good at Providing Bad News

A few years ago an informal survey showed that many security practitioners report mostly “bad news” information to management. Typical statistics include items like security operations costs, overtime costs, cost of investigations, number of security incidents, serious incident descriptions, and so on. Often this is information that management has asked for. But this kind of information does little to justify a security program. In fact, it often gives a false negative impression of the state of security and security measures.

A Good Day is Not “When Nothing Bad Happens”

A good day is when security measures are effective, whether people, process or technology. A good day is when the impact of a risk incident is minimized or avoided altogether, due to the effectiveness of the security program. Risk conditions are unavoidable. The true test of a security program is whether its measures are intact and functioning, and whether or not the program actually is reducing security risks to acceptable levels, at an acceptable cost.

Without realizing it, practitioners can give the impression that good security results are more dependent upon luck or happenstance than on the effectiveness of the organization’s security program. After all, their focus is on managing risks and keeping security operations up to par, not on departmental public relations.

It’s Not What You Say, It’s What People Hear

That is the subtitle of the book Words That Work by Dr. Frank Luntz, available on Amazon. Applying this principle to information on security activities, it’s not what you report—it’s how people interpret it. Thus reporting as well as casual comments about security should do these two things:

  • Provide insight into the appropriate part of organization’s risk picture and the state of related security measures, whether the topic is as narrow as a specific incident or as broad as the question, “How is Security doing?”
  • Provide a perspective for the information recipient, who otherwise is likely to apply a wrong perspective and come to a wrong conclusion.

You will be easily able to do this if you have done your justification homework.

Justification Evidence

Justification requires evidence in context about the status of risks and the effectiveness of risk measures. Evidence can take the form of:

  • Anecdotal evidence (true stories)
  • People’s impressions (as volunteered or surveyed)
  • Measures and metrics (raw numbers and comparisons indicating status or trends)

Anecdotal Evidence. Some things can be hard to measure, but that doesn’t mean you can’t characterize them. While there can be pitfalls in using anecdotal evidence, when understood and used properly anecdotal evidence can be appropriate and effective. See the Parking Lot Security Story.

People’s Impressions. A key objective of physical security is a safe and secure workplace. A key objective of information security is safe and secure data. Surveys are a good way to obtain useful information about security impressions and awareness from key stakeholders including employees, contractors, partners, customers and management. The SANS Institute provides downloadable Information Security Awareness Surveys, two of which are available here and here. ASIS published a very informative case study about security surveys written by R. Scott McCoy in Security Management magazine; the article is titled Better Service Through Surveys and is available to ASIS members upon login.

Measures and Metrics.  A measure is a single-point-in-time view of a specific factor being measured. A metric is a comparative view relative to a requirement, a baseline, or two or more measurements taken over time. A requirement, baseline, or set of measurements provide important context for any single measurement.

For one thing, physical security cost-effectiveness metrics could include a picture of how security costs relate to other factors:

  • per dollar of revenue
  • per dollar of profit
  • per dollar of company valuation
  • per square foot of property or building space
  • per employee
  • per contractor

For example, what if security costs are increasing due to company growth, yet the company is mandating cost reductions? If you can demonstrate that the cost of security is decreasing per square foot of property or building space, per employee, or per dollar of profit—your request for a budget increase can be seen in the correct light.

All three of these types of evidence can provide valuable talking points when opportunities arise to say something insightful about security status or activities.

Additionally, it is a recognized principle that “you can’t manage what you can’t measure”, and metrics provide an effective way of obtaining valuable insight into your security program. Utilizing metrics is a standard business best practice and in and of itself sends a good message to management about your status as a manager and leader.

If you already have measures and metrics in place, this may be a good time to review them in light of the current risk and business contexts.

Go here to view a few graphical examples of security metrics.

Validation Steps

Don’t try to justify all of the various elements of your security program. Start with what is most important, and when you get to Step 4 below, select the justification items that you think you can easily get done within three to six months.

Step 1. Copy your original Security Program Outline (created in Part Two of this series). Save the document as a new document (such as “Security Program Outline with Justification Notes”).

Step 2. Rate each element’s status for justification. Use three ratings, one to rate Justification Evidence status, one for whether or not status is regularly or periodically Reported, and one for whether or not you have documented Talking Points you can use on demand.

 Justification Evidence Ratings

  • Have good ongoing measures and metrics.
  • Have some measures or metrics in use.
  • High priority to develop justification.
  • Low priority to develop justification.
  • Justification evidence not important at this time

Reporting Ratings

  • Have satisfactory regular/periodic reporting.
  • Only report when requested.
  • High priority to determine how best to report.
  • Low priority to have reporting.
  • Reporting on this element not important at this time

Talking Points Ratings

  • Can easily speak to the value of this program element.
  • High priority to develop good talking points.
  • Low priority to develop talking points.
  • Talking points not important at this time

Step 3. Prepare to develop appropriate justification. In addition to the various links provided above, get one or more of these additional references that apply to the types of justifications that you want to develop. I highly recommend all of them, but choose one or two that fit your immediate needs, based upon the ratings that you established in Step 2.

For developing anecdotal evidence and talking points:

For developing measures and metrics:

Information Security:

Physical and IT Security:

Step 4. Create an Outline Plan for Justification. After you have reviewed the content of the justification references that you have downloaded or purchased, outline a plan for developing the talking points, surveys, measures and metrics that you want to develop. Include the reason why each particular justification item is needed, and how you will utilize it going forward. Set objectives for completing the actions in the plan. Consider making use of any staff resources that could assist your efforts.

Step 5. Schedule Plan Progress Reviews. Set a monthly or quarterly schedule to review your justification progress. Follow through and complete the steps of your plan.

Step 6. Update Your Justification Outline. Record the new status based upon the justifications that you have put in place. Follow Steps 3 through 5 if you would like to expand what you have done in your first pass justification work.