Answer
In practice, the ownership model that works best assigns a single accountable technical owner, usually a senior IBM i administrator, who is responsible for the runbook's accuracy after every infrastructure or application change, paired with a business sponsor who owns the recovery priorities and signs off on the plan at a set interval, typically annually or after any material change to the application portfolio. Splitting ownership this way keeps the plan grounded in both operational reality and business consequence, rather than becoming either a purely technical document nobody outside IT reads or a policy document detached from how recovery actually works.
Change control is the mechanism that keeps this from decaying. Whenever a new PTF group, a new interface, an added LPAR, or a staffing change touches anything the runbook depends on, that change should trigger a runbook review as a matter of process, the same way it might trigger a security or backup review. Buyers should ask whether the DR software they are evaluating can flag when the underlying environment has changed since the runbook was last validated, because that kind of drift detection is what turns ownership from a title into an ongoing discipline.