I agree with the rest of this, but I'm not sure about 4. If you're new to a system, you don't have a good sense of who "really needs" access, and in particular you don't have a good sense of all the terrible, awful, dangerous things that are nonetheless delivering business value.
Maybe person X built system A, and is now working on system B, but remembers a lot of details - keeping their access to system A can help you recover in an emergency. Maybe someone wrote a monitoring job (or worse, a deployment job) that runs as themselves. Maybe someone has read-only access to a system and is using it to ask occasional good questions to the team that actually runs the system. Maybe team C has a formal API but it doesn't work well so person Y informally got access to C's database and it's making system D able to run at all, and it would take a few months of effort to fix the API that's supposed to be there between C and D.
And, more frustratingly but no less impactful - maybe there's a senior person who likes still having access to system E, and making them mad will cause political problems for you and impose burdens when you you try to make any other changes, which gets in the way of your ability to solve all the other problems that you need to solve.
Your priority in the short term is to keep the business running, not to improve things. Insider threats are real, but they are much rarer than all the other reasons your business could get in trouble. If you don't have a good understanding of your tech debt and why the tech debt exists and how quickly it can be paid off, focus on that first.
Maybe person X built system A, and is now working on system B, but remembers a lot of details - keeping their access to system A can help you recover in an emergency. Maybe someone wrote a monitoring job (or worse, a deployment job) that runs as themselves. Maybe someone has read-only access to a system and is using it to ask occasional good questions to the team that actually runs the system. Maybe team C has a formal API but it doesn't work well so person Y informally got access to C's database and it's making system D able to run at all, and it would take a few months of effort to fix the API that's supposed to be there between C and D.
And, more frustratingly but no less impactful - maybe there's a senior person who likes still having access to system E, and making them mad will cause political problems for you and impose burdens when you you try to make any other changes, which gets in the way of your ability to solve all the other problems that you need to solve.
Your priority in the short term is to keep the business running, not to improve things. Insider threats are real, but they are much rarer than all the other reasons your business could get in trouble. If you don't have a good understanding of your tech debt and why the tech debt exists and how quickly it can be paid off, focus on that first.