I wanted to share this answer because it took a bit of discussion and then I needed to develop a strategy. First, I had to realize that security settings as it relates to items are not stored in roles or users. They are stored in the items themselves. Once I understood this, my whole strategy as it relates to packaging and installing these roles and users had to change.
If these content items can be packaged up or controlled through TDS for deployment, then you can deploy or install those items and then package all the roles and users which also need to appear in the higher environments. This is the ideal situation where after all the content items, roles and user items are deployed, everything should link up just fine and you are ready for testing or production usage.
However if you have a mature content tree information architecture whose content section is not maintained through TDS or some other mechanism and packaging up hundreds to thousands of items is out of the question, then while packaging up the roles and users is still a step to perform, you will have to recreate the security settings once those roles and users exist in higher environments. This might be possible using PowerShell but I had a tight time frame and the amount of time I would have invested, I would have it done the hard way in that time. Thankfully all I really needed was one main role that did most of the work and a bunch of child roles inheriting the main role with some minor changes per role.
Before I got started, I did package up the main and children roles and installed them on the higher environment. This will be much faster than creating each one individually again one at a time and you are less likely to forget one.
First, as Sitecore would suggest, I had to update the main role which all my child roles would inherit. What I needed for this main role had to be well documented since I would have to duplicate this process again on each higher environment (such as QA followed by PROD).
Second, I created a process for creating the roles which would inherit the main role (my child roles) and eventually followed a cadence which would allow me to create and even test all the child roles in a pretty quick manner. I would literally assign a test user and re-use it on each child role to ensure that the proper security mechanism met the needed criteria. Since the core database responds immediately, it was not hard to change the role assigned using the User Manager, switch to my Sitecore browser, sign in the same way and take a quick look.
Third, setting up this entire mechanism did require me to build a bunch of items (in this case media library folders) to support these uniquely secure content editors. Since this is new and a relatively small set of items, once I assigned the proper roles or users to each of these folders in DEV, I then packaged them up and installed them on QA. The advantage being that in this specific situation, these folders know about the roles and users I had already installed in its own package. Therefore as a result, this part of the system was completely set with no additional work in the Security Editor to address any access issues.
Those are my thoughts on handling this situation, I hope you found this helpful.