A consultant proposes a separate ‘compliance-only CMDB’ so IRM never touches the enterprise CMDB. What should the implementation lead answer?
Select an answer to reveal the explanation.
Short Explanation
Two maps of the same city that disagree are worse than one good map. IRM should use the shared entity framework tied to trusted enterprise sources—not a shadow compliance CMDB that drifts the moment IT updates reality.
Full Explanation
Implementation leads should reject a consultant's separate compliance-only CMDB proposal and instead use the shared entity framework sourced from trusted enterprise data. Approving a parallel universe because GRC must never share data with IT operations creates dual masters, reconciliation nightmares, and examiner confusion for a city or utility that already struggles with identity. Building the parallel store and syncing nightly with undocumented scripts multiplies operational risk and hidden failure modes. Replacing entities with Security Incident Response assignment groups abandons the GRC entity model and cannot support policy, risk, and audit attachment patterns. Exam caveat: shared sourcing does not mean IRM writers get unconstrained CMDB edit rights—use governed feeds, filters, and stewardship while keeping one identity for governable objects. Operational check: map enterprise CMDB classes into IRM entity types, prove generation against trusted CIs, reject shadow CMDB proposals in architecture review with written rationale, and document data stewardship between IT operations and compliance. Revisit federation rules when new agencies join the municipal ServiceNow estate so parallel universes are not reintroduced under a new name or SharePoint alias.