Security+ SY0-701: Security Controls, CIA, AAA, and Zero Trust

Introduction

Security controls, the CIA triad, AAA, and zero trust provide a shared language for Security+ SY0-701 scenarios. This lesson opens Domain 1, General Security Concepts, which carries 12% of the scored content of CompTIA Security+ SY0-701. Objective 1.1 (compare and contrast various types of security controls), 1.2 (summarize fundamental security concepts) and 1.3 (explain the importance of change management processes and the impact to security) are the vocabulary of the whole exam. Every later domain, from incident response to governance, assumes that you can tell a preventive control from a detective one, explain what authentication adds that authorization does not, and recognize when a design follows zero trust.

Practise applying definitions to short scenarios: a company deploys a camera, a bank adds a second approval step, an engineer wants to patch a production server on a Friday afternoon. You must name the control type, the principle or the process that applies.

Learning objectives

After this lesson you will be able to:

• Classify any control by category (technical, managerial, operational, physical) and by type (preventive, deterrent, detective, corrective, compensating, directive).
• Explain confidentiality, integrity, availability and non-repudiation, and map a described failure to the right property.
• Distinguish authentication, authorization and accounting, and name the technologies that implement each.
• Describe the zero trust control plane and data plane, and the roles of the policy engine, policy administrator and policy enforcement point.
• Recognize deception technologies (honeypot, honeynet, honeyfile, honeytoken) and gap analysis.
• Walk a change request through approval, impact analysis, test, backout plan, maintenance window, and documentation.

1. Security controls

A security control is any safeguard that reduces risk. SY0-701 classifies controls along two independent axes. Mixing them up is the most common mistake on this objective.

1.1 Categories: who or what implements the control

Classify the function described, not whether equipment is tangible: a firewall appliance can be technical even though you can touch it. Ask "Does it protect physical premises?" (physical), "Does software or hardware enforce it automatically?" (technical), "Is it a decision or document that steers the program?" (managerial), "Is it a routine that humans carry out?" (operational).

1.2 Types: what the control does in the attack timeline

For an exam scenario, identify the category and the primary function being asked about. A real control can serve several purposes; its classification depends on the described implementation. A security guard is an operational control that is preventive (blocks entry) and deterrent. A camera is a physical control that is detective and deterrent. A firewall rule is technical and preventive; the firewall log review that spots abuse is detective.

Example 1: classifying a retail chain's controls

A retailer with 120 stores adds four measures after a theft of card readers: (1) tamper-evident seals on every payment terminal, (2) a policy requiring store managers to inspect terminals each morning, (3) cameras pointed at the checkout counters, (4) a signed policy stating that tampering leads to dismissal.

• Seals: physical, detective (tampering becomes visible) and deterrent.
• Morning inspection: operational, detective.
• Cameras: physical, detective and deterrent.
• Written policy: managerial, directive and deterrent.

Example 2: a compensating control

A hospital runs an MRI console on an unsupported Windows version that cannot be patched without voiding the vendor's certification. The security team cannot apply the preventive patch, so it places the console in an isolated VLAN, allows only the imaging server through a firewall rule, and disables USB ports. These measures are compensating controls: they reduce risk through alternative means. Assess their effectiveness and residual risk rather than assuming isolation is automatically equivalent to a patch. The exam typically phrases it as "the primary control cannot be implemented".

2. The CIA triad and non-repudiation

The triad is the lens for every security discussion.

• Confidentiality: only authorized parties can read the data. Supported by encryption, access control, data masking, and classification. Failure: a laptop with unencrypted patient records is stolen.
• Integrity: data and systems are accurate and unaltered by unauthorized parties. Supported by hashing, digital signatures, file integrity monitoring, and version control. Failure: an attacker modifies a payroll file so that account numbers change.
• Availability: authorized users can access resources when needed. Supported by redundancy, backups, load balancing, and DDoS protection. Failure: ransomware encrypts the order-management database.
• Non-repudiation: a party cannot credibly deny having performed an action. Supported by digital signatures and tamper-resistant audit logs, often combined with timestamps. Failure: an executive claims "I never approved that wire transfer" and nothing proves otherwise.

