An implementer activates every IRM-related plugin “just in case” without a checklist. What practice should replace that approach?
Select an answer to reveal the explanation.
Short Explanation
“Just in case” plugin shopping turns the instance into a flea market of half-configured apps. The checklist says activate what the agreed use case needs—nothing more on day one. Scope first, then licenses and plugins follow the plan.
Full Explanation
Implementers should activate only the applications and plugins aligned to the agreed phase-one use cases, not every IRM-related plugin “just in case.” Indiscriminate activation turns the instance into a flea market of half-configured apps, complicating testing, roles, licensing conversations, and support for municipal teams. Scope first; plugins and applications follow the signed-off plan so unused surface area does not create false expectations. Future use cases can be enabled through normal change control when data and owners are ready. Keeping unused plugins active so future use cases need zero change control still expands configuration drift and support burden today. Disabling the entire GRC suite until a single custom app is coded abandons the product the city purchased. Allowing each analyst to activate plugins in production without review invites uncontrolled change and broken dependencies. Exam caveat: checklist-driven activation matched to use case is the planning standard. Operational check for the implementer: list plugins required for phase-one Policy and Compliance or Risk only, obtain change approval, activate that set in subprod first, validate roles and menus, and record explicit deferrals for Vendor Risk, BCM, or other apps until later phases.