Information security policy: the short version a small company can follow

An information security policy is the document that says what information your company protects, who is accountable for protecting it, and what each person has to do. It sits above the specific rules — passwords, devices, access, suppliers — and gives them a reason to exist. In a large organisation it is one document in a stack of forty. In a company of twenty it can be two pages, and two pages that people follow beat forty nobody has opened.

Most small companies acquire one for an external reason: a customer questionnaire, an insurance form, a certification. That is a legitimate trigger, but it produces the characteristic failure — a downloaded template with the company name substituted, describing controls that do not exist. That document is worse than nothing, because it is now evidence that you claimed something untrue.

What an information security policy has to say

• What you are protecting: customer data, financial records, credentials, source code, whatever actually matters here.
• Who is accountable — one named person, even if security is a fraction of their job.
• How information is classified, in two or three levels rather than five nobody can apply.
• The rules for access: who gets what, who approves it, and how it is removed when someone leaves.
• Device and password expectations, in specific terms.
• What staff must do if something goes wrong, and the promise that reporting early is not punished.
• How suppliers who handle your data are assessed.
• How often this is reviewed, and by whom.

The most valuable clause is the one about reporting mistakes. If someone who clicks a phishing link expects trouble, they will say nothing for three days, and those three days are the whole difference between an incident and a disaster. Say plainly that prompt reporting is expected and never punished — then honour it the first time it happens, because that is when the policy is really written.

Write only what is true

Every claim in a security policy is a claim you may have to demonstrate — to a customer, an auditor, an insurer, or in the aftermath of a breach. A policy stating that access is reviewed quarterly, in a company that has never reviewed it, is not a statement of intent. It is a documented failure to follow your own process, which is a materially worse position than never having claimed it.

The honest approach is to write what you do now, mark what you intend to do with a date, and revisit. A one-page policy describing real practice is more defensible in every direction than a comprehensive one describing aspirations.

Building it

1. List what you actually hold, and where it lives. Most companies find data in services nobody remembers signing up for.
2. Decide the two or three classification levels and give an example of each.
3. Write the access rules, including the leaver process — the step most often missing.
4. Write the incident reporting instruction so a non-technical person can follow it under stress.
5. Name the accountable person and the review date.
6. Have someone outside the drafting read it and mark anything they would not know how to do.
7. Publish it where people can find it without asking, and cover it during onboarding.
8. Review annually and after any incident, and record what changed.

Where it fits with standards and law

If you are working towards a certification such as ISO 27001, the policy is one required element of a wider management system, and the standard specifies what it must contain. Data protection law imposes its own obligations independently of any certification. Neither is satisfied by a policy document alone, and neither should be approached by editing a template found online — where a specific regime applies to you, follow it, and take advice on the parts that determine liability.

For a small company with no certification pressure, none of that removes the value of the two-page version. The controls it describes are the ones that prevent the incidents small companies actually have: an account nobody closed, a shared password, a laptop with no encryption, a supplier holding data nobody assessed.

Keeping it current

Ettex Docs is where the document itself belongs: version history so the policy in force last March is still readable, comments to collect review feedback before publishing, and one shared link so there is a single current version rather than copies in inboxes. The related policies — access, devices, retention — sit alongside it and get reviewed on the same cycle.

It is a document tool, not a compliance platform. It does not track control implementation, collect evidence, map clauses to a standard, or manage an audit. If you need those, that is a different category of product; what belongs here is the writing, the review and the record of what was agreed when.

Write what is actually true, name one accountable person, make incident reporting safe, and keep it to a length people will read.