IT Internal Controls for the Internal Controls?

Putting access controls on the release docket 

Having the list of all projects included with a major production release is an internal control used to protect the release. Risks are observed early, a release planning meeting can be called with appropriate people, and everything is transparent. But who can add an entry to that list of projects? By restricting write access to only Project Leads and Scrum Masters - one further reduces release risk. Developers are wonderful (I was a full-time developer for many years and I still code a bit) but only a Lead/Manager should be including (listing) production changes. A change may require testing beyond what is performed by the developer, or a change may not be appropriate for a given release, and we often need to communicate to others in advance (by the way… we are fixing that bug Thursday night so your phone representatives no longer should ‘talk around the bug’ starting Friday)

In summary, having access controls around who can put projects on the release docket is a good internal control, for an internal control