Alright, so this was originally intended as a comment to your response to the answer given by @jl01 but it became too long and it should have merit on it's own....
There's almost an art to creating policies. Ideally (though i'm sure some people would disagree with me) a policy would be a very general statement regarding the topic. For example, something not much more complex than "This company will operate with current best practices for system patching". The idea is that a policy should be established and not need changed (if done perfectly). It should be generalized enough that it will not need to be updated as different technologies, attack vectors, regulations, etc change.
It is very common to split policies up into each separate realm of business/technology. This lends itself to producing policies that are more custom fitted to your company and allows you to keep clarity when referring to those policies.
Another way to think of it is that a policy is the business' way of covering their hind ends. It is created to cover as much as possible so if something goes wrong the company can mold their response to each separate situation while still using the same policy.
Those policies would be expanded on via procedures, guidelines, and regulations (come to think of it, this should be fairly close to how SANs describes it). I believe SANs refers to what I call "procedures" as "standards". I apologize for any confusion because of that.
A procedure would be an actual practice which follows a policy (many policies that i have seen seem to refer to the applicable procedures within the policy itself).
A guideline on the other-hand is exactly that, a suggestion of acceptable practices. Though they are only suggestions, they are not to be taken lightly. When audits occur, these are the low hanging fruit that an auditor can latch onto.
Procedures and guidelines are the only things that you should need to update with changing business climate, environmental issues, threats, etc.
When i designed my first set of policies, granted this was from a class regarding information security policies, I set up these different policies:
- Information Sensitivity Policy
- Extranet Policy
- Email Policy
- Removable Media Policy
- Password Policy
- Security Monitoring Policy
- Router Security Policy
- Server Security Policy
- System Update Policy
- ASP Policy
- Server Management Policy
- Security Training Policy
This is not an exhaustive list, but it should give you an idea of some of the break downs that may take place. The way policies are divided are dependent on the needs of that company.
Last, but definitely not least, each policy should be created in such a way that there is do doubt as to what and how it's applied. By this, i mean that along with each policy the purpose, the scope, the enforcement, and the definitions regarding that policy should be established. I always have fun typing the phrase "will be subject to repercussions up to and including termination".
Though I did not list it earlier, an ethics policy should be in every policy set. Even when using ASPs, or any service for that matter, it's good practice to request their ethics policy and, depending on what you see, require by contract that they abide by your companies ethics policy for that job.
So, i may have dove a bit too far into the subject... but i hope it helped.
Disclaimer: I am more than aware that this isn't the only way policies can be constructed. From my experience, most companies have a set of policies that have been loosely constructed over years of regulation changes and compliance issues.
p.s. an ASP is an application service provider, i see that i haven't mentioned it's definition anywhere above.
