What a Small Company Information Security Policy Must Actually Say

TL;DR — An information security policy for a small company should say who is responsible for security, what systems and data are in scope, which baseline rules everyone must follow, how access is granted and removed, how incidents are handled, and how the policy is reviewed. For most small companies, the key fix is not writing a 30-page document; it is writing a short policy that matches what you really do today, then backing it with a few concrete procedures such as MFA (multi-factor authentication), backups, offboarding, and incident reporting. Reading time: ~7 min

What it is and where it sits

An information security policy is the top-level rulebook for how your company protects systems and data. In compliance terms, it is a governance document: it tells people what must happen, who approves it, and which lower-level procedures carry it out.

For a small company, the policy is not the same thing as a technical setup guide. It sits above your tools and dashboards. It should be short enough that leadership can approve it and staff can follow it, but specific enough that a customer, auditor, or insurer can see real controls behind it.

Think of it as a stack:

• Policy: the mandatory rules and responsibilities.
• Standards: the specific baseline settings you require, like MFA on all admin accounts.
• Procedures: the step-by-step actions, like how to onboard a new employee.
• Evidence: screenshots, logs, tickets, and reports showing you actually did it.

In a typical company workflow, the policy does not "talk" to systems directly. People, managers, IT admins, and vendors use it to decide what to configure and what to do when something goes wrong.

[Board/Owner] ---- approves ----> [Security Policy]
                                 | 1. sets rules
                                 v
                           [Procedures/Standards]
                                 | 2. used by
                                 v
[HR] ---- onboarding/offboarding ----> [Admins/Managers]
                                 | 3. configure
                                 v
                    [Email][Devices][Cloud Apps][Backups]
                                 | 4. generate logs/evidence
                                 v
                         [Audit/Customer Review]

What it replaces: informal habits like "we usually remove access when people leave" or "the developer knows how backups work." A policy replaces tribal knowledge (things only a few people know) with approved rules.

Where it lives: usually in your document system, wiki, or shared drive, with version history and an owner. Common places are your company wiki, Google Drive, or Microsoft 365 document library. The exact location matters less than these three facts being true:

• staff can find the current version,
• leadership has approved it,
• older versions are retained.

What the policy needs to say

For a small company, a solid policy usually covers these sections:

1. Purpose and scope — what the policy protects and which people, systems, and vendors are covered.
2. Roles and responsibilities — who owns security, who approves exceptions, who reports incidents.
3. Asset and data handling — what kinds of data you have and how they should be stored, shared, and deleted.
4. Access control — how accounts are created, reviewed, and removed; password and MFA rules.
5. Acceptable use — what staff may do on company systems and devices.
6. Device and endpoint rules — screen lock, encryption, updates, antivirus/EDR (endpoint detection and response, a device security tool) if used.
7. Vulnerability and patching — how you apply security updates.
8. Logging and monitoring — what important events are logged and who reviews them.
9. Backup and recovery — what is backed up, how often, and how restores are tested.
10. Incident response — how staff report a security issue and who leads the response.
11. Vendor and third-party risk — how you approve software vendors and service providers.
12. Security awareness and training — what training staff receive and how often.
13. Exceptions and review cycle — how temporary exceptions are approved and when the policy is reviewed.

How it actually works

The mechanism is simple: the policy sets mandatory rules, and each rule points to a repeatable operational action.

A realistic example: a small software agency hires a project manager who needs email, Slack, a password manager, and access to a client portal.

End-to-end example: onboarding and later offboarding one employee

Step 1: The policy defines the rule.

Your policy says something like:

• all company accounts must use MFA,
• access must be approved by the employee's manager,
• access must be least privilege (only what the person needs),
• offboarding must remove access the same business day employment ends,
• company data must stay in approved systems, not personal email or personal cloud drives.

Step 2: HR or the manager starts onboarding.

The manager submits an access request in your ticket system or onboarding form. The policy should say who can approve access. For a small company, that is often the hiring manager plus the system owner.

Step 3: Admins create accounts using the baseline rules from the policy.

They create the employee in Google Workspace or Microsoft 365, require MFA at first sign-in, add them only to the needed groups, and record what was granted.

Step 4: The employee starts work under the acceptable-use and data-handling rules.

They use company-approved storage, not a private Dropbox or personal Gmail account. If they handle customer data, the policy tells them where it may be stored and who may receive it.

Step 5: Logs and reviews create evidence.

Your identity provider (the login system, such as Google Workspace, Microsoft Entra ID, or Okta) logs sign-ins and MFA enrollment. Your ticket or HR record shows who approved access. That becomes evidence for customers and audits.

Step 6: An incident happens or a person leaves.

Suppose the employee leaves. The policy says offboarding happens the same day. HR notifies the admin, the admin suspends the account, revokes sessions, transfers ownership of files, and removes access to client systems.

Step 7: The policy drives the response.

