insider-risk-baseline

Name: insider-risk-baseline
Author: vinayaklatthe

161stars34forks

How to install insider-risk-baseline?

vinayaklatthe/microsoft-security-skills/insider-risk-baseline

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill insider-risk-baseline

Installs into the current project.

Summary

Guidance for establishing a Microsoft Purview Insider Risk Management (IRM) baseline - detecting and managing risky insider activity (data theft, leaks, policy violations) with privacy-by-design. Covers prerequisites, HR connector, policy templates, indicators, pseudonymisation,

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Purview Insider Risk Management (Baseline)
2
3	Insider Risk Management (IRM) uses signals across Microsoft 365 and connected sources to detect,
4	investigate, and act on risky insider activity - data theft, leaks, and policy violations - with
5	privacy-by-design controls (pseudonymisation, RBAC, separation of duties).
6
7	## When to use
8	Standing up an insider-risk program: departing-employee data theft, sensitive-data leaks, and
9	security-policy violations - with legal/HR/privacy sponsorship in place.
10
11	Do not use this skill for risk-adaptive DLP design after IRM is running (use
12	`purview-advanced-dlp`) or for general communication compliance (use
13	`purview-communication-compliance` if available).
14
15	## Pick the right starting policy template
16	\| Concern \| Template \|
17	\|---\|---\|
18	\| Employees leaving with data \| Data theft by departing users (needs HR connector for resignation/termination) \|
19	\| Sensitive-content leaks to unauthorised recipients \| Data leaks (general / by priority users / by disgruntled users) \|
20	\| Security-policy violations (malware, AV disable, etc.) \| Security policy violations \|
21	\| Risky AI usage \| Risky AI usage (preview/GA as available) \|
22	\| Patient data / healthcare scenarios \| Patient data leaks (sector-specific) \|
23
24	Rule of thumb: pick one template per quarter, tune it to acceptable signal-to-noise, then
25	add the next. Multiple templates active simultaneously without tuning swamps reviewers.
26
27	## Approach
28	1. Engage stakeholders - Bring legal, HR, privacy, and (where applicable) works councils to
29	the design table; document the lawful basis for monitoring.
30	Verify: signed-off scope document specifying data sources, retention, reviewer roles.
31	2. Configure prerequisites - Set IRM settings, enable required indicators (Office, device,
32	physical badging via connectors), and connect HR data via the Microsoft 365 HR connector
33	for events like resignation/termination.
34	Verify: HR connector status is healthy and a test resignation event appears within 24 hours.
35	3. Choose policy templates - Start with templates: data theft by departing users,
36	data leaks, security policy violations, and risky AI usage; configure scope.
37	Verify: policy is in place with a defined user scope (pilot first) and indicator set.
38	4. Privacy by design - Enable pseudonymisation of usernames, scope analyst/reviewer roles
39	tightly (RBAC, separation of duties), and configure anonymisation per legal/works-council
40	needs.
41	Verify: reviewers see pseudonymised identifiers by default; un-anonymise requires elevated role.
42	5. Triage & investigate - Review alerts, build cases, examine the user activity timeline, and
43	escalate (e.g., to eDiscovery / HR) per the documented workflow.
44	Verify: case management workflow exists with stages, owners, SLAs.
45	6. Tune indicators and thresholds - Adjust thresholds to acceptable signal-to-noise; document
46	tuning decisions for audit.
47	Verify: alert volume per reviewer per week within the agreed range.
48	7. Adaptive Protection - Feed IRM risk levels into Adaptive Protection so DLP/Conditional
49	Access tighten dynamically for elevated-risk users.
50	Verify: an elevated-risk test user triggers the stricter DLP branch.
51
52	## Guardrails
53	- Engage legal/HR/privacy stakeholders before deployment; insider risk monitoring is sensitive
54	and getting governance wrong damages employee trust and creates legal risk.
55	- Use pseudonymisation and least-privilege reviewers by default; separate IRM analyst from
56	investigator roles.
57	- Tune indicator thresholds to avoid alert overload; start with a focused scope (one BU or
58	priority-user group) before tenant-wide.
59	- HR connector is mandatory for departing-user detection - resignation/termination events drive
60	the highest-confidence signal; without it the template is half-blind.
61	- Document retention for IRM signals/cases per legal/regulatory requirements; do not retain
62	longer than justified.
63
64	## Common anti-patterns
65	- Switching on every template tenant-wide on day one - reviewer fatigue within a week.
66	- No HR connector - departing-user template fires on weak signal and misses real cases.
67	- Pseudonymisation off because "we trust our analysts" - works council and legal disagree lat

