The REST-Hook channel section describes a Subscription lifecycle:

"When a Subscription is created for a REST Hook channel type, the server SHALL set initial status to requested, pending verification of the nominated endpoint URL. After a successful handshake notification has been sent and accepted, the server SHALL update the status to active. Any errors in the initial handshake SHALL result in the status being changed to error."

The lifecycle of Subscription.status from requested to active/error seems too strict, especially for administratively created subscriptions (see FHIR-43505).  Specifically, the "After a successful handshake notification has been sent and accepted, the server SHALL update the status to active." requirement implies (because of the SHALL) that a handshake is sufficient to move from requested to accepted, when in fact you might need (at least) two activities (the handshake, and the async IT governance approval).  I suppose you could say that approval has to happen before the client submits the Subscription request.

But my main point is that only a handshake may not be sufficient to activate a subscription, so we should loosen the SHALL so a server can do more than just a handshake before activating the subscription.