# Essential IT Policies: The List and the Proof | Policy Confirm Canonical URL: https://policyconfirm.com/blog/essential-it-policies Source: Policy Confirm (https://policyconfirm.com) Published: 2026-08-08 Modified: 2026-08-08 Summary: The IT policies most organizations need, what each document has to cover, and how to record that staff have read and acknowledged the version in force. --- Best Practices August 8, 2026 # Essential IT policies: the documents to have, and how to prove they were read Originally published: August 2026 Last updated: August 2026 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. Policy What it has to settle Who acknowledges it Information security policy The top-level statement of intent, scope, roles, and management commitment. Everyone Acceptable use policy What company systems, networks, and accounts may and may not be used for. Everyone, including contractors Access control policy How accounts are granted, reviewed, and revoked, and how privileged access is handled. Everyone, with extra scope for IT Password and authentication policy Credential requirements, multi-factor authentication, and password manager use. Everyone Data classification and handling policy Categories of data, where each may be stored, and how it may be shared. Everyone who handles customer or personal data Device and remote work policy Endpoint requirements, encryption, patching, personal devices, and working outside the office. Everyone with a device Incident response policy What counts as an incident, how to report it, who decides, and notification timelines. Everyone, with detailed scope for the response team Backup and business continuity policy What is backed up, how often, how restores are tested, and recovery objectives. IT and system owners Change management policy How changes to production systems are requested, approved, and recorded. Engineering and IT Supplier and third-party policy How vendors are assessed, what is required in contracts, and how access is limited. Procurement, IT, and vendors with system access Secure development policy Code review, secrets handling, dependency management, and environment separation. Engineering Privacy and data protection policy Lawful basis, retention, data subject requests, and transfers. Everyone who processes personal data 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. ## What each policy needs on the page 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. ## Ownership and review 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. ## The evidence layer 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](https://policyconfirm.com/blog/excel-vs-policy-tracking-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](https://policyconfirm.com/blog/policy-acknowledgement-quiz) . ## 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. ### Get started. Free up to 10 recipients. Distribute your IT policies, collect version-specific confirmations, and export the record an auditor asks for. [Get started](https://app.eu.policyconfirm.com) Try with up to 10 recipients No credit card Get started in seconds Magic link access Choose between EU or US hosting ## 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](https://policyconfirm.com/blog/how-to-keep-track-of-company-policies) - [Policy version control best practices: Why v1.0 matters](https://policyconfirm.com/blog/policy-version-control-best-practices) - [How to prove policy acknowledgement during an ISO 27001 audit](https://policyconfirm.com/blog/how-to-prove-policy-acknowledgement-iso-27001) - [Audit ready compliance checklist: What auditors actually look for](https://policyconfirm.com/blog/audit-ready-compliance-checklist) ## 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.