Principle of Least Privilege

Introduction

Always employ the Principle of least privilege when designing a security strategy or developing for SQL Server. Only grant the minimum level of permissions required for a person to perform their job function and nothing more.

Some examples

Developers

Do developers need to be in the sysadmin role on your development and test servers to be able to drop databases etc. Usually not and is done for convenience/laziness. This can lead to lots of problems for the DBA and can be very time consuming to resolve issues where things have changed and the root cause is not immediately obvious.

DBA

If authenticating to production using your windows integrated logon do not add that login into the sysadmin fixed server role. Create another elevated account for each DBA that they have to use to administer production as a sysadmin. This is good practice and makes people think prior to connecting to avoid accidental errors.

Conclusion

The above are just some examples of this principle in action. There are countless others that are all valid and good practice.

Applying this principle strictly throughout your SQL Server estate will stand you in very good stead resulting in a robust environment resistant to accidental errors or hackers.