Insider Risk Policies Tuned From Alert Flood to Actionable Signal at a 4,100-employee Insurer
Insider Risk Management was switched on with default templates and thresholds, producing 1,150 alerts a week nobody could triage. We connected real HR data, tuned indicators, and rebuilt the investigation workflow around privacy controls the works council would sign.
About the Client
The Challenge
The insurer's exposure was well understood by the business and badly served by the tooling. Brokers own client relationships, and when one leaves for a competitor the book tends to go with them — client lists, renewal dates, premium history, loss runs. Security had switched on Insider Risk Management with the data theft by departing users and data leaks templates and left the defaults in place.
Without the HR connector, the departing-user template had nothing to trigger on. It was dormant for the population it was built for, while the general data leaks policy fired on everything else: an underwriter attaching a loss run to a broker email, a claims handler printing a file, an actuary copying a spreadsheet to USB on a site visit. The queue hit 1,150 alerts in a typical week against a team that could examine a fraction of that.
The privacy position was unresolved and blocking progress. The tool shows an investigator exactly which documents a named employee touched — a serious capability in any jurisdiction and a regulated one in several where the insurer operates. There was no written agreement on who could see identities, on what basis, or who audited them.
Underneath both problems sat a design mistake: the policies watched single events. One download is not evidence of anything; that download followed by a rename stripping a client name and an upload to personal cloud storage is a different matter. Nothing was configured to look for the sequence.
Our Approach
Insider risk tuning is mostly an exercise in context. The same action is unremarkable from one person and urgent from another in their notice period, and the platform can only tell the difference if you give it the data that distinguishes them.
Privacy Design and Sign-Off First (Weeks 1-4)
Nothing was tuned until the privacy model was agreed and written down. Pseudonymisation stays on as the default view, so analysts work with anonymised identifiers while assessing whether an alert has substance. Role groups were separated — administrators configure policies but cannot investigate, analysts triage pseudonymised alerts, and only named investigators can de-anonymise and open content. De-anonymisation needs a documented reason, is written to the audit log, and is reviewed by a role outside security. The package went to works councils and privacy officers in 3 jurisdictions before a policy changed.
HR Connector and Population Scoping (Weeks 3-6)
Stood up the Microsoft 365 HR connector to push resignation dates, termination dates, job level changes and performance review outcomes on a scheduled job. This is what makes the departing-user template work at all: the policy activates on the resignation date and watches a window either side of it rather than treating every employee as permanently suspect. The connector needs an upload at least once every seven days or a policy health alert fires, so the job was built with monitoring around it. Priority user groups covered roles with real book-of-business exposure. Around 65 employees enter the window monthly — a volume a small team can own.
Indicator Selection and Threshold Tuning (Weeks 5-10)
Policy indicators are disabled by default, the commonest reason a deployment looks quiet when it should not, so the selection was made explicitly: device indicators requiring Defender for Endpoint onboarding, cloud egress to personal storage, printing. Default thresholds were replaced with daily-volume bands from the firm's own baseline — the defaults assume an average tenant, and an insurer where sharing loss runs with brokers is the job is not one. Risk score boosters were enabled for activity unusual for the individual rather than in absolute terms.
Sequences, Obfuscation and Cumulative Exfiltration (Weeks 8-13)
Rebuilt the high-severity policies around sequence detection rather than single events. Sequences run across four categories — collection, exfiltration, obfuscation and clean-up — and are detected only in the order set at policy setup, so we modelled it on the firm's confirmed cases: collection, then obfuscation, then exfiltration — downloading from a SharePoint site, renaming files to strip client identifiers, moving them to a USB device or personal cloud account. Sequence matching keys on file names, which is why the renaming step registers. Cumulative exfiltration detection was enabled so a slow drip over a rolling 30 days registers even when no single day crosses a threshold — it depends on the Entra ID hierarchy being accurate, since the peer groups come from it.
Triage Workflow and Adaptive Protection (Weeks 12-16)
Defined what happens to an alert: triage against a written standard, dismiss with a reason or confirm into a case, then close with a recorded outcome, send a reminder notice, or escalate to HR and legal with an eDiscovery case attached. Risk levels were connected to Adaptive Protection so enforcement follows the score without anyone raising a ticket: elevated blocks sharing and saving of sensitive data, moderate audits with policy tips, minor shows tips and education. Levels reset after seven days by default, configurable between five and thirty — the dial deciding how long a confirmed concern keeps stricter data loss prevention applied.
Solution Architecture
Signal sources: Microsoft 365 activity, Defender for Endpoint device indicators, cloud egress to personal storage, printing, and HR events for resignation, termination and role change
Policy design: Departing-user and priority-user policies scoped by HR event; general data leak policies built on sequences and cumulative exfiltration rather than single actions
Privacy controls: Pseudonymisation on by default, separated administrator, analyst and investigator roles, documented de-anonymisation with independent review
Response: Templated notices, escalation to HR and legal, and handover into eDiscovery where an investigation becomes a matter
Enforcement link: Adaptive Protection raising DLP and access controls for elevated-risk users rather than applying maximum restriction to everyone
Results
Client identity withheld under confidentiality. Figures are representative of engagements of this scope.
Technologies Used
Key Takeaways
If your organization is facing a similar challenge, here's what we learned:
Without an HR feed, the departing-employee policy is decoration. The template is built around a resignation or termination date. No date, no trigger, and the population you most wanted to watch is the one the policy ignores.
Single events are not signals; sequences are. Downloading files is work. Downloading, renaming to remove client identifiers, then uploading to personal storage is a pattern with intent behind it. Configure for that and the noise falls away.
Settle the privacy question before you tune anything. Who can see a real name, on what basis, and who audits them — agree it, write it down, get it signed. Programmes that skip this get switched off by legal, usually after the first alert involving someone senior.
Default thresholds describe an average tenant you do not work for. If sharing large client files is the daily job of half your staff, the out-of-the-box bands produce an unusable queue. Baseline your own activity first, then set them.
A triage standard matters more than a detection rule. Every alert needs a written definition of dismiss, confirm and escalate, and a recorded reason.
Related Case Studies
Is Your Insider Risk Queue Being Read?
Default templates with default thresholds produce a volume no team can triage, and the policy that matters most usually is not firing at all. We tune insider risk to a signal your investigators can act on.