So the first inevitable question we need to ask is, “what exactly is a security policy”? Well, a policy would be some form of documentation that is created to enforce specific rules or regulations and keep a structure on procedures. Here, in the context of ‘security’, is simply a policy based around procedures revolving around security. Think of any other kind of policy… a disaster recovery policy is a set of procedures, rules and plans revolving around having a disaster and how to recover from it. Security polices are much the same. Ok, now that you have the general idea now, lets talk about what the security policy will generally provide. Remember… a security policy is the foundation and structure in which you can ensure your comprehensive security program can be developed under. If I can make an analogy, a security policy is like the spine, and the firewalls, IDS systems and other infrastructure is the meat and flesh covering it up. There are a great many things you will need to understand before you can define your own.

Security policies are generally overlooked, not implemented or thought of when it’s already too late. To keep you in the loop on what this means, we can flip flop back to the example I first stated with the Porn Surfer… It doesn’t help ‘after’ the fact when your dealing with a court case, if you had a policy in place to keep people informed about what it is they can or cannot do (like surf the web during business hours hitting sites that are not business related) they may not do it in the first place, and If they do, you have a tool (the policy) to hold them accountable.

So, now that we understand the fundamentals of what a security policy is, lets sum it up in one sentence before we move forward… A security policy is a living document that allows an organization and its management team to draw very clear and understandable objectives, goals, rules and formal procedures that help to define the overall security posture and architecture for said organization. This article will cover the most important facts about how to plan for and define a security policy of your own, and most of all, to get you to think about it – whether you already have one or not.

A security policy must also be created with a lot of thought and process. You can make a security policy too restrictive. If you do, you could cause a lot of strain on your employees, who may be accustomed to one way of doing business, and it may take awhile to grow them into a more restrictive security posture based on your policy. A security policy should contain some important functions and they are as follows.

• The security policy must be Understandable! People who read it should be able to easily comply with it. You need to ensure that it’s not full of complete techno-babble that can be argued by an end user.
• The security policy must be Realistic! Ok, you need to draw a line in the sand with your policy. If you are too restrictive, than you need to address why complaints could arise, or worse yet, management not backing your policy because it isn’t realistic. Remember, too much security actually impedes business so you have to find a perfect balance. Also, as new hires are brought into the company and perhaps made to sign a policy such as this, they need to feel comfortable with it at some level, so make sure it realistically meets your business, technological and security needs simultaneously.
• The security policy must be Consistent! You need to be consistent. Telling people they can only surf business related websites and then overturn that decision to allow full access, to only three weeks later, again reverse your decision. This causes discontent amongst your user community.
• The security policy must be enforceable! You can do this with auditing tools, logging and by other means. It must also be ‘clearly’ backed by management and human resources. If you decide that someone is in violation of policy, and management doest back the proposed punishment for breaking policy, then the policy is useless. I have seen this so many time in practice that this should be the number one item you look at when trying to get a policy together… if management doesn’t back it from the onset, then I could assure you, the effort of doing the policy and the enemies you could possibly creating enforcing it solely by yourself is a waste. Make sure you have backing from management!
• The security policy must be documented, distributed, and communicated properly! To not do so is harmful to the organization because if you try to enforce a security policy nobody has read, then you are basically alone in your battle to enforce it. I suggest having new hires sign a copy as they join the organization and have the current employees do an intranet web form enforced via their managers or supervisors.
• A successful security policy needs to be flexible! In order for a security policy to be a solution you have implemented for a long time to come, the policy needs to be flexible on what it covers, who maintains it and most important of all, who changes is. Your policy WILL experience change, just as your business changes (today’s business change faster than a heartbeat), you need to stay on top of the policy, that’s why it needs to be flexible and changeable.
• A successful security policy must be reviewed! To ensure that your policies do not become obsolete, you should implement a regular review process of them. Its very possible that months after you create and implement a security policy that it doesn’t even fit into your organization anymore, depending on how often your company changes it other business relationships, or if it is in merger and acquisition mode. If so, you may find yourself in constant review of your policy. Make sure you are aware of what would instigate a review, and make sure you do a proper review after a certain amount of stagnation occurs, like if you had 6 months of no change in the organization.

Objective
THE DEPARTMENT's objective of managing information security is to ensure that its core and supporting activities for the State of Victoria continue to operate with minimal disruptions. THE DEPARTMENT shall ensure that all information that is disbursed or produced by THE DEPARTMENT has the requisite integrity. THE DEPARTMENT shall also ensure that all relevant information is managed and stored with appropriate confidentiality and availability procedures and controls. THE DEPARTMENT shall ensure appropriate access to information to allow effectiveness and efficiency within the department.

ISMS Policy Context

The document deals with the Information Security Policy. This Policy is part of the Information Security Management Framework, that each department must develop in its response to the requirements of SEC/STD/01 - Information Security Management Framework.

Guiding Principles
The ISMS will make full use of existing THE DEPARTMENT corporate policies, procedures, intellectual property, resources, services and assets.
The principal focus on Information Security is to provide the following:
Confidentiality: the restriction of access to information by authorised persons, entities and processes at authorised times and in an authorised manner;
Integrity: safeguarding the accuracy and completeness of information and information processing systems; and
Availability: ensuring that authorised users have access to information and associated assets when required.

By successfully implementing the above principles, THE DEPARTMENT aims to secure the environment in which information is acquired, held and used.
The ISMS will focus on a number of key control functions for the prevention and detection of threats to the security of THE DEPARTMENT's information assets, (refer Appendix 1 for examples of threats).
Legislative Requirements

The following State and Federal legislation has been considered in the development of THE DEPARTMENT ISMS:
Commonwealth and Federal Legislation
- Copyright Act 1968
- Trade Marks Act 1995
- SPAM Act 2003
- Trade Practices Act 1974
- Privacy Act

Victorian State Legislation
- Fair Trading Act 1989
- Surveillance Devices Act 1999
- Victorian Privacy legislation

Exemptions
An exemption to the ISMS Policy may be granted if it is clear that the costs and resources necessary for compliance far outweigh the risks of non-compliance.
If an exemption to the ISMS Policy is required, a written request, including a description of and justification for the exception, is to be sent in the first instance to ISMS Owner
A regular exemption review process will also ensure that ISMS compliance is consistently observed across the department.


Article source: http://www.windowsecurity.com/articles/Defining_a_Security_Policy.html
Article source: http://www.grcservice.com/information-security-management-system-isms-policy-template
.