Drafting a whistleblowing policy for your small UK startup

Why a whistleblowing policy matters, even when you are tiny

When you are a five or ten person team, a whistleblowing policy can feel like corporate overhead. You trust everyone. You talk every day. You assume people will just speak up if something is wrong.

That assumption is risky. UK law provides protections for workers who blow the whistle on certain types of wrongdoing. For those protections to apply clearly, your people need to know what constitutes whistleblowing and how to raise a concern. Without a written framework, early-stage problems can fester while the person who spotted them stays silent because they do not want to rock the boat.

A short, practical policy also signals to your team, investors and potential enterprise customers that you take governance seriously. It is a lightweight document that gives you outsized credibility.

What UK law expects

The Public Interest Disclosure Act 1998 protects workers from detriment or dismissal if they make a "protected disclosure." That means raising certain categories of concern, in good faith, to the right person. The qualifying categories include:

• a criminal offence
• breach of a legal obligation
• a miscarriage of justice
• danger to health and safety
• damage to the environment
• a deliberate covering up of any of the above

Your policy does not need to replicate the statute. It simply needs to tell people that you encourage them to raise genuine concerns in these areas, without fear of negative consequences.

Who the policy should cover

Your policy should apply to all workers, not just employees. That includes:

• permanent employees (full and part time)
• fixed-term contractors who work on your premises or systems
• agency temps
• some self-employed consultants, depending on their working relationship

A startup often has a blurry mix of people contributing. If someone notices a serious issue while working on your product, you want them to feel safe flagging it. Extending the policy beyond direct employees is a low-cost way to reduce risk.

What the policy should contain

Keep it concise. If the document runs longer than two pages, people will not read it. Include these sections:

Purpose and scope

A short statement that the startup encourages workers to report genuine concerns about wrongdoing, that the policy applies to all workers, and that it covers the categories listed above.

How to raise a concern

Give one or two clear reporting routes. In a small startup, the route might simply be "email your line manager or the CEO." If the concern involves that person, provide an alternative: a non-executive director, an external HR advisor, or a designated email address that a second founder monitors.

Avoid creating an elaborate committee at an early stage. The best route is the simplest one that guarantees someone independent can hear the concern.

What happens next

Set basic expectations. Tell people that:

• the recipient will acknowledge the concern promptly (say, within five working days)
• a preliminary review will take place
• the outcome of any investigation will be communicated, subject to confidentiality constraints
• the startup will keep the identity of the person raising the concern confidential where possible

Do not overpromise on timelines. A small team can handle most concerns quickly, but complex situations may take longer.

Protection and confidentiality

State explicitly that the startup will not tolerate retaliation or victimisation. If someone raises a concern in good faith, they will not face negative consequences even if the investigation finds no wrongdoing. Bad-faith reports made maliciously are a different matter and can be dealt with under your disciplinary procedure.

External disclosures

Explain that in most cases, workers should first raise concerns internally. However, the law allows disclosures to prescribed external bodies in certain circumstances. Your policy can note that workers may contact a regulator or relevant body if they reasonably believe the matter is exceptionally serious or that internal reporting would not be appropriate.

This shows you understand the legal framework without encouraging people to bypass internal channels.

Record keeping

Request that the person handling the concern keeps a brief written record of:

• the date the concern was raised
• a summary of the issue
• actions taken and the outcome
• dates of key communications

These records can be simple. A shared Google Doc or a notes field in your HR system works. Good records demonstrate that you took the concern seriously if it is later questioned.

Making the policy work in practice

A policy sitting in a shared drive achieves little. The real work is cultural. Three small habits help:

1. Mention the policy during onboarding. A two-minute overview during someone's first week sets the tone.
2. Reference it if a relevant situation arises. If you are doing a post-mortem on a product issue that had safety implications, remind the team that raising concerns early is exactly what the policy is for.
3. Lead by example. If a founder receives a concern, handle it visibly and fairly. People watch how leaders react to the first disclosure more than they read the policy wording.

When to review the policy

Treat the policy as a living document. Review it:

• annually as part of your compliance rhythm
• if your headcount passes a notable threshold (e.g., 50 people, where some governance obligations kick in)
• after any incident that tested the process

Most startups find their first version needs only minor tweaks over two or three years.

Getting help

This post outlines what a reasonable whistleblowing policy contains, but it is not legal advice. The right wording and scope will depend on your specific business and team structure. Consider asking a solicitor to review your draft before you publish it internally. For most early-stage companies, this is a short and inexpensive exercise.

StartupDocs offers a whistleblowing policy template as part of our employment and compliance pack. It covers the essential sections in plain English, with placeholders for your reporting routes and review dates.