Essential IT policies: the documents to have, and how to prove they were read

Essential IT policies are the small set of documents that state how an organization handles access, data, devices, systems, suppliers, and incidents. The working set is smaller than most template packs suggest: eight to twelve documents cover the risks that auditors, customers, and regulators ask about.

The list is the easy part. The part that fails is the second half of the sentence: the documents have to be current, owned, and demonstrably read by the people expected to follow them. A policy nobody has acknowledged is an intention, not a control.

The core set

Titles vary between organizations. The coverage below does not. If one of these areas has no document behind it, the gap shows up during the first serious security review.

Smaller organizations often merge several of these into one document, and that is defensible as long as the coverage survives the merge. What is not defensible is a document set that grew to thirty titles because every audit finding produced a new policy instead of an edit to an existing one.

A policy that an auditor can work with carries the same six elements, regardless of topic:

• A version number and an effective date. Without them, no acknowledgement can be tied to anything specific.
• A named owner. A role, not a person who left two years ago.
• A scope statement. Who it applies to, including contractors and vendors where relevant.
• Requirements written as obligations. Statements a reader can comply with or breach, not aspirations.
• A review cadence. When it is reviewed next, and by whom.
• Consequences. What happens when the policy is not followed.

What the frameworks actually ask for

ISO 27001 requires an information security policy under Clause 5.2 and a set of topic-specific policies under Annex A 5.1, covering areas including access control, acceptable use of assets, secure development, supplier relationships, incident management, and continuity. Clause 7.3 adds that personnel must be aware of the policy and of the implications of not conforming with it.

SOC 2 does not publish a list of policy titles. The Trust Services Criteria expect documented policies behind the controls being tested, and CC2 expects internal communication of those policies to the people responsible for them. In practice an auditor asks for the policy, its approval, and the record showing staff received it.

NIS2 and the UK Cyber Security and Resilience Bill move in the same direction, with the addition that management can be held accountable for governance failures. The documentation burden is the same in each case: show the policy, show it is current, show who acknowledged it.

Annual review is the baseline, plus a review after any material change: a new system, a reorganization, an incident, or a regulatory change. Record the review even when nothing changes, because the question in an audit is whether review happened, not whether the text moved.

Reviews also produce the event that most policy programs handle badly. A new version invalidates every acknowledgement of the previous one. If your records do not distinguish between the two, you cannot state who has read the version currently in force, which is the only figure that matters.

Having the documents is the first half. The second half is a record, per person and per version, showing that the document was received and acknowledged. That record needs four properties to survive review:

• Version-specific. Tied to the exact version the recipient saw, not to the policy title.
• Attributable. Linked to an identifiable individual, not a shared mailbox or a distribution list.
• Timestamped. With the time of confirmation, not the time the report was produced.
• Retrievable. Exportable months later without reconstructing it from mailboxes and spreadsheets.

Read receipts fail the first three. Shared drive folders fail all four. A spreadsheet maintained by hand passes until the person who maintained it leaves, which is the point covered in Excel vs. dedicated policy tracking: The hidden risks.

A sequence that works

• Map the twelve areas above against what you already have, and note the gaps rather than writing new documents immediately.
• Close gaps by extending an existing policy where the topic fits. Add a new document only when it does not.
• Give every document a version number, an effective date, an owner, and a review date.
• Define who each policy applies to, as groups rather than name lists, so joiners and leavers do not break the scope.
• Distribute and collect acknowledgements per version, with reminders for non-responders and an export you can hand to an auditor.
• Repeat on the review cadence, and treat every new version as a new acknowledgement round.

For policies where comprehension matters and not only receipt, the question of when to add questions is covered in Acknowledgement vs comprehension: when to add a quiz to a policy.

Frequently asked questions

How many IT policies does an organization need?

Most organizations operate on eight to twelve IT policies. Below eight, common risks such as access control, acceptable use, and incident response tend to be uncovered. Above twelve, documents overlap and staff stop reading them.

Which IT policies are required for ISO 27001 and SOC 2?

ISO 27001 explicitly requires an information security policy and a topic-specific set covering access control, acceptable use of assets, secure development, supplier relationships, incident management, and business continuity. SOC 2 does not list titles, but the Trust Services Criteria expect documented policies for security, change management, and incident response, plus evidence that personnel are aware of them.

How often should IT policies be reviewed?

Annually as a baseline, and after any material change such as a new system, a reorganization, an incident, or a regulatory change. The review date and the reviewer should be recorded even when nothing changes, because an auditor asks for the review record and not only for the document.

Do employees have to sign IT policies?

A handwritten signature is rarely required. What is required is evidence that a named person was given a specific version of the policy and confirmed reading it, with a timestamp and a retention period. An acknowledgement record with version linkage meets that requirement; a signature on an undated printout usually does not.

About the author

The team behind Policy Confirm has hands-on experience across full-stack development, product growth, compliance leadership, and executive technology roles such as CTO and CPTO. They have led and supported ISO 27001 implementations, policy governance initiatives, and audit-driven compliance projects in regulated environments. This background informs a practical, audit-oriented approach to policy management and policy acknowledgements.

Related content

• How to keep track of company policies
• Policy version control best practices: Why v1.0 matters
• How to prove policy acknowledgement during an ISO 27001 audit
• Audit ready compliance checklist: What auditors actually look for

Legal disclaimer

The information provided in this article does not, and is not intended to, constitute legal advice; instead, all information, content, and materials available on this site are for general informational purposes only. You should contact your attorney to obtain advice with respect to any particular legal matter.