Scenarios 13–18
13 — New role model
Situation: enterprise needs consistent privileges for 5,000 users across job families.
Decision: individual or role-based assignment?
Expected reasoning: role-based access control; centrally manage identities, memberships, approvals, and changes.
14 — Data-first role design
Situation: security starts with confidentiality/regulatory classes and asks which roles may see each combination.
Decision: Grid or Hierarchy?
Expected reasoning: Role Assignment Grid because the design begins with data/classification.
15 — Contracted cloud analytics
Situation: vendor processes company PII and says security is now the vendor’s responsibility.
Decision: What does DMBOK say?
Expected reasoning: operations/control may be delegated; organizational accountability remains. Define custody, shared responsibility, SLA/contract terms, audit rights, reporting, and monitoring.
16 — Security added at the end
Situation: system is complete before the team discovers regulated fields need special access/logging.
Decision: What should have happened?
Expected reasoning: security requirements should have been identified during project analysis and designed into architecture.
17 — Audit conflict
Situation: DBA who administers the database also performs its formal audit.
Decision: What governance issue exists?
Expected reasoning: audit independence/separation of duties. Formal assurance should be independent of control operation.
18 — Metric overload
Situation: dashboard has 90 security counts but no baseline, target, trend interpretation, or action.
Decision: What is wrong?
Expected reasoning: use a smaller organized set of actionable, baselined measures tied to management decisions/improvement.