Whenever I do a security presentation, I make sure to cover the Principle of Least Privilege. And when I do I boil it down to this very simple definition:
Giving the rights to do the job. No more. No less.
If you don't give enough rights, the person can't do the job. Obviously that doesn't work. And the whole point of the Principle of Least Privilege is to ensure too many rights aren't given out. After all, a user could do something unexpectedly and because of the additional rights cause damage he or she shouldn't. Or the user's account could be compromised and the attacker uses those additional rights in a bad, bad way.
Okay, all that's logical. So how to determine what rights are needed? I've seen a lot of folks start by saying, "No!" and then making folks prove they need the rights. That's the quick and easy way, for the person "signing off" on said rights. It's also the lazy and least productive way, IMHO. I saw a tweet today by a DBA who was facing that issue with management. I tend to take a different approach. Here's what I do:
I approach it not from the "You must justify it" side but rather the "What do you need to do it" one. That makes it an interactive process where both parties are working to ensure security is taken seriously, minimal effort is expended overall for the organization, and the correct solution goes into place the first time. So what happens if you have the "You must justify it" person? I approach that situation like so:
And that usually does the trick. If they still say, "No," and then I'm not able to do something expected of me, I have the documentation to explain why i can't do my job and the evidence that shows I communicated the need for those rights. After being burned once or twice, usually they'll go back and grant all the rights I said I needed. And next time they are less likely to question my assessment.