A municipal IRM team keeps entities in ServiceNow but a bureau proposes a parallel SharePoint list as a second master for the same governable buildings and applications. What should the architect insist on?
Select an answer to reveal the explanation.
Short Explanation
Think of entities like the city’s official property map—if two maps claim to be master, every policy and risk drifts. Keep one system of record in IRM for those governable objects. Shadow lists create ghost buildings nobody can attest the same way twice.
Full Explanation
ServiceNow IRM entities are the join point for policies, risks, controls, and audits. When a bureau proposes a parallel SharePoint list as a second master for the same governable buildings and applications, the architect should reject dual systems of record and keep a single IRM entity framework as the governable source of truth. A SharePoint shadow list creates conflicting masters, breaks generation consistency, and leaves examiners arguing which list is authoritative for the city. Approving SharePoint as authoritative with nightly one-way sync into IRM still leaves an unmanaged master outside workflow, ownership, and audit trails. Splitting buildings to SharePoint and applications to ServiceNow without reconciliation guarantees permanent mismatch. Disabling entity generation to manage controls from SharePoint titles abandons the IRM content model. Exam caveat: integrations may feed entity sources, but the governable system of record for GRC attachments must remain the shared entity framework—not a competing bureau list. Operational check: inventory any shadow lists, map their objects to IRM entities, retire duplicate masters under change control, and require bureau stewards to update entities in ServiceNow. Verify a sample building and application each have one entity used by Policy, Risk, and Audit reports for municipal leadership.