Security+ Exam Domains and Topics

The Security+ blueprint is a map of the knowledge and tasks the exam can assess. The official SY0-701 Version 6.0 objectives divide that work into five weighted domains. The percentages describe relative emphasis in the exam outline. They do not reveal the exact item count on an individual form, guarantee a particular question for each task, or provide a formula for a passing score.

Security Operations carries the greatest weight, but it is not a standalone exam. A response decision may rely on architecture, a risk assessment, or governance authority. A candidate who studies technical procedures without learning who owns risk or why a control is required may struggle with mixed scenarios. The domains create structure for study; real security decisions cross their boundaries.

Domain 1: General Security Concepts

This domain supplies the language for security decisions. Understand confidentiality, integrity, and availability; authentication and authorization; least privilege; separation of duties; defense in depth; and the difference between preventive, detective, corrective, deterrent, and compensating controls. A control's label matters less than its purpose and limitations. Logging can detect or support investigation; it does not automatically prevent the underlying activity.

Cryptographic concepts belong here as well. Encryption protects information from being read by an unauthorized party when data is stored or transmitted, provided keys are protected. Hashing produces a digest used for integrity checks and other security purposes; it is not reversible decryption. Digital signatures can support integrity and origin verification. Candidates should understand the role of keys, certificates, and secure protocols without assuming that cryptography alone solves identity or access problems.

Example: a company encrypts a laptop, but an employee shares a valid account password with a colleague. Encryption protects data if the laptop is lost while powered off, but it does not prevent an authorized session from exposing files. The access risk calls for identity controls, individual accounts, least privilege, and appropriate monitoring. The scenario tests whether you match the control to the threat rather than selecting encryption whenever data is mentioned.

Domain 2: Threats, Vulnerabilities, and Mitigations

This domain asks candidates to recognize who may attack a system, how the attack could work, what evidence it leaves, and how to reduce the risk. Study threat actors and motivations, social engineering, malware, credential attacks, exploitation, misconfiguration, and vulnerability management. Learn the difference between a vulnerability, a threat, an exploit, and risk. A weakness is not automatically an incident, but exposure and exploitability can make it urgent.

Mitigation is contextual. A phishing campaign may call for blocking known malicious infrastructure, disabling a compromised account, preserving email evidence, and communicating with users. A vulnerable internet-facing service may require patching or temporarily restricting exposure after evaluating business impact. A vulnerability scanner's severity label is one input, not a complete prioritization decision. Asset value, accessibility, available exploits, and compensating controls matter.

Example: two findings are reported. A critical issue is on an isolated test system containing no sensitive data; a high-severity issue is on a public service that processes customer records. The best first remediation decision should consider exposure and consequence, not merely sort by the severity label. Document the rationale, assign an owner, and verify the fix.

Domain 3: Security Architecture

Architecture is about building systems and environments so that security properties are supported by design. Topics include secure network design, segmentation, zero-trust principles, cloud and hybrid environments, secure configurations, resilience, data protection, and application security. Understand where a control operates and which component owns it. A design that depends on one perimeter firewall can fail when users, services, and data are distributed across networks and cloud platforms.

Segmentation limits paths between systems and can reduce lateral movement. A secure baseline reduces unnecessary services and settings. Resilience design addresses how essential services continue or recover after failure. Backups and high availability solve different problems: redundancy can keep a service running, while a backup supports restoration of data or configuration. Both require testing and access protection.

Cloud responsibility is shared between the provider and customer, with the division changing by service model. A provider may secure physical infrastructure while the customer manages identities, data, and configuration. Do not conclude that a service is secure simply because it runs in a provider environment. Identify who configures each control and what evidence demonstrates the configuration.

Example: a team moves a database to a managed cloud service. The service provider operates the underlying infrastructure, but the customer still needs to configure access, protect keys, limit network exposure, monitor activity, classify data, and test backups. A design question is asking for control placement and ownership, not a generic statement that cloud is secure or insecure.

Domain 4: Security Operations

Security Operations is the largest domain at 28%. It covers work that protects and monitors systems day to day: identity and access, endpoint controls, logging, detection, vulnerability management, change management, incident response, and recovery. Learn processes, not only tools. A security information and event management platform can correlate logs, but people still tune alerts, investigate context, decide severity, and coordinate response.