Note that SY0-701 lists non-repudiation next to the triad because signing and logging provide something hashing alone cannot: proof of who. A hash comparison detects a change only when the reference hash is trusted. A verified digital signature supports evidence of origin and integrity, provided the public key is correctly bound to the claimed signer and the private key has remained under that signer's control.

Example 3: mapping failures to properties

• A customer-service agent can view full credit card numbers when only the last four are needed: confidentiality.
• A web page defacement that replaces prices with zeros: integrity.
• A database server that is down for six hours because a single disk failed: availability.
• A supplier who denies having sent a purchase order that carries no signature: non-repudiation.

For the mechanisms behind integrity and origin evidence, continue with Security+ encryption, hashing, digital signatures, and certificates.

3. Authentication, authorization, and accounting (AAA)

AAA servers centralize the three functions. RADIUS and TACACS+ are the classic protocols: RADIUS (UDP, widely used for network access and Wi-Fi 802.1X) combines authentication and authorization, while TACACS+ (TCP, Cisco-originated) separates all three, which suits fine-grained device administration commands.

Authenticating people relies on factors: something you know, something you have, something you are. Location and behavioral signals can inform risk-based access decisions, but location is not an independent MFA factor. Behavioral biometrics may contribute to inherence when implemented as an appropriate authenticator. Using two different categories is true multifactor authentication; a password plus a security question is two "know" factors and is not.

Authenticating systems uses certificates, pre-shared keys, or device identity in a trusted platform module (TPM). Authorization models matter because the exam asks which one fits a scenario:

• Discretionary (DAC): the owner decides who has access, as with file sharing in a typical operating system.
• Mandatory (MAC): the system enforces labels such as Secret or Confidential; users cannot override it.
• Role-based (RBAC): permissions attach to job roles.
• Attribute-based (ABAC): decisions use attributes of user, resource and context, such as department, device compliance and time.
• Rule-based: access is driven by rules that apply to everyone, such as a firewall ACL or a "no login after 20:00" rule.

Worked example: choosing authentication and authorization controls step by step

Scenario. A regional bank gives call-center agents a web application. Requirements: only employees reach the app, agents see only the customers assigned to their region, supervisors can approve refunds above 500 euros, and the auditors must reconstruct who approved each refund.

1. Identify the three functions. Employees reaching the app is authentication. Region limits and the supervisor privilege are authorization. Reconstruction of approvals is accounting.
2. Authentication. Use single sign-on with the bank's identity provider and require MFA, since the application handles financial data. Something you know (password) plus something you have (authenticator app or hardware key).
3. Authorization. Roles alone say "agent" or "supervisor" but do not express the region. An attribute-based model, with the attribute region on both the user and the customer record, expresses the rule directly. The supervisor privilege can still be an RBAC role.
4. Accounting. Log each refund approval with user ID, timestamp and amount, and ship it to a central log store the agents cannot edit. Signatures, trusted timestamps, and protected logs can strengthen evidence of approval. Write-once storage protects the records from alteration; it does not by itself prove which human controlled an account.
5. Why other choices are weaker. A shared supervisor account fails accounting and non-repudiation because many people use the same identity. Pure RBAC with one role per region creates dozens of near-identical roles that are hard to maintain. Discretionary access lets each manager grant rights informally and breaks consistency.

4. Gap analysis

A gap analysis compares the current state of controls to a desired state, such as a framework, a regulation, or an internal target, and lists what is missing. It can be technical (which systems lack EDR) or business-focused (which ISO 27001 clauses have no evidence). The output is a prioritized remediation plan. On the exam, "compare the current security posture to a standard to find missing controls" is a gap analysis.

5. Zero trust

Traditional security trusted whatever sat inside the network perimeter. Zero trust assumes breach: no user, device or network location is trusted by default, and every access request is verified continuously against policy. The motto is "never trust, always verify".

5.1 Planes and components

SY0-701 describes two planes.

Control plane: decides.

