Why your SMB needs an IT security policy right now

An IT security policy is a written document that defines how your company protects its data, devices, and systems from unauthorized access, loss, and misuse. Every SMB needs one, even without a dedicated IT team, because customers, insurers, and regulators increasingly demand documented proof that you take security seriously.

The urgency is real. GDPR requires "appropriate technical and organizational measures" for any company handling personal data. Germany's NIS2 implementation is already in force, and supply-chain clauses are pushing security requirements downstream to small vendors. Cyber-insurance applications now routinely ask for a written policy before they'll quote a premium.

This guide gives you a complete, copy-paste IT security policy template covering nine sections. It's written for companies of 10 to 100 people with no internal IT staff, and you can adapt it in an afternoon. The full template is in Step 2 below.

What is an IT security policy?

An IT security policy is a formal set of rules that govern how employees, contractors, and systems handle company data, devices, and access credentials. It spells out what's allowed, what's not, and what happens when something goes wrong.

It is not an ISO 27001 certification, a technical configuration document, or a one-off project. Think of it as a living rulebook: short enough that people actually read it, specific enough that it changes behaviour, and structured enough that an auditor or insurer can verify you follow it.

Prerequisites: what you need before you start

• A document editor (Google Docs, Notion, or even Word will do)
• An inventory of your current IT assets: laptops, phones, SaaS accounts, and a list of who has access to what
• Familiarity with your compliance obligations. GDPR applies to almost every European SMB. If your customers require ISO 27001 or you sell into sectors covered by NIS2, note those requirements too.

No special tools are required to write the policy itself. Enforcing it is a different story, and we'll cover that in Step 4.

Step 1: Identify your risks and assets

Before you write a single policy clause, catalogue what you're protecting. List every device your company owns or manages, every cloud service you pay for, and the categories of data you store (customer records, employee files, financial data).

Then note who has access to what. This is where you'll spot the gaps that matter most: unmanaged personal devices connecting to company email, shared passwords for critical tools, and former employees whose accounts were never revoked. According to the 2026 Verizon Data Breach Investigations Report, 62% of breaches involved the human element – errors, social engineering, or misuse (Verizon). Your asset and access inventory is the foundation for reducing that risk.

If you don't have visibility over your IT security without an IT department, this step will feel uncomfortable. That discomfort is the point: it reveals what you need to fix first.

Step 2: Define the nine essential sections of your policy

The table below lists every section your IT security policy should contain, along with a brief description of what it covers. Below the table, you'll find the actual template text you can copy and adapt.

Template: copy-paste policy text

1. Access control and MFA. All systems at [Company name] use role-based access. Employees receive only the permissions required for their role. Multi-factor authentication (MFA), meaning a second verification step beyond a password, is mandatory on every SaaS application and email account. [Policy owner] reviews access rights quarterly.

2. Passwords and credential management. Passwords must be at least 15 characters. Length matters more than complexity: NIST SP 800-63B (Rev. 4, 2025) no longer permits mandated character-class rules or scheduled password expiry, and requires screening new passwords against a blocklist of known-compromised credentials. All employees must use the company-approved password manager. Passwords may not be reused across services or shared via email or chat, and are changed only where there is evidence of compromise.

3. Device and BYOD management. Company-issued devices are enrolled in mobile device management (MDM) and must run the latest supported operating system. Personal devices may access company data only if they meet the same encryption and OS requirements. Lost or stolen devices must be reported within four hours so they can be remotely wiped.

4. Data handling and classification. Data is classified as Public, Internal, or Confidential. Confidential data (customer PII, financial records) must be encrypted at rest and in transit. Sharing confidential data externally requires approval from [Policy owner]. When data is no longer needed, it must be securely deleted.

5. Remote work. Employees working outside the office must connect through the company VPN. Work on public Wi-Fi without VPN is prohibited. Screens must be locked when unattended, and confidential calls should not be taken in public spaces.

6. Backup and recovery. Critical business data is backed up daily. Backups are stored in a separate location from the production environment. [Policy owner] schedules a restore test at least once per quarter. Untested backups are treated as unreliable.

7. Third-party and vendor access. External vendors receive the minimum access required for their task, limited in scope and time. All vendor access is logged and reviewed monthly. Contracts with vendors handling personal data must include a GDPR-compliant data processing agreement.

8. Incident response. Any suspected security incident (phishing click, unauthorized access, data loss) must be reported to [Policy owner] immediately. [Policy owner] assesses severity, isolates affected systems, and coordinates response. Under GDPR Article 33, personal data breaches must be reported to the supervisory authority within 72 hours of becoming aware of them. [Company name] maintains a breach log documenting every incident and the actions taken.

9. Onboarding and offboarding. New employees receive accounts and device access on their start date according to a role-based checklist. On their last day, all accounts are deactivated and devices are collected or remotely wiped before end of business. [Policy owner] confirms full revocation within 24 hours.

Step 3: Align the policy with GDPR, ISO 27001, and NIS2

Your policy doesn't exist in a vacuum. It needs to hold up when a customer sends you a security questionnaire or an insurer reviews your controls.

GDPR applies to virtually every European SMB. Sections on data handling, incident response, and offboarding map directly to Articles 5, 32, and 33. If you can show an auditor that your policy addresses these areas and that you enforce it, you've covered the core IT requirements.

ISO 27001 is a voluntary standard, but enterprise customers increasingly require it from suppliers. The nine policy sections above correspond closely to Annex A controls for access management, asset handling, and incident management in ISO 27001. Having a documented policy is the first step toward certification readiness.

