Risk Register and Risk Treatment

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

Risk Register and Risk Treatment

Key Takeaways Explain This Topic AI

A risk register tracks identified risks, owners, likelihood, impact, treatment decisions, status, and residual risk.

The four risk treatment options are mitigate, transfer, avoid, and accept.

Risk ownership should be assigned to an accountable business or system owner, not a generic team.

Residual risk is what remains after controls; risk appetite and risk tolerance set the threshold for what is acceptable.

Risk decisions should include evidence, review dates, KRIs, and escalation when they exceed risk appetite.

Last updated: June 2026

What a Risk Register Is

A risk register is a structured, living record of risks the organization has identified and is tracking. It lets leaders see which risks exist, who owns them, how severe they are, what treatment was chosen, and whether the residual risk is acceptable. On SY0-701 the register appears in scenario items that ask you to pick the right treatment, identify a missing field, or decide who is allowed to accept a risk.

The register is the bridge between technical findings and business decisions: a vulnerability scanner produces thousands of tickets, but only the items that rise to enterprise significance are promoted into the register where they get an owner, a dollar or qualitative rating, and a tracked decision. This is also where inherent risk (before any control) is distinguished from residual risk (after controls), a distinction the exam tests directly.

Risk Register Fields

• Field Purpose
• Risk ID Unique tracking reference
• Risk statement Threat + vulnerability + asset + impact in one sentence
• Owner Accountable person or role
• Likelihood Estimated chance of occurrence
• Impact Estimated business harm
• Inherent risk Risk before any treatment
• Treatment Mitigate, transfer, avoid, or accept
• Control plan Actions that reduce likelihood or impact
• Residual risk Risk remaining after treatment
• KRI Key Risk Indicator that signals the risk is rising
• Review date When the decision must be revisited
• Status Open, in progress, accepted, closed, or overdue
• The Four Risk Treatment Options

This is the single most-tested concept in the section. Memorize all four and the verb that signals each.

• Treatment Meaning Signal verb / example
• Mitigate Reduce likelihood or impact with controls Patch, add MFA, deploy a WAF, segment the network

Transfer Shift financial or operational impact to a third party Buy cyber insurance; outsource under contract terms

Avoid Stop the activity that creates the risk Retire or never deploy an unsupported internet-facing app

Accept Formally acknowledge residual risk without further treatment An authorized owner signs off on low residual risk

A fifth phrase you may see is risk exception or deterrence , but CompTIA's core four are mitigate, transfer, avoid, accept. Note that transfer does not remove accountability – insurance reduces financial exposure but the organization still owns due diligence, breach notification, and reputation.

Appetite, Tolerance, and Thresholds

Risk appetite is the broad amount and type of risk an organization is willing to pursue in pursuit of its objectives (CompTIA describes it as expansionary, conservative, or neutral). Risk tolerance is the acceptable variation around a specific risk or objective – the band within which a measured risk can move before action is required. A Key Risk Indicator (KRI) is a metric that signals a risk is approaching or crossing tolerance, such as a climbing count of failed logins or unpatched critical findings.

When residual risk exceeds the defined appetite, the correct action is to escalate to leadership with authority to accept it, not to accept it locally. Appetite is set by senior leadership and the board; it is not something an operator or analyst is empowered to override, which is why the "who can accept" question is a recurring exam theme.

Worked Risk Register Entry

• Field Entry
• Risk ID R-2026-041

Risk statement Customer portal uses an unsupported library that could allow unauthorized access to confidential profile data

• Owner Director of Digital Services
• Likelihood High
• Impact High
• Inherent risk Critical
• Treatment Mitigate
• Plan Upgrade library, add WAF rule during change window, raise monitoring
• Residual risk Medium until upgrade completes, low after verification
• KRI Count of failed auth attempts on the legacy endpoint
• Review date 2026-05-15
• Status In progress

The entry creates accountability: it is clear who owns the risk, why it matters, which treatment was selected, what indicator is being watched, and when the decision is reviewed.

Decision Rules

• Situation Likely treatment
• Vulnerable public system can be patched Mitigate
• Commodity service has strong vendor controls and contract protections Transfer part of the risk
• Legacy application creates high risk and no business value Avoid by retiring it
• Low risk remains after controls and is within appetite Accept with owner approval
• Risk exceeds appetite Escalate, do not accept locally
• Common Traps

Recording risks without named owners.

Confusing formal risk acceptance with informally doing nothing.

Treating transfer as a way to erase all accountability.

Leaving accepted risks with no expiration or review date.

Logging vulnerabilities as isolated tickets without linking major items to the register.

Exam Focus

Lock in the four treatments: mitigate, transfer, avoid, accept . In a scenario, match the action to the verb – patching/controls equals mitigate, insurance/contracts equals transfer, stopping the activity equals avoid, signed sign-off equals accept. If a question says the residual risk is above the organization's risk appetite, the best answer is to escalate rather than to accept it at the team level.