A county compliance program must apply policies to IT assets and to non-IT objects such as business processes and physical facilities. How should entity architecture be designed?

IRM entity architecture is not limited to configuration items. A county compliance program that must apply policies to IT assets and to non-IT objects such as business processes and physical facilities should support both IT and non-IT governable objects as entities so policies and controls can attach across the civic scope. Limiting entities to CMDB hardware classes and managing processes in email folders leaves non-IT obligations outside attestations and reporting. Modeling only servers and network gear while treating facility and process obligations as informal notes creates examiner findings and unowned work. Creating a separate GRC instance for non-IT objects that cannot share entity classes with IT fragments the system of record and complicates rollups. Exam caveat: non-IT entities still need identity, ownership, and type filters—calling something a process is not enough without operational stewardship. Operational check: identify in-scope processes and facilities with county stewards, define entity types and classes for those populations alongside IT types, generate pilot controls, and verify owners can attest in business language. Publish an entity catalog showing IT and non-IT civic objects under the shared framework.