What is the purpose of relating control objectives to policies?

[Kitty1]

I am weighing an option of not relating control objectives to polices in our environment.  I understand the the basis for relating is control objectives to policies may be: 

1. The related control objectives provide the foundation for the policy.  Once approved, the policy text and the related control objectives become a governance package for the organization and the control objectives are printed at the bottom of the policy in the KB.

2. Provides an indirect relationship between entity types and policies

3. Provides an indirect relationship for the controls for the entities to the policies.

Are there other benefits to relating the policy to control objectives?

Is there an automated function in ServiceNow that the association of the control objective to the Policy triggers?

[Jan Spurlin]

Technically I guess you could skip relating Control Objectives to Policies. But here are a few thoughts if you did.

• The approval process is at the Policy level, so you would be omitting that.
• You would not see any type of rollup of the compliance percentage for multiple control objectives. If you are using Authority Docs/Citations and create the relationship to Control Objectives, then you could see it there.
• There is no Valid To/From dates on the Control Objective - so nothing to trigger a review.
• Regarding the relationship to entities - what we hear from the field is that most of the time customers/partners are relating Entity Types to the Control Obj and not the Policy. So, shouldn't matter in this decision.
• Without Policies you cannot use the Policy Acknowledgement function - which is pretty nice.
• The policy exception process also leverages a value on the Exception Setup tab on the Policy record. There is a property where the default for the exception duration is set. But if you don't have policy docs, then that means that the default duration would be the same for all your policies.
• There is no "automated" way to relate Control Objs to Policies in the baseline. Consider the intent of the Policy record - and how it is different from an Auth doc:
• A policy is meant to represent the company/organization. The collection of policies really defines who the company wants to be, what they value. One of the reasons that you don't see collections of policies that can be imported is because Policies should be unique to a company.
• For example - a company may have a Security Policy and that policy may be related some some Cyber Security regulations (aka Auth Docs and Citations) but the difference between the two is that the Control Objs for the Policy are actually more stringent that the requirements outline in the regulation. That is what the company thinks they need to do to be successful. So, the Control Obj more than covers the requirements in the Auth Doc.
• Management may want to know not just how compliant they are with the Cyber Security regulation, but also how compliant they are with their own Security Policy.

There may be other considerations, but these are the ones that come to mind for me. I probably wouldn't leave them out.

Jan