Over the past few months I’ve been in increasingly more discussions, online and at in-person group meetings, about information security policies and exceptions; often more like venting sessions. A common theme is that the information security folks were complaining about how their companies’ managers are granting exceptions to their information security policies, or that they are always getting requests, often from the same people, for exceptions to policies, and then having a lot of holes created as a result, for an ongoing and undetermined amount of time. Typically the advice provided by some of the others involved in the conversations was generally the following, “You should NEVER grant policy exceptions. It will result in…” then fill in your favorite: “non-compliance,” “too much risk,” “weak policies,” and a variety of other comments.
Well, if you are constantly getting policy exception requests that result in few in your organization actually following the policies, or if your managers are granting policy exceptions at their own discretion, or if you have implemented a “no policy exceptions ever” stance within your organization, then change your practices! Otherwise your policies truly will not be effective, and security will be interfering with, and not supporting, business activities unless they are missing altogether.
Exceptions will always be necessary
There will always be some legitimate need(s) to grant information security policy exceptions. Always. You can never say never when it comes to information security, especially when considering the unlimited ways in which technologies are being used, and new ones that are emerging. Here are some of the exceptions I’ve seen over the years that had legitimate needs to be implemented.
- A specialized vendor system was configured to require a password that did not meet the organization’s password policy requirements.
- A propriety business system allowed for only one admin ID, and there was a team of admins that supported it, resulting in not being able to comply with the policy to not share IDs.
- Some laptop operating systems that were being used within the organization did not support the policies for network attachment requirements.
- A (REALLY old!) legacy system was depended upon for business processing, but it did not have the technical options to meet compliance with some of the information security policy technical requirements.
- A court case was brought against an organization, requiring an exception to the email retention policy for the associated legal hold.
- A key business systems support employee was in an accident, requiring an exception to the access policy to allow co-workers to use her ID and cover time-critical business processing requests.
I’ve found the exceptions are most often necessary with:
- Legacy systems
- Third party access to the organization’s systems
- Propriety systems
- Physical security
- Emergencies
- Legal cases
Expect that you’ll need to make some information security policy exceptions. Then what?
Exception management
The key is to have an information security policy exception management process in place and consistently followed. Some of the components you need to include are:
- Allowing policy exceptions to be granted by only one, centralized area. Typically the Information Security department. Managers should not be allowed to grant exceptions at their own discretion.
- Establishing mitigating controls that must be implemented if an exception is made. This is critical! Too many organizations simply allow for an exception without specifying any mitigating controls, leaving the organization with significant risk. Mitigating actions can be administrative, technical, physical, or an appropriate combination of one or more of these.
- Establishing responsibility on the personnel to whom the exception is given. Those who have been granted an exception must be held accountable, and sanctions consistently applied for not following mitigation requirements.
- Establishing a time limit for how long the exception will be allowed. The time for the exception will depend upon the exception; some may be only for one hour, or one day. Others may need to be for a month, a year, or longer. You need to apply critical thinking when establishing the time limits, and consider the business impacts in addition to the associated information security risks.
- Determining how to monitor those who have been given an exception. The method used will depend upon the type of exception given. I’ve seen a huge multi-national organization set up an exception monitoring system that would automatically send out messages to those that had been granted exceptions, asking them to re-apply for the exception at pre-established dates, in addition to doing regular exception audits.
- Establishing a process to remove/cancel the exception. An exception should not be considered as being permanent. The centralized group managing exceptions needs to establish a process for removing exceptions when they are no longer necessary.
- Documenting all aspects of the exception. Items to include in your documentation include those involved, the scope, limitation, mitigating controls, dates, times, and reasons why the exception is necessary, just to name a few.
Bottom line for organizations of all sizes…
Exceptions to information security policies sometimes need to be made. In such situations, all organizations need to be prepared by having an effective, documented information security policy exception management process in place. Not only do you need this to maintain security, you also need such documentation and supporting processes to meet compliance with a wide range of legal requirements.
Additional information about policy exception management
Here are some additional sources of information about information security policy exceptions:
- Example: Information Security Policy Exception Procedure from the State of California Technology Agency
- See the Business Alignment and Acceptance Section of this ISACA Journal article, “Key Considerations When Evaluating ISRM Programs and Capabilities”
This post was written as part of the IBM for Midsize Business (http://goo.gl/t3fgW) program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
Tags: audit, awareness, breach, compliance, customers, data protection, e-mail, electronic mail, email, employees, employment, exception management, hiring, HR, human resources, IBM, Information Security, information technology, infosec, IT security, job applicants, laws, messaging, midmarket, non-compliance, patients, personal information, personally identifiable information, personnel, PII, policies, policy exception, policy management, privacy, privacy breach, privacy professor, privacyprof, Rebecca Herold, risk, risk assessment, risk management, security, sensitive personal information, SPI, systems security, training, walk through