Control Attestations requirements

David347
Tera Contributor

We are currently looking at putting in some Control Attestations and I have been informed that all Control Attestations HAVE to start with a Yes/No Question on whether the control is compliant or not.

I thought that the whole point of weighting the questions was that you can generate a compliance score?

Q1. blah blah - weight 10

Q2. blah blah - weight 10

Q3. blah blah - weight 10

Q4. blah blah - weight 10

If weight = 30 then you are compliant?

My understanding could be wrong.

I appreciate your guidance.

10 REPLIES 10

No you do not.

https://docs.servicenow.com/bundle/rome-governance-risk-compliance/page/product/grc-policy-and-compliance/task/create-attestation-using-attestation-designer.html

No you don't. You need to define at least one Correct answer in the Attestation Designer. This can be a value, a choice or multiple choices. Only the default attestation type template has a yes/no to keep things simple.

Hi, you only need to choose one "Correct Answer" in the Attestation Designer. You can pick from checkbox, values/strings, and so on. 

 

Yes/No is just the default checkbox option used in the GRC Attestation template

@David347 I would recommend using the Smart Assessment attestation. You dont have to use the Yes/No question time and dont have to start with it. Ideally you should have some logic to determine if an attestation indicates a control is compliant/non-compliant. You can use the automation in flow designer with Smart assessments to build what ever logic you like. OOTB the Yes/No is used to indicate a control is compliant but you can use what ever you like.

Your statement After the Control attestation is completed , it comes for Review and automatically has Status of the control "Complaint" is not correct.

If the answer to the first question of the attestation (which should have a Yes/No response) is "No" then the control becomes Non-Compliant (an issue record is also created).  If the the answer to that question was "Yes" then the control becomes Compliant.

That's the behaviour that has existed for a number of platform releases now.

Looking at the script include that governs this there may be more flexibility that can be exploited to it (as of the Tokyo compatible plugin) David was asking -- I'm looking into this as we speak as it happens and will come back if I find anything of value here.