It should outline the security acceptance/appetite of the organisation in order that the standards which support the policy can be defined in the correct environment.
It also needs to define responsibilities, ownership and sponsorship.
Updated just to provide some examples, as I did leave this pretty light. At high level you should have at the minimum policies to allow you to measure, understand and regulate your technology risk. These will also be required from a governance perspective in a lot of environments -
- Information Security Policy
- Information Classification Policy
- Acceptable Use Policy
- Data Retention Policy
- Data Protection Policy
- Risk Assessment Policy
You will probably also want to look at the following if you provide services or products to larger organisations, as they may run a governance scheme which includes their 3rd parties -
- Corporate and Social Responsibility Policy
- Environmental Policy
- Equal Opportunity Policy
In the UK you must define your data protection requirements with respect to the Data Protection Act 1998. You should also construct your policy framework taking the ISO27001 family of standards into account, as many security audits and assessments for the regulator and for the IT piece of statutory audit are structured around 27001.
A corporate security policy should be short, easy to read, and in general terms. It should basically list what the overall threats and risks are to the business and the general approach for mitigating them.
For example, if you have a company who's value is in the data it stores in a database, a corporate security policy may state that the database should be protected with multiple level security controls including network access controls and encryption controls, and perhaps that sensitive data should be stored in systems which exist under strict change control.
The implementation of those details is going to depend more specifically on the system itself and the chosen standardised technologies by the business and so should be detailed in lower-level documentation.
I agree with the above comments - the "right" policy largely depends on your organization.
However, it may be helpful to review the ISO/IEC 27000 series, which is a set of standards for information security management often adopted by large IT organizations (http://en.wikipedia.org/wiki/ISO/IEC_27001, http://iso-17799.safemode.org/).
For example, 27002 is a "code of practice" which covers things like:
- Risk Assessment And Treatment
- Security Policy
- Security Organization
- Asset Classification and Control
- Personnel Security
- Physical and Environmental Security
- Communications and Operations Management
- Access Control
- System Development and Maintenance
- Information Security Incident Management
- Business Continuity Management
Even if you don't fully adopt it, I'd start with that standard to develop a draft table of contents for your policy.
That depends: what are the biggest risks to your business? Security policy shouldn't be about mandating anti-virus because all the cool kids have anti-virus, it should be about understanding what threats it's most important that you mitigate, and defining a strategy (though not tactics) to perform such mitigation.