Understanding the relationship between policies, statements and citations

[thx1138]

I am seeking to understand the relationship between components in GRC. As I understand now…

An organization’s policy is to have “policy statements” attached to it. Those statements have associated citations which in turn have controls which could/should be applied.

So track backwards…

Framework > Authority Document > Citations > Policy Statement > Org’s Policy.

Am I way off base here?

[Jan Spurlin · Accepted solution]

That's not exactly how it works.

Authority Docs are usually references to regulations, laws or standards - like COBIT, SOX or one of the ISO standards.

The citations are children of the Authority Doc - they break down something like COBIT into requirements.  I also refer to it as the legalize that explains the regulation.

Many times a company needs to comply with multiple authority docs.  And many times the requirements in different authority docs end up being duplicative.  For example - many of these regulations have requirements about passwords or access to data.  Keep that in mind as we move forward.

Now regarding Policies - these represent what they company has decided they want to follow.  This helps drive the culture of their company.  These are the policies they want their employees to follow.  Examples of Policies could include:  Acceptable Use Policy, Expense Policy,, Facility Access Policy, Non-Charitable Contribution Policy.  It can also include procedures, standards, etc.  In the baseline there are about 7 different types.  There is no workflow in the baseline for the different types.

BTW - a Policy can have sub-policies.  A Policy should also have children that are stored in the Policy Statement table.  These further define the Policy.  it is from Policy Statements that Controls are created.  Policy Statement is a ServiceNow term that is often misunderstood by customers. Other names for this table could be Control Objective, Control Template or Requirement. Regardless of what you call it - it is a breakdown of the Policy.  These are statements that describe how the company wants to manage the policy.  And BTW Policy Statements can also have sub-policies.

So - how do Auth Docs/Citations and Policies/Policy Statements relate to each other?

Citations are related to Policy Statements.

You may a single Password Policy that contains several Policy Statements about how the company will manage passwords.

There are a bunch of Citations, across a bunch of Auth Docs that say the same thing.  Relate those citations to the right Policy Statement.  This is the beginning of "measure once and satisfy many".  When you look at the Related list of a Policy Statement - check out the Citations related list.  You will find (in the demo data) citations from various Auth Docs.

This is one of the "set up" parts to managing Controls.

Step 2 - identify the Profile Types

After you have figured out what Policies a company wants to adhere to and set up the Policy Statements to support it and related the Citations to it, you have one more step.  Figure out who is going to manage the Controls that will be generated from the Policy Statements.  For passwords - will the control be per Application?  will it be per Business Unit?  will it be per Application area?  Answers to those questions will determine what Profile Type gets set up.

When a Profile Type is set up - for our example, we will say that they want to manage the password policy at the application level.  The profile type filter will be set up against a table (probably the CMDB Applications) and profiles will be generated.  Assume that we have 40 applications, so 40 profiles would be set up.

Note:  for the Password Policy - as you review the individual Policy Statements, you may decide that some need to managed at the Application level, but others could best be managed at the Business Unit level.  So, a second Profile Type for Business Units would be set up.

Step 3 - Relate the Profile Type to the Policy Statement(s)

After the Policy has been approved, then you can relate a Profile Type to the right Policy Statement.

There is a flag on the Policy Statement (Create Controls Automatically).  In order to automatically generate controls from the Policy Statement this must be checked.  This flag exists because if you have multiple levels of Policy Statements you probably only want to generate the controls at the lowest level.  If you generated controls at all the levels then you probably would be creating duplicates.  (I have heard of reasons to do this - so it is technically possible, but not used very often.)

So, if the Policy is approved, AND the create controls automatically checkbox is checked - then when you add a Profile Type (related list) to a Policy statement it will generate Control records.

In our example of using the applications as the profile type - if we apply the Applications Profile Type to a single Policy statement, then 40 control records would be generated.  It may appear that these are duplicates because they all have the same value in the "Name" field.  They are not duplicates.  They are unique because there is a control for EACH application.  You need to look at the "Name" and the "Profile" values.

The Control Owner is derived from the Owner field on the Profile record - so it is important to make sure those are accurate.  It can be changed on the Control record - but it is nice to have it correct on the Profile.