Identity lifecycle starts when an account is requested and continues through changes, reviews, and removal. Strong authentication helps prove a user's identity, while authorization restricts actions. Privileged access should be controlled and reviewed. A departing employee's account should be disabled promptly, and service accounts should have defined ownership and scope.

Incident response is a sequence of preparation, detection and analysis, containment, eradication, recovery, and lessons learned. The exact best action depends on the scenario's objective. Preserve useful evidence, restrict ongoing harm, remove the cause, restore systems safely, and improve controls based on what happened. A candidate should distinguish immediate containment from long-term architecture work.

Example: alerts indicate a server is communicating with a suspected command-and-control address. The analyst should validate the alert and scope, contain the affected host if warranted, retain relevant logs, and coordinate the response. Immediately wiping the host may destroy evidence; leaving it connected may allow continued harm. The best answer accounts for both urgency and investigation needs.

Domain 5: Security Program Management and Oversight

This domain connects security work to organizational authority and accountability. Learn governance structures, policies and standards, risk assessment, risk response, awareness, third-party management, audits, and compliance concepts. A policy states the organization's requirement; a standard makes it measurable; a procedure describes repeatable steps. A risk owner decides whether to accept residual risk, while security teams can advise and implement controls.

Risk is not just a technical severity score. Consider likelihood, impact, asset importance, legal or contractual duties, and existing controls. Risk treatment can include mitigation, transfer, avoidance, or acceptance. Acceptance should be an explicit decision by the appropriate owner and may need a review date. Compliance demonstrates alignment with specified obligations, but passing an audit does not prove that all security risks are absent.

Third-party oversight begins before access is granted. Determine what data or systems a supplier will use, which controls the relationship requires, how evidence will be reviewed, and how access ends. A contract clause is not itself proof that a supplier's controls operate effectively. A program needs owners, monitoring, incident communication, and a plan for transition or termination.

Example: a supplier requests broad administrator access to troubleshoot a system. The organization should understand the task, limit access to what is needed, define a time boundary, log activity, and review the arrangement. A policy exception should have an accountable risk owner. Granting permanent broad access because it is convenient ignores least privilege and supplier oversight.

How domains connect in one scenario

Imagine that a staff member reports an unexpected multifactor prompt and a monitoring alert shows a login from an unfamiliar location. Domain 1 supplies identity and control concepts. Domain 2 helps identify credential theft and suspicious behavior. Domain 3 asks whether access segmentation limits the exposed account. Domain 4 guides account containment and investigation. Domain 5 determines incident escalation, risk ownership, and notification obligations. A question may focus on one best next action while relying on all five areas.

This is why memorizing domain labels has limited value. Learn to classify a prompt, then follow the relevant decision path. Is the issue a control design gap, an active event, a vulnerability, a governance exception, or some combination? Which action reduces risk now? Who owns the decision? What evidence will establish that the action worked?

Turn the outline into a study map

1. Copy the five domain names and weights into a tracker. Keep the official objective list beside them.
2. For every objective, write one plain-language explanation and one realistic example.
3. Mark each task as explain, apply, or troubleshoot. A definition alone may not be enough for scenario work.
4. Use short quizzes to find gaps, then use labs or case studies for skills involving logs, configuration, identity, and response sequence.
5. Revisit each domain in mixed practice so you can move between technical controls and governance decisions.

The percentages can help balance time. Security Operations gets the largest share, but no domain should receive zero study time. A candidate strong in system administration may shift effort toward governance and threat analysis. A candidate strong in policy may need practical work with identity, network design, and incident response. The objective list gives the detail; the weight helps set emphasis.

Original domain-mapping exercise

A small retailer stores customer records in a cloud service. An employee receives an unexpected login challenge, and a new administrator account appears. The retailer also has a supplier with support access. Identify one concern from each domain: the identity control problem; a likely threat or attack path; the architecture control that could constrain access; the operational actions to investigate and contain; and the governance or supplier decision needed after the event.

One sound answer is: review authentication and authorization; consider credential compromise or abuse of supplier credentials; verify segmentation and role boundaries; disable or restrict suspicious accounts, preserve logs, scope activity, and recover safely; notify the accountable risk owner and assess supplier obligations. Different details could change the sequence, but every domain contributes a useful lens.