Information Security Policy Template

The complete information security policy, free to copy from this page or download as an editable Word document. No sign-up. Replace every [bracketed placeholder] with your own details, delete anything that does not apply, and have it approved before you rely on it. The guide below explains what each section has to contain and what an auditor checks.

14

sections

4

with real wording

6

auditor requests

7

failure modes

A top-level policy is short - two to four pages is normal - and it fails for one reason, which is that it describes an organization that does not exist. Here is every section in order, what each has to contain and what an assessor is checking when they read it. Four of them carry an example clause, because those four are the ones people get wrong. Some organizations call it an IT security policy; the structure is the same.

1. 1

   Purpose

   What it must contain

   Say why the policy exists, and say that it sits above every other security document you hold, so that a conflict with a lower-level procedure has an obvious winner. Two or three sentences is plenty.

   What the auditor checks

   It is where they decide whether your organization has taken a position on security, or has only collected documents.

2. 2

   Scope

   What it must contain

   Name the entities, sites, teams, information and systems the policy covers, and say plainly what it excludes. Cover information in every form, including paper, and settle whether personally owned devices are in or out.

   What the auditor checks

   Scope is checked first, because everything sampled afterward is judged against it. Claim the whole company and one weak team becomes a company-wide finding.

   This policy applies to all employees, contractors and third parties acting on our behalf; to all information [Organization] holds in any form, including paper; and to every system, device, network and cloud service used to process it, including personally owned devices where their use is permitted.

   It sweeps three times - people, information, systems - and each sweep names its awkward edge: third parties acting on your behalf, paper, personal devices. Those are exactly the three places a policy usually goes quiet, and silence reads as an oversight rather than a decision. Narrow the sentence if you cannot honestly claim all of it: a small true scope is worth far more than a large one you cannot evidence.

3. 3

   Policy statements

   What it must contain

   The commitments themselves, as a short bulleted list - six or seven lines is typical, each a single sentence written as a principle rather than a rule. Between them they should cover what you are protecting, how you decide what to protect it from, the obligations you are bound by, and what you expect of the people handling it. Principles only - no settings, no tool names, nothing that needs a number in it.

   What the auditor checks

   Every line here is a thread someone can pull, so write only the commitments you are willing to be tested on.

4. 4

   Roles and responsibilities

   What it must contain

   The position that owns this policy and the security program, the forum it reports into and how often, then what managers are accountable for and what everyone else must do.

   What the auditor checks

   They check the named role exists on your org chart and that whoever holds it knows they hold it. A role nobody recognizes fails this section on the spot.

   [Role, for example the CISO or IT Manager] owns this policy and the wider security program, and reports on it to [management forum] at least [quarterly].

   One owning position, one forum, one frequency: three facts that can be tested against a calendar and a set of minutes. Use the position title rather than a person's name so the document survives someone leaving. If you have never held that forum, either start holding it or write the frequency you will actually meet.

5. 5

   Risk management

   What it must contain

   State that you keep a documented method for identifying, assessing and treating information security risk, and a register recording each risk, its owner, the treatment chosen and the residual risk accepted, plus when both are reviewed and what triggers a review early.

   What the auditor checks

   This clause promises that two specific artifacts exist. They will ask to see the register, and an empty one is worse than a short one.

6. 6

   Information classification and handling

   What it must contain

   The classification tiers you use, that the tier determines how information is stored, shared, transmitted, printed, destroyed and how long it is kept, and who is responsible for classifying something in the first place.

   What the auditor checks

   They test it by pointing at a real file and asking which tier it is and who decided. Use the labels your business already says out loud, not the ones the template shipped with.

7. 7

   Acceptable use

   What it must contain

   The principle in a few lines - company systems are for business use, credentials protected, multi-factor authentication where it exists, devices locked, confidential information kept out of unapproved tools - and a pointer to the document that carries the detailed rules.

   What the auditor checks

   They check the pointer resolves: that the named document exists, and that it does not contradict this one.

8. 8

   Access control

   What it must contain

   Least privilege and need to know, who approves access, how often rights are reviewed, how quickly they are removed when someone moves or leaves, and that privileged accounts are separate, held by named individuals and monitored.

   What the auditor checks

   The most sampled section on the page. They take real leavers from the last few months and check the dates against what you wrote, so every number here is a test you have agreed to sit.

   Access rights are reviewed at least [every six months] and removed the same day someone changes role or leaves.

   A cadence and a deadline, both of which leave evidence behind: a dated review record and an offboarding ticket. It works because it is falsifiable, which is also the danger. Write six months only if six months is what you do - an unenforceable rule hands an assessor a documented control you visibly do not operate.

9. 9

   Suppliers and third parties

   What it must contain

   Who assesses a supplier before it touches your information or connects to your systems, that the security obligations end up in the contract, and that supplier access is limited to the service, reviewed on a stated cycle and revoked when the engagement ends.

   What the auditor checks

   They pick a supplier you have named somewhere else - in an incident, a system list, an invoice - and ask for its assessment and its contract clause.

10. 10

    Incident response

    What it must contain

    Where an incident gets reported and how fast, that concealing one is never acceptable, that you triage, contain and correct, that you notify affected parties and regulators where law or contract requires, and that you record what happened and what changed. Point at the plan for the detail.

    What the auditor checks

    They ask for the last incident, however small, and what changed because of it. Answering 'we have never had one' invites a longer conversation, not a shorter one.

11. 11

    Business continuity

    What it must contain

    That you know which systems and information your critical activities depend on, that backups and recovery arrangements are sized to agreed recovery targets, and that both are tested on a stated cycle.

    What the auditor checks

    They ask for the date of the last restore test. An untested backup counts as no backup, and recovery targets are a business decision rather than an IT one.

