Control Requirement Details View

The CAM view of the Control form has fields that have been added to capture the control requirement details.

To accommodate the control requirement details in the CAM view of a Control objective form a Control objective requirements related list is added.

Note:

The views of the Control objective form and Control form in the CAM view are almost the same as the Control objective and Control forms used in Policy and Compliance Management. However, some fields have been removed and some added in the forms to capture the control requirement details.

CAM view of a Control objective form

Table 1. CAM view of the Control objective form

Field	Description
Reference	Unique numerical identifier or the content reference number.
Family	Control objectives grouped into a family.
Active	Option to activate a control objective.
Family ID	Unique identification for a family of control objectives.
Name	Name of the control objective.
Source	Source of the control objective, which is NIST 800-53 revision 5 for which the test templates are provided.
Parent	Control objective that is not a child of the current control objective. This relationship is to avoid cyclic parent – child relationship.
Compliance Score (%)	Compliance score percentage calculated for this control objective and its color code: 80 and higher in green 80 to 50 in yellow below 50 in red
Creates controls automatically	Option to indicate that controls are automatically created when an entity is associated from the Additional entities related list by selecting Add relationship and the entity.
Create control requirements	Option to generate control requirements automatically for the control objective. Note: If there are no control objective requirements, then there won’t be any control requirements either.
Attestation	Reference to the metric type. GRC Attestation is chosen by default. Note: If the user changes the control attestation, the related control objective attestation type is changed also.
Impact	Potential impact to business functions because of loss of confidentiality, integrity, or availability of target and data.
Organizational guidance	Security control definitions from NIST, which when designated as common control definitions by organizations, are inheritable by one or more organizational targets.
Description	Description of the control objective.
Supplemental guidance	If it is control objective sourced by NIST 800-53 revision 4, then a direction for the control objective implementation.
Discussion	If it’s a control objective sourced by NIST 800-53 revision 5, then content-related information that is sourced by NIST.

Control objectives are just guidelines and aren’t specific to an entity or any object. You can link one control objective with any control objective requirement, and one control objective requirement with any number of control objectives, as the relationship between the control objective and the control objective requirement is many-to-many.

Table 2. Control objective requirements related list

Field	Description
Requirement number	Requirement number of the control objective.
Active	Option to make the requirement active.
Description	Detailed description about the requirement for the control objective.

In the Control objective requirements related list, you can select New to create a requirement for the control objective if necessary, based on which requirements are generated. Or, select Edit to add an existing control objective requirement to the control objective.

Note:

• If the control objective is in the Inactive state, you cannot create or add control objective requirements. Therefore, New and Edit are not available.
• If the control objective requirement is inactive, you cannot add a control objective to the control objective requirement.

CAM view of the Control form

Table 3. CAM view of Control form

Field	Description
Reference	Unique identifier.
Name	Name of the control.
Number	Unique identification number of the control.
Entity	Related entity. Note: If you change the state of the entity to Active from Retired state, then the manually created control on the entity also moves to the Draft state.
Control objective	Related control objective.
Owner	User who owns the policy. Note: The owner is always added as a respondent. The control owner that you select belongs to the owning group.
Status	Control status. Possible choices are: Compliant Non-compliant Not applicable
State	Control state. Possible choices are: Draft: When the control is created from a control objective, controls are in this state. In this state, all compliance users can modify the control. Only available when creating a one-off control. One-off controls are possible but not recommended. Attest: When you select Attest and take attestations, the control moves to this state. Note: When a control is set back to draft, the attestation is canceled. Review: Controls are automatically moved to review from the attestation phase. Monitor: In this state, all compliance managers can move the control from review to monitor. Retired: Compliance managers or administrators can move a control from Monitor to Retired. Note: When a control is retired: Associated indicators don’t run Associated attestations are canceled Changes to associated control objectives don’t update the control
Authorization package	The authorization package that the control is associated with or originating from.
Frequency	List of options: Event Driven Daily Weekly Monthly Quarterly Semi-Annually Annually Attestation is sent based on the value selected for the control or control requirement. Note: For information on the difference between the Frequency field for a control and the Attestation Frequency field in an entity, see KB0694607.
Weighting	Value used when calculating control score effectiveness.
Owning group	Group that owns the policy.
Control allocation	Type of control that is created: either system-specific or hybrid.
Description	Description of the control.
Discussion	Content-related information from NIST 800-53 revision 5.
Supplemental guidance	If it’s a control sourced by NIST 800-53 revision 4, then a direction for the control implementation.
Implementation statement	An explanation on how the control will be implemented. This information is required if the control is created from an authorization package and in the Draft state.
Attestation
Take attestation at requirement level	Option to send attestations at the control requirement level and not at the control level.
Attestation	Select from a list of options. Other attestation types can be configured. If this field is populated, then the Attestation Respondents value is required, and the owner is made the respondent. Note: If the user changes the attestation type in the control objective, all related controls are also changed.
Attestation respondents	Users assigned to the attestation of this control. Only a user with the sn_grc.user role can be added as a respondent. Note: When both the Attestation and Attestation respondents fields are set, attestations are created when you select Attest.
Activity Journal
Additional comments	Public information about the control.
Activities	Message logs of control state change.

Table 4. Control requirements related list

Field	Description
Number	Control requirement's unique number.
Requirement number	Reference number.
Control	Control to which the control requirement is associated.
Status	Status of the control requirement.
State	Requirement state.
Frequency	Control frequency.
Description	Description of the control requirement.
Attestation
Attestation	Attestation metric type.
Attestation respondents	Users who attest the control requirement.
Activity Journal
Additional comments	Information about the control requirement. When the control objective requirement is dissociated, that is removed or deleted, the control requirement becomes manual. This information is logged in this field.
Activities	Message logs of control requirement's state change.