• Adaptive identity: authentication strength adapts to context (a login from a new country triggers extra verification).
• Threat scope reduction: limit the blast radius by narrowing who and what can reach each resource.
• Policy-driven access control: policies, not network position, grant access.
• Policy administrator: establishes or removes the communication path to a resource, based on the policy engine's decision.
• Policy engine: evaluates the request using policy and signals such as identity, device health and threat intelligence, and grants, denies or revokes access.

Data plane: enforces and carries the traffic.

• Subject/system: the user or device requesting access.
• Policy enforcement point (PEP): the gateway or agent that allows or blocks the connection.
• Implicit trust zones: areas, such as the segment behind the PEP, where the connection is assumed trustworthy once approved; the goal is to keep them small.

The flow: a subject asks for a resource; the PEP forwards the request to the policy administrator; the policy engine decides; if allowed, the administrator configures the PEP to open the path.

Example 4: zero trust for a contractor

A consulting firm gives a contractor access to a project wiki. In the old model a VPN would place the contractor's laptop on the corporate network, exposing file servers and printers. In the zero trust model the contractor authenticates with MFA, the policy engine checks that the laptop has disk encryption and current EDR, and the PEP exposes only the wiki, for a limited session. If the EDR reports an infection mid-session and that signal is integrated into policy evaluation, the architecture can revoke the session; response time depends on signal delivery and enforcement. This is adaptive, least-privilege and continuous.

6. Physical security

Though listed with security concepts, physical controls often appear in scenarios.

7. Deception and disruption technology

These tools detect attackers by offering bait.

Unexpected interaction is a high-value signal, but approved scanners, backup jobs, or users can also touch decoys. Investigate the actor and context before declaring an intrusion. They are detective controls and give security teams intelligence on techniques.

8. Change management and its security impact

Uncontrolled change causes outages and opens vulnerabilities. A formal change management process answers: who requested what, why, what could go wrong, who approved it, and how do we undo it.

Business processes impacted by change

• Approval process: a change advisory board or an authorized manager signs off. Emergency changes follow the defined expedited authorization route, with required records and a retrospective review. Urgency is not blanket permission to bypass all approval.
• Ownership: each asset or service has an owner accountable for approving changes.
• Stakeholders: affected teams are informed (application owners, service desk, customers).
• Impact analysis: what systems, data, compliance obligations and users are touched, and what is the risk if the change fails.
• Test results: evidence from a non-production environment that the change works.
• Backout plan: the tested steps to return to the previous state.
• Maintenance window: an agreed time with minimal business impact.
• Standard operating procedure (SOP): the documented steps for pre-approved routine changes.

Technical implications

• Allow lists and deny lists: a firewall or application control change can block critical traffic.
• Restricted activities: during the change, certain actions are limited.
• Downtime: planned service interruptions.
• Service and application restarts, legacy applications that may not tolerate the change, and dependencies that fail in sequence.

Documentation and version control

Update diagrams, configuration inventories, policies and procedures after changes. Version control (for code, infrastructure definitions and configuration) records every revision with author and timestamp, supports review, and allows rollback.

Worked example: a Friday firewall change

Scenario. An administrator wants to replace a firewall rule allowing the whole 10.0.0.0/8 range to the database tier with a rule allowing only the application subnet 10.20.5.0/24. It is Friday at 15:00 and the company ships orders until 18:00.

1. Request and impact analysis: identify which systems currently use the broad rule. The analysis finds that a reporting server in 10.30.1.0/24 also queries the database.
2. Test: apply the new rule in the staging environment and run the reporting job; it fails, confirming the dependency.
3. Design adjustment: add an explicit rule for the reporting server.
4. Approval: the change advisory board approves with the amended rule list.
5. Backout plan: keep the old rule disabled but not deleted, with a script to re-enable it.
6. Schedule: choose the Sunday 02:00 maintenance window rather than Friday afternoon.
7. Implement, verify, document: apply, run smoke tests, update the network diagram and the ticket, and commit the firewall configuration to version control.

Skipping steps 1 to 3 would have broken reporting; skipping step 5 would have lengthened the outage; changing at peak time would have magnified the impact.

