Using SN to document and manage exceptions of various types.

[sams]

Hi,

First time submitting a question and somewhat new to service now terminology and capabilities.

I am wondering if anyone has devised a way to leverage service now to capture exceptions of various types. Ideally a process that might be leveraged by a few different use cases since most exceptions will have common attributes. The objective is to provide management better visibility of the various exceptions that exist and a maybe some idea of risk associated with them. It might also help to ensure that certain activities are performed on a regular basis.

Below is a an initial outline of what an exception is and some of the common attributes in most cases. I also provided a few use cases that might be addressed.

Definition of an Exception:   A exceptions represent situations where a configuration or activity identified in policy or standard cannot be met.   The risks introduced by exceptions must be documented and the exception should managed in an ongoing fashion.

Exceptions are used in a variety of situations and introduce varying degrees of risk to the organization. All exceptions have some common attributes including:

Submitter (user/dept wanting the request)

Submission Approver: Manager of the submitter authorizing the request to enter workflow) (Ultimately is the owner sponsor of the exception request)

Justification: Identify what policy/standard is not being met.

Mitigating controls & compliance plan:

Exceptions should incorporate mitigating controls (In some cases this may be mandatory for approval of the exception)

Risk Determination:   Rudimentary way of identifying the risk associated with an exception.

Security Review: comment area for security

Expiration and re-certification Time Frame:  

As part of lifecycle of systems and services risk posture can impact the risk presented by exceptions.

It is also important to recognize that as systems and services mature exceptions may be nullified partially or fully, or risk may worsen depending on conditions.

Exception Approval:     The type and level of risk may determine who is delegated to review the exception request. (some might require VP approval, approval of others might be delegated to a manager related to the type of exception being requested)

Attached to a Configuration Item of some sort:

Other Aspects of Exceptions

• Exceptions should be few (if there are many for a given policy or standard something is amiss)
  • The ability to measure exceptions is important because it helps to ensure policy and standards are effectively defined.

Exception Scenarios:

• Encryption of data in transit for an application
  • Maybe there is a list of domains in the email/exchange application/service that should be evaluated by management on an annual basis.
• Exception to Vendor Remote Access standard
• Exception to password policy
• Exception to standard prohibiting direct connected printers (often in home/office situations)
• Exception to patching standard
  • Maybe a system can't be patched for some reason but mitigating controls exist.
• Exceptions related to privileged access accounts
• Exception to install non-standard software

I know there is an aspect of GRC that allows for issues but I am not sure if that would require greater maturity in GRC in order to get a rudimentary method in place. I also recognize that depending on the exception type it may be best to capture them as part of other processes.   For example exceptions related to PC's might be captured as part of the asset management process, and exceptions related to User Access might be captured as access request process.

My apologies for the long winded explanation and thanks in advance for any suggestions or responses.

[rohantyagi]

Hi sams, yes you are right. this is all part of GRC and ServiceNow has a very specific offering for GRC which combines capabilities of a number of applications that we have on the platform like cmdb, asset management, security ops, itsm, etc. Please refer this page: Governance Risk and Compliance | ServiceNow

You should not worry about your maturity level in GRC, as the various components of it can be rolled out in an incremental manner which i think is a good topic to discuss with the professional services team however looking at the requirements you mentioned above i think GRC will solve your purpose.

[robertmolenda]

Certainly while GRC _could_ be utilized to define the exceptions - it is really utilized to capture the "compliance standards"..

Example - all data must be encrypted at rest on a "server' - servers without data encryption software installed and configured require an exception to this compliance standard.

The Architectural Compliance Module - could be utilized to automatically detect and register systems that do not match compliance - however that does require a bit of a mature CMDB in order to implement.

Since you have a defined process surrounding the exceptions (submit/ approval / renewal) - it is probably easiest to create a stand alone table and business rules to track this process all together.

Hope this helps

Robert Molenda