12. 12

    Training and awareness

    What it must contain

    Who is trained, when (on joining and at a stated interval afterward), that it covers the parts of the policy relevant to the role, what extra training elevated access attracts, and who keeps the completion record.

    What the auditor checks

    They ask for the record and compare it against your staff list, including the people who joined last month.

13. 13

    Compliance and consequences

    What it must contain

    That compliance is monitored and reported to management, what happens when the policy is breached - the disciplinary process for staff, contract terms for suppliers - and how a genuine exception is requested, risk-assessed, time-limited, recorded and reviewed.

    What the auditor checks

    The exception route is the part they look for. A policy with no way to say 'not this time, and here is why' gets quietly ignored instead of followed.

14. 14

    Review and approval

    What it must contain

    The document control facts: the owner, the approver and their title, the approval date, the version number, the review cycle and the date the next review falls due.

    What the auditor checks

    The cheapest evidence you will ever produce and the most commonly missing. An undated policy reads as an unapproved one.

    Owned by [role]. Approved by [name], [title], on [date]. Version [x.x]. Next review [date].

    Five checkable facts in four short sentences, each answering a question an assessor would otherwise have to ask out loud. Then do the review when it falls due, even if nothing has changed: 'reviewed, no change required' with a date on it is a valid outcome, and a missing review is not.

Get it written for your organization - your first document is free Card required; no charge today.

Assessors rarely comment on how a policy is written. They ask a short run of questions, and every one leads off the page into something you either have or do not: an approval record, a link people can open, a review log with a date on it. Answer these about your own draft before somebody else does.

? Show me the current version.

Satisfies One authoritative copy, carrying a version number and a date, in a place you can open in front of them. Two copies with different dates - one in email, one on the intranet - is a finding before anyone reads a clause.

Fails An emailed PDF marked version 1.1 while the intranet still presents version 1.0 as current.

? Who approved it, and when?

Satisfies A signature block, a management meeting minute or an approval record naming a real person senior enough to own it, dated after the draft was finished and before today. Top management has to own the top-level policy; nobody else can.

Fails An approval block that still says [name] and [date], or a document signed only by its author.

? How do people know it exists?

Satisfies The place staff can actually reach it, the induction it forms part of, and the acknowledgment record with names and dates. Being communicated is part of the requirement, not a courtesy.

Fails A link added to the intranet with no distribution, induction step or acknowledgment record behind it.

? Is the role in section 4 a real person?

Satisfies An org chart or a job description that carries the title, and the holder answering questions about the program without having to ask who owns it.

Fails A Security Manager named in the policy when nobody holds that title and nobody present accepts the responsibility.

? You say access is reviewed every six months.

Satisfies The last two review records, and a handful of leavers sampled against the removal deadline your own policy sets. This is where a copied cadence gets caught.

Fails A current-user export with no reviewer decisions, or a last completed review more than six months old.

? When was it last reviewed?

Satisfies A review log with at least one entry later than the day the policy was written, including the entries that say nothing changed.

Fails A next-review date that has passed and no review record later than the original approval.

Notice how little of that is about the document itself. The policy is only where the conversation starts, and almost every answer sits somewhere else in your evidence. That is why a borrowed policy is such a poor trade: it gives an assessor plenty to pull on and leaves you nothing to pull from.

The same faults account for most of what gets flagged, and not one of them is a writing problem. Run your draft past each of them before you send it for approval. The risk assessment this policy points at fails in a different set of ways, from a matrix that contradicts its own score bands to a register that stops moving between audits - the ISO 27001 risk assessment template guide runs through those.

• ! Placeholders that survived

  A bracketed [role] left in, or another company's name in the footer. It tells a reader the document was acquired rather than adopted, and everything downstream of it is then read with suspicion.

• ! A scope larger than the company

  The policy claims every system, site and team; in practice only the engineering team ever followed it. Overclaimed scope is the most common way a policy contradicts reality, and the contradiction is found by sampling, not by reading.

• ! Cadences nobody meets

  Quarterly access reviews written by a team that manages one a year. Every frequency in the document is a commitment you will be measured against, so write the number you can hold and mean it.

• ! A procedure wearing a policy's clothes

  Password lengths, backup schedules and product names in the top-level document. It goes stale the first time a tool is swapped out, and every small operational change now has to go back through management approval.

• ! No approval, or an undated one

  The approval block still reads [name] and [date], or the policy has sat at version 1.0 for three years with no review entries behind it. Both say the same thing: nobody owns this.

• ! Published nowhere

  The policy lives in a folder two people can reach. If staff cannot find it and there is no record that they saw it, an assessor treats it as a document that exists rather than one that operates.

• ! Documents that disagree

  One policy reviews access quarterly, another twice a year; one names a security manager your org chart does not have. Contradictions are found faster than gaps, because they are visible from the documents alone without anyone testing a control.

Every decision the guide above leaves to you comes back already made: a named owner reporting into the management forum you actually hold, classification tiers matching the labels your business already uses, the access review and risk review cadences you set, and a completed approval and version block. The supporting policies beneath it are written to agree with it. The cover in the hero and the body page below are this document generated for an example company, in that company's branding, shown exactly as PolicyMint renders it.

Where the guide says [role] or [system], the document says yours; where PolicyMint cannot know a fact, it asks rather than guesses.

Guided review Actual product

The one fact this document could not know stays highlighted in the document and the export. The review explains what is needed and writes your answer in. Nothing is invented. Fictional demo data.

Both columns end with the same document in your hands. The difference is who settles the decisions inside it, and what is left over for you to maintain afterward.