NIS2 deserves a precise explanation. Germany's NIS2 Implementation Act (NIS2UmsuCG) has been in force since 6 December 2025, with no transition period. The BSI registration deadline of 6 March 2026 has already passed. Direct scope covers companies with 50+ employees or €10M+ annual turnover in listed sectors. Most SMBs are not directly in scope. But here's why it still matters: in-scope companies must manage supply-chain security and pass obligations down to their suppliers by contract. If you sell to a mid-sized manufacturer, energy provider, or healthcare group, a documented IT security policy is now a contractual requirement, not a nice-to-have. Third-party involvement now features in 48% of all breaches, a 60% increase year over year, according to the 2026 Verizon DBIR. That number explains why larger customers are tightening vendor requirements faster than the law obliges them to.

Cyber-insurance applications typically ask whether you have a written security policy, enforce MFA, and run regular backups. The template in Step 2 lets you answer "yes" to all three with evidence.

Step 4: Build enforcement into your operations

A policy without enforcement is just a PDF sitting in a shared drive. Each section of your policy needs a corresponding real-world control that makes it hard to violate the rules, not just a rule that asks people to behave.

• Access control: enforce MFA through your identity provider's settings, not through a policy clause that says "please enable MFA."
• Password and screen lock rules: set them once at fleet level – required passcode, minimum length, auto-lock timeout, failed-attempt limits – so the rule is applied by the device instead of remembered by the employee.
• Device management: enrol devices in MDM so you can verify encryption, push OS updates, and wipe lost hardware remotely.
• Offboarding: automate account deactivation so that access revocation happens the moment HR processes a departure, not days later when someone remembers.
• Patch compliance: monitor OS and application versions centrally, flag devices that fall behind, and block non-compliant devices from accessing company resources.
• Software inventory: keep a per-device record of which applications are actually installed and when. This is what turns Step 1's asset inventory from a one-off spreadsheet into something that stays true.

For SMBs without an internal IT team, this is where the gap between policy and practice becomes painfully obvious. Platforms like deeploi close it in different ways. You set password and screen lock policies across the whole fleet in a couple of minutes, then see each device's compliance status against that policy, which is exactly the evidence an insurer or enterprise customer asks for when they want proof a policy is enforced rather than written. Each device also shows which applications are installed and when, so onboarding gaps surface before they become security gaps. And offboarding runs automatically: accounts deactivated and devices wiped on the leaving date, without anyone having to remember.

Step 5: Train your team and roll out the policy

Writing the policy is half the work. The other half is making sure every employee understands it and follows it.

• Walk new hires through the policy during onboarding. Explain the "why" behind each rule, not just the rule itself.
• Run short quarterly refreshers: a 15-minute session covering one topic (phishing recognition, password hygiene, or reporting incidents) is more effective than an annual two-hour lecture.
• Consider phishing simulations to test real-world awareness. The results are usually humbling and always educational.

Assign a policy owner. This doesn't have to be a security expert. In most SMBs, the office manager, HR lead, or a founder takes the role. What matters is that one person is accountable for keeping the document current and following up on violations.

Finally, collect documented employee acknowledgement. A signed or logged confirmation that each employee has read the policy is what auditors, NIS2 supply-chain auditors, insurers, and enterprise customers actually ask to see. The policy itself is rarely enough.

Common mistakes that weaken your policy

• Writing a 40-page document nobody reads. Keep it under 15 pages. If it's longer, people skip it entirely.
• Forgetting to revoke access during offboarding. This is the single most common SMB security gap. Automate it.
• Having a backup policy but never testing a restore. Schedule a quarterly restore test and document the result.
• Treating the policy as a one-time project. Threats evolve, tools change, and people join and leave. Review the policy at least annually.
• No enforcement mechanism. A policy that relies entirely on trust and memory will fail. Pair each rule with a technical control wherever possible.

FAQ

Who owns the IT security policy in a company without an IT team?

Typically the founder, office manager, or HR lead. The owner doesn't need to be a technical expert; they need to be empowered to make decisions and follow up. Many SMBs assign ownership internally and use an external IT partner such as deeploi to maintain and enforce the policy in practice.

How long should an IT security policy be?

Between 8 and 15 pages for most SMBs. That's long enough to be specific about access control, incident response, and data handling, but short enough that employees actually read it. If your policy exceeds 15 pages, split operational procedures into a separate runbook and keep the policy focused on rules and responsibilities.

How often should you review and update the policy?

At least once a year. You should also review it after any security incident, a major change in your tool stack, a shift in your compliance obligations, or significant team growth. Put a recurring calendar reminder on the policy owner's schedule so the review doesn't slip.

Does NIS2 apply to small businesses?

Not directly if you have fewer than 50 employees and under €10M in annual turnover. But it applies indirectly through supply-chain requirements. In-scope companies must ensure their suppliers meet certain security standards, and they enforce this through contractual clauses. If you sell to or partner with larger organisations in regulated sectors, a documented IT security policy is now a practical requirement.

Next steps

You now have a five-step process: inventory your assets and risks, write the nine policy sections using the template above, align with GDPR, ISO 27001, and NIS2 where relevant, build enforcement into your daily operations, and train your team.

Start by copying the template into your company's document system and filling in the placeholders. Schedule a quarterly review cycle so the policy stays current. And if you want the policy to be more than words on a page, connect it to automated enforcement through a platform like deeploi's security and device management so that access controls, patch compliance, and offboarding actually happen the way your policy says they should.