Sentinel Workspace: Roles & Retention
Before you can detect threats, you need a workspace. Learn how to configure Microsoft Sentinel roles, manage data retention across Analytics, Data lake, and XDR tiers, build workbooks, and optimise your SOC with built-in recommendations.
What is a Microsoft Sentinel workspace?
Think of a security operations centre (SOC) as a command room.
Before analysts can monitor screens, you need to build the room. You need desks, monitors, badge access for different team members, and a filing system that decides how long you keep surveillance footage before archiving or deleting it.
A Microsoft Sentinel workspace is that command room. It sits on top of a Log Analytics workspace in Azure. You configure who can access it (roles), how long data is kept (retention tiers), what dashboards are on the screens (workbooks), and how to keep the room running efficiently (SOC optimization).
Get the workspace wrong, and everything downstream — connectors, analytics rules, hunting — suffers.
Microsoft Sentinel roles
Not everyone in a SOC needs the same access. Sentinel uses Azure RBAC (role-based access control) to separate duties.
| Role | What They Can Do | Who Gets It |
|---|---|---|
| Microsoft Sentinel Reader | View incidents, workbooks, hunting queries, and data — but cannot change anything | Junior analysts, auditors, stakeholders |
| Microsoft Sentinel Responder | Everything a Reader can do, plus manage incidents (assign, change status, add comments) | Tier 1 and Tier 2 analysts |
| Microsoft Sentinel Contributor | Everything a Responder can do, plus create/edit workbooks, analytics rules, and automation | Senior analysts, detection engineers |
| Microsoft Sentinel Playbook Operator | Run playbooks manually on incidents | Analysts who need to trigger automation |
| Logic App Contributor | Create and edit playbooks (Logic Apps) | Automation engineers |
Scenario: Anika's MSSP role structure
Anika Singh manages Sentinel for 40+ clients at Sentinel Shield (MSSP). She cannot give every client’s analysts Contributor access — they might accidentally edit another client’s analytics rules.
Her role design:
- Client analysts → Sentinel Responder (manage their own incidents, cannot edit rules)
- Sentinel Shield Tier 2 → Sentinel Contributor (edit analytics rules across workspaces)
- Automation team (Dev) → Logic App Contributor + Playbook Operator (build and test playbooks)
- Client CISOs → Sentinel Reader (dashboards and reports only)
Each client workspace uses resource-level RBAC so analysts only see their own data.
Exam tip: role hierarchy
The exam loves testing whether you know the hierarchy: Reader → Responder → Contributor. Each level includes everything below it.
Key distinction: Responder can manage incidents but cannot create analytics rules. If a question says “an analyst needs to create a scheduled rule,” the answer is Contributor, not Responder.
Also remember: Playbook Operator is separate from the main hierarchy. A Responder cannot run playbooks unless they also have Playbook Operator.
Data retention: Analytics, Data lake, and XDR tiers
Where your data lives determines how fast you can query it and how much it costs.
| Feature | Analytics Tier | Data Lake Tier | XDR Tier |
|---|---|---|---|
| Purpose | Hot data for active investigation and detection | Long-term, cost-effective storage for compliance and hunting | Microsoft Defender XDR data at no extra Sentinel cost |
| Query speed | Fastest — optimised for KQL | Slower — designed for occasional queries | Fast — pre-ingested by Defender |
| Cost | Highest per GB | Significantly cheaper | Included with Defender XDR licence |
| Retention | Default 30 days (Sentinel solution tables get free extension to 90 days), configurable up to 2 years | Up to 12 years | Default 30 days in Defender, extends with Sentinel |
| Use case | Active alerts, real-time detection, incident investigation | Audit logs, historical hunting, compliance requirements | Defender incidents, alerts, device events |
| Analytics rules | Yes — scheduled, NRT, ML all work | Limited — summary rules for aggregated queries | Yes — included in unified Sentinel experience |
How to decide which tier
- High-frequency data you query daily (security events, sign-in logs, firewall logs) → Analytics tier
- Compliance or audit data you rarely query (Azure activity logs older than 90 days, historical DNS) → Data lake tier
- Defender XDR data (incidents, alerts, device events from MDE/MDO/MDI/MDCA) → XDR tier (already there)
Scenario: James optimises Pacific Meridian's costs
James Mwangi at Pacific Meridian (10,000 staff) was spending $45,000/month on Sentinel ingestion. His team ran a cost analysis:
- 70% of queries hit the last 30 days of data
- Compliance requirement: keep Azure AD sign-in logs for 7 years
- Defender XDR data was being double-ingested into Analytics tier
James moved:
- Historical sign-in logs → Data lake (7-year retention, much cheaper)
- Defender data → XDR tier (already included, stopped duplicate ingestion)
- Kept active security events in Analytics (30-day default retention, extended to 90 days for Sentinel solution tables)
Result: 38% cost reduction while meeting compliance requirements.
Workbooks: your SOC dashboards
Workbooks are interactive dashboards in Sentinel that visualise your security data. They combine KQL queries, charts, tables, and parameters into reusable reports.
Common workbook types:
- Incident overview — open incidents by severity, mean time to resolve, analyst workload
- Data connector health — which connectors are active, which have stopped sending data
- Threat intelligence — indicator counts, types, sources, expiration dates
- Investigation — entity timelines, related alerts, geographic maps
You can use built-in workbook templates from the Content Hub or create custom workbooks from scratch.
Exam tip: workbooks vs analytics rules
Workbooks visualise data. Analytics rules detect threats. The exam may describe a scenario where someone wants a “dashboard showing failed sign-ins” — that’s a workbook. If they want an “alert when failed sign-ins exceed 50 in 5 minutes” — that’s an analytics rule.
SOC optimization
Microsoft Sentinel includes SOC optimization recommendations — built-in analysis of your workspace configuration that suggests improvements.
SOC optimization checks for:
- Coverage gaps — MITRE ATT&CK techniques not covered by your analytics rules
- Data value — tables ingesting data that no analytics rule or workbook references
- Cost efficiency — tables that could move to a cheaper tier without impacting detection
- Threat intelligence — whether your TI feeds are active and being used in detections
Think of it as a health check for your SOC — it tells you what you are missing, what you are wasting money on, and where to focus next.
Anika at Sentinel Shield needs a client's junior analyst to view incidents and dashboards but not change anything. Which role should she assign?
James at Pacific Meridian needs to keep Entra ID sign-in logs for 7 years to meet compliance. Which Sentinel data tier should he use for the historical data?
Pacific Meridian's SOC optimization recommends moving SecurityEvent data to the Data lake tier. James checks: no analytics rules reference SecurityEvent, but his threat hunter Tyler uses it daily for KQL hunting. What should James do?
Next up: Now that the workspace is ready, it’s time to get data flowing in. We’ll start with the most common source — Windows security events.