Domain 3 · Objective reference 3.2 · Chapter 11 of 19
Least privilege, separation of duties and access models
About 6 minutes · ISC2 CC outline effective 1 September 2026
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: Need to know is about data; least privilege is about permission.
Explore the anchors
Grant only necessary permissions.
Concept matching activity
Match this task or description to its concept:
Split conflicting powers.
Choose a concept before checking the explanation.
Access-decision sandbox
Try to edit a fictional record as a reader. Then change one condition and evaluate again. This simplified policy requires authentication, object scope and action permission; real policies have more conditions.
Change the request, then evaluate it.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Distinguish the access decision models
- Apply least privilege and separation of duties
- Separate the policy decision from enforcement
Distinguish the access decision models
Discretionary access control allows an owner or delegated authority to grant access within system rules. Mandatory access control enforces centrally defined labels and clearances rather than leaving the decision to the individual object owner. Role-based access control groups permissions around job functions. Attribute-based access control evaluates properties of the identity, resource, action and environment against a policy.
These models can be combined. A role can establish a job function while attributes constrain which region or project it may access. Authorization must be enforced at the actual service or resource boundary. Hiding a user-interface button or using an unpredictable identifier does not replace that decision.
Apply least privilege and separation of duties
Least privilege grants only the authority needed for the approved task and duration. Separation of duties prevents one person completing incompatible steps alone, such as creating a supplier and approving payment to it. Dual approval can support this principle when the approvers are meaningfully independent. A second account belonging to the same person does not necessarily separate the business decision.
Evaluate both permitted and forbidden actions with controlled identities and data. Review accumulated grants, group inheritance, temporary access and emergency privileges. Multi-factor authentication does not repair excessive authorization. Automated agents should also have restricted resource scope and, for significant actions, suitable human approval or other controls.
Separate the policy decision from enforcement
A policy decision determines whether an action is allowed under the current rules and attributes. Enforcement applies that decision at the resource or service boundary. If one application endpoint checks ownership but an export endpoint does not, the policy may be written correctly while enforcement is incomplete.
Test both positive and negative cases: the approved user can perform the necessary operation, another user is denied and a disabled identity cannot reuse a surviving session. Avoid evaluating only the happy path. An access model is useful only when the intended decision reaches every relevant execution path.
| Model or principle | Basis of decision | Common mistake |
|---|---|---|
| Discretionary | Owner/delegated grants | Assuming ownership removes all organization rules |
| Mandatory | Centrally enforced labels and clearance | Letting an ordinary owner override the label policy |
| Role-based | Job responsibility | Ignoring inherited or accumulated roles |
| Attribute-based | Identity/resource/environment properties | Trusting unverified attributes |
| Least privilege | Minimum required authority | Keeping temporary rights permanently |
| Separation of duties | Independent incompatible stages | Giving both stages to one person under two accounts |
Worked example
A payment clerk receives a role permitting invoice preparation. Payment release requires a separate approver, and project attributes restrict which accounts each clerk can work on. The design combines role, attribute and separation-of-duties controls.
Check your understanding
What distinguishes role-based permission from attribute-based restriction in this example?
Show explanation
The role defines the general job operations. Attributes constrain which particular resources or circumstances allow those operations. The server must enforce both parts.
Source and study boundary
Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.