Today I read in a forum someone asking about the best way to write an organization's security policy; should it be a long and complete document or a simpler one with just a couple of pages?I was answering the question when I realized I could post here some of the approaches I have been taking to this problem.I believe that a security policy should describe how security works for the organization. So, it must contain information about the basic security processes, like risk management and exemption approval. My rule of thumb is to identify all the security processes of the organization and describe then in separate documents (Policies). Over them there would be a one page documents with the main directives, i.e., the main security rules to the organization. This document (Directives / General Policy) would be something very similar to those Mission/Vision/Values statements that lots of companies like to hang on their walls.Besides Policies and Directives, I also like to work with two more focused sets of documents, one for the technical public and other for the general public. The technical documents (Guidelines, Standards, Architecture) would fill the need for technical requirements that need to be addressed by IT teams, like IT support and developers. The "general public" document is usually called "Information Security Manual", and it will contain all the rules that every person working for the organizations (employees, consultants..."associates"?) must know. It needs to be written in a more friendly language, usually produced as a nice booklet. This should include a page with some sort of commitment that the person will sign after reading, generating the evidence that everybody is aware of their responsibilities regarding information security.