A CMDB owner asks how IRM relates technically to configuration items in a regulated city environment. Which explanation is correct?
Select an answer to reveal the explanation.
Short Explanation
Entities are the GRC name tags hanging on real org and CMDB objects—not a second mystery inventory. When those source records are clean, risk and control scoping stay trustworthy. Junk in the CMDB shows up as junk in compliance coverage.
Full Explanation
Entities often derive from or reference CMDB and organizational data so GRC inherits that data quality. In a regulated city environment, IRM entity records are name tags on real org units and configuration items, not a second mystery inventory of free-text labels disconnected from operations. When source records are clean—owners, status, class—risk and control scoping stay trustworthy; junk in the CMDB becomes junk in compliance coverage and audit arguments. Technical linkage is therefore a feature and a responsibility shared with CMDB stewards. Forbidding any reference to CMDB or organization data and allowing only free-text entity names creates unsustainable silos and reconciliation debt. Saying every CI automatically becomes a closed audit engagement without entity typing invents automatic assurance nonsense. Transferring CMDB ownership permanently to the audit manager role when IRM is installed confuses data stewardship with third-line assurance. Exam caveat: IRM links to CMDB and org data; it does not seize CMDB ownership or auto-close audits. Operational check for the CMDB owner: for a pilot application CI, generate or link an IRM entity, verify key attributes and ownership flow through, and agree a data-quality checklist before broad entity generation from CI classes.