IT Policies and Procedures: The 10 Every Company Needs

Every company that uses computers needs a core set of IT policies and procedures: an acceptable use policy, an information security policy, access control, password and MFA rules, data classification and handling, backup and recovery, incident response, vendor management, change management, and a remote work and device policy. Ten documents, each a few pages, each saying who is responsible for what. They are the first thing an auditor, insurer or customer asks for, and they are what turns security from one person’s habits into the company’s practice.

They are also far easier to write than most people expect once you know what each one has to say. This guide covers that, with a template you can reuse. This is general information, not legal advice.

Policy versus procedure (and standard and guideline)

The words get mixed up, and the mix-up produces forty-page “policies” nobody reads. Keep the four layers separate.

Document	What it says	Who approves it	How often it changes
Policy	The rule and the intent: what must happen, who is accountable, what the consequences are. Two to four pages.	Leadership	Yearly review, rarely rewritten
Standard	The measurable requirement that satisfies the policy: password length, encryption algorithm, patch window	IT or security lead	As technology changes
Procedure	The step-by-step instructions for one task: how to onboard a user, how to restore a backup, how to report an incident	The team that performs it	Whenever the steps change
Guideline	Recommended practice where judgment is allowed	Anyone qualified	Informally

A policy that says “backups are taken daily and restored quarterly, and the IT manager is accountable” will survive three generations of backup software. The procedure for the current software lives in a separate document that changes when the software does.

The 10 IT policies and procedures every company needs

For each policy: what it must say, and the procedure that usually sits behind it. Keep the policy statements short and testable.

1. Acceptable use policy

What staff may and may not do with company systems, accounts, devices and data. Must say: company systems are for business use with any permitted personal use defined; no circumventing security controls; no installing unapproved software; no sharing accounts; what monitoring the company performs; how to handle company data on personal devices; consequences of misuse. Every employee signs it at hire. Companies adopting AI tools add an AI section or a separate AI acceptable use policy.

2. Information security policy

The parent document for everything below. Must say: the company’s security objectives and risk appetite; who is accountable (a named security lead, and leadership’s role); that a risk assessment is performed and maintained; the list of supporting policies; how exceptions are requested and approved; how compliance is monitored; the sanctions for violations. This is the IT security policy customers mean when they ask whether you have one.

3. Access control policy

Who gets access to what and how it is granted, reviewed and removed. Must say: access is based on role and least privilege; every user has a unique account; administrative access is separate from daily accounts; access is requested and approved in writing (a ticket counts); access is reviewed on a schedule; access is removed on the day of departure or role change; third-party access follows the same rules. Procedures: onboarding, role change, offboarding, access review.

4. Password and authentication policy

Must say: minimum password length and the ban on reuse across systems; a company password manager is provided and required; multi-factor authentication is mandatory on email, remote access, administrative accounts and any system that supports it; service accounts and API keys are stored in a vault and rotated; account lockout and what to do after a suspected compromise. Standards (length, MFA method) sit in an appendix so they can change without re-approving the policy.

5. Data classification and handling policy

Must say: the classification levels (for most companies three or four: public, internal, confidential, restricted or regulated); who classifies data; the handling rules per level for storage, sharing, encryption, email, printing and disposal; retention periods and the deletion process; special rules for regulated data such as health, payment or personal information. The companion data classification and retention policy guide has worked examples and a schedule template.

6. Backup and recovery policy

Must say: what is backed up (servers, databases, cloud services, endpoints), how often, where copies are kept (including one offline or immutable copy), how long backups are retained, that restores are tested on a schedule and the results recorded, recovery time and recovery point objectives per system, and who is responsible. Procedure: the actual restore steps, kept where you can reach them when the primary system is down.

7. Incident response policy

Must say: what counts as a security incident; that every employee must report suspected incidents immediately and how; who leads the response; the phases (identify, contain, eradicate, recover, review); who may speak to customers, regulators, insurers and the press; the legal and contractual notification obligations that apply to your data; that every incident is logged and reviewed. Procedure: the one-page playbook with phone numbers, isolation steps and the evidence log.

8. Vendor and third-party management policy

Must say: vendors that handle company data or access company systems are inventoried and risk-rated; due diligence before signing (security questionnaire, SOC 2 report or equivalent, insurance); contract terms required (confidentiality, security obligations, breach notification, data return and deletion, business associate agreement where health data is involved); access is limited and reviewed; vendors are reassessed on a schedule and at renewal.

9. Change management policy

Must say: changes to production systems, network, cloud configuration and applications are requested, assessed for risk, approved, tested where possible, scheduled, documented and reversible; emergency changes are allowed with retrospective approval; who approves what size of change. Even a ten-person company benefits from a ticket per change, because the ticket is what you read at 2 a.m. when something breaks.

10. Remote work and device policy

Must say: which devices may access company data (company-owned, or personal devices enrolled in management); required device controls (encryption, screen lock, current patches, endpoint protection); how remote access works (VPN or zero-trust access with MFA, no public remote desktop); rules for public Wi-Fi, home networks and travel; what happens when a device is lost or an employee leaves. Companies that write software often add an eleventh, secure development policy; see the fifteen small-business controls for the technical side these policies describe.

Security policy template

Use one structure for all ten documents. Consistency is what makes them readable, and auditors will look for the same elements in each. The skeleton below is the structure we use; the sample statements are real policy language you can adapt.

