Policy Expire/Renew and Attestations

[Gene Manuel3]

Can someone explain what happens after a policy expires? Do you need to create a new Policy or can you update the expiration date?

What happens to the Controls that have attestations? Do they all get reset?

We have a policy that states that Service Catalog items have be reviewed and validated every year. Ideally what we would like to see is the controls "re-attested" after the policy expires but it's not clear now to renew the policy or send out attentions again for controls that have an attestation from the previous year.

[Scott Ferguson]

First, a published policy creates KB article published to your GRC knowledge base.

By default, via a workflow, 30 days prior to the policy record's valid to date, the policy (based on reviewers and owners) gets set back to draft or review.  You then have a period of time to make updates and approve the updated policy.  When you re-publish the updated policy, it retires the previous kb policy and publishes a new versions.  To the end users, they only see the kb article versions.  Work gets done behind the scenes (in GRC) before you have a policy coverage gap. 

For attesting the controls yearly, set the attestation frequency on the control objective to yearly. 

Keep in mind (from support KB article) regarding control verse entity level frequency:

If you define the 'Attestation frequency' on the entity level, this will run the schedule job 'Control attestation nightly run' for ALL Controls under this entity.  However, if you wanted Controls to have an attestation frequency at different times, (example, one weekly and another monthly), you can define this in the 'Frequency' field in Controls individually (executed by same scheduled job 'Control attestation nightly run').  Please note: You will have to ensure that in the scheduled job script, you have defined either the Profile Table and field or Control Table and field to be used in the execution.

[Gene Manuel3 · Accepted solution]

Awesome, thank you for clearing that up! Is there a notification that goes out when an attestation needs to be done again or does it just show up in a report as being non-compliant?

[priyajames1]

Hi Gene,

Below is my inline response for your questions: 

1. Can someone explain what happens after a policy expires? Do you need to create a new Policy or can you update the expiration date?

ANS: Once the Policy expires you may not want to move it to draft/attest instead the best way is to restart process. A new policy needs to be created once a Policy is retired. When the Policy is in Monitor state you can ensure based on the "valid to" date you can send out notifications before a specific number of days [ you can set that by navigating to Policy and Compliance -> properties -> Number of days after reaching a policy "Valid to" date in which the expired policy will automatically move from its Published state back to a Draft/Review state  = 30 for example ]. So once based on that date the state is set to attest notifications will be triggered to the attestation respondents to ensure that the policy is attested and the flow continues. 

2. What happens to the Controls that have attestations? Do they all get reset?

ANS: Once a Policy is retired, all the associated Policy statements become inactive and in turn controls are retired. So be careful when you chose to retire a policy. 

3. We have a policy that states that Service Catalog items have be reviewed and validated every year. Ideally what we would like to see is the controls "re-attested" after the policy expires but it's not clear now to renew the policy or send out attentions again for controls that have an attestation from the previous year.

ANS: In this case you will ideally want to just set the "Valid To" date of the policy and set up notifications to trigger 30/45 days before the policy reaches it valid date so just re-reviewing and approving the policy. Simultaneously, onthe control side , setting up the frequency of the control will ensure the control is moved back to the "Attest" state. 

Point to remember is -> Policy Statements are related to Policies. So if you expect to retire a policy all the associated policy statements and controls are at risk of being retired too. 

Hope this helps !

Cheers. 

Priya

[Phil Swann]

Sorry Priya, I disagree with some of this. I think you can bring a Policy back from retired. More akin to Scott's comments above, but you need to be mindful of the ACLs and conditions on the UI Actions, as there is a method called isReviewer() which only lets a reviewer handle these actions. (How it determines reviewer can be quite obtuse, but something like being listed in Reviewers field, being the owner or being a member of the owning group). Even an Admin cannot override. Can be tricky for application users, and definitely something to consider at configuration. I suggest always having an owning group so there is always a way to get in. 

Also, regarding policy statements being made inactive, and retiring controls. I believe I have seen different results to this.

I will investigate and post back to confirm as I am happy to stand corrected 🙂 

To Scott's point about the attestation job, it changed in Madrid to point at the control level - and by default all controls inherit from the profile so the control can override. I would suggest keeping the job to run at control level and then set accordingly. You can always set to none.

On this, the date is determined by the last updated date of the assessment instance. So if you trigger everything on 1st Jan; this does not mean they will all re-trigger on 1st Jan. It depends how long the users take to submit each assessment instance.