People who liked this also viewed

6 picks

Type

insider-risk-baseline

161stars34forks

View on GitHub

How to install insider-risk-baseline?

vinayaklatthe/microsoft-security-skills/insider-risk-baseline

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill insider-risk-baseline

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Purview Insider Risk Management (Baseline)
2
3	Insider Risk Management (IRM) uses signals across Microsoft 365 and connected sources to detect,
4	investigate, and act on risky insider activity - data theft, leaks, and policy violations - with
5	privacy-by-design controls (pseudonymisation, RBAC, separation of duties).
6
7	## When to use
8	Standing up an insider-risk program: departing-employee data theft, sensitive-data leaks, and
9	security-policy violations - with legal/HR/privacy sponsorship in place.
10
11	Do not use this skill for risk-adaptive DLP design after IRM is running (use
12	`purview-advanced-dlp`) or for general communication compliance (use
13	`purview-communication-compliance` if available).
14
15	## Pick the right starting policy template
16	\| Concern \| Template \|
17	\|---\|---\|
18	\| Employees leaving with data \| Data theft by departing users (needs HR connector for resignation/termination) \|
19	\| Sensitive-content leaks to unauthorised recipients \| Data leaks (general / by priority users / by disgruntled users) \|
20	\| Security-policy violations (malware, AV disable, etc.) \| Security policy violations \|
21	\| Risky AI usage \| Risky AI usage (preview/GA as available) \|
22	\| Patient data / healthcare scenarios \| Patient data leaks (sector-specific) \|
23
24	Rule of thumb: pick one template per quarter, tune it to acceptable signal-to-noise, then
25	add the next. Multiple templates active simultaneously without tuning swamps reviewers.
26
27	## Approach
28	1. Engage stakeholders - Bring legal, HR, privacy, and (where applicable) works councils to
29	the design table; document the lawful basis for monitoring.
30	Verify: signed-off scope document specifying data sources, retention, reviewer roles.
31	2. Configure prerequisites - Set IRM settings, enable required indicators (Office, device,
32	physical badging via connectors), and connect HR data via the Microsoft 365 HR connector
33	for events like resignation/termination.
34	Verify: HR connector status is healthy and a test resignation event appears within 24 hours.
35	3. Choose policy templates - Start with templates: data theft by departing users,
36	data leaks, security policy violations, and risky AI usage; configure scope.
37	Verify: policy is in place with a defined user scope (pilot first) and indicator set.
38	4. Privacy by design - Enable pseudonymisation of usernames, scope analyst/reviewer roles
39	tightly (RBAC, separation of duties), and configure anonymisation per legal/works-council
40	needs.
41	Verify: reviewers see pseudonymised identifiers by default; un-anonymise requires elevated role.
42	5. Triage & investigate - Review alerts, build cases, examine the user activity timeline, and
43	escalate (e.g., to eDiscovery / HR) per the documented workflow.
44	Verify: case management workflow exists with stages, owners, SLAs.
45	6. Tune indicators and thresholds - Adjust thresholds to acceptable signal-to-noise; document
46	tuning decisions for audit.
47	Verify: alert volume per reviewer per week within the agreed range.
48	7. Adaptive Protection - Feed IRM risk levels into Adaptive Protection so DLP/Conditional
49	Access tighten dynamically for elevated-risk users.
50	Verify: an elevated-risk test user triggers the stricter DLP branch.
51
52	## Guardrails
53	- Engage legal/HR/privacy stakeholders before deployment; insider risk monitoring is sensitive
54	and getting governance wrong damages employee trust and creates legal risk.
55	- Use pseudonymisation and least-privilege reviewers by default; separate IRM analyst from
56	investigator roles.
57	- Tune indicator thresholds to avoid alert overload; start with a focused scope (one BU or
58	priority-user group) before tenant-wide.
59	- HR connector is mandatory for departing-user detection - resignation/termination events drive
60	the highest-confidence signal; without it the template is half-blind.
61	- Document retention for IRM signals/cases per legal/regulatory requirements; do not retain
62	longer than justified.
63
64	## Common anti-patterns
65	- Switching on every template tenant-wide on day one - reviewer fatigue within a week.
66	- No HR connector - departing-user template fires on weak signal and misses real cases.
67	- Pseudonymisation off because "we trust our analysts" - works council and legal disagree lat

People who liked this also viewed

6 picks

Type