An information security policy is the document where leadership states how the organisation protects information and who is accountable. Every major framework requires one. The trap is that it is easy to download and hard to live up to - and auditors test you against your own document, so an aspirational policy actively creates findings.
The sections your policy needs
- Purpose - why the policy exists and what it protects.
- Scope - which people, systems, locations and information it covers, including contractors.
- Policy statements - the actual rules, written as clear obligations.
- Roles and responsibilities - who owns security, who owns risk, what every employee must do.
- Objectives - measurable security goals, which ISO 27001 requires explicitly.
- Compliance obligations - the laws, regulations and standards you must meet.
- Exceptions - how a deviation is requested, approved and time-limited.
- Enforcement - the consequences of non-compliance.
- Review cycle - how often it is reviewed and who approves it.
- Version control - version, approval date, approver, next review date.
The supporting policy set
The top-level policy is an umbrella. Auditors expect these underneath it:
- Access control policy
- Acceptable use policy
- Data classification and handling policy
- Cryptography and key management policy
- Change management policy
- Secure development policy
- Incident response policy
- Business continuity and disaster recovery policy
- Supplier and third-party security policy
- Human resources security policy - screening, onboarding, offboarding
- Physical and environmental security policy
- Backup, logging and monitoring policies
- Remote working and mobile device policy
Generate a policy set that matches how you actually operate
GRC Copilot drafts your policy set from your organisation profile and frameworks, tracks approvals and version history, and runs acknowledgement campaigns so you can evidence that staff read them.
Try GRC Copilot free Generate an AI-powered assessment Download the template Book a demo
The template trap
A downloaded policy usually contains commitments you have not implemented. Each one becomes a nonconformity the moment an auditor asks for evidence:
- "Access is reviewed quarterly" - but you review annually.
- "All staff complete annual security training" - but you have no completion records.
- "Penetration testing is performed annually" - but the last test was three years ago.
- "Logs are retained for twelve months" - but retention is set to thirty days.
Write what you do today, then raise commitments deliberately as you implement them. A modest policy you meet beats an impressive one you do not.
Approval, communication and acknowledgement
A policy is not in force because it exists in a folder. Auditors look for the full lifecycle:
- Approved by top management, with a date and an approver.
- Communicated to everyone in scope.
- Acknowledged - staff confirmed they read it, with records.
- Reviewed at the stated interval and after significant change.
- Version controlled, with superseded versions retained.
Ask of every sentence in your policy: what record proves we do this? If there is no answer, either build the control or soften the sentence.
Frequently asked questions
How long should an information security policy be?
The top-level policy is typically five to fifteen pages. Detail belongs in the supporting policies and procedures, keeping the umbrella document readable by everyone.
How often must policies be reviewed?
Annually is the widely accepted norm, plus after any significant change - a new system, a restructure, a major incident or a regulatory update.
Do we need a separate policy for every topic?
Not necessarily. Smaller organisations often combine related topics into fewer documents. What matters is that every required subject is covered, owned and approved.
Can we use AI to draft policies?
Yes, for a first draft grounded in how you actually operate. A human owner must then review, correct and approve it - and the same rule applies: only commit to what you can evidence.
Key takeaways
- Cover purpose, scope, statements, roles, objectives, exceptions and review.
- The umbrella policy needs a supporting set beneath it.
- Never commit in writing to a cadence you do not meet.
- Approval, communication, acknowledgement and version control are all evidence.