LogiUpSkill

Control and Control Objective

Control and Control Objective 1.Introduction In Governance, Risk, and Compliance (GRC), a control is a specific process, action, or technical measure implemented to reduce risk and ensure compliance with organizational policies and regulatory requirements. Controls provide evidence that business activities are being performed securely and effectively. A control objective, on the other hand, defines the high-level goal or desired outcome that these controls are designed to achieve. It sets the direction for what needs to be accomplished—for example, protecting sensitive data, ensuring accurate financial reporting, or maintaining proper access management. Together, control objectives outline the “what,” while controls define the “how,” enabling organizations to manage risks consistently and maintain strong governance. 2.What is Control objective A control objective is an objective, direction, or standard that acts as guidance for company interactions and operations. Control objectives can be categorized, classified, and related to policies. Control objectives are breakdown of policy A policy holds multiple control objectives, and control objectives hold multiple policies. It’s many to many relationships. From control objectives it will create control 3.What is Control? Control is specific implementation of a control objective Controls are automatically generated when you associate a policy with an entity type, or an entity type with a control objective. A control is created for each entity listed in the entity type for the control objective. Control can also be manually created 4.Role required for control and control objective Compliance User /Compliance analyst(User) Control Owner Compliance Manager(sn_compliance.manager) Attestation Creator(sn_compliance.attestation_creator) Compliance Reader(sn_compliance.reader) 5.Difference between control and control objective  Feature Control Objective Control Definition A high-level, desired outcome or goal that guides compliance efforts. A specific, actionable task or activity performed to meet a control objective. Hierarchy At a higher level; a policy can have multiple control objectives, and a control objective can be implemented across multiple entities. A lower-level, concrete instance of a control objective. Purpose To define what needs to be achieved, often based on a policy or regulation. To perform the actual action to achieve the objective for a specific entity. Example “Ensure all remote employees have the necessary equipment.” A specific control created for each remote employee, detailing what equipment they need. 6.Fields of Control Objective Field Name Type Explanation objective_id String Unique identifier for the control objective objective_name String Name of the control objective objective_description Text Detailed purpose and scope of the control objective related_entity Reference/ String Entity or business unit linked to this objective risk_statement Text Risk that this objective mitigates classification_score Number Score representing risk classification residual_risk Choice Remaining risk after control implementation (Low, Medium, High, Critical) regulatory_mapping Text Link to regulations, standards, or frameworks this objective supports control_dependency Text Other objectives or controls that depend on this objective owner Reference/ String Person responsible for the objective start_date Date Effective start date of the objective end_date Date End or retirement date of the objective attestation_required Boolean Indicates if periodic attestation is required attestation_frequency Choice Frequency of attestation (Quarterly, Annually, etc.) last_attestation_date Date Date of the most recent attestation 7.Fields of Control Field Name Type Explanation control_id String Unique identifier for the control control_name String Name of the control control_description Text Purpose and details of the control control_type Choice Preventive, Detective, Directive, Automated, Manual control_owner Reference/String Responsible person for execution and monitoring related_objective Reference/String Linked control objective(s) control_frequency Choice Execution frequency of control (Daily, Weekly, Monthly, Quarterly, Annual) section Choice Business area (IT, Finance, Legal, Operational) assessment_method Choice Self-assessment, Audit, Automated assessment_date Date Date control was assessed assessment_result Choice Effective, Needs Improvement, Ineffective remediation_plan Text Plan to address gaps remediation_due_date Date Due date for remediation activities remediation_status Choice Not Started, In Progress, Completed closure_date Date Date control issue is resolved closure_comments Text Notes at closure risk_rating Choice Risk level associated with control (Low, Medium, High, Critical) last_audit_date Date Last date the control was audited attestation_required Boolean Indicates if control attestation is required attestation_status Choice Not Started, In Progress, Completed 8.How controls created When policy and Entity are connected it automatically generates control, if “Create controls automatically ” checkbox is checked in control objective. The count of Controls are dependent on the count of Entities. Control owning group  Owner will same as entity. 9.Process to create Control Objective from policy  Here under policy, we can create control objective, In review state In the related list of Policy, we can add control objectives by clicking on new or Edit UI action Create control objective In control objective Attestation, Entity Types should be added After creating entity types 7 controls will be created. Control count will be depending on the entities. 10.States of control  Draft: In this state, all compliance users can modify the control. Only available when creating a one-off control. One off control is possible but not recommended. Attest: When the control is created from a control, objective controls are in 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 control from Monitor to Retired.  11.Process flow of control 11.1 Draft state When a control is first created, it starts in the Draft stage. In this stage, the control can be edited as many times as needed until all details are properly defined and documented. Control in Draft is only considered “identified” and is not yet implemented or active. Usually, the Control Owner (the person responsible for the control) adds the required information. If they do not have all the details, the control can be reassigned to someone else who can complete it. Once all information is filled in, the control becomes ready to move to the next stage. The required fields at this stage are: Name Entity Attestation Respondents(not needed to create the control initially, but required before moving to the next stage) 11.2 Attest state After clicking attest UI action move to attest state Once the control is fully defined, the first attestation (also called a