Study guide
SOAR, Playbooks, and Automation
CompTIA Security+ SY0-701
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook
2 Domain 1: General Security Concepts (12%)
CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact
3 Domain 1: Identity, Trust, and Cryptography Basics
AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules
4 Domain 2: Threat Actors, Vectors, and Social Engineering
Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios
5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks
Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping
6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities
Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions
7 Domain 3: Security Architecture - Secure Architecture Models
Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios
8 Domain 3: Security Architecture - Network Security Architecture
Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design
9 Domain 3 Part C: Data Protection and Resilience
Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience
10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT
Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security
11 IAM Operations and Access Control
Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring
12 Logging, Monitoring, and Detection
Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling
13 Incident Response
IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics
14 Digital Forensics and Investigation
Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps
15 Vulnerability, Patch, Asset, and Automation Operations
Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling
16 Governance, Policies, and Risk Management
Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting
17 Third-Party Risk, Compliance, and Privacy
Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences
18 Audits, Penetration Testing, and Awareness
Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls
19 Final Review and PBQ Labs
PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation
SOAR, Playbooks, and Automation
Key Takeaways Explain This Topic AI
SOAR platforms orchestrate security workflows across tools, automate repeatable actions, and coordinate the response.
Playbooks define the steps for common alert types such as phishing, malware, or account compromise.
Automation should be scoped to impact: low-risk actions can run automatically, high-impact actions need human approval.
Approval gates protect against disrupting executives, customers, or critical infrastructure with automated containment.
Strong playbooks include triggers, enrichment, decision points, actions, evidence capture, rollback, and escalation paths.
Last updated: June 2026
Breaking Down the SOAR Acronym
Security Orchestration, Automation, and Response (SOAR) helps a security operations center (SOC) handle repeatable workflows at machine speed. The exam wants you to separate the three words precisely:
Orchestration connects disparate tools (SIEM, EDR, email gateway, firewall, ticketing) so they pass data to one another through a single workflow.
Automation executes predefined actions — query a hash, search mailboxes, disable an account — without a human typing each command.
Response is the coordinated end-to-end process that drives an alert toward containment, recovery, or closure.
A closely related term is runbook vs. playbook : a runbook is the low-level, often automated technical procedure (the exact API calls), while a playbook is the higher-level, decision-oriented workflow that may invoke several runbooks and human checkpoints. The exam may also pair SOAR with scripting — short scripts (PowerShell, Python, Bash) that automate a single repetitive task such as pulling indicators from a ticket or resetting a password. SOAR is essentially scripting plus orchestration, state tracking, and an audit trail wrapped around a multi-step workflow.
Anatomy of a Playbook
- Playbook element Example
- Trigger SIEM alert for a suspected phishing message
- Enrichment Sender reputation, URL detonation, recipient list, attachment hash
Decision point Was the URL malicious or newly registered?
- Automated action Search all mailboxes for the matching message
- Approval gate Analyst sign-off before deleting messages org-wide
- Evidence capture Store headers, URLs, hashes, screenshots, actions taken
- Escalation Open an incident if any user entered credentials
- Scenario: A Phishing Playbook in Action
An employee reports a message claiming to be from the benefits portal. The SOAR platform parses the headers, extracts URLs, checks the sender domain's age, detonates the URL in a sandbox, searches every mailbox for the same message, and asks an analyst to approve quarantine. 2026-06-14T16:30:01Z soar playbook=phishing_report case=CASE-221 trigger=user_report reporter=ngarcia
2026-06-14T16:30:07Z soar action=parse_headers result=success sender=benefits-update-example.com
2026-06-14T16:30:20Z soar action=url_reputation url=hxxps://benefits-update-example.com/login result=suspicious domain_age=2d
- 2026-06-14T16:31:05Z soar action=mailbox_search matches=38 result=success
- 2026-06-14T16:32:10Z soar action=quarantine_messages matches=38 approval=analyst result=success
- 2026-06-14T16:33:22Z soar action=create_ticket ticket=IR-5591 reason="two users clicked the URL"
This is a strong playbook because it gathers evidence first , scopes the incident (38 copies), contains the threat (quarantine), and escalates only when there is a clicked-link indicator of compromise.
Matching Automation to Risk
- Level Description Example
- Manual Analyst performs each action Analyst checks the URL and removes messages by hand
Semi-automated Tool gathers evidence; analyst approves the impactful step SOAR searches mailboxes, then asks before quarantine
Fully automated Tool acts the moment conditions are met Auto-block a confirmed-malicious file hash at the EDR
The guiding rule: automation should match blast radius. Blocking a known-bad hash on endpoints is low-risk and safe to fully automate. Disabling an executive's account, deleting mail from every user, or null-routing a large IP range can cause real business disruption and therefore belongs behind an approval gate. Performance-based questions love to ask you to place actions into the correct automation tier.
Designing Playbooks That Hold Up
A durable playbook is specific enough to guide action yet flexible enough to permit analyst judgment. It should:
Capture evidence before any destructive action.
Log every automated step for an audit trail.
Include rollback or exception handling (for example, restore quarantined mail if it proves legitimate).
Define clear escalation criteria to incident response.
Be revised after each lessons-learned review so it reflects real attacks.
Why Organizations Adopt SOAR
The business case rests on three measurable wins the exam associates with automation. First, speed : a playbook executes enrichment and containment in seconds, sharply lowering the mean time to detect and respond. Second, consistency : every phishing report is handled the same way, eliminating the variance of a tired analyst at 3 a.m. skipping a step. Third, scale and analyst leverage : automating tier-1 toil frees scarce human expertise for the genuinely ambiguous cases that need judgment. CompTIA frames these as the core benefits of automation and scripting in security operations.
Automation Pitfalls to Recognize
Automation also introduces failure modes the exam tests. Complexity grows as playbooks chain together, making them hard to debug. Brittleness appears when an upstream tool changes an API field and a silent playbook stops acting. Single point of failure risk arises if the SOAR platform itself goes down or is compromised, since it holds privileged credentials to many tools. And technical debt accumulates when playbooks are written once and never revised against new attacker behavior.
Common Traps
Automating containment without understanding the business impact.
Writing playbooks that only notify people but never collect evidence.
Failing to update playbooks after a lessons-learned debrief.
Letting automation delete the very evidence an investigation needs.
Granting the SOAR platform broad standing privileges without protecting it as a high-value, single-point-of-failure asset.
Treating SOAR as a substitute for trained analysts and tested procedures, rather than a force multiplier for them.