There is no custom code to display.

How to Validate Your Security Program: Part Seven

Print Friendly, PDF & Email

By Ray Bernard PSP, CHS-III

Note: This is the seventh 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: Official


  1. of or relating to an office or position of duty, trust, or authority
  2. appointed or authorized to act in a designated capacity

In most organizations, policies are the high-level documents that express management’s views and intentions regarding how important aspects of the business should be run. Typically, there is a high-level organization-wide policy that describes the scope and purpose of security, and is intended to set direction. It often specifies the key people, process and technology security program elements. It may also direct compliance with applicable governmental laws and security standards.

There is much advice recommending that management’s risk appetite be expressed in the policy. However, given the pace of business today and the amount of change that most organizations undergo, it may not be possible to describe management’s risk appetite relative to a changing risk picture. This is why some organizations include in their security policy a description of the approach that security will take to keep security aligned with the business and with management’s intentions. Often this takes the form of a management system such as those described in ISO 31000, ISO 27001, or ANSI/ASIS ORM.1-2017.

From the perspective of our “Official” validation attribute, it is important to ensure that any existing security policy matches that actual scope of the organization’s security programs. If a problem arises relating to a security program element that falls outside the official scope of the overall security policy, there can be significant negative repercussions for a security leader who is “doing the right thing” but isn’t actually authorized to do it. Such a situation can occur if you have inherited a security program that, unknown to you, contains an “out of scope” element.

Validation Steps

These validation steps are simple and can usually be performed in a few hours or less.

Step 1. Obtain a copy of the high-level security policy or policies that apply to your assigned scope of security management.

Step 2. Obtain or create a chart or list of your security program elements.

Step 3. Check the scope specified in the high-level security policy against your security program elements.

Step 4. If changes are needed to the high-level policy, propose the appropriate revisions and get them approved.

There are a number of possible outcomes from this validation exercise.

If you inherited your security program from your predecessor, you may not have read the high-level security policy since your first look at it when you assumed your current position. Now that you have an organizational context from which to view it, you may have some different thoughts about that policy.

If you have significantly revised your security program since assuming your position, you will be checking your improvements against the scope of the high-level policy.  If it is a well-written high-level policy, chances are that your security program improvements are right in line with the policy.

If you are newly appointed to your position, this exercise will provide a way to get a good perspective from which to view what you learn from this point on.

Regardless of your exact situation, it’s always good to be running an officially sanctioned security program.