Change Management and Business Impact

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

Change Management and Business Impact

Key Takeaways Explain This Topic AI

Change management reduces the risk that IT or security changes cause outages, untracked exceptions, or new exposure.

Business impact analysis ties technical failures to mission impact, downtime tolerance, and recovery objectives.

Emergency changes still require documentation, approval, testing when feasible, and after-action review.

RTO is time to restore service; RPO is acceptable data loss in time; MTTD is time to detect; MTTR is time to recover.

Technical change topics on SY0-701 include allow/deny lists, restarts, dependencies, downtime windows, and updating documentation/diagrams.

Last updated: June 2026

Why Change Management Is a Security Topic

Many incidents begin as ordinary changes: a rushed firewall exception, an untested patch, a disabled control, a misconfigured cloud bucket, or a temporary account that never expires. SY0-701 objective 1.3 makes change management a security control because uncontrolled change is one of the most common root causes in incident reports. Structured change ensures risk is understood before production is modified.

Change element Security value
Request Records what is changing and why
Risk assessment Identifies outage, exposure, compliance, and data risks
Approval (CAB) Confirms accountability and business acceptance
Testing Finds errors before production impact
Implementation/maintenance window Reduces disruption and coordinates stakeholders
Backout / rollback plan Defines how to recover if the change fails
Validation Confirms the change worked and created no new exposure
Documentation Updates diagrams, configs, and evidence for audit

SY0-701 also lists technical implications candidates must recognize: allow lists and deny lists , service or system restarts , dependencies between systems, scheduled downtime , and legacy application constraints. Forgetting to update network diagrams and policies after a change is an explicit testable gap.

Dependencies are a frequent exam theme because a change to one system can silently break another. Restarting an authentication server, for instance, may log out every dependent application; changing a firewall deny list may sever a partner data feed that nobody documented. The change process surfaces these dependencies during the risk-assessment step, which is exactly why skipping risk assessment is so dangerous.

Allow lists and deny lists also appear in change scenarios: an allow list (default-deny) is the more secure posture because only explicitly approved items run, whereas a deny list (default-allow) blocks only known-bad items and silently permits everything else, including new threats.

Standard, Normal, and Emergency Changes

Change type Example Expected handling
Standard Monthly patch already tested and pre-approved Follow the preapproved procedure; record completion
Normal New firewall rule for a business app Risk review, CAB approval, test, implement, validate, document

Emergency Critical exploited flaw on an Internet-facing system Compressed approval, immediate action, then documentation and post-change review

Emergency does not mean undocumented. It means approval and timing are compressed because the risk of waiting exceeds the risk of acting. The paperwork and review still happen — just after the fire is out.

Business Impact Analysis Metrics

Term Meaning Example

BIA Identifies critical processes and the impact of disruption Ranking payroll, portal, and wiki recovery order

RTO Recovery time objective — max tolerable time to restore "Portal must be back within 4 hours"
RPO Recovery point objective — max tolerable data loss in time "No more than 15 minutes of orders may be lost"
MTTD Mean time to detect How fast monitoring spots a problem
MTTR Mean time to repair/recover How fast service is restored
MTBF Mean time between failures Reliability of a repairable component

The single most common confusion is RTO vs. RPO. RTO points forward (how long until we are back); RPO points backward (how much data, measured in time, can we afford to lose). A 15-minute RPO drives backup frequency; a 4-hour RTO drives failover and restore design.

Worked Scenario: Patch or Wait?

A vendor announces active exploitation of an Internet-facing VPN appliance. A patch exists, but applying it interrupts remote access for ~15 minutes during business hours.

Consideration Security reasoning
Exposure Internet-facing and actively exploited raises urgency
Asset criticality The VPN gates access to internal systems
Business impact A 15-minute interruption beats a breach
Change path Use the emergency process: notify, patch, validate, document
Rollback Know how to restore service if the patch fails

The wrong answers are predictable: "wait for the next quarterly window" (ignores active exploitation) and "patch silently with no record" (skips accountability and validation). The exam-correct answer routes through the emergency change process with stakeholder notice and a post-change review.

Change Management Traps

Trap Better choice

Production change with no approval "because it's security" Use the normal or emergency approval path by urgency

Permanently disabling a control to fix a user problem Use a temporary exception with owner, expiration, compensating control, and review

Patching without validation Confirm version, service health, logs, and control state
Treating all systems equally Prioritize by criticality, exposure, exploitability, and impact
Confusing RTO and RPO RTO = time to restore; RPO = acceptable data-loss window
Practical Exam Rule

When a scenario weighs business impact, the best answer reduces risk while preserving accountability. Look for the option that includes approval, evidence, rollback, validation, stakeholder notice, and risk-based prioritization — and reject any option that trades all process away for speed or all speed away for process.