Lesson 28 — Building Investigation Playbooks
Investigation playbooks turn analyst knowledge into repeatable workflows that define triggers, evidence checks, pivots, decisions, response actions, handovers and closure requirements.
Security Copilot promptbooks can standardise prompt sequences, while Microsoft Sentinel playbooks and automation rules can orchestrate approved response tasks.
This lesson explains how to combine these capabilities without confusing analyst guidance, generative-AI prompting and automated action—and without removing the human review gates that protect investigation quality.
What you will learn
This lesson develops a governed, repeatable investigation-playbook framework.
Investigation-playbook workflow
↓
Set scope, ownership, prerequisites and evidence standards
↓
Map triage, collection, enrichment, hunting and timeline steps
↓
Add Security Copilot prompts and promptbook sequences
↓
Insert source-validation and confidence checkpoints
↓
Define decision branches and escalation criteria
↓
Add approved containment and response actions
↓
Identify Sentinel automation opportunities
↓
Apply permissions, approvals and failure handling
↓
Test with controlled incidents and peer review
↓
Publish, measure, version and improve the playbook
Playbook capability model
| Component | Purpose | Core question |
|---|---|---|
| Analyst playbook | Human investigation workflow, decisions, evidence and ownership. | How should the incident be investigated? |
| Copilot promptbook | Chained prompts for a repeatable Security Copilot task. | Which AI-assisted steps can be standardised? |
| Sentinel playbook | Azure Logic Apps workflow for orchestration and response. | Which approved actions can be automated? |
| Evidence gates | Source validation, confidence, alternatives and missing visibility. | What must be proven before continuing? |
| Decision gates | Escalation, containment, approval and business checks. | Who decides the next action? |
| Lifecycle | Testing, publishing, versioning, measurement and retirement. | How will the playbook remain safe and current? |
Learning objectives
- Design repeatable investigation workflows.
- Separate analyst playbooks, promptbooks and automation.
- Define triggers, scope, evidence and ownership.
- Add prompts, pivots and validation gates.
- Define escalation and containment criteria.
- Use Sentinel automation safely.
- Test, version and maintain playbooks.
What is an investigation playbook?
An investigation playbook is a documented, repeatable analyst workflow for triage, evidence collection, pivots, decisions, response and closure.
Playbook versus checklist
A checklist confirms steps, while a playbook also explains triggers, decisions, evidence requirements, ownership and outcomes.
Playbook versus promptbook
A Security Copilot promptbook is a chained series of prompts that supports a task; it can form part of a wider investigation playbook.
Playbook versus automation
A Microsoft Sentinel playbook is a Logic Apps workflow used for orchestration and response automation.
Keep the terms separate
Analyst playbooks, Copilot promptbooks and Sentinel automation playbooks can work together but have different purposes and controls.
Why playbooks matter
Playbooks improve consistency, handover quality, evidence completeness, training and response speed.
Consistency is not rigidity
Analysts should follow the playbook while adapting to evidence and recording justified deviations.
Define the use case
Create a playbook for a clear scenario such as phishing, identity compromise, malware, OAuth abuse or cloud incidents.
Define the trigger
State which alert, incident, report, behaviour or request starts the workflow.
Define entry criteria
Specify the minimum evidence or condition required before the playbook begins.
Define exit criteria
State when the playbook can close, transfer, escalate or move into recovery.
Define scope
Identify products, environments, users, devices, mailboxes, applications and resources covered.
Define ownership
Assign the incident owner, analyst roles, approvers and escalation contacts.
Define priority
Explain how severity, business criticality and evidence affect response priority.
Define prerequisites
List required licences, permissions, connectors, tables, plugins and tools.
Define source systems
Identify Defender XDR, Sentinel, Entra, Defender for Cloud, Intune, Purview and third-party evidence.
Define evidence standards
State which identifiers, timestamps, screenshots, exports and source records must be preserved.
Define time handling
Use one investigation time zone while preserving original source timestamps where required.
Define confidence labels
Use consistent classifications such as confirmed, probable, possible and unsupported.
Define decision points
Show where evidence determines which branch the analyst follows.
Define stop conditions
Prevent destructive or unnecessary actions when evidence does not support escalation.
Define review gates
Require analyst, incident commander, business, legal or change approval at appropriate stages.
Start with triage
Confirm alert quality, affected entities, business context and immediate risk.
Confirm the incident
Determine whether activity is true positive, benign, expected, duplicate or unresolved.
Collect core entities
Record users, devices, mailboxes, files, IPs, domains, applications, alerts and resources.
Use immutable identifiers
Preserve DeviceId, AccountObjectId, NetworkMessageId, AlertId, IncidentId and resource IDs.
Build the initial timeline
Record first observed, first detected, latest activity and response actions.
Summarise the incident
Use Security Copilot to create a draft while requiring source attribution and uncertainty.
Review the process log
Confirm which Copilot plugins, sources and actions contributed to each result.
Use prompt sequences
Break the investigation into orientation, evidence collection, pivoting, validation and reporting prompts.
Promptbook inputs
Define the exact incident ID, user, device, script, indicator or threat actor required by each promptbook.
Promptbook outputs
Specify tables, summaries, confidence, source references and next actions.
Prompt chaining
Use previous prompt output as context only after the analyst validates it.
Avoid error propagation
An incorrect first prompt can contaminate later prompts if its conclusions are reused without review.
Use evidence checkpoints
Pause after major steps to compare Copilot output with original portal evidence.
Use KQL checkpoints
Validate generated queries, schema, time range, joins and returned rows.
Use IOC checkpoints
Validate freshness, ownership, internal sightings and reputation before action.
Use ATT&CK checkpoints
Map techniques only when source evidence supports the behaviour.
Use malware checkpoints
Separate artefact reputation, sandbox behaviour and confirmed internal execution.
Use identity checkpoints
Confirm sign-ins, MFA, device context, role changes, tokens and authentication methods.
Use endpoint checkpoints
Confirm process trees, files, network events, persistence and device scope.
Use email checkpoints
Confirm message delivery, URLs, attachments, clicks and post-delivery activity.
Use cloud checkpoints
Confirm resource IDs, identities, permissions, alerts, recommendations and activity logs.
Use Sentinel checkpoints
Confirm workspace, connector health, retention, tables, bookmarks and entity mapping.
Build investigation pivots
Define the next user, device, mailbox, process, file, domain, IP or resource to investigate.
Prioritise pivots
Choose the pivot most likely to change scope, impact or response.
Document rejected pivots
Record why a possible relationship or indicator was not pursued.
Define escalation criteria
State the evidence required to expand scope, raise severity or involve specialists.
Define containment criteria
Specify when account disablement, token revocation, device isolation or blocking is justified.
Define preservation steps
Capture evidence before destructive remediation where required.
Define business checks
Confirm system ownership, service dependency, criticality and potential operational impact.
Define legal and privacy checks
Identify when personal, regulated, customer or legally sensitive information requires review.
Define communications
Specify who receives technical, executive, customer and regulatory updates.
Define handover content
Require current status, evidence, completed actions, open questions, owners and next steps.
Define closure content
Document root cause, scope, impact, containment, remediation, residual risk and lessons learned.
Use reusable templates
Standard sections improve consistency across different investigation scenarios.
Phishing playbook
Include message analysis, authentication, URL and attachment enrichment, clicks, user activity and post-delivery response.
Identity compromise playbook
Include sign-ins, MFA, risk, tokens, privileges, mailbox activity, devices and session revocation.
Endpoint alert playbook
Include device context, process tree, files, persistence, network evidence, prevalence and isolation decisions.
OAuth abuse playbook
Include application identity, consent, permissions, publisher, users, tokens, activity and revocation.
Cloud incident playbook
Include resource identity, owner, exposure, permissions, attack paths, alerts, activity and remediation.
Threat-intelligence playbook
Include actor, campaign, indicators, freshness, internal relevance, hunting and detection actions.
Malware playbook
Include file identity, delivery, execution, behaviour, prevalence, sandbox results and specialist escalation.
Hunting playbook
Include hypothesis, data sources, queries, pivots, negative findings, bookmarks and escalation.
Executive reporting playbook
Include incident story, scope, business impact, status, remaining risk and required decisions.
Microsoft prebuilt promptbooks
Security Copilot provides prebuilt promptbooks that chain prompts for specific security tasks.
Custom promptbooks
Custom promptbooks can standardise repetitive prompt sequences around organisational workflows.
Promptbook permissions
Users need appropriate Security Copilot and plugin permissions for the promptbook to access data.
Promptbook review
Review prompt sequence, dependencies, inputs, outputs and failure handling before publishing.
Sentinel automation rules
Automation rules can triage incidents, change properties, assign ownership and invoke playbooks.
Sentinel playbooks
Sentinel playbooks are built on Azure Logic Apps and can run automatically or manually.
Automation permissions
Sentinel requires explicit permissions to run playbooks on incidents, alerts or entities.
Manual first
Run high-impact playbooks manually until behaviour, permissions and outcomes are understood.
Use least privilege
Automation identities and connectors should have only the access required.
Use approval gates
Destructive actions should require approval where business or security risk is significant.
Use idempotent actions
Repeated execution should not create duplicate tickets, blocks, messages or changes.
Handle failures
Document what happens when a connector, API, permission or response action fails.
Handle partial completion
A playbook should show which steps succeeded, failed or remain pending.
Avoid silent automation
Record actions, timestamps, identities and results in the incident.
Test with simulations
Use approved test incidents and controlled scenarios before production deployment.
Version control
Track owner, version, change history, review date and approval.
Review after platform changes
Update playbooks when portals, tables, permissions, plugins or APIs change.
Review after incidents
Lessons learned should improve evidence checks, branches, actions and communications.
Retire obsolete playbooks
Remove or archive workflows that rely on retired products, tables or procedures.
Measure usefulness
Track consistency, time saved, missed evidence, false escalations, response quality and adoption.
Avoid prompt volume metrics
The number of prompts or automated actions does not prove investigation quality.
Train analysts
Analysts should understand why each step exists and when to deviate.
Preserve human judgement
Automation and promptbooks should accelerate repeatable work without replacing accountability.
Final analyst validation
The incident owner approves the investigation outcome, response and closure regardless of how much of the workflow was automated.
Example investigation-playbook design prompt
Include:
1. Trigger and entry criteria
2. Required roles, permissions, products and connectors
3. Initial triage and business-context checks
4. Identity, email, endpoint, cloud-app and Sentinel evidence
5. Security Copilot prompts and suitable promptbook stages
6. KQL, IOC, ATT&CK and timeline validation checkpoints
7. Decision branches for true positive, benign, duplicate and unresolved outcomes
8. Escalation and containment criteria
9. Manual and automated response actions with approval gates
10. Handover, executive reporting, closure and lessons learned
Separate analyst guidance from Sentinel Logic Apps automation, identify every destructive action and require source evidence before escalation.
Agent Foskett investigation: “The second analyst solved it faster…”
↓
The first analyst followed the account-compromise playbook
↓
The message, user, device, sign-ins and mailbox activity were recorded
↓
Security Copilot generated the incident summary and enrichment drafts
↓
Every result was checked against the source evidence
↓
The analyst preserved queries, identifiers, confidence and open questions
↓
The case transferred to the night shift
↓
The second analyst knew exactly what had been completed
↓
The next playbook branch required token review and related-user hunting
↓
A second affected account was found
↓
The escalation criteria were met
↓
Approved session revocation and password reset actions were completed
↓
The final timeline and executive update used the same evidence record
↓
The second analyst reached the right conclusion in less than half the usual time
↓
The playbook had not replaced either analyst
↓
It had preserved their judgement between shifts
Investigation-playbook validation checklist
| Area | Question | Validation action |
|---|---|---|
| Scenario | Is the trigger and use case specific? | Define entry and exit criteria. |
| Ownership | Are analyst, approver and escalation roles clear? | Assign responsibility for every branch. |
| Evidence | Are source systems and required identifiers defined? | List products, tables and preservation steps. |
| Prompts | Do prompt sequences require validation? | Add source and confidence checkpoints. |
| Decisions | Are branches based on observable evidence? | Define true-positive and benign outcomes. |
| Actions | Which actions are manual, assisted or automated? | Separate guidance from execution. |
| Permissions | Does automation use least privilege? | Review identities, connectors and access. |
| Failures | What happens when a step fails? | Log partial completion and recovery actions. |
| Testing | Has the playbook been exercised safely? | Use simulations and peer review. |
| Maintenance | Is owner, version and review date recorded? | Schedule review and retirement criteria. |
Key takeaways
- An analyst playbook documents a repeatable investigation workflow with evidence, decisions, ownership and response.
- Security Copilot promptbooks are chained prompts that can function as reusable workflows for repetitive security tasks.
- Microsoft Sentinel playbooks are Azure Logic Apps workflows used for orchestration and response automation.
- Promptbooks and automation should support—not replace—the broader analyst playbook.
- Evidence and decision gates prevent incorrect early conclusions from propagating through the workflow.
- Automation rules can triage Sentinel incidents and invoke approved playbooks.
- Sentinel requires explicit permissions to run playbooks on incidents, alerts and entities.
- Destructive actions require least privilege, testing, approval and failure handling.
- Playbooks should be versioned and updated after incidents and platform changes.
- The incident owner remains accountable for the investigation, response and closure.
What Agent Foskett preserved
- Incident trigger
- Entity identifiers
- Source evidence
- Validated prompts
- KQL results
- Confidence labels
- Open questions
- Decision branches
- Response approvals
- Handover status
Best practices
- Define the scenario.
- Separate playbook types.
- Assign ownership.
- Preserve evidence.
- Add validation gates.
- Document decisions.
- Automate cautiously.
- Test failures.
- Version changes.
- Keep judgement human.
Related Agent Foskett resources
Continue the Microsoft Security Copilot Academy
How do you build investigation playbooks with Microsoft Security Copilot?
Investigation playbooks combine triggers, evidence collection, Security Copilot prompts, hunting pivots, validation checkpoints, decisions, response actions, handover and closure requirements.
Security Copilot promptbooks and investigation workflows
Security Copilot promptbooks chain prompts for repeatable security tasks and can support a broader analyst investigation playbook.
Microsoft Sentinel automation playbooks
Microsoft Sentinel playbooks are Azure Logic Apps workflows that can be attached to analytics or automation rules or run manually on incidents, alerts and entities.