[COMPANY NAME] Policy: [Policy title]
Document owner: [Role]        Approved by: [Role, date]
Version: [1.0]                Next review: [Month, year]
Classification: Internal

1. Purpose
   Why this policy exists and the risk it addresses, in two or three sentences.

2. Scope
   Who and what it covers: all employees, contractors and vendors; all company-owned
   and company-managed systems, accounts, devices and data, wherever located.

3. Policy statements
   Numbered, testable rules. Each starts with "must", "must not" or "may".
   3.1 ...
   3.2 ...

4. Roles and responsibilities
   Leadership: approves the policy and provides resources.
   [Security lead]: maintains the policy, monitors compliance, approves exceptions.
   Managers: ensure their teams know and follow it.
   All staff: comply and report suspected violations.

5. Exceptions
   Requested in writing to the [security lead], recorded in the exceptions register
   with a business justification, compensating controls and an expiry date.

6. Enforcement
   Violations are handled under the disciplinary process and may result in loss of
   access, termination of employment or contract, and referral to authorities where required.

7. Related documents
   Information security policy; [related policies, standards and procedures].

8. Review
   Reviewed at least annually and after any significant incident, audit finding
   or change in systems, law or contracts.

9. Version history
   Version | Date | Author | Summary of change

Sample policy statements for section 3 of an access control policy:

3.1 Access to company systems and data must be granted on the basis of job role and
    the minimum necessary to perform it.
3.2 Every user must have an individual account. Shared accounts must not be used except
    where a system cannot support individual accounts, in which case the account must be
    recorded in the exceptions register and its password held in the company password manager.
3.3 Administrative privileges must be assigned to separate administrative accounts that are
    not used for email, web browsing or daily work.
3.4 Access requests and changes must be approved by the user's manager and recorded.
3.5 Access rights must be reviewed at least quarterly by system owners, and any access no
    longer required must be removed.
3.6 All access must be removed on the day an employee or contractor leaves or changes role,
    following the offboarding procedure.
3.7 Third-party access must be limited to the systems and duration required, approved by
    the [security lead], and reviewed at the same frequency as employee access.

Write the other nine policies to the same pattern. The statements for a password policy, for example, are the five bullets in section 4 above, rewritten as “must” sentences with the measurable values moved to an appendix.

Keeping policies alive

A policy that was approved once and never looked at again is a liability in an audit, because it proves you knew what to do and did not do it. The habits that keep the set current:

• One owner per policy, named by role, with the review date in their calendar.
• Annual review, plus a review after any incident, audit finding or major system change. Record the review even when nothing changed.
• Version control in one place (a document system or a repository), with the version history table filled in and old versions kept.
• Acknowledgment at hire and after material changes, recorded with date and name. Auditors sample these.
• Training that references the policies, so people connect the rule to the reason.
• An exceptions register with expiry dates, reviewed quarterly, so exceptions do not become the unwritten policy.
• Evidence of operation: access review records, restore test results, incident logs, vendor assessments. The policy says what happens; the evidence shows it did.
• Mapping to frameworks you are measured against (SOC 2, HIPAA, ISO 27001, NIST CSF, CMMC), so one policy set serves every audit.

Where PS3G fits

PS3G writes and implements IT policy sets for organizations of every size: a founder who needs a credible set for a first customer security review, a growing company replacing an inherited binder, or a department that must align with a corporate framework. Through our cybersecurity consulting we tailor the ten policies to how you actually operate, write the procedures behind them and set up the review cycle. When the policies must satisfy a specific framework, our IT compliance consulting maps them to SOC 2, HIPAA, ISO 27001 or CMMC and prepares the evidence your auditor will sample.

Related reading

• AI Acceptable Use Policy Template for Employees (Free, Editable)
• Data Classification and Data Retention Policy: Templates and Examples
• Cybersecurity for Small Business: The 15 Controls That Matter Most
• Cybersecurity consulting and information security services

Frequently asked questions

What is the difference between an IT policy and an information security policy?

An information security policy is one specific IT policy: the top-level statement of how the company protects its information, who is accountable and which supporting policies exist. “IT policies” is the broader set, which also covers acceptable use, change management, backup, remote work and vendor management. In most companies the information security policy is the parent document and the others are referenced from it.

How long should an IT policy be?

Two to four pages for most policies. If a document is longer, it usually contains procedures or standards that belong in separate documents. Short policies get read, signed and followed; long ones get skimmed. The template in this guide produces a policy of that length when the statements are kept to testable “must” sentences and the technical values are moved to an appendix.

Can I use a free security policy template?

Yes, as a starting structure, and the one in this guide is free to adapt. The risk with downloaded templates is adopting statements your company does not actually follow, which is worse in an audit than having no policy. Edit every statement until it describes what you do or what you will do by a date you commit to, and delete the rest.

Which policies do SOC 2, HIPAA and cyber insurers ask for?

The same core set with different emphasis. SOC 2 auditors expect an information security policy, access control, change management, incident response, vendor management, backup and business continuity, and acceptable use. HIPAA requires documented policies for every Security Rule standard, with the risk analysis and contingency plan in front. Insurers focus on MFA, backups, incident response and access control, and the ten in this guide cover all three.

Who should write and approve IT policies in a small company?

The person who runs IT or security drafts them, a leader with authority over the whole company approves them, and managers enforce them. In a company without an IT lead, the operations manager or a consultant drafts and the owner approves. What matters is that the approver can commit the company to the rules and that the owner of each policy is a named role, not “IT”.