Comparison: commonly confused pairs

Common pitfalls

• Treating category and type as the same axis. "Technical" is not a type, and "preventive" is not a category.
• Calling a policy "preventive". A policy is managerial and directive; the technical enforcement of the policy is what prevents.
• Believing that two passwords are MFA.
• Forgetting that audit logs support accounting, not authentication.
• Assuming that zero trust is a product. It is an architecture and strategy.
• Ignoring the backout plan in change scenarios; many questions hinge on the missing rollback.

Exam tips

• When a scenario says "a control that cannot be implemented because of technical limits, so an alternative is used", the answer is compensating.
• "Discourage" or "warning sign" points to deterrent; "alert", "log review" or "camera recording" points to detective.
• In zero trust questions, the policy engine decides and the policy enforcement point enforces. The policy administrator is the link between them.
• If the question involves proving who performed an action, think non-repudiation, not integrity.
• For change management, the best answer usually includes testing and a backout plan before production deployment.

Mini case study

Case. Northwind Logistics (800 employees) suffered an incident: a former employee's account was used for three weeks after departure to download route-optimization files. The audit shows that account removal depended on a manual email from HR, that file downloads were not monitored, and that the data had no integrity or authenticity protection. Management wants three improvements.

Questions.

1. Which CIA property was primarily breached, and what additional property is hard to prove?
2. Classify these proposed measures by category and type: (a) automated deprovisioning triggered by the HR system, (b) a SIEM alert for bulk downloads, (c) a quarterly access-review procedure performed by managers.
3. The deprovisioning change touches the identity system. What change-management elements are required?

Solution.

1. Confidentiality was breached (unauthorized disclosure). Non-repudiation is also weak because the account activity cannot be tied to a specific person without strong authentication and reliable logs.
2. (a) Technical, preventive. (b) Technical, detective. (c) Operational (a human procedure), detective; it is also a directive if backed by policy.
3. Impact analysis (applications that rely on the account directory), testing in a non-production directory, an approval from the identity system owner and HR, a backout plan to switch back to manual removal, a maintenance window, communication to stakeholders, and updating documentation and version-controlled automation scripts.

Key terms

• Control category: technical, managerial, operational, physical.
• Control type: preventive, deterrent, detective, corrective, compensating, directive.
• CIA triad: confidentiality, integrity, availability.
• Non-repudiation: proof that prevents denial of an action.
• AAA: authentication, authorization, accounting.
• Zero trust: architecture that verifies every request; uses a policy engine, policy administrator and policy enforcement point.
• Honeypot, honeynet, honeyfile, honeytoken: deception assets.
• Gap analysis: comparison of current and desired control state.
• Backout plan: tested rollback procedure for a change.

Summary checklist

• I can state the four control categories and six control types and classify a given control on both axes.
• I can match a failure scenario to confidentiality, integrity, availability or non-repudiation.
• I can separate authentication, authorization and accounting and name RADIUS and TACACS+ roles.
• I can choose DAC, MAC, RBAC, ABAC or rule-based access for a scenario.
• I can name the zero trust components and their order in a request.
• I can identify the deception technology that fits a description.
• I can list the steps of a safe change: impact analysis, test, approval, backout plan, window, documentation.

For a deeper treatment of ownership, ethics, and risk decisions, see the CISSP security governance course.

Exam version and source check

This lesson targets SY0-701 (Security+ V7). As of October 26, 2026, CompTIA announces V8 for November; check the exam series before booking. Use the V7 certification page below for the official domain summary.

Sources

• CompTIA Security+ SY0-701 overview and exam objectives summary: https://www.comptia.org/en-us/certifications/security/v7/ (opens in a new tab)

• NIST SP 800-207, Zero Trust Architecture: https://csrc.nist.gov/pubs/sp/800/207/final (opens in a new tab)

• NIST SP 800-53 Rev. 5, security and privacy controls: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final (opens in a new tab)

• NIST authenticator requirements (opens in a new tab)

• TACACS+ protocol, RFC 8907 (opens in a new tab)

• NIST Digital Signature Standard (opens in a new tab)