Disaster-recovery obligations cover different systems than the city’s PCI scope. How should entity scoping handle that?
Select an answer to reveal the explanation.
Short Explanation
PCI cares about card data paths; disaster recovery cares about what must survive an outage—those circles overlap but are not twins. Let each program keep its own entity scope instead of mashing them into one giant blob. Multiple scopes keep obligations honest.
Full Explanation
Disaster-recovery obligations and PCI obligations often cover different systems, so entity scoping should allow distinct program scopes rather than forcing one mega-scope. PCI cares about card-data paths; disaster recovery cares about what must survive an outage—those circles overlap but are not twins. Purpose-driven scopes keep obligations honest while still reusing shared entity master data where overlap exists. Merging DR and PCI into one mandatory mega-scope that includes every municipal CI either over-tests systems or under-covers recovery targets. Using only the PCI entity list for DR because payment systems are always the recovery priority can miss non-payment systems that are still critical to restore. Prohibiting multiple scopes by claiming IRM permits only one global entity list per instance is false and harmful. Exam caveat: different GRC programs may define different applicability on shared entities. Operational check for the city: maintain separate PCI and DR scope lists (or program associations) on entities, review overlap deliberately, and generate controls/tests per program instead of one undifferentiated blob. Keep civic stakeholders aligned on the operating model, and verify platform records after each change before reporting posture to leadership. Revisit the design when CMDB classes, org structures, or program charters change.