The CMDB is known to be stale, yet the team wants entity types pointed at all CIs immediately. What should the implementation checklist emphasize first?
Select an answer to reveal the explanation.
Short Explanation
Pointing entity types at a junkyard CMDB just industrializes bad inventory into bad GRC scope. Fix or filter the data first, then generate. Coverage vanity metrics are not worth a polluted entity tree.
Full Explanation
When the CMDB is known to be stale, the implementation checklist should emphasize data readiness and CMDB quality work before broad entity generation from CIs. Pointing entity types at a junkyard inventory industrializes bad data into bad GRC scope for the city, multiplying remediation across controls, risks, and audits. Fix ownership, status, and class suitability—or tighten filters—before celebrating coverage metrics. A smaller clean population beats a large dirty one that leadership cannot defend to auditors. Ignoring data quality and generating entities for every CI to maximize coverage metrics celebrates volume over trust. Deleting the CMDB and re-keying all assets as free-text risk statements abandons platform sourcing and creates reconciliation debt. Handing entity creation exclusively to external auditors with no platform data review outsources stewardship incorrectly. Exam caveat: entity generation inherits source quality—data readiness is a planning gate on CIS-RC. Operational check for the team: score CI classes intended for entity types on ownership completeness and status accuracy, remediate or tighten filters for the pilot class, then generate a limited population and sample-check entities before citywide generation.