It is then the Control record that is actually managed on an ongoing basis.  The control record has a workflow that it goes thru to determine if the control is compliant or not.

And now a plug for ServiceNow training...  all this and much more is covered in our GRC Fundamentals class.  

[Jaskirat Singh]

Thanks @Jan Spurlin for answering this.
I am just rephrasing a few terms and sharing your response back as i thought it might be helpful. 

------------------------------------------------------------------------------------------------------------------------

Authority Documents are usually references to regulations, laws or standards - like COBIT, SOX or one of the ISO standards.

Citations are children of the Authority Doc - they break down something like COBIT into requirements.  I also refer to it as the legalization that explains the regulation.

Many times, a company needs to comply with multiple authority documents and the requirements in different authority docs end up being duplicative.  For example - many of these regulations have requirements regarding passwords or access to data.

Policies - these represent what they company has decided they want to follow.  This helps drive the culture of their company.  These are the policies they want their employees to follow.  For Example - Acceptable Use Policy, Expense Policy, Facility Access Policy, Non-Charitable Contribution Policy.

OOTB there are about 7 different types (Policy, Procedure, Standard, Plan, Checklist, framework, template) but no workflow for the different types.

a Policy can have sub-policies.  A Policy should also have children that are stored in the Control objective table.  These further define the Policy.  it is from Control objectives that Controls are created.  Control objective is a ServiceNow term that is often misunderstood by customers. Other names for this table could be Policy statement, Control Template or Requirement. Regardless of what you call it - it is a breakdown of the Policy.  These are statements that describe how the company wants to manage the policy.  And Control objectives can also have child control objectives.

Step 1 - How do Authority Documents/Citations and Policies/Control objectives relate to each other?

Citations are related to Control objectives.

You may have a single Password Policy that contains several Control objectives about how the company will manage passwords.

There are a bunch of Citations, across a bunch of Auth Docs that say the same thing.  Relate those citations to the right Control objective.  This is the beginning of "measure once and satisfy many".  When you look at the Related list of a Control objective - check out the Citations related list.  You will find (in the demo data) citations from various Auth Docs.

This is one of the "set up" parts to managing Controls.

Step 2 - Identify the Entity types

After you have figured out what Policies a company wants to adhere to and set up the Control objectives to support it and related the Citations to it, you have one more step.  Figure out who is going to manage the Controls that will be generated from the Control objectives.  For passwords - will the control be per Application?  will it be per Business Unit?  will it be per Application area?  Answers to those questions will determine what Entity type gets set up.

When an Entity type is set up - for example, we will say that they want to manage the password policy at the application level.  The Entity type filter will be set up against a table (probably the CMDB Applications) and entities will be generated.  Assume that we have 40 applications, so 40 entities would be set up.

Note: for the Password Policy - as you review the individual Control objectives, you may decide that some need to manage at the Application level, but others could best be managed at the Business Unit level.  So, a second Entity type for Business Units would be set up.

Step 3 - Relate the Entity type to the Control objective(s)

After the Policy has been approved, then you can relate an Entity type to the right Control objective.

There is a flag on the Control objective (Create Controls Automatically).  To automatically generate controls from the Control objective this must be checked.  This flag exists because if you have multiple levels of Control objectives you probably only want to generate the controls at the lowest level.  If you generated controls at all levels, then you probably would be creating duplicates.  (I have heard of reasons to do this - so it is technically possible, but not used very often.)

So, if the Policy is approved, AND the create controls automatically checkbox is checked - then when you add an Entity type (related list) to a Control objective it will generate Control records.

In our example of using the applications as the Entity type - if we apply the Applications Entity type to a single Control objective, then 40 control records would be generated.  It may appear that these are duplicates because they all have the same value in the "Name" field.  They are not duplicates.  They are unique because there is a control for EACH application.  You need to look at the "Name" and the "Entity" values.

The Control Owner is derived from the Owner field on the Entity record - so it is important to make sure those are accurate.  It can be changed on the Control record - but it is nice to have it correct on the Entity.

It is then the Control record that is managed on an ongoing basis. The control record has a workflow that it goes through to determine if the control is compliant or not.
 Policy and Compliance Architecture