A municipal IRM rollout spans Policy and Compliance, Risk, and Audit. How should roles and groups be patterned?
Select an answer to reveal the explanation.
Short Explanation
Least privilege is like city badge access: finance gets the vault, parks gets the greenhouse—not master keys for everyone. Common GRC role patterns still carve access by job, even when the apps share a platform. Admin-for-all is the opposite of that design.
Full Explanation
A municipal IRM rollout spanning Policy and Compliance, Risk, and Audit should apply common GRC role and group patterns with least privilege so users get only the access needed in each app. Shared platform does not mean shared master keys: finance compliance analysts, risk owners, and auditors receive carved access aligned to duties. Least privilege preserves segregation even when apps coexist.
Granting every compliance user sn_grc.admin so all apps share one powerful account destroys least privilege and elevates change risk to methodologies and ACLs. Using only ITIL roles and avoiding sn_grc or sn_risk roles starves GRC of appropriate personas. Giving auditors write access to all risk scoring fields so they can fix scores during fieldwork collapses independence into score ownership.
Exam caveat: common GRC roles still enforce least privilege; admin-for-all and auditor score-edit are classic CIS-RC traps.
Operational check: map persona→role matrices for compliance, risk, and audit; verify no blanket sn_grc.admin for routine users; confirm auditors lack residual score write on first-line risks; re-certify roles quarterly after org changes.
Role reviews should include a toxic-combination check that flags users holding both high-privilege compliance configuration rights and audit closure rights. Document exceptions with compensating controls and expiry dates. Prefer group-based GRC roles mapped to job functions over personal one-off admin grants across the municipal rollout.