When implementing ServiceNow Governance, Risk, and Compliance (GRC), one of the keys to a successful implementation is getting a solid understanding of the Policy and Compliance module and how GRC defines and uses profile types and profiles. Profile types and profiles are fundamental to understanding how GRC works. By reviewing and establishing the correct set of profile types and profiles, you’ll gain significant benefits as you implement GRC for your organization.
ServiceNow defines profile types and profiles as elements of profile scoping:
Profile types
Profiles types are dynamic categories containing one or more profiles. Business logic automates the process of creating and categorizing any profiles in the system that meet the profile type filters. Profile types are associated to policy statements, which generate controls for every profile listed in the profile type.
Profiles
Profiles are the records that aggregate GRC information related to a specific item. Each profile is associated with a single record from any table in the instance. Profiles cannot be created for items that do not have a record in a table in the platform.
Before getting into the specifics of profile types and profiles, we’ll provide some background on GRC and the standards and frameworks that apply to your organization.
Asset-centric Policy & Compliance
I’d like to share a quote from a long-time ServiceNow expert on what makes GRC unique. This person stated that ServiceNow GRC is an asset-centric governance, policy, and compliance-management application. The term “asset-centric” illustrates how GRC tightly integrates the ServiceNow Asset/Configuration Management database— the place where important IT things (Configuration Items) are stored—with the policies and standards that each of those important things must comply with for your business to meet the various applicable, regulatory standards. By relating assets and configuration items to policies, standards, and controls, GRC provides a tool that allows your group to measure and maintain compliance asset by asset, and configuration item by configuration item.
That’s a Lot of Compliance Tracking!
Having the ability to track compliance for each asset or configuration item can be a good thing. But be careful what you ask for. Take a simple example: your organization needs the ability to “assign and maintain user accounts and User Access Management for all systems.” What does “all systems” mean? For every server? For every application? For just the corporate Active Directory system (which in turn manages user access to systems)? Or just critical systems? If “all systems” truly means all systems, do your policy and compliance goals dictate you track and measure compliance for each of the hundreds or thousands of systems in your environment for this one control? These are the things that your team needs to consider when implementing GRC and ultimately, when defining profile types and profiles.
Frameworks and using Unified Compliance Framework (UCF)
Most companies leverage industry standards and frameworks as a basis for developing their internal policies and standards. Whether it’s NIST, CobiT, ISO 27001, PCI, or another standard, these frameworks have documented best practices, standards, and controls that apply to processes, applications, and systems within your organization.
These frameworks are extremely comprehensive. For example, if your organization is considering adopting ISO-27001/2 to implement security techniques within your IT department, there are potentially over 360 citations that your group will need to review to determine which are applicable. It is not uncommon for a typical GRC implementation to implement one or more frameworks that results in having 400+ citations loaded into GRC. While the volume of records is not necessarily significant, each citation often translates into one or more controls which are required to be attested, tested, and/or audited. Most likely, your group already has established controls and policies. However, based on ever evolving industry standards, it’s a good idea to see if you can leverage UCF, to automatically populate GRC with the frameworks and related data that will drive your compliance maturity goals.
If your organization is just starting to develop your internal policies and standards and has to support two or more frameworks, UCF is a great way to go. UCF has gone through the hard work of extracting the various citations from the frameworks and mapped those citations to a set of common controls.
Using the previous example “assign and maintain user accounts and User Access Management for all systems”, UCF has done the heavy lifting to map this control to one ISO 27001, one CobiT, and four NIST 800-53 citations. UCF helps you validate whether you are compliant with the related ISO, CobiT, and NIST requirements for this particular control.
Awesome you say! Let’s go with UCF! That is a great idea if you are willing to throw away all of your current controls and restructure your current policies, procedures, and standards that you already have in place. It’s a lot of work to update your existing standards and policy documentation, but this effort may pay off in the end. You can let UCF keep your controls up-to-date so that you can focus on making sure your organization remains compliant. On the other hand, the data that is downloaded from UCF is very detailed. Your team might find that they would prefer to keep what they have and manually reconcile the various frameworks to the current corporate compliance structure that is already in place.
Policy Statements vs. Controls
Policy statement vs. control is invariably one of the main points of confusion for people new to GRC. GRC uses policy statement records as a template to create one or more control records based on the system configuration. In the prior example, “assign and maintain user accounts and User Access Management for all systems” is used as a policy statement. If you have three critical application systems (SAP, Oracle e-Business, and ServiceNow) that you want to track and measure compliance, GRC can create three controls based on that one policy statement (that is, one control record for SAP, one for Oracle, and one for ServiceNow). These control records are basically identical and created from the one policy statement record. GRC will differentiate between these control records in that one will be related to SAP, one to Oracle, and the last one to ServiceNow.
The Math
After bringing together asset-centric policy and compliance tracking and policy statements, you can use simple math to estimate the potential number of controls that will be created. If you configure and load GRC with a number of assets/configuration items (the profiles) and multiply this number by the number of policy statements, the maximum number of potential controls that GRC will auto-create is:
(# of profiles) X (# of policy statements) = # of controlsmax
From this equation, it’s evident that the number of controls created can be significant. Remember, each control should be tested or audited on a regular basis. Is your group capable of auditing 200 controls quarterly? How about 2,000 or 20,000? It is common for customers to reconfigure GRC based on this equation, after realizing their security or audit team doesn’t have the resources to track and manage the number of controls in GRC.
Behind the Math - Profiles Types and Profiles
In order to categorize your controls effectively and efficiently, it is time well spent to analyze how your controls are grouped and organized, and how compliance issues and risks are reported to senior management, especially to the CEO or CISO.
This organization and reporting are the basis for properly setting up profile types in GRC. In my various GRC projects, I have created profile types based on major IT systems, business units, and locations. I have also created profile types by operating system type and by first creating one generic asset/configuration item. This is truly the case where if you are looking for your GRC consultant to answer the question “What is best practice?” and the consultant replies “Well, that depends...”, I would absolutely defend the consultant’s response and go on to say that profile types are essentially stored GRC searches. Profile types allow you to organize and group how you want GRC to create your controls for the important things that reside in your asset/configuration database. If you want to create a set of controls for your SOX applications, create a profile type for those apps. If you want to create another set of controls for your datacenters, create a profile type called Datacenters. And if you want to create a set of standard controls that are measured for each business unit, create a profile type for those business units.
In summary, profile types organize, group, and establish a structure for selecting a set of controls that apply to a set of things. When you create a profile type and define one or more filters, GRC will automatically create one or more profile records based on the filter or stored search.
Behind the Math - Relating Profiles Types to Policy Statements
Once you have created your profile types, profiles and policy statements, the next step is to relate or link each profile type to the appropriate set of policy statements. This step configures GRC to generate the correct set of controls for each profile. In other words, by linking profile types to policy statements, GRC will create data center controls for each of your datacenters, or standard IT controls for each of your business units, or IT process controls for each major development team.
When you relate profile types to policy statements, this triggers GRC to auto-create one control record for each profile record in the profile type using the policy statement as a template.
Summary
In summary, understanding how ServiceNow GRC leverages profiles types and profiles to dynamically create and manage a controls framework is the first step to properly implement GRC to meet your policy and compliance goals.
Once properly defined, profile types can be linked to policy statements to dynamically create and manage the correct set of controls for the various IT systems, applications, or business departments in your company, resulting in increased compliance tracking and reporting. This data-driven approach offers tremendous flexibility to meet the needs of organizations of all sizes and industries. With ongoing administration of profile types and profiles, organizations can grow and mature policy and compliance management for years to come.
