The transfer that cannot wait

A good governed answer starts by naming the change as significant rather than arguing about it: four hundred new users, a new inbound integration and a major-version upgrade each change the configuration and the exposure the nine-month-old test examined, so the prior assurance no longer describes the running system — ISM-2118 attaches testing to deployment and to significant change, not only to the annual floor, and it is the change trigger that bites here. But a system owner does not resolve this alone. The governed move is to write down, before the decision, what counts as significant for this system, then take the conflict between the fixed transfer date and the testing requirement to the security function and the accountable person above the delivery decision, with an explicit choice: move the date, reduce the scope, or accept a stated risk with a named owner, a committed remediation window and a review date — and whichever is chosen, the findings go into a register with owners and dates. Any of the three positions can be governed or ungoverned; what makes the difference is whether the trade-off was described, decided by someone with the authority to decide it, and recorded — not whether testing happened before or after the transfer date. Hardening of the upgraded platform under ISM-2110 applies to the new version, not the old, and any AI component of the upgrade is tested with the rest.