Standing Up an Insider Risk Programme: The First Ninety Days

Most programmes begin with a purchase and a deployment, then spend a year retrofitting the governance that should have come first. The reverse order costs less and survives longer.

Days 1–30: decide what you are protecting and who decides

Name the sponsor. Someone senior enough to settle disputes between security, HR, legal and the business. Without one, every contested decision escalates and stalls.

Define scope in writing. Which categories of data, which populations of staff, which channels. A programme that begins as "monitor everything" attracts opposition it never recovers from.

Establish the governance before the tooling. Who can request an investigation. Who approves it. Who can see the raw data. What is retained and for how long. What triggers HR or legal involvement.

Writing this down early is not bureaucracy. It is the thing that makes the programme defensible when someone challenges it, and someone will.

Engage legal and HR now, not at deployment. Employee monitoring engages employment law, data protection, and in many jurisdictions consultation obligations. Discovering this after purchase is expensive.

Consult employee representatives where required. In several jurisdictions this is a legal requirement, not a courtesy, and doing it late invalidates the deployment.

Days 31–60: get visibility without acting on it

Deploy in monitor mode only. No blocking, no user warnings, no alerts to managers. You are learning what normal looks like.

Start with two or three channels, not all of them. Email and cloud sharing usually first.

Write policies against the categories you defined, not against the vendor's default library. Default policies generate default alerts about data you never said you cared about.

Look at the output daily and expect it to be unusable at first. The first week of any deployment produces thousands of events, nearly all of them legitimate business activity.

Days 61–90: tune, then act narrowly

Tune aggressively. The goal is a volume a human can actually review. If nobody can look at every alert, the ones that matter are invisible.

Identify the approved workflows that look like violations. Every organisation has several — a finance process that emails spreadsheets externally, a team that uses a personal-looking cloud service for a legitimate reason. Find them and exclude them, or the noise never drops.

Start acting on one narrow, high-confidence thing. Usually a user warning on a specific pattern with almost no false positives. Not blocking, not investigation — a prompt that says "are you sure".

Publish the programme to staff. What is monitored, why, who sees it, what it is not used for. Programmes discovered by employees rather than disclosed to them lose trust permanently and, in some jurisdictions, lawfulness.

What not to do in the first ninety days

Do not block. You do not yet know what you would break, and the first business process you interrupt determines your reputation for two years.

Do not investigate individuals on the basis of untuned alerts.

Do not report alert counts upward as a metric. It sets an expectation that the number means something, and it will fall by ninety percent during tuning, which then looks like failure.

Do not extend scope. Every additional channel before the first is working properly multiplies noise.

The measure of success at ninety days

Not incidents caught. Three things:

A defined scope and governance that legal and HR have agreed. Visibility into two or three channels with an alert volume a person can review. One narrow control acting, with the business informed and not complaining.

That is a programme that can grow. Deployments that skip to blocking with a full policy library are usually turned off within eighteen months.