Change Control Isn't an Agile Scoping Tool
If he/she wishes to change the scope by adding in/taking out/re-prioritizing the Backlog the PO must submit a Formal Change Request/IOCA before taking an approved Change to the Scrum Master for Planning consideration.
This is the antithesis of agility. While Scrum works just fine in environments that require formal change control, the change control process is generally intended to safeguard the integrity of the production environment rather than keeping the Product Backlog sacrosanct.
Analysis and Recommendations
I suspect the "change control" requirement is really an attempt by the stakeholders or steering committee to control project scope or budget. If that's the case, the Scrum Master needs to educate the organization better on how iterative development actually works, and work with the team to ensure that the product is always in a releasable state at the end of each iteration.
The stakeholders, through the Product Owner, can add or remove items from the Product Backlog at any time. The only thing they can't do is change the stories within the current Sprint unless the Product Owner calls for an early termination and a return to Sprint Planning.
Technically, there's nothing in Scrum that requires or prevents stakeholders from enforcing change control on the requirements they pass on to the Product Owner. How the Product Owner interfaces with stakeholders is an externality to the Scrum framework, which simply mandates that the Product Owner is in charge of the contents and ordering of the Product Backlog.
However, such heavyweight quarterbacking is a significant "project smell" that typically indicates that the organization has not embraced the iterative development model, and probably doesn't understand how to effectively use the framework's built-in process controls. Educating the organization about the Scrum framework is the Scrum Master's job, and effectively managing the stakeholders is the Product Owner's job.
Reconsider the Framework Choice
Education would seem to be the missing ingredient here. Of course, Scrum is also not a silver bullet, is not right for every organization, and may simply be a bad fit for a command-and-control organization. Good waterfall isn't any more likely to fail than improperly-implemented Scrum, so it may also be worth reconsidering whether Scrum is the right framework for the organization.
Different frameworks may fit better. Your mileage can certainly vary!