How to validate your security program: Part 4

Feb. 9, 2016
What every security professional needs to know about justifying their program to management

Editor's 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 introductory article before launching into the validation steps found in part one, part two and part three.

Validation Attribute: Justifiable

Definition:  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. 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.

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.

Click 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

  • J-1. Have good ongoing measures and metrics.
  • J-2. Have some measures or metrics in use.
  • J-3. High priority to develop justification.
  • J-4. Low priority to develop justification.
  • J-5. Justification evidence not important at this time

Reporting Ratings

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

Talking Points Ratings

  • T-1. Can easily speak to the value of this program element.
  • T-2. High priority to develop good talking points.
  • T-3. Low priority to develop talking points.
  • T-4. 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:

  • Beyond Fear: Thinking Sensibly About Security in an Uncertain World
  • Tell to Win: Connect, Persuade, and Triumph with the Hidden Power of Story
  • The Presentation: A Story About Communicating Successfully With Very Few Slides

For developing measures and metrics:

Information Security:

  • Security Metrics, A Beginner’s Guide
  • Security Metrics: Replacing Fear, Uncertainty, and Doubt

Physical and IT Security:

  • Measures and Metrics in Corporate Security (Includes 375 real examples of security metrics across 13 categories)

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.

About the Author: Ray Bernard, PSP, CHS-III is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides security consulting services for public and private facilities ( Mr. For more information about Ray Bernard and RBCS go to or call 949-831-6788. He is an active member of the ASIS Physical Security Council and Information Technology Security Council. Mr. Bernard is also a member of the Subject Matter Expert Faculty of the Security Executive Council (

About the Author

Ray Bernard, PSP, CHS-III

Ray Bernard, PSP CHS-III, is the principal consultant for Ray Bernard Consulting Services (, a firm that provides security consulting services for public and private facilities. He has been a frequent contributor to Security Business, SecurityInfoWatch and STE magazine for decades. He is the author of the Elsevier book Security Technology Convergence Insights, available on Amazon. Mr. Bernard is an active member of the ASIS member councils for Physical Security and IT Security, and is a member of the Subject Matter Expert Faculty of the Security Executive Council (

Follow him on LinkedIn:

Follow him on Twitter: @RayBernardRBCS.