Categories Topics
Exception Management

The exception process should ensure non-compliant items can be documented, approved and tracked to ensure remediation of security gaps to an information security policy or standard. An exception should also not be frequent but may be required if longer time period (e.g. need for budget approval, testing, etc.) is needed to implement action plan in order to meet policies and standards.

An effective security program will ensure the organizations controls are effective to meet policies and standards. To that end, it's not uncommon that some systems, applications, or processes may require more time to come into compliance to policies. The exception process will allow the system or application owners to submit a formal exception request aligned with standard/policy along with an action plan with a target date for remediation.

Each request should be formally approved (or denied) by the standard owner or management and should be limited in time (e.g. no more than 12 months as most common). Exceptions should also require risk based analysis (e.g. high, medium, low risk) to consider the likelihood and impact if the non-compliant item were to be exploited leading to loss of data confidentiality, integrity or availability. Higher risk exceptions should be highest priority and could be used as leverage for justification to resource security activities.

Some organizations with a limited budget may choose to manage exceptions via internal lists or solutions (like Excel or Sharepoint). As companies mature in exceptions management, Governance Risk and Compliance (GRC) are also effective solutions to manage exceptions. GRC solutions can be configured to manage company policies and standards as well as better workflow automation/routing of exception requests. GRC can also be used to better track lifecycle of exceptions and escalations as needed. See "Governance Risk and Compliance" topic for more information.