Internal audit asks whether entity scoping is only a compliance concept. How should the IRM lead respond?
Select an answer to reveal the explanation.
Short Explanation
Think of entities as the city’s shared map. Compliance walks it, risk marks hazards on it, and audit picks routes from it—they do not each draw a different city. One scoped population keeps the three programs talking about the same departments and systems.
Full Explanation
The same entity scope underpins compliance, risk, and audit so programs share a common governed population. Entities are the city’s shared map: compliance walks it, risk marks hazards on it, and audit picks routes from it—they should not each draw a different city. Shared scoping enables test-once/report-many value and consistent executive reporting. Treating scoping as exclusive to Policy and Compliance while Risk and Audit invent unrelated object lists forces duplicate, inconsistent inventories. Saying audit engagements ignore entities and attach only to knowledge articles abandons entity-based assurance. Claiming entity scoping applies solely to Vendor Risk Management and never to internal departments wrongly excludes internal civic objects. Exam caveat: Entity Framework is architectural shared foundation across IRM programs, not a compliance-only courtesy. Operational check for the IRM lead: pick one critical application entity and show the same record linked to a control test, a risk assessment, and an audit engagement plan item, demonstrating one population serving three consumers. In civic IRM programs, document the decision, name owners, and verify the platform records match the intended operating model before expanding scope. Re-check after organizational or CMDB changes so evidence remains defensible.