CIIM common mistakes
CIIM · Understand the traps and how to avoid them.
Treating 'identity governance' as a synonym for 'access management' and answering governance questions with provisioning or SSO mechanics - for example, answering a question about who certifies entitlements with a description of how a connector syncs accounts.
The two domains share vocabulary (accounts, entitlements, roles), and candidates who work day-to-day in IAM operations default to the tooling they touch, not the control objective being tested. Governance questions are about decision rights, accountability and evidence; access management questions are about authentication and enforcement.
What to do instead
Before answering, classify the question by its object: if it asks who decides, who approves, who reviews, or how evidence is retained, it is governance. If it asks how a subject proves identity or how a resource enforces a decision, it is access management. Write that classification in one word before choosing an option.
Assuming a periodic access review is effective because it was performed and documented, without testing whether the reviewer had the context, authority, or data quality to make a real decision.
Review campaigns are usually measured on completion rate, so candidates equate '100% certified' with 'control operating effectively'. In practice, rubber-stamped reviews, reviewers approving their own access, and reviews scoped to the wrong population are the common defects.
What to do instead
Evaluate a review on four attributes: population completeness (does it include service, privileged, and orphaned accounts), reviewer independence (no self-certification), decision quality (revocations actually actioned within SLA), and evidence linkage (decision traceable to the ticket that removed access). If any is missing, the control is deficient regardless of completion percentage.
Choosing role mining or RBAC redesign as the fix for an access problem when the actual defect is orphaned accounts, stale entitlements, or missing joiner-mover-leaver triggers.
Role modelling is the most visible governance topic, so it becomes the default answer. Candidates skip the diagnostic step of asking whether the lifecycle events that should have removed access actually fired.
What to do instead
Work the lifecycle first: joiner (account created with correct baseline), mover (old access removed on transfer, not just new access added), leaver (all access revoked within a defined window, including non-SSO and locally provisioned accounts). Only recommend role redesign when the evidence shows entitlement sprawl that lifecycle controls cannot contain.
Answering authentication questions by naming a factor or protocol ('we use MFA', 'we use SAML') instead of matching the control to the threat it addresses, such as phishing-resistant authentication for high-risk enrolment or recovery.
Candidates memorise factor categories (something you know/have/are) and protocol names but not the attack each one resists. Push notification MFA and SMS OTP are still 'MFA' yet fail against real-time phishing and SIM swap.
What to do instead
For every authentication question, name the attack in the stem and select the control that defeats it: FIDO2/passkeys for phishing resistance, number matching or device binding for MFA fatigue, out-of-band verification for helpdesk-driven reset fraud. If an option only states a factor type, it is usually the weaker answer.
Treating federation and single sign-on as automatically reducing risk, and ignoring the trust configuration, assertion signing, and session lifetime that determine whether SSO actually enforces the intended policy.
SSO is marketed as a security improvement, so candidates assume any SSO design is the secure option. They overlook that a permissive identity provider trust, an unsigned or weakly validated assertion, or a long-lived session token can widen access rather than narrow it.
What to do instead
When evaluating an SSO or federation option, check four things explicitly: who can be a trusted identity provider, how assertions are signed and validated, how session and token lifetimes compare to the sensitivity of the relying application, and whether de-provisioning at the identity provider actually terminates sessions at the relying party.
Confusing authentication with authorisation and answering an authorisation question (can this user perform this action on this record?) with a stronger login control.
Both are 'access' and both appear in the same scenarios. Candidates see a security incident and reach for step-up authentication, when the defect was that the application trusted a client-supplied role or object identifier.
What to do instead
Separate the two in every scenario: authentication establishes who the subject is; authorisation decides what that subject may do to a specific resource. If the stem describes a user reaching data they should not reach while legitimately logged in, the answer is a server-side authorisation or object-level permission control, not a login control.
Treating encryption as a complete data-protection answer without specifying data state, key custody, and who can decrypt - for example, recommending 'encrypt the database' for a problem about over-broad analyst access.
Encryption is the most familiar data-protection control, so it is selected reflexively. Candidates miss that encryption at rest does not stop an authorised application user from reading data, and that encryption with poorly segregated keys provides little protection against an insider with administrative rights.
What to do instead
State the data state (in transit, at rest, in use), the threat model (external attacker, insider, host compromise, backup theft), and the key boundary (who holds keys, whether they are separated from the data custodian, how rotation and revocation work). If the threat is an authorised user seeing too much, the answer is minimisation, masking, or access scoping, not encryption.
Applying data-protection controls uniformly instead of classifying data and differentiating controls by sensitivity, retention need, and jurisdiction.
Candidates learn control catalogues as checklists and apply them everywhere, which produces answers that are technically correct but disproportionate or that fail to protect the specific data the scenario describes.
What to do instead
Start each data-protection question by naming the data category and its handling obligation (for example, special-category personal data, credentials and secrets, payment data, or telemetry). Then select controls for that category: minimisation and purpose limitation for personal data, tokenisation for card data, secrets management with rotation for credentials.
Scoring identity risk with a single static rating per application or role, and failing to incorporate behavioural signals, privilege level, or the confidence and recency of the underlying evidence.
Risk registers and heat maps encourage one number per asset, and candidates carry that habit into identity risk questions. They then miss that the same account is low risk when dormant and high risk when it holds privileged entitlements and exhibits anomalous access patterns.
What to do instead
Build the risk view from independent inputs: entitlement sensitivity (privileged versus standard), account state (dormant, orphaned, shared), behavioural deviation (new geography, unusual time, volume spike), and control coverage (is MFA enforced, is the account reviewed). Show how a change in any input changes the rating, and state the decision threshold that triggers action.
Proposing monitoring and alerting as the remedy for identity risk when the risk originates from excessive standing privilege that should be removed or made time-bound.
Detection tooling is prominent in the domain and easy to recommend, so candidates answer 'alert on anomalous use' when the scenario describes permanent administrator rights that no one needs. Detection does not reduce the blast radius of standing privilege.
What to do instead
Distinguish reducing likelihood from reducing impact. For standing privilege, the primary control is elimination or just-in-time elevation with approval and expiry; detection is the compensating control for the residual window. If an option removes the entitlement and another only alerts on it, the removal is the stronger answer unless the stem explicitly asks for detection.
Treating identity theft and fraud controls as purely customer-facing, and omitting the enrolment, recovery, and account-takeover paths that attackers actually use.
Candidates focus on the login screen and on transaction fraud detection, while most account takeover happens through account recovery, contact-detail change, helpdesk social engineering, or new-account enrolment with synthetic or stolen identities.
What to do instead
Map the full lifecycle: enrolment (identity proofing strength matched to risk), credential and contact-detail change (re-verification and notification to the old channel), recovery (no weaker path than the primary login), and post-authentication monitoring (device and behaviour signals). For each, state the attacker's method and the control that interrupts it.
Answering fraud-detection questions with a single control and no discussion of tuning, false-positive handling, or the feedback loop between detection outcomes and control adjustment.
Detection is taught as a technology choice (rules versus models) rather than as an operating process, so candidates stop at 'deploy scoring'. They then cannot answer questions about threshold selection, customer friction, or how confirmed fraud cases improve the model.
What to do instead
Describe detection as a loop: signals collected, decision threshold set against an explicit risk appetite, outcomes routed to step-up verification or manual review, confirmed cases fed back to recalibrate rules and models, and false-positive rates monitored as a customer-experience and abandonment metric. Mention that thresholds differ by transaction value and channel.