Policy is such a strange word. It can mean so many things in different contexts. Doing a Google search for “What is a security policy?”, I got some interesting results… including “A set of rules that says who can do what to whom”… really? The vast majority of search results I obtained relate to IT Security Policies. That’s not a bad thing, necessarily. But suppose you’re a Chief Security Officer. There’s more to your world than IT Security. Doesn’t a Security Policy deal with other things in “meatspace” (see my “Vernacular” section)?Given that there are so many different views, I thought I would spend a moment to discuss Security Policies.

What is a Security Policy? In my view, a Security Policy is “A clear, over-arching statement of an organization’s objectives with respect to protecting its facilities, assets, personnel, systems, resources, information etc.” It doesn’t (and shouldn’t) go into great detail about what specific safeguards are used. The policy should not have to change as technology changes, unless there are new risks to deal with.

A security policy may defined at more than one level, with subordinate policies such as IT Security, Physical Security, Personnel Security, etc. that go into somewhat more detail. The subordinate policies still should not require frequent changes. Usually, the top level roles are defined for individuals responsible for the policies, so that people in the organization know who to bring issues to for clarification or changes to policy.

A Security Policy will also address universally applicable rules in the form of:

  1. What must be done (at a high level)
  2. What must not be done (at a high level)
  3. How deviations must be handled
  4. What sanctions are applicable when policy is not followed

Once a good policy framework is in place, there should be Security Procedures that support each policy directive. They should be traceable from one document to another so that audits can easily verify that policies are being enforced.

Security Procedures detail the implementation and maintenance of safeguards that support the policies. They also specify which personnel roles are responsible for which activities, what activities need to be logged, and how often inspections and reviews are done either internally, or by third parties.

This is by no means a comprehensive lesson on Security Policy, but it may help you to recognize the difference between a policy, a procedure and a safeguard.

One more thing. A good Security Policy is usually readable and comprehensible to everyone in the organization. It can and should, therefore, be made available to the entire organization. This helps with Security Awareness and lets people understand why the safeguards are in place.
For a good discussion of IT Security Policies, visit the SANS security education site. If you have comments or know of other good policy resources, please post a comment.