There is no custom code to display.

How to Validate Your Security Program: Part Five

Print Friendly, PDF & Email

By Ray Bernard PSP, CHS-III

Note: This is the fifth 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 validate your security program.

Validation Attribute: Proven


  1. has been found by trial or experience to be true, workable, acceptable, etc.
  2. demonstrated to be effective in practice

There are many definitions for the word “proven”. For our purposes in validating security program elements, we’re using it in the sense of “proven practice”, which means proven to work in actual application.

The effectiveness or feasibility of a security program element or specific security measure can be proven within your own program using metrics, or other means such as observation. This perspective is presented in the “justifiable” attribute (Part Four), which deals with providing evidence about the effectiveness of security measures to show that a particular measure is worth the cost, effort and/or inconvenience involved.

However, you can also prove the effectiveness or feasibility of any part of your security program by its use in the security programs of other organizations. The “proven” attribute of your security program deals with the ability to assert the validity of security measures or program elements, by identifying which ones are practices that have been proven in use elsewhere.

We are now dangerously close to entering buzzword-land, as the terms best practice, common practice, good practice, proven practice and so on are often used interchangeably—but they definitely do not mean the same thing and, also importantly, are not regarded identically by management.

The Security Executive Council begin using the phrase “proven practice” when its research showed that the term “best practice” had fallen into disfavor in many organizations. A best practice is one that has consistently shown results that are superior to those achieved by other means. However, sometimes the cost of superior results is unacceptable, especially if the specific level of quality is not necessary or is not worth the cost or effort. In some organizations, if you use the word “best practice” you run the risk of being accused of “gold-plating” your security measures. In other organizations, you may be given an award for implementing a best practice. It really depends upon the company culture.

Good Practice vs. Best Practice

The job of security is to reduce security risks to acceptable levels, at an acceptable cost. In that context, being “effective” is far more important than being “superior” by virtue of a best practice. This is why the term “good practice” is in widespread use in fields where health or safety is concerned. Unlike “best practice”, “good practice” isn’t considered an overused buzzword, and is more acceptable in many company cultures.

A good practice is not only a practice that is good, but a practice that has been proven to work well and produce good results. It is a successful experience that has been tested and validated, in the broad sense, and which has been repeated and deserves to be shared so that a greater number of people can adopt it.

Characterizing Your Good Practices

It can be very helpful to create a good practice profile of your security program. To do this you:

  • label the security measures in each program element (as explained below)
  • label the program element by using the most common label among its various security measures

Here are labels to use that characterize your security measures in a meaningful way.

Regulatory Requirement. The fact that it’s a regulatory requirement is all the proof you need to include it in your security program. The only question might be, “To what extent do you need to implement the requirement?” That’s where security design and planning come into play, as well as assessment.

Standards-Based. Standards are usually based upon best practice and/or good practice. Sometimes a standard gathers and unifies a collection of good practices under an overarching framework, to make it easier to implement and manage them. The question relating implementing a standard revolves around what parts of the standard are relevant to organization’s specific security risks. Assessment usually has a role here.

Common Good Practice. Most common good security practices are easily recognizable because you see them practically everywhere. It’s likely that the majority of your security program elements are common practices. Examples include central station security alarm monitoring, security officer patrols, card access control and video surveillance—which are utilized in most facilities. However, there are other good practices that are less common—such as routine security system testing, periodic re-assessment of security officer patrol routes (for completeness and value).

Sector-Specific Good Practice. Many business sectors have security practices that are specific to their type of business. For example, hospital security can include wheelchair tracking using any of several technologies; this is really asset management combined with asset protection. It is a good example of aligning a security measure with the operational needs of the organization. (In a hospital, if wheelchairs are not available, patients may not make their labs appointment and so lab time can be wasted, and patient treatment may need to be postponed as a result of a missed test.)

Company-Specific Good Practice. In large companies, it is common to find that good security practices become fine-tuned based upon company needs and company culture. In such a case the security practices can be designated for implementation on a company-wide basis and become a company standard. There can, of course, be variations based upon geographic and cultural factors.

Proven Program Element. A proven security program element is one that has shown itself to be very effective as you have implemented it, regardless of whether or not it is in practice outside your organization.

Validation Steps

Step 1. List Your Security Program Elements and Their Key Measures. Several earlier steps involved making or using a list of your security program elements. In this exercise you expand the list to include the key security measures of each program element.

Step 2. Make a Good Practice Profile Chart. Create an empty chart (or download a template) to profile your security program good practices. In Word (using a Landscape-oriented page) or Excel, you can create a table containing the following columns as described below.

The first two columns are for the names of your security program elements and their security measures. The second two columns (Age, Reviewed ) are optional, as explained in the paragraphs that follow this columns listing.

  • Program Element
  • Security Measure
  • Age
  • Reviewed

The next columns are for a check mark, an X, or a Yes/No dropdown list selection. (The last two “Company” columns are optional.)

  • Regulation
  • Standard
  • Common Practice
  • Sector-Specific Practice
  • Company-Specific Practice
  • Proven Program Element
  • Company Strategic Objective
  • Company Innovation

The final column is for any notes you may want to make for yourself:

  • Note

Add rows to the chart as needed to hold the security program elements and their security measures that you will be rating.

Step 3. Fill Out the Profile Chart. This may require multiple sittings, with a little bit of research in between to finalize the chart. The majority of the work can be delegated if you have an available staff person; that is usually a good staff educational step.

Using the Good Practice Profile Chart

The Age and Last Reviewed columns can help you prioritize a plan for reviewing your security measures. There are a number of valuable perspectives that you can use to review security measures, and those are covered in a later article in this series.

The Company Innovation column is useful if your company values innovation, and you have implemented security measures that are innovative for your company. For example, providing the ability for Real Estate or Facilities personnel to securely access security video on their mobile devices could be considered a helpful innovation within your company, as it can provide a number of operational benefits to personnel with certain roles and responsibilities.

Utilize the Company Strategic Objective column to identify any your security program elements directly support one or more company strategic objectives, utilize that column as well. That may require a close review of your organization’s strategic planning, something that you probably should be doing anyway if you are not already.

For the Notes column, you can eliminate space constraints by entering “See Note 1”, “See Note 2”, and so on and then writing the notes on pages that follow the chart pages.

During this work you may come across information on good practices that you don’t have in your security program yet, but which you think would be beneficial. Be sure to make a note for the related Security Program element to capture the key information about the potential new good practice.

As always happens when you look at your security program from a new perspective, great ideas can come to light. You should gain some new security talking points and possibly something worth reporting on or maybe even some good points to brief management about.