After a city IT reorg mid-cycle, the group that owns a generated access-control record moves to a new service desk. How should ownership be handled?
Select an answer to reveal the explanation.
Short Explanation
The control is still the same lock on the same door—only the key-holder changed. Swap the owning group on the live record. Deleting and regenerating throws away mid-cycle history for no good reason.
Full Explanation
After a city IT reorg mid-cycle, ownership of a generated access-control record should move by updating the owning group on the existing control without deleting the control record. Preserving the control keeps lifecycle history, open issues, and test evidence intact while routing future work to the new service desk. Deleting and regenerating under the new group resets lifecycle context and can orphan issues or confuse owners mid-campaign. Leaving the old group assigned and opening a separate SIR security incident for the reorg misuses incident response for an ownership metadata change. Converting the control into a risk statement so ownership follows Advanced Risk rules confuses compliance controls with risk content. Exam caveat: update related entity ownership if entity-level routing also drives tasks—control-only edits may be incomplete when entity owners still point at the old group. Operational check: identify controls and entities impacted by the reorg, update owning groups under change control, notify the new service desk, verify in-flight tasks reassign or are manually corrected, and sample attestation queues for stranded assignments. Record the ownership migration in the municipal reorg checklist.