Lesson 31 — Building SOC Promptbooks
Security Copilot promptbooks turn repeatable analyst knowledge into reusable sequences of prompts that can support incident response, threat hunting, reporting and daily SOC workflows.
Each prompt runs in order, and later prompts can build on earlier responses—but only when analysts preserve source context, validate evidence and prevent incorrect conclusions from propagating through the sequence.
This lesson explains how to design, test, govern, share and maintain SOC promptbooks for phishing, compromised accounts, endpoint alerts, OAuth abuse, cloud incidents and threat hunting.
What you will learn
This lesson begins Module 4 with a governed SOC promptbook design and lifecycle model.
SOC promptbook lifecycle
↓
Define audience, trigger, inputs and expected outcome
↓
Map the investigation into small sequential prompts
↓
Specify required plugins, products and permissions
↓
Add source, evidence and confidence requirements
↓
Insert analyst validation gates between stages
↓
Test known malicious, benign and incomplete cases
↓
Review sensitive data, sharing and governance
↓
Publish to the approved audience
↓
Measure quality, overrides and operational value
↓
Version, update or retire the promptbook
SOC promptbook design model
| Component | Content | Design question |
|---|---|---|
| Purpose | Scenario, audience, trigger and intended outcome. | What repeatable SOC task should this solve? |
| Inputs | Incident IDs, users, devices, messages, resources and time ranges. | What exact context must the analyst provide? |
| Sequence | Orientation, enrichment, hunting, validation and reporting prompts. | In what order should the work occur? |
| Evidence | Products, plugins, tables, entities, citations and raw records. | What supports each result? |
| Governance | Owner, permissions, sharing, approvals and sensitive data. | Who may run and maintain it? |
| Lifecycle | Testing, versioning, measurement, review and retirement. | How will it remain safe and useful? |
Learning objectives
- Design reusable SOC promptbooks.
- Define inputs, outputs and dependencies.
- Build sequential evidence-driven prompts.
- Create scenario-specific investigation workflows.
- Add validation and review gates.
- Test permissions, data gaps and false positives.
- Govern, version and maintain promptbooks.
What is a SOC promptbook?
A SOC promptbook is a reusable sequence of Security Copilot prompts designed to complete a defined security task consistently.
Promptbooks run sequentially
Each prompt runs in order, and later prompts can build on the validated output of earlier prompts.
Promptbooks support repeatability
They reduce the need to rewrite common investigation prompts for every analyst and every incident.
Promptbooks are not autonomous agents
Promptbooks follow a defined sequence when a user runs them, while agents can operate using configured logic, permissions and triggers.
Promptbooks are not Sentinel playbooks
Microsoft Sentinel playbooks are Azure Logic Apps workflows for orchestration and response automation.
Define one clear outcome
A promptbook should solve a specific problem rather than attempt every possible security task.
Name the promptbook clearly
Use a title that describes the scenario, product and expected outcome.
Define the intended audience
Identify whether the promptbook supports Tier 1 analysts, investigators, hunters, engineers or incident commanders.
Define required inputs
Specify incident IDs, user accounts, device IDs, message IDs, scripts, indicators or resource IDs.
Use immutable identifiers
Prefer stable IDs over names wherever the connected product supports them.
Define required products
List Defender XDR, Sentinel, Entra, Defender for Cloud, Purview or other sources needed.
Define required plugins
The promptbook can only use plugins that are available, enabled and permitted for the user.
Define required permissions
Users need Security Copilot access and permission to the underlying security data.
Define the expected output
State whether the result should be a timeline, summary, table, checklist, decision record or handover.
Define evidence requirements
Require source citations, raw records, entity IDs and timestamps for material claims.
Define confidence labels
Use consistent labels such as confirmed, probable, possible and unsupported.
Define uncertainty
Require the promptbook to identify missing data, unsupported assumptions and conflicting evidence.
Define review gates
Insert analyst validation before one prompt’s output is reused as the basis for the next.
Start with orientation
The first prompt should establish incident context, affected entities, available sources and known gaps.
Separate orientation from verdict
Do not ask the first prompt to declare compromise before evidence has been gathered.
Use prompt decomposition
Break complex investigations into smaller prompts with one clear objective each.
Use logical sequencing
Order prompts so that entity and source validation occurs before deep analysis and recommendations.
Use structured outputs
Tables, numbered findings and fixed headings make downstream prompts easier to interpret.
Reference earlier output carefully
Later prompts should refer only to validated facts from earlier stages.
Avoid compounding errors
An unsupported conclusion in an early prompt can contaminate the entire sequence.
Require source attribution
Each major result should identify the plugin, product, table, alert or entity page supporting it.
Require alternative explanations
Ask for benign administrative, deployment, user and operational possibilities.
Require missing-evidence review
Ask which logs, connectors, products or time periods are absent.
Require a final validation stage
The last prompt should compare the complete output with the original evidence and list unresolved questions.
Use explicit time ranges
State exact dates, times and time zones rather than vague expressions.
Use exact environment context
Identify tenant, workspace, subscription, device group or business unit.
Use exact entity context
Provide users, devices, messages, resources and indicators with stable identifiers.
Use output constraints
Set length, headings, table columns and evidence requirements.
Use exclusions carefully
Document approved scanners, service accounts, management tools and test systems.
Phishing promptbook
A phishing promptbook can summarise the message, validate authentication, analyse URLs and attachments, review clicks and search related recipients.
Phishing input
Use Network Message ID, recipient, sender, delivery time and relevant incident ID.
Phishing orientation prompt
Confirm delivery status, sender identity, authentication and affected recipients.
Phishing enrichment prompt
Enrich domains, URLs, attachment hashes and sender infrastructure.
Phishing interaction prompt
Check Safe Links, click activity, attachment execution and endpoint evidence.
Phishing scope prompt
Search for related messages, recipients, devices and user activity.
Phishing response prompt
Recommend purge, block, user containment and monitoring only after validation.
Compromised-account promptbook
An identity promptbook can review sign-ins, MFA, tokens, privilege changes, mailbox activity and affected devices.
Identity input
Use AccountObjectId, UPN, incident ID, time range and known DeviceIds.
Identity orientation prompt
Summarise risky activity, account role, business criticality and current sessions.
Identity authentication prompt
Review sign-ins, MFA outcomes, devices, IP addresses and applications.
Identity persistence prompt
Review token activity, inbox rules, OAuth consent, service principals and authentication-method changes.
Identity scope prompt
Search other users, applications, mailboxes and devices connected to the activity.
Identity response prompt
Recommend password reset, token revocation, account disablement or monitoring based on confirmed evidence.
Endpoint-alert promptbook
An endpoint promptbook can review the device, alert, process tree, files, persistence and network activity.
Endpoint input
Use DeviceId, AlertId, IncidentId, process ID, hash and time range.
Endpoint orientation prompt
Summarise device ownership, OS, risk, exposure, alerts and active investigation state.
Endpoint process prompt
Analyse parent and child processes, command lines, users and integrity context.
Endpoint persistence prompt
Review services, tasks, registry, startup mechanisms and exclusions.
Endpoint network prompt
Connect destinations with processes, users and observed timestamps.
Endpoint response prompt
Recommend isolation, quarantine, blocking or live response only after scope and impact review.
OAuth-abuse promptbook
An OAuth promptbook can investigate app identity, publisher, permissions, consent, users, tokens and activity.
OAuth input
Use ApplicationId, ServicePrincipalId, tenant, consent event and affected user IDs.
OAuth orientation prompt
Summarise publisher verification, ownership, permissions, consent type and affected users.
OAuth activity prompt
Review Graph, mailbox, SharePoint, Teams and other cloud activity associated with the app.
OAuth scope prompt
Identify additional users, tenants, grants, credentials and service principals.
OAuth response prompt
Recommend consent revocation, credential removal, app disablement or monitoring using approved criteria.
Cloud-incident promptbook
A cloud promptbook can investigate resources, alerts, attack paths, permissions and activity.
Cloud input
Use full resource ID, subscription, tenant, alert ID and investigation window.
Cloud orientation prompt
Summarise resource owner, workload, region, exposure, recommendations and alerts.
Cloud identity prompt
Review identities, role assignments, managed identities, applications and permissions.
Cloud activity prompt
Review control-plane and available data-plane events around the incident.
Cloud scope prompt
Search related resources, subscriptions, identities and external connections.
Cloud response prompt
Recommend remediation while considering availability, ownership and change control.
Threat-hunting promptbook
A hunting promptbook can structure hypothesis creation, query generation, result review, pivots and closure.
Hunting hypothesis prompt
Define what should confirm, weaken or disprove the suspected behaviour.
Hunting query prompt
Generate focused Defender XDR or Sentinel KQL using validated schemas.
Hunting interpretation prompt
Explain returned events, confidence, alternatives and missing telemetry.
Hunting pivot prompt
Identify the next user, device, file, domain, IP or resource to investigate.
Hunting closure prompt
Document confirmed findings, negative results, visibility gaps and escalation criteria.
Malware-analysis promptbook
A malware promptbook can combine file identity, script analysis, process evidence, sandbox results and internal prevalence.
Executive-summary promptbook
A reporting promptbook can translate validated technical findings into a concise business-facing summary.
Shift-handover promptbook
A handover promptbook can capture current status, completed actions, evidence, open questions, owners and next steps.
Testing promptbooks
Run promptbooks against known incidents, benign cases and edge conditions before wider use.
Validate every stage
Check source context, entity IDs, timestamps, query logic and returned evidence.
Test permission failures
Confirm how the promptbook behaves when a user cannot access a plugin or underlying product.
Test missing data
Ensure the promptbook identifies absent connectors, empty tables and retention limits.
Test conflicting evidence
The promptbook should preserve contradictions rather than force a single narrative.
Test false positives
Use approved administrative and software-deployment examples to assess noise.
Test performance
Review execution time, prompt count, capacity use and unnecessary duplication.
Publish carefully
Share promptbooks only after technical, operational and governance review.
Assign an owner
Every production promptbook needs an accountable owner and backup owner.
Use version control
Record version, date, author, changes, approvals and retirement status.
Set a review cycle
Reassess promptbooks after platform updates, incidents, schema changes and policy changes.
Monitor usage
Review whether promptbooks are used, where they fail and whether outputs improve investigations.
Measure quality, not volume
Prompt count and execution count do not prove better security outcomes.
Record analyst overrides
Document when analysts reject, modify or bypass promptbook recommendations.
Retire obsolete promptbooks
Archive workflows that rely on retired products, tables, plugins or procedures.
Protect sensitive data
Promptbook inputs and outputs can contain personal, confidential, customer or regulated information.
Respect data permissions
Promptbooks do not grant access to data users could not otherwise retrieve.
Audit usage
Use organisational logging and Microsoft audit capabilities to review relevant Security Copilot activity.
Final analyst accountability
Promptbooks create consistency, but analysts remain responsible for validating evidence and approving conclusions.
Example SOC promptbook design
Input:
AccountObjectId, UPN, IncidentId, start time, end time and known DeviceIds
Prompt 1 — Orientation:
Confirm the account, tenant, role, business context, current risk and available evidence sources.
Prompt 2 — Authentication:
Review sign-ins, MFA, devices, IP addresses, applications and session activity.
Prompt 3 — Persistence and impact:
Review authentication-method changes, OAuth consent, inbox rules, privilege changes and cloud activity.
Prompt 4 — Scope:
Search related users, devices, mailboxes, applications and indicators.
Prompt 5 — Validation:
Separate confirmed, probable, possible and unsupported findings with source citations and missing telemetry.
Prompt 6 — Response and reporting:
Recommend approved containment options and produce technical and executive summaries.
Analyst gate:
Do not run Prompt 6 until the source evidence and affected scope from Prompts 1–5 have been validated.
Agent Foskett investigation: “The new analyst”
↓
The initial investigation took almost four hours
↓
The analyst repeated searches and missed one related recipient
↓
The SOC introduced a reviewed phishing promptbook
↓
The first prompt confirmed message identity and delivery
↓
The second enriched the sender, URLs and attachment
↓
The third checked clicks, endpoint activity and related recipients
↓
The fourth built the validated timeline
↓
The fifth produced response options and the handover summary
↓
Every stage required source evidence
↓
The same analyst used the promptbook on the next incident
↓
The investigation finished in just over an hour
↓
No important evidence was missed
↓
The promptbook had not made the analyst more experienced
↓
It had made the investigation more consistent
SOC promptbook validation checklist
| Area | Question | Validation action |
|---|---|---|
| Purpose | Does the promptbook solve one clear scenario? | Define trigger, audience and outcome. |
| Inputs | Are required entities and identifiers explicit? | Use stable IDs and exact time ranges. |
| Sequence | Does each prompt have one clear job? | Review order and dependencies. |
| Sources | Are plugins and evidence requirements defined? | Require citations and original records. |
| Validation | Can an early error contaminate later prompts? | Add analyst review gates. |
| Permissions | Can intended users access required data? | Test product and plugin access. |
| Privacy | Could inputs or outputs expose sensitive information? | Apply handling and sharing controls. |
| Testing | Has it handled malicious, benign and incomplete cases? | Run controlled scenarios. |
| Ownership | Is an accountable owner assigned? | Record owner, backup and approvals. |
| Lifecycle | Is version, review date and retirement status recorded? | Maintain a promptbook register. |
Key takeaways
- Security Copilot promptbooks contain one or more prompts that work together to complete a security task.
- Prompts run sequentially, allowing later prompts to build on earlier responses.
- Custom promptbooks can standardise repetitive investigation workflows and can be shared with other users.
- Promptbooks differ from autonomous Security Copilot agents and Microsoft Sentinel Logic Apps playbooks.
- Inputs, outputs, plugins, permissions and evidence requirements should be explicit.
- Validation gates prevent unsupported early conclusions from propagating through the sequence.
- Scenario-specific promptbooks are stronger than one oversized universal workflow.
- Testing should include malicious, benign, incomplete and permission-limited cases.
- Owners should version, measure, review and retire promptbooks throughout their lifecycle.
- The analyst remains accountable for every conclusion and operational decision.
What Agent Foskett standardised
- Message identity
- Sender validation
- URL enrichment
- Attachment analysis
- User interaction
- Endpoint evidence
- Related recipients
- Timeline
- Response options
- Shift handover
Best practices
- Choose one scenario.
- Use stable inputs.
- Keep prompts focused.
- Require source evidence.
- Add analyst gates.
- Test missing data.
- Limit sharing.
- Assign ownership.
- Version changes.
- Keep judgement human.
Related Agent Foskett resources
Continue Module 4 — Operational Security Copilot
How do you build custom promptbooks in Microsoft Security Copilot?
Custom Security Copilot promptbooks combine sequential prompts into reusable workflows for defined security tasks such as phishing, identity compromise, endpoint alerts and threat hunting.
Security Copilot SOC promptbooks
SOC promptbooks should define inputs, expected outputs, plugins, permissions, evidence requirements, validation gates, ownership and lifecycle controls.
Promptbooks versus agents and Sentinel playbooks
Security Copilot promptbooks run a defined prompt sequence, autonomous agents operate within configured logic and triggers, and Microsoft Sentinel playbooks use Azure Logic Apps for orchestration and response.
