TechMiso

When creating a quality defense in depth strategy , you must not forget to build a quality “policy program”.  A “policy program” is not just a binder, wiki, or web page with all of your current policies categorized neatly by date and purpose. A “policy program” will include the drafting of the policies, the communicating of the policies to all of your user community, enforcement of the policies, and validation that the policy is meeting its defined goal.  We often see policy programs that only encompass one or two of these steps and administrators wondering why their policies are ineffective.   In order to create a successful program you need to utilize all of the steps in the policy program framework.

The first step is drafting a policy.  The policy should clearly define the issue, why we need to take action on this issue, who this policy effects, and what are the repercussions for not following the instructions in the policy. The policy also needs to have the appropriate authority behind it. The policy should be bottom-lined by the CEO, CIO, Commanding Officer, or whoever has the direct responsibility for your network.  No one is going to care about a policy that was drafted by an intern and bottom-lined by the mail-room guy.  Violations of certain policies can have employee termination as an immediate consequence, so make sure the proper and legal authority have signed off the policy.

The next step is communicating the policy out to all of those affected.  Information Bulletins, Employee Handbooks, User FAQ’s, Annual User Trainings,  and office memo’s are some of the avenues to get this information out to your users.  The first line of defense is usually “well I didn’t know we are not allowed to do that”.  In some cases they are right because the policy never did reach the end user. The best bet is to use multiple communication methods and have evidence that the user understands and fully acknowledges the policies and their associated repercussions. Lack of information flow to the end user will only make enforcement of policy more difficult in the long run.

The third step is enforcing your policy.   This should be the easiest step in the policy program. The technical solution should already have passed the testing phase during the drafting process. There is no need to spend time developing a policy that you have no means to enforce.  You would be surprised how many places actually fall into that trap.  You should also clearly define the start time for enforcement of your policy, so make sure to stick to that plan.  If you need to push the enforcement time back, make sure to communicative this to all of your end users.

The final step is the validation process. Is the policy effective in meeting it’s stated goals?  Do you need to adjust the repercussions for policy violations?  Did the policy get communicated out to all of the users?  Is my policy up to date? You should be revisiting your policies every 6-12 months and asking yourself these very questions.  Make the necessary changes and communicate the new policy out to all of your users.  If you policy does not need an update,  make sure to annotate the policy has been reviewed.

If you follow all of these steps you should have no problem in developing a quality “policy program”.