Aurora Software: insider risk noise, missing HR signal, and adaptive protection

Why it is silent

• The departing-employees template depends on HR data. With no HR connector, the policy has no joining or leaving date per person, so the departure trigger and the resignation indicators have nothing to evaluate; the selected indicators are left scoring generic file activity, which is exactly what generates the 400 alerts.
• The Slack-to-service-desk path is not a data source. Disabling the account on the last day also removes the activity you most want to observe.

Prerequisites, in order

1. Connect HR data - the built-in connector via CSV/SFTP or an API feed - including a reliable termination date and manager field. Confirm field mapping and refresh cadence; stale HR data is worse than none because it looks authoritative.
2. Rebuild the policy so the departing-employee scenario is scoped to people with an actual departure date, and keep a separate policy for general data exfiltration rather than mixing both intents.
3. Decide the privacy settings before go-live: anonymized user names versus identifiable alerts determines who can act on an alert and whether analysts can investigate at all. Changing this later restarts the analytics baseline.
4. Run Analytics for at least two weeks to establish what normal looks like for these users, so the first alerts are measurable against a baseline.

Expectation to set

• The alert count should fall sharply and become more serious when the policy is scoped to departures. If it does not, the HR dates are not flowing.

Confirming the six-month-old send

• Activity explorer is the wrong tool: it covers label and DLP activity for roughly 30 days. Use audit log search in Purview instead, which retains 180 days by default and up to a year for E5 licensing; if the organisation needs longer, an audit retention policy extends it (up to ten years with the add-on).
• Search send and mail-access operations for the user and date range, and corroborate with the DLP alert record and any label activity around the same window. Two independent sources is what makes it evidence rather than a log line.
• Decide the audit retention period now, because it is the constraint on every future investigation of this kind.

Getting to a triageable volume

• Cut the indicator set to the two or three with real signal for this business, and set thresholds - for example, a download count or volume in a rolling window - instead of alerting on any single event.
• Use sequence detection for the pattern that matters: download, then email to a personal domain within a short window. A single indicator rarely justifies an alert.
• Restrict scope to priority user groups (privileged access, departing staff, people in sensitive roles) rather than all 6,000 users.
• Default new alerts to a pending-review queue with a defined triage SLA, and review the top alert sources monthly; a policy nobody reviews is a cost with no control.

Say plainly what the analysts need: 400 alerts a week with two people is not triage, it is sampling. Target a volume where every alert gets read.

What must be in place

• An insider risk policy with adaptive protection enabled, plus a DLP policy whose rule includes an insider risk level condition (elevated) and is in enforce mode with a blocking action for external sharing. A simulated or audit-only DLP policy will not block anyone.
• The user must be in scope of both the insider risk policy and the DLP policy. This is the most common reason nothing happens - the two scopes are configured by different people at different times.
• Audit logging must be on, and the insider risk analytics baseline should exist so risk levels are not assigned on day-one noise.
• Confirm which locations your tenant actually supports for risk-based DLP before promising coverage across Exchange, SharePoint, OneDrive, Teams, and endpoints. Endpoint coverage in particular depends on devices being onboarded and healthy.

What will surprise leadership

• Elevation is fast; de-escalation is not automatic in the way people expect. A user stays elevated until an analyst closes the alert appropriately or the configured period expires. Without a triage SLA, a blocked user can stay blocked for days.
• A month is unrealistic for production. Sequence it: HR connector and baseline (weeks 1-4), policy rescoping and alert reduction (weeks 3-6), adaptive protection in audit mode, then enforce on a pilot group.
• Expect false elevations from legitimate high-volume work such as a salesperson sending decks externally. Those are tuning inputs, not failures - but they need a named owner before go-live.