<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=3189114&amp;fmt=gif">

Share the Wealth: Policy & Compliance Management in ServiceNow

In this Share the Wealth video, John Gilaspy of GlideFast gives an overview and demonstration on Policy and Compliance Management in ServiceNow.

What is Policy & Compliance Management?

ServiceNow's Policy and Compliance Management provides a centralized process for managing policies, standards, and internal control procedures that are cross-mapped to external regulations and best practices. It supplies structured workflows for the identification, assessment, and continuous monitoring of control activities. It further serves as an integration point with a globally recognized compliance aggregator for importing regulatory compliance frameworks.

What do we do with Policy & Compliance? 

Upfront Configuration

14f293_0eb4fda4f6b341cd92978b114e34cfbc~mv2

Focusing on the Upfront Configuration with Policy and Compliance Management, we’re looking at the authority documentation, or the internal and external regulatory sources. An example of an authority document is IRS 1075 for how finances should be run at a business. Each section that provides testable content in that document is a citation.

Citations are what we map to our internal policies. Policy Management and Policy Acknowledgement is how we manage those internal policies. We come up with the control that allows us to test compliance and that is our control objective. It is a template at the enterprise level that shows how we as an enterprise are doing compliance-wise. Those compliance templates and control objectives allows us to create indicator templates.

Indicator templates are part of the automation behind the scenes that allows us to create test templates because compliance only deals with whether your process is compliant with the actual requirements that are in place. We do this by going back to the hub of an entity type and finding the entities that are relevant. We then assign the control objectives to that. The automation automatically creates controls — one control per control objective per entity. For example, if we have 50 authority documents, 50 control objectives (one per), and 50 entities, we will have a control per entity that matches each of those control objectives. We also attest to the compliance of that control or not.

Compliance is a yes or no — do we comply or don’t we? And if we don’t comply, why and what will it take to get us there? There are levels of compliance, but not from a regulatory body’s standpoint. When it comes to security compliance, such as the NIST 800-53 CSF and the top 20 security controls, you are either complying with those controls or you’re not. The level of compliance does not matter to the regulatory source.

Measuring compliance internally, or the level of compliance, is much like what we do in projects when it comes to stories. It is a great thing to be able to measure the velocity of someone working stories to measure how well you’re doing and how quickly you're ramping up the ability to complete stories, but from a project standpoint, either the story is done or it’s not done on time. The same is true with policy and compliance. It is great to measure effectiveness and your level and maturity of compliance, but you’re still either compliant or not compliant.

ServiceNow Automation

14f293_aacf00c4b2024f1cb79a72ff5370f518~mv2

The Servicenow Automation behind the scenes is going to take the indicator templates that we create and assign to objectives. The automation will take the test templates that are created, the relationship of control objective to entity type, and the attestations that are created for each control objective and entity, and it will generate for us the indicators, test plans, controls, and attestations necessary. This will automate on a regular basis as the source data changes.

From a compliance standpoint, if you change the way ServiceNow works for relationships between these fundamental functional templates, including the control objective, test template, indicator template, etc., you run the risk of breaking the automation behind the scenes that is meant to get your compliance admins out of manual operational compliance monitoring and into an oversight level.

Daily Operations

14f293_71b109c0a1464d58b201ee7a1147d04b~mv2

Operationally, you want the system to do the indicator monitoring. You want the system to automatically generate controls, automatically generate attestations at a certain frequency, and automatically generate issues if non-compliance is found to be the case.

There is a relationship to risk because compliance mitigates risk. If you tie the two together, that is where the daily risk can be seen as matching or not matching the target residual risk. View John’s Risk Management in ServiceNow Demo for a full explanation. While you do not need to run policy and compliance and risk at the same time linked together, it is more effective for the enterprise if you do link them.

Regular Verification

14f293_7080c68c4d794a17b41eafacdda1572b~mv2

Opposed from risk, policy and compliance directly impacts audit. Internal audit is normally an IT function that looks at two things: (1) Are the controls that you're running designed well? and (2) Are they effective from an operational standpoint?. The audit engagement is designed specifically to allow you to do selective testing of the controls that are monitored from a compliance standpoint and look at them from both standpoints — design effectiveness and operational effectiveness.

Although the design effectiveness can be made optional, from an IT audit standpoint, a good auditor will look at both sides. First they will look at controls — are they designed well and easily implemented and followed? Then they look at the operational effectiveness — when people run through their business processes daily, are your controls effective at mitigating risk and maintaining compliance in those processes? That is where policy and compliance directly impacts audit and supports it from an internal IT audit standpoint for control review.

It is important to note that overall GRC is not IT specific. Although it originally started as IT GRC, it is now simply GRC — governance, risk, and compliance. In the next Paris version, it will be referred to as IRM, or Integrated Risk Management. The overall concept from governance, risk, and compliance will switch to integrated risk management. Frankly, policy and compliance is simply a gigantic self-integrating self-contained module that supports the mitigation of risk.

Compliance Management

First, we document requirements from external regulatory bodies, such as federal, state, and local governments, the EU or other international bodies, and industry organizations.

Next, we obtain the perspectives of process owners or operators regarding compliance with those regulations and policies via controls over business processes.

Then, we remediate non-compliant business processes if possible and document the inability to do so if needed.

 

How do we evaluate Compliance?

Regulatory compliance frameworks provide the controls by which entities are tested. ServiceNow provides for two methods of evaluation:

  1. Attestations — Subjective; gathers the perspectives of individuals with direct knowledge of the business process in question.

  2. Indicators — Objective; assigns tasks to provide data from external sources, or queries ServiceNow tables to identify data that proves compliance.

 

How do we respond to Non-Compliance?

ServiceNow automatically generates Issues for non-compliant controls, from which acceptance or mitigation can be managed:

  • If to be accepted, a Policy Exception is expected to be created.

  • If to be mitigated, Remediation Task(s) is/are expected to be created.

At the resolution of either, the failed control must be evaluated to prove compliance has been attained.

Policy Management

As the internal perspective of how an external regulation or best practice standard relates to the enterprise, policies are also monitored for compliance. When related to controls, policies aggregate compliance from them.

Policies are created, published, and managed in Policy Management but are published as Knowledge Articles as well, in the GRC Knowledge Base.

Policy Acknowledgment is an additional process that allows a “campaign” to be created, whereas relevant individuals are notified of a policy or policy change and asked to acknowledge their understanding of it. This can be done on a recurring basis, or whenever a policy is updated and republished.

Expanding into Audit

Controls are attested-to in Compliance Management, but the design and operational effectiveness are not reviewed and tested.

Audit Management provides for the testing of design and operational effectiveness, which can directly correlate with perceived compliance.

An ineffective control test will automatically create an issue for remediation for the control in question.

 


 

Interested in working with experts like John? Reach out to our team. We would love to learn more about your ServiceNow challenges and how we can help your organization build better solutions.

Related Posts