DoD and DoR for Change Requests

Why do you need a Definition of Ready and Definition of Done for Change Requests? Why do you even need Change Requests to begin with?

If you're talking about features or functionality yet to be delivered, you shouldn't need a Change Request for stakeholders to talk to the Product Owner and then the Product Owner to update the Product Backlog. And once a feature or functionality has been delivered, Product Backlog Items become the Change Request.

I would recommend revisiting the value in a formal change request process. This kind of process is useful in plan-driven methods, where late changes can be impactful since you've invested a lot of time into getting your requirements right and then specifying a design that can satisfy those requirements, and then implementing that design. A requirement change can have a large, expensive, and time-consuming ripple effect. Agile methods, like Scrum, mitigate the need for expensive change control processes by making tolerance and acceptance of change a part of the way of working.

If they don't understand their workflow policies, their delivery model can't really be said to be a hybrid of anything.

It's more likely that organizational constraints are forcing compromises from the outset. Unless these are identified and challenged, nothing will really change even if some kind of DoR and DoD policy is cooked up.