A lot of great comments here already. I'll just throw in my two cents.
I think the foremost problem you have here is that you don't have a real security policy in place, or the one you have is obviously woefully inadequate.
do you default to locking something down until it's asked for / demanded, or leaving something allowed until there is a problem
Both of these approaches are a terrible way to implement security. If you lock everything down and people have to complain to do their jobs not only will they be frustrated and resentful but, you'll be out of a job someday if someone in management can't do his job because of your lock down. If you allow everything and only implement security after something goes wrong, the company is taking unnecessary risks with their assets and again...you will carry all the blame.
The whole idea of implementing a security policy is:
1) It's a documented company policy that EVERYONE must know and follow.
2) It's a collaborative policy all the stakeholders had input on and formed with management support. As opposed to a policy it was your responsibility to arbitrarily form on your own and be blamed for when problems arise.
First and foremost, you must understand the business needs of your users. There are no "best practices", or perhaps I should say "best practices" are somewhat of a misnomer. As everyone has already said, there is no one size fits all idea of security policy. Your best practices certainly aren't going to be anywhere close to mine. You need to find out what your users need to do on their machines and over your networks to do their jobs (their business needs), so that you can do yours. So go out there find out. Form a committee, send out a survey, interview the stake holders, sacrifice a lamb on your CEOs desk, whatever is appropriate for your workplace.
Once you have the business needs, you need to ask yourself some questions.
What are you trying to protect? Are you protecting the sales desktops or the developer's machines? These will have vastly different business needs and security approaches.
Who are you trying to protect them from? Malicious employees...outsiders...the users from themselves?
What's the risk? What is the value of these assets to the company? If there's no or little risk or value involved is it worth spending the man hours or money to protect? How much is it going to cost to protect? These type of questions are probably going to have to be answered in part by your superiors. IT usually doesn't get to decide how much risk the company is willing to take, you can only plead with them not to take too much risk and CYA (in writing!) if they decline your recommendations.
Once that's done document the policy and implement it with either technical controls and/or written company policy as appropriate.
This is a brief summary of the process. Entire books have documented the process of forming, writing, and implementing a security policy, and I highly recommend you read some!