Policy development
Information Security people often come from a highly technical background. As they move up through the ranks, and achieve management level, one of the hardest things turns out to be how to write a good policy. When I was confronted with this problem, I decided to take a step back and worry about developing a framework and a policy life cycle, before any real policies would be written.
One of the most fundamental steps in an information security program is to have a sound policy. It sounds boring, but it is absolutely required, as having a policy that is shared, supported and approved by the highest level of management gives direction, and mandate. It gives the information security officer the ammunition he needs: "because the president says so" is always more convincing than "because I say so"
I have developed a policy framework (see below) that is based on an executive statement. The executive statement provides the basis for everything that is to come. In it, somebody at the level of CEO or president publicly acknowledges that information must be considered as a critical business asset and that handling information requires special rules.
Without something like an executive statement, you will always lack the appropriate level of management support. Without that, you might as well quit and find another place to work.
Having identified that information needs protection, and that protection in grounded in policy, a policy life cycle needs to be identified. The policy life cycle should describe what steps need to be taken when the need for a new policy is identified, who must be involved in identifying the extent, scope, and content of the policy, and how it gets approved and finally implemented.
My view on policy development is to only write a policy when there is a real need to do so. When a policy is written, keep it as short as possible. Make sure that any requirements identified in the policy can be monitored and enforce compliance. Always make sure that implementing a policy does not prevent necessary work from getting done, or incur unreasonably high costs. For this reason, all policies should identify if deviation of the policy is permissible and if so, which role may authorized these deviations.
One the executive statement and the policy life cycle are in place, actual policy development may begin. I distinguished a few separate "policy domains". First, since the executive statement designates information as something "business critical", an information classification and protection policy must be created that identifies categories of information, and describes in global terms how each of these categories needs to be treated.
Next, more specific policies in the areas of Protection, Privacy, Incident management, and Audit may be created, as the need arises. All of these policies together will for the "Information Security Policy". More details on policies, and how they are written, will be the topic of another post.
Finally, near the top of the framework, an Acceptable use statement can be found. The acceptable use statement is not a "normative" policy by itself, but contains abstract of and references to all the other policies. It is a document that should be short enough to give to anyone bound by the policies, but complete enough that the general tone of policy development is clear.
This policy framework is now in an early stage of development, and it has not been put to the test yet. Any feedback and/or comments are greatly appreciated!
One of the most fundamental steps in an information security program is to have a sound policy. It sounds boring, but it is absolutely required, as having a policy that is shared, supported and approved by the highest level of management gives direction, and mandate. It gives the information security officer the ammunition he needs: "because the president says so" is always more convincing than "because I say so"
I have developed a policy framework (see below) that is based on an executive statement. The executive statement provides the basis for everything that is to come. In it, somebody at the level of CEO or president publicly acknowledges that information must be considered as a critical business asset and that handling information requires special rules.
Without something like an executive statement, you will always lack the appropriate level of management support. Without that, you might as well quit and find another place to work.
Having identified that information needs protection, and that protection in grounded in policy, a policy life cycle needs to be identified. The policy life cycle should describe what steps need to be taken when the need for a new policy is identified, who must be involved in identifying the extent, scope, and content of the policy, and how it gets approved and finally implemented.
My view on policy development is to only write a policy when there is a real need to do so. When a policy is written, keep it as short as possible. Make sure that any requirements identified in the policy can be monitored and enforce compliance. Always make sure that implementing a policy does not prevent necessary work from getting done, or incur unreasonably high costs. For this reason, all policies should identify if deviation of the policy is permissible and if so, which role may authorized these deviations.
One the executive statement and the policy life cycle are in place, actual policy development may begin. I distinguished a few separate "policy domains". First, since the executive statement designates information as something "business critical", an information classification and protection policy must be created that identifies categories of information, and describes in global terms how each of these categories needs to be treated.
Next, more specific policies in the areas of Protection, Privacy, Incident management, and Audit may be created, as the need arises. All of these policies together will for the "Information Security Policy". More details on policies, and how they are written, will be the topic of another post.
Finally, near the top of the framework, an Acceptable use statement can be found. The acceptable use statement is not a "normative" policy by itself, but contains abstract of and references to all the other policies. It is a document that should be short enough to give to anyone bound by the policies, but complete enough that the general tone of policy development is clear.
This policy framework is now in an early stage of development, and it has not been put to the test yet. Any feedback and/or comments are greatly appreciated!