TL;DR
An information security policy states how your organisation protects what it holds, who owns that, and how exceptions are decided. Most companies write the first one because a customer asked. Three to five pages, honest about gaps, with a named owner, beats forty pages of borrowed language every time.
- The trigger is usually commercial, not regulatory. A deal is waiting.
- Three to five pages, with specific topics in separate referenced policies.
- Name a person as owner, not a department.
- Describe the current state. Flag gaps with an owner and a date.
- Add the equipment section, which most first drafts skip entirely.
- Record the review date, because an undated policy reads as abandoned.
When you do not need one yet
Four stages, and the first two do not need a document.
Pre-customer. No external party holds you to anything. Spend the time on actual controls instead, because a policy describing nothing is an empty gesture.
Best tools for HR Operations
Early customers, no questionnaires. You have revenue and nobody has asked. Write a one-page statement of how you handle data so the knowledge is not only in one head.
The first questionnaire arrives. This is the genuine trigger for most companies. A deal depends on answering, and the honest version takes a week rather than a quarter.
Certification or enterprise customers. Now the document needs structure, evidence behind each claim and a review cycle. The framework most reach for is ISO/IEC 27001, which sets out what a management system is expected to cover.
What an information security policy should contain
Six sections. Each should be short enough that somebody reads it.
- Purpose and scope. What information you hold, whose it is, and which systems and people are covered. Say explicitly whether contractors are in scope.
- Ownership. A named individual accountable for security decisions, plus who deputises. This is the first thing a reviewer looks for.
- Access control. How accounts are created, reviewed and removed. Removal is the part reviewers probe, because it is the part that decays quietly.
- Data handling. Classification if you have it, where data may live, and what must never leave approved systems.
- Equipment. Issue, tracking, encryption, return and disposal. Covered below.
- Incidents. How something gets reported, who decides severity, and who communicates. A short, real process beats an elaborate one nobody has rehearsed.
Technical detail belongs underneath rather than inside. For media sanitisation, point at your own procedure and align it with NIST Special Publication 800-88, which distinguishes clearing from purging from destruction. Referencing a recognised standard is more credible than describing a method you invented.
The equipment section nearly everyone omits
First drafts are consistently strong on access and encryption, and consistently silent on the physical device. That gap is visible to anybody who reviews these for a living, because the questions are obvious.
Four paragraphs cover it.
Issue and record. How a device is assigned and where that is recorded. If the honest answer is a spreadsheet, say spreadsheet. Reviewers are not impressed by systems, they are reassured by records that exist.
Protection in use. Encryption, screen lock, update expectations. Short, and only claim what is actually enforced rather than requested.
Return. What happens when somebody leaves, who initiates it, and the expected timeframe. This is the question most often asked and least often answered in a first draft.
Disposal. What happens to a device at end of life and what evidence you keep. If you do not currently know where retired laptops went, that is a gap to name rather than paper over.
Five questions a reviewer will ask
Who owns this? A name. “The security team” invites a follow-up when the team is two people.
How do you remove access when somebody leaves? The specific sequence and who triggers it.
What happens to their laptop? The honest end-to-end answer, including how long it usually takes.
When was this last reviewed? A date in the document, not a file timestamp.
What are you still working on? A policy with no gaps is either mature or untrue, and reviewers know which is likelier at your size.
Where teams get the document, and the trade-offs
A template. Best for structure and for not missing a section. It struggles on specificity, and experienced reviewers recognise common templates immediately, which costs you credibility rather than saving time.
Compliance automation platforms. Best for generating the document and tracking evidence against a framework. They struggle by encouraging claims the tooling implies rather than the ones you can defend, which is exactly the trap worth avoiding.
A consultant. Best for a first certification, where knowing what evidence is expected saves months. They struggle on maintenance, since the document often stops being updated once they leave.
Writing it yourself. Best for accuracy, because you know what you actually do. It struggles on completeness, so use a framework as a checklist rather than a source of wording.
Operational vendors for specific sections. Disclosure: RemoAsset is owned by the same people who publish this site. It handles procurement, delivery, retrieval, wiping and storage across 80 or more countries, which matters to the equipment section because that section is only credible if the operations exist. Where it struggles: it is a logistics service rather than a security or compliance provider, so the policy remains yours to write and own. What changes is whether your return and disposal claims are backed by a process or by intention.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Pre-revenue | Under 10 | Founders only | None external | Build controls, skip the document |
| First customers | 10 to 30 | No security owner | Knowledge in one head | One page, named owner |
| First questionnaire | 30 to 100 | One ops owner | A deal is waiting | Three to five pages, honest gaps |
| Enterprise prospects | 100 plus | Security owner | Claims get tested | Evidence behind every statement |
| Pursuing certification | Any | Compliance owner | Framework coverage | Consultant plus your own wording |
| Policy exists but is stale | Any | Any | Two years untouched | Review, date it, cut what is untrue |
What an overstated policy costs
The expensive failure is not an incident. It is being caught claiming a control you do not have, which converts a technical gap into a question about whether anything else in the document is true.
It usually surfaces in a follow-up call. The policy says devices are tracked and recovered on exit. The reviewer asks how many are currently outstanding. Nobody knows, and the conversation stops being about security and starts being about credibility.
The second cost is internal. A policy describing an organisation that does not exist cannot guide anybody, so people fall back on improvising, which is what the document was meant to replace.
The third is the renewal problem. Claims made to win a deal get re-examined at renewal, usually by somebody more thorough. A gap you named yourself and then closed is a good story. The same gap discovered by a customer is not.
So the question is not whether your policy sounds strong. It is whether every sentence in it would survive somebody asking for the evidence behind it.
When the policy outruns your operations
Policies drift ahead of reality because writing is faster than building. The gap is usually widest in equipment, since that section involves physical work in places you are not.
Three signals say you have crossed into overstatement. You cannot say how many company devices are currently unaccounted for. Nobody can produce evidence of what happened to the last ten retired laptops. And the return process depends on a specific person remembering rather than a trigger.
None of those requires a large investment to fix. They require a record that is accurate and a route that works where your people actually are. Once those exist, the policy section writes itself and survives questioning.
If the honest answer to any of the three is uncomfortable, that is the thing to fix before the next rewrite. Seeing how device return and disposal evidence gets produced as a by-product of the work is usually quicker than building the tracking yourself.
See how equipment claims get backed by a working process
Read our guide to equipment compliance evidence
Related reading
- Equipment compliance evidence
- Running an equipment vendor security review
- Putting device policy in the handbook
- Equipment under legal hold
- Writing an employee equipment policy
Frequently Asked Questions
What is an information security policy?
A document stating how your organisation protects the information it holds: who is responsible, what the rules are, and how exceptions get decided. It sits above the specific policies on passwords, devices and data, and its main job is to show that security has an owner rather than being everyone’s vague concern.
Do we need one before certification?
Usually yes, and for a commercial reason rather than a compliance one. Customer security questionnaires ask for it long before any auditor does. Most companies write their first version because a deal is waiting, which is a perfectly reasonable trigger as long as the document is honest.
How long should it be?
Three to five pages for the main document, with specific topics in separate policies it references. A forty-page policy signals effort rather than control, and reviewers increasingly read for specificity rather than length. Say what you actually do, including where you are still building.
What gets missed most often?
Equipment. Policies cover access, encryption and incident response thoroughly, then say nothing about how devices are issued, tracked and recovered. A reviewer who asks what happens to a laptop when somebody leaves is asking a question most first-draft policies cannot answer.
Should we claim things we are still building?
No. Describe the current state and name the owner and timeline for anything in progress. Reviewers test claims, and a policy describing controls you do not have is worse than one admitting a gap with a plan attached. Being caught overstating costs more than the gap would have.
Who should own it?
One named person with authority to decide exceptions, typically a founder, a head of operations or whoever runs IT. Shared ownership means nobody updates it. The name should appear in the document, because a reviewer will ask who is accountable and expect a person rather than a department.
How often should it change?
Review annually and after any material change, such as a new class of customer data or a significant tooling shift. Record the review date in the document. An unchanged policy two years old reads as unmaintained, regardless of whether the content is still accurate.
