Creating an effective security policy requires planning.
By following these 8 DON'Ts you should be able to create an
effective policy.
Top |
 |
How
often is the policy updated and how often should it be updated? |
 |
When did it
go into effect and when was the policy last update? |
 |
What areas
are included in the security policy?
|
 |
What areas
are not covered by the policy?
|
 |
How does the
policy relate to the current business objectives and / or mission?
|
 |
What are the
consequences for non-compliance of the security policy?
|
 |
What
exceptions to the policy are allowed and who approves them?
|
 |
What are the
limitations of the policy and to whom do they apply?
|
 |
How are the
policy and updates to the policy communicated to the organization?
|
 |
What are your
security education requirements?
|
 |
What is your
senior management’s involvement with the support of the security
policy?
|
 |
What is the
overall objectives and scope of your security policy?
|
 |
What
legislative and contractual compliance requirements do you have to
include in your security policy?
|
|
|
| Top |
|
Don't implement a security policy that is
not backed up by management.
A security policy that has not been approved
by management, is not enforceable. The penalties and the
policies that you are trying to implement will be bypassed or
overridden.
Top
Don't include penalties that you cannot or
will not backup.
Your policy should only include penalties that
your organization is willing to back up. If your policy
says that someone will receive a written warning the second time
that the policy is broken then it has to be done.
Otherwise, the policy will become unenforceable as more of the
penalties are ignored.
Top
Don't make it too long so that no one will
read it.
If your policy is too long or needs an interpreter
to understand then it will be ignored. The policy should
be only a few pages long. It is a document that should be
used to create the guidelines and standards.
Top
Don't cover more than one area in your
policy.
Your policy should only cover one area.
Different areas need different policies such as passwords or
blogs. Keeping it to one area, make the policy easier to
update and less confusing.
Top
Don't make your policy too vague or too
broad.
Your policy should be direct and to the
point. If it is too vague then it can not be enforced.
If it is too broad, it makes it too confusing for the
reader. The reader needs to know what the policy is about,
what it covers and what happens if the policy is not followed.
Top
Don't forget to include exceptions.
As with everything, there are
exceptions. If you don't list them in the policy at least
include a statement that exceptions will be handled by
management or case by case.
Top
Don't name specific products to use.
Remember that this is a policy.
Guidelines and standards can list specific products. For
example, your security policy may have a statement "All PCs
should have a firewall." which would may translate to the
guidelines that "All PCs will have a 'Checkpoint'
firewall" or "Department A will have 'Checkpoint'
firewall and the other departments will use a Microsoft
firewall". Therefore, a separate policy does not have
to created for each area. The departments can use the
policy as a guide to what needs to be done. However, they
have flexibility in how to implement the policy.
Top
Don't start writing your security policy
until you have answered the following questions.
By answering the questions above
before you start your policy, you can create one that will be
understandable and hopefully followed.
|
| Top |
|