Running with high privileges
You know you shouldn't do it, but you're running as Administrator aren't you? You've disabled UAC in Windows Vista, although we don't blame you we did too. But really, consider what you really need there's an awful lot you can get done and you can always RUNAS where necessary.
Using SQL Query Analyzer
Now using this tool in itself isn't a crime, but using it to poke around in databases directly is. Yes it might be easier to tweak that third-party application this way, rather than using the awful administration tools provided. But really, don't do it. Far too many have come to grief at the hand of an ill crafted SQL statement. DELETE without a WHERE, it's easily done.
Backups
You are doing backups aren't you? When was the last time you audited the backup logs?
Reusing old hardware
Now all too often admins will point to their print-server, hand-crafted from a collection of old PC parts and gaffer-tape. They'll wax lyrical about how cheap it was and how environmentally friendly they are. But it's simply storing up trouble for later. We absolutely advocate keeping some old hardware around, it can get you out of a jam. But don't under any circumstances allow it to become part of your infrastructure because when it dies, and it will, you'll have a bigger mess to clear up and no easy way of doing it.
Wide open Wifi
There will always be one, and it'll probably be a salesman, who decides their convenience is more important than your security. They'll bring in an old wifi router from home and plug it into the office lan. Then smugly sit across the room from their desk, tapping away on their newly untethered hardware. So keep an eye out and if you see access points you don't recognise, track them down.
Lack of training
While vendor certified training for all the users in an organisation is a pipedream, there's an awful lot to be gained from providing basic training to staff. It doesn't have to be expensive, even creating crib-sheets for users covering commonly used applications can bring benefits.
Passwords
How often to you change passwords? Now, whilst enforcing policies that require users to change passwords too regularly can actually make security worse, setting reasonable time limits will go some way towards preventing that favourite user security subversion – sharing passwords!
User buy-in is always helpful, whatever policy you have to enforce. So provide helpful hints to users on how to choose and remember appropriate passwords, for instance using the first characters of a phrase or replacing characters with appropriate numbers (e.g. B becomes 8, 1 become l etc.).
Failing to maintain good records
Keeping and maintaining records is time consuming, there’s no getting around the fact. However, it will save you immeasurably more time when for instance a laptop is misplaced or stolen. Knowing the specifications of all your equipment will make planning upgrades easier, it will make contacting manufacturers for tech support easier. You don’t need a complicated system, particularly in a small business, a simple spreadsheet or database should suffice.
Not listening to your users
Although it’s all too easy to assume you know best, that isn’t always so. The task you’re providing a software solution for is their area of expertise, not yours; after all they do their job every day. Interview your users, spend some time with them and get to know how they perform tasks – you can use this information to see if new software will be a good fit.
Giving in to your users
Now having just said your should listen to your users, you shouldn't confuse listening with capitulating. Users are often resistant to change and you may feel the line of least resistance is to customize software to fit in with existing business practise. All too otften the changes to process required are minimal and persuading users to change means substantial gains as it means working with software rather than against it. Also, if you need a better reason, upgrading customised software is always more troublesome than updating out-of-the-box installations.
Backups (Part II)
When was the last time you did a test restore? Knowing you're performing backups is one thing, ensuring they will actually work is quite another.
Lack of testing
The mantra should be test, test, test. Really, it's almost always better (whatever the short-term pain) to put off implementation to do more testing, rather than have a malfunctioning live system. Actually this is a good test of management, when senior staff are screaming for the system, can your manager (or possibly you) hold them at bay?