Great article! I've implemented similar mechanisms and also solved the backup security problem (how to avoid granting backup/restore rights to developers) by polling a status table from a Server Agent job.
One step I've always included in my implementation is updating security on the newly refreshed test server database. I think it's safe to say that most shops limit or even exclude developer permissions on production servers and also don't allow any end-user connections to test servers. Additionally, there are still systems out there that require the use of SQL Server logins. Both of those scenarios might require that users be dropped and created on the newly refreshed test database along with permission re-assignments.
I know that ideally the prod/test servers won't have logins from other environments, so it's possible to simply accept existence of "orphan" database users as benign, but that practice puts you just one step away from inadvertently granting incorrect database access.
So, I'm just curious if you implement any security adjustments after a refresh and, if so, how do you maintain and execute scripts that may have to be tailored for each database?