Standards are like Rules...Made to be Broken

Standards are the preferred; however, as we all know, not everything fits into the same box.   How does your company handle the exception to the standard? 

Let’s say your company has a password standard of 8 characters, to include at least one lower case, one capital letter, one number, and one special character.  You also require account locking after 3 invalid tries and limit password reuse of last 10 passwords. If a department, say marketing, finds an application they say would greatly increase the company’s presence on the Internet and has a great Return on Investment (ROI); however, the application doesn’t require account locking after 3 invalid attempts.  Although the information stored in the application doesn’t include any company confidential information, do you allow the application?   If so, do you document it, along with the reasoning behind the decision?  

Now, if that same scenario is for a HR application that has sensitive employee data, do you make the same decision?  Maybe, maybe not.  You need to make the decision based on your organizations appetite for risk and what other controls are in place that might help mitigate the risk?  For example, if the HR application does checking to validate that the user is in a certain group, maybe a HR managers’ group, then maybe the decision is made to allow it.  However if you have loose controls around software installation on desktops and laptops and this HR application doesn’t do any group membership checking (or other compensating controls), then you might not want to allow it; this is the prime situation for a insider data breach. 

There is nothing wrong with deviating from the standards as long as you document the deviation and reasoning and you must also evaluate the risk associate with the situation. 

~Skeeter