If the account showed suspicious logins before offboarding, the incident section tells staff where to report it, who investigates, and whether customers must be notified.

The key point: the policy is useful only if each rule maps to an action someone can actually perform in a dashboard, ticket, or checklist.

When to use it (and when not to)

If you are a company with employees, contractors, customer data, cloud systems, or client security questionnaires, you need an information security policy. The real question is how formal it should be.

You probably do not need:

• a giant enterprise policy with 20 approval layers,
• a separate policy for every tiny topic on day one,
• language copied from a template that mentions tools or teams you do not have.

You do need a formal policy if any of these are true:

• customers ask for it,
• staff share access today without clear rules,
• offboarding is inconsistent,
• backups exist but nobody has written who checks them,
• there is no named person responsible for security decisions.

Trade-offs

A good policy gives clarity, but every benefit has a cost.

The biggest trade-off for a small company is operational burden. Every sentence in the policy can create work. If you write "all laptops are centrally managed," but you do not have device management, you have created a gap you will need to explain.

A practical rule: only put mandatory statements in the policy if you are willing to do them repeatedly.

In practice

Below are examples you can adapt today. They are not a full policy, but they show the level of specificity that works.

Example 1: short policy section you can paste into your document

## Access Control

- All company email, file storage, password manager, finance, code hosting, and customer-support accounts must use multi-factor authentication.
- Access to a system must be approved by the employee's manager and the system owner before access is granted.
- Access must be limited to the minimum needed for the person's job duties.
- Shared user accounts are not allowed unless a system does not support individual accounts. Any exception must be approved in writing by the Operations Lead and reviewed every 90 days.
- User access must be removed or suspended by the end of the employee's last working day. For involuntary terminations, access must be removed immediately.
- Access reviews for admin accounts must be performed every quarter and documented in the company ticket or document system.

This is what a useful policy clause looks like: it names systems, owners, timing, and exceptions. The gotcha is overpromising; if you cannot really do quarterly admin reviews yet, change the wording before approval.

Example 2: onboarding/offboarding checklist in YAML

onboarding:
  trigger: "Manager submits new hire request"
  approvals:
    - hiring_manager
    - system_owner_if_admin_access
  actions:
    - create_email_account
    - require_mfa_at_first_login
    - add_to_required_groups_only
    - issue_company_device_if_applicable
    - send_acceptable_use_policy
    - record_access_granted_in_ticket

offboarding:
  trigger: "HR confirms termination date/time"
  actions:
    - suspend_email_account
    - revoke_active_sessions
    - remove_from_groups
    - transfer_file_ownership_to_manager
    - disable_password_manager_vault_access
    - remove_client_portal_access
    - collect_or_wipe_company_device_if_applicable
    - record_completion_time_in_ticket

This turns policy into an operational checklist. The gotcha is timing: for involuntary departures, some steps must happen immediately and in the right order, or the person may retain access.

⚠️ Suspending or deleting user accounts can lock people out and may stop automated jobs, shared mailbox flows, or ownership of files. Before deleting an account, transfer file ownership and check whether the account is used by any integrations.

Example 3: a lightweight policy review record in JSON

{
  "policy_name": "Information Security Policy",
  "version": "1.3",
  "approved_by": "Managing Director",
  "approved_date": "2026-03-15",
  "next_review_date": "2027-03-15",
  "owner": "Operations Lead",
  "exceptions": [
    {
      "system": "Legacy client portal",
      "exception": "No MFA support",
      "approved_by": "Managing Director",
      "expires": "2026-06-30",
      "mitigation": "Unique password stored in company password manager; access limited to 2 named users"
    }
  ]
}

This is a simple way to track ownership, review dates, and exceptions. The gotcha is letting exceptions live forever; every exception should have an expiry date and a compensating control (a backup safety measure).

What to do first in the real world

If you want to put this into practice this week, do these actions in order:

1. Open your document system and create a file named "Information Security Policy".
2. Add the 13 sections listed earlier, even if some are brief.
3. In your identity provider's dashboard, turn on MFA enforcement for all admin accounts first, then all users. In your provider's dashboard this is usually under a path like Security → Authentication → Multi-factor authentication.
4. In your HR or ticket tool, create a simple onboarding/offboarding form with manager approval.
5. In your cloud storage or backup dashboard, record what is backed up, how often, and who checks restore success.
6. Put an owner and annual review date at the top of the policy.
7. Have leadership approve the document, then tell staff where it lives.

That sequence matters because a policy without ownership and a few real controls behind it will not survive customer review.

Further reading

• NIST Cybersecurity Framework 2.0
• NIST SP 800-61 Computer Security Incident Handling Guide
• CIS Critical Security Controls
• ISO/IEC 27001 Annex A
• The "Access Control" and "Incident Response" sections of the SOC 2 Trust Services Criteria

This article was written by an AI system and published pending human review. Verify anything you intend to act on.