ISC2 CC Domain 3 IAM Concepts

Domain 3 accounts for 20% of the ISC2 Certified in Cybersecurity (CC) outline effective September 1, 2026. It contains only two numbered objectives, but they cover a large part of everyday security: managing identities through change and making sure each identity receives appropriate access.

Identity And Access Management (IAM) is easier when you treat it as a lifecycle rather than a login screen. Access can be correct on the day an account is created and become excessive after a promotion, transfer, leave of absence, contractor change, or departure.

1. Domain 3 map

Objective	Official focus	Useful question
3.1	Identity life cycle management: roles, provision, review, deprovision, frameworks, tools	What should happen to the identity and its access at this point in the person's or account's lifecycle?
3.2	Logical access controls: Principle of Least Privilege (PoLP), Separation of Duties (SoD), access-control models	What access is justified, who should control the decision, and what rule or model enforces it?

2. Identity lifecycle: access should change when responsibility changes

An identity represents a person, service, device, application, or other subject that needs to be recognized by a system. Identity lifecycle management keeps that representation and its access aligned with a valid business need.

A practical lifecycle looks like this:

Define the role and need. Determine why the identity exists and what responsibilities justify access.
Establish or verify the identity. Create the account or digital identity through an approved process.
Provision access. Grant permissions based on approved roles, duties, policies, and other requirements.
Review access. Confirm that the identity still needs the permissions it has.
Change access when responsibilities change. Remove old access and add new access when roles, projects, locations, or employment status change.
Deprovision. Disable or remove access promptly when the identity no longer needs it.
Retain required evidence. Preserve appropriate records of approvals, reviews, changes, and removal.

The lifecycle is not always linear. A user can move between roles several times before leaving an organization. A service account can remain for years but still require periodic review.

The goal is not merely to create accounts correctly. The goal is to keep access appropriate throughout the identity's entire useful life.

3. Roles and ownership: know who requests, approves, and uses access

Titles vary between organizations, so focus on responsibility.

Role	Typical IAM responsibility
User or subject	Uses the identity and follows authentication and access requirements.
Manager or business owner	Confirms that requested access supports legitimate duties and remains appropriate.
Resource or data owner	Defines who should access a resource and under what conditions.
IAM or system administrator	Implements approved account, role, and permission changes through the authorized system or process.
Security or compliance function	Defines control requirements, monitors exceptions, and may review evidence or policy compliance.

The person who can technically create access is not automatically the person who should approve it. Separating approval from implementation can reduce unauthorized or excessive access.

4. Provisioning: grant what is justified, not what is convenient

Provisioning creates or enables the identity and grants access needed for an approved role or task.

A good provisioning process answers:

What business need justifies the account?
Who approved the access?
Which systems or resources are required?
What role or permission set fits the work?
When should the access begin?
Does the access need an expiration or review date?
Does the request create a separation-of-duties conflict?

Standard roles can make provisioning more consistent. They reduce the chance that every new user receives a custom permission set that becomes difficult to review later.

Default access should be intentional

Convenience can create privilege creep. Granting broad access "just in case" makes later reviews harder and increases the effect of mistakes or compromise.

Provision the smallest reasonable set of permissions for the approved work, then add access when a real need is established.

5. Access reviews and role changes

Access reviews compare existing permissions with current responsibilities.

A review can ask:

Is the identity still active and valid?
Does the user still hold the same role?
Are all assigned permissions still necessary?
Are temporary privileges still justified?
Are privileged or sensitive permissions receiving extra scrutiny?
Do any access combinations violate policy or separation-of-duties rules?
Is inactive or unused access creating avoidable exposure?

Role changes can create privilege creep

When someone transfers from one job to another, adding the new role without removing the old one can accumulate unnecessary authority.

A useful rule is:

Change means review, not just add.

Before adding new permissions, determine which old permissions should be removed.

Reviews need accountable evidence

An access review is more than sending a list to a manager. The organization needs a process for decisions, exceptions, unresolved items, changes, and evidence that the review was completed.

6. Deprovisioning: remove access when the need ends

Deprovisioning disables or removes access that is no longer authorized.

Common triggers include:

employment termination;
contractor or vendor end date;
completion of a temporary project;
expiration of elevated access;
retirement of an application or service identity;
discovery of an unused or unauthorized account.

Prompt deprovisioning limits the time an unnecessary account or permission can be abused.

Disable versus delete

Organizations may disable an account before deleting it so records, ownership, legal requirements, or investigations can be handled correctly. The security priority is to stop unauthorized future use while following the organization's retention and lifecycle requirements.

Shared knowledge must survive departures

Deprovisioning is not only about the account. Organizations should consider ownership of files, automation, credentials, encryption keys, service dependencies, and other resources that could become inaccessible when someone leaves.

7. IAM frameworks and tools support the process

IAM frameworks and tools help organize and automate identity proofing, account creation, access requests, approvals, role assignment, authentication, reviews, changes, and deprovisioning.

NIST Digital Identity Guidelines provide a useful primary reference for identity proofing, authentication, federation, and lifecycle concepts.

For CC, remember the difference between process and tool:

The process defines what should happen and who is accountable.
The tool helps implement, automate, record, or enforce the process.

Automation can improve speed and consistency, but incorrect source data or role definitions can automate the wrong access just as efficiently.

Identity source matters

Organizations commonly rely on an authoritative source, such as an approved personnel or contractor record, to trigger account creation, updates, and removal. The quality and timeliness of that source affect the IAM lifecycle.

8. Logical access controls: decide what an identity may do

Logical access controls restrict digital access to systems, applications, data, functions, and other resources.

They can enforce decisions based on:

identity;
role;
group membership;
resource classification;
attributes;
device or connection conditions;
time or location;
policy rules.

Authentication answers whether the claimed identity can be verified. Authorization answers what that identity may access or perform after authentication.

Domain 3 concentrates on three authorization ideas: least privilege, separation of duties, and access-control models.

9. Principle of Least Privilege (PoLP)

The Principle of Least Privilege (PoLP) limits an identity to the access necessary for its assigned responsibilities.

Least privilege reduces:

the impact of a compromised account;
accidental changes;
unnecessary exposure of sensitive information;
the ability to misuse unrelated functions;
the amount of privileged access the organization must monitor.

Least privilege is not "no privilege." A user still needs enough authority to perform approved work.

Privilege should match time as well as role

Some access is needed only temporarily. Elevated access for a short maintenance task may be appropriate while permanent elevated access is not.

Useful questions include:

Does the identity need this permission all the time?
Can the access be limited to a specific system, action, or period?
Should privileged use require additional approval or monitoring?

10. Separation of Duties (SoD)

Separation of Duties (SoD) divides sensitive responsibilities so one person or identity does not control an entire high-risk process.

Examples:

one person requests a payment and another approves it;
one administrator changes a critical configuration and another reviews the change;
one employee creates a vendor record and another approves payments to that vendor;
one person develops code and another approves it for production.

SoD reduces the chance that one person can make and conceal an unauthorized action.

Least privilege and SoD solve different problems

Principle	Main question	Security effect
Least privilege	Does this identity have more authority than its work requires?	Reduces unnecessary access and the effect of misuse or compromise.
Separation of duties	Does one identity control too many conflicting steps in a sensitive process?	Requires independent participation or oversight for high-risk actions.

An organization may need both. A payment approver can receive only the permissions needed for approval while still being prevented from creating the payment being approved.

11. Access-control models

Access-control models describe different ways authorization decisions can be organized.

Model	Decision basis	Useful clue
Role-Based Access Control (RBAC)	Access follows an assigned job role or function.	Many users performing the same job need the same permission set.
Attribute-Based Access Control (ABAC)	Policy evaluates attributes of the subject, resource, action, environment, or other context.	Access depends on combinations such as department, resource sensitivity, device state, or location.
Discretionary Access Control (DAC)	An authorized owner or controller has discretion to grant access to an object.	The resource owner can decide who else receives access.
Mandatory Access Control (MAC)	Access follows centrally enforced labels, classifications, clearances, or policy rules rather than owner discretion.	The subject and object must satisfy mandatory classification or label rules.

For CC, focus on the basis of the decision rather than memorizing product implementations.

RBAC is especially useful for standardized job responsibilities. ABAC can express more contextual rules. DAC emphasizes owner discretion. MAC emphasizes centrally enforced policy and labels.

12. Put the concepts together

Consider a new employee joining a finance team:

The organization verifies the employment record and creates the identity.
The manager approves the finance role.
The IAM system provisions the standard RBAC permissions for that role.
Least privilege limits the role to the functions needed for assigned work.
SoD prevents the same employee from both creating and approving certain high-risk transactions.
Periodic reviews confirm that the role is still appropriate.
A transfer triggers removal of finance permissions before unrelated new access is added.
Departure triggers deprovisioning.

This is why IAM is a lifecycle. The access model helps make a decision, but governance and review keep that decision correct over time.

13. Common Domain 3 exam traps

Authentication is not authorization

Authentication verifies identity. Authorization determines permitted actions.

Provisioning is not finished when the account works

A technically functional account can still have excessive or conflicting permissions.

A role change should not simply add access

Adding a new role without removing old permissions creates privilege creep.

Least privilege is not separation of duties

Least privilege limits unnecessary authority. SoD divides sensitive responsibilities.

Automation does not remove accountability

An IAM platform can enforce and record workflows. People and organizational processes still define appropriate access and approve exceptions.

RBAC and ABAC are not the same model

RBAC bases access mainly on role membership. ABAC evaluates attributes and policy conditions.

DAC and MAC differ in who controls the decision

DAC gives authorized owners discretion over access. MAC applies centrally enforced policy or label rules.

Deprovisioning should not wait for an annual review

When the valid need ends, access should be removed or disabled according to the organization's process.

14. Rapid review checklist

Before leaving Domain 3, make sure you can explain:

[ ] The identity lifecycle from role definition through deprovisioning
[ ] Why provisioning requires approval and business need
[ ] Why role changes can create privilege creep
[ ] What an access review is trying to confirm
[ ] Why prompt deprovisioning matters
[ ] What IAM frameworks and tools support
[ ] Authentication versus authorization
[ ] Principle of Least Privilege (PoLP)
[ ] Separation of Duties (SoD)
[ ] Least privilege versus SoD
[ ] Role-Based Access Control (RBAC)
[ ] Attribute-Based Access Control (ABAC)
[ ] Discretionary Access Control (DAC)
[ ] Mandatory Access Control (MAC)
[ ] Why an access model does not replace lifecycle review

A useful final exercise is to take one employee transfer scenario and describe what should be removed, what should be added, who should approve it, and which evidence should remain afterward.

15. Official and primary references

Use the ISC2 outline as the authoritative scope for this domain:

ISC2 CC exam outline effective September 1, 2026

Primary references that add context:

These sources provide deeper identity and authorization context. They do not replace the ISC2 exam outline as the coverage checklist.

CertHappens is an independent study resource and is not affiliated with or endorsed by ISC2.