LogiUpSkill

Menu

+91 996 011 2296

Policy in GRC

By Shubham KumbharPosted on Posted in UncategorizedTagged No Comments on Policy in GRC

Policy in GRC Contents What is Policy? Policy and Compliance Architecture. Roles Required Process Flow Diagram for Policy Policy – FORM View Policy All Fields Policy States and its Lifecycle 7.1. Approval Rule 7.2. Policy Versions 7.3. Policy Lifecycle Summary 1. What is Policy? A policy is a formal, high-level statement that defines an organization’s rules, expectations, and guiding principles. It sets the direction for how the organization operates and outlines what must be done to meet business goals, comply with regulations, and manage risks. A policy defines an internal practice that an organization or business process must follow to ensure compliance and reduce risk exposure. In simple words, A policy tells people what needs to be done and why it matters. Example – Employees must store company data only on approved, encrypted systems and are not allowed to save sensitive information on personal devices or share it through unauthorized applications. 2. Policy and Compliance Architecture 3. Roles Required   Role Name Description Compliance Reader [sn_compliance.reader] Read-only access to compliance data for reporting and monitoring. Compliance User [sn_compliance.user] Performs core compliance tasks: create policies, manage controls, test effectiveness, handle exceptions Compliance Manager [sn_compliance.manager] Manages daily compliance operations: approves policies, sets acknowledgements, monitors controls, produces reports. Compliance Administrator [sn_compliance.admin] Administers compliance application and data, manages dependencies and full configuration. Compliance Developer [sn_compliance.developer] Builds workflows, dashboards, reports, and platform components to enhance compliance processes.   4. Process Flow Diagram for Policy 5. Policy – FORM View Navigate to All > Policies and Compliance > Policies > New  Sections 6. Policy All Fields Field Description Name Title of the policy document. Type Category or kind of policy (e.g., Standard, Guideline, Framework). Owning group The team or department responsible for owning the policy. Owner The person responsible for the policy’s maintenance and governance. Compliance score (%) The calculated compliance percentage for this policy. Parent A higher‑level policy under which this policy is nested. Policy categories Classification tags or groups used to group similar policies. State Current lifecycle stage of the policy (e.g., Draft, Published, Retired). Valid from The date from which the policy takes effect. Valid to The date until which the policy remains valid (expiry). Approval method The method by which the policy must be approved. Approvers The individuals or roles who must approve the policy. Reviewers The individuals or roles responsible for reviewing the policy content. Contributors Individuals or roles who contribute content or updates to the policy. Description A short summary of what the policy covers. Policy text The full detailed text of the policy. Policy knowledge base The repository or knowledge base where this policy is stored. Published policy The specific published policy record this setup relates to. Policy template The predefined template used to structure and format this policy. Frequency How often users must acknowledge this policy (e.g., annually). First acknowledgement The date when users must first acknowledge the policy. Number of days to respond How many days users have to complete their acknowledgement. Audience The group of users who are required to acknowledge the policy. Reference material URL A link to supporting documents or resources related to the policy. Allow users to decline policy Enables a user option to refuse or decline the policy acknowledgement. Allow users to request exception Allows users to request an exception to the policy requirements. Maximum exception duration (days) The maximum number of days an approved exception can remain valid. Additional comments Any notes or remarks related to the policy’s configuration or changes.    7. Policy States and its Lifecycle Below flow represents the standard policy lifecycle within a GRC system. Each stage is a formal status that shows where the policy is in its journey from creation to retirement. 1. Draft This is the creation stage and Policies are created in Draft by default A new policy is being written for the first time, or an existing policy is being heavily revised. The Policy Owner (often a subject matter expert or manager) works with stakeholders (like Legal, IT Security, or HR) to write the content. Goal is to create the first complete version of the policy document that addresses a specific risk, regulation, or business need. Fill the mandatory fields along with other fields and then click on ‘Request Review’ UI button and fill the Message given below then state will change from Draft to Review. 2. Review The draft is complete and is now being circulated to a formal review team. This group includes reviewers and key stakeholders. These are often department heads, the GRC team, and the Legal/Compliance department. While in Review, reviewers can send the policy back to draft, edit the policy, can add additional comments Goal is to ensure the policy is accurate, clear, enforceable, and aligned with existing policies and regulations. Reviewer will review the policy and then click on ‘Request Approval’ UI Action the provide message then state will change from Review to Awaiting Approval. 3. Awaiting Approval Approvers receive the approval task in Awaiting approval​ and approvers can send the policy back to Review​ The policy has been reviewed, all feedback has been incorporated, and the final version is now locked. It is waiting for a final “go-live” signature. This is usually one or more designated Approvers, such as a committee, or the head of the business unit. Goal is to get formal, auditable sign-off that the policy is officially accepted by the organization’s leadership. Check Related List > Once Approved state will change from Awaiting Approval to Published. 4. Published Policy is published after approval​ The policy is now active and is the official standard for the organization. The GRC team or system administrator publishes the policy to a central portal. KB article is created in the KB identified on the policy record​. Goal is to publish the policy so it is accessible to employees and to trigger supporting activities such as communication, employee attestation, and mapping to related controls. KB Article is created for the Policy KB Article 5. Retired The policy is no longer active or relevant. The Policy Owner, with approval from GRC/Legal, initiates the retirement.

Policy Exception in GRC

By Shubham KumbharPosted on Posted in UncategorizedNo Comments on Policy Exception in GRC

Policy Exception in GRC 1. What is Policy Exception? A policy exception is a formally documented and approved deviation from a policy when a user or business unit cannot meet specific policy requirements. In simple words it provides temporary relief for control owners that are unable to meet compliance requirements. It allows temporary non-compliance under controlled conditions by capturing the justification, assessing the associated risk, and ensuring the exception is reviewed, approved, and tracked within the GRC framework. 2. Purpose of Policy Exception? Allows users to request documented exceptions when they cannot comply with a policy. Ensures exceptions are reviewed and approved to maintain controlled compliance. Helps identify and manage risks associated with policy deviations. Promotes accountability by requiring justification and transparency. 3. Roles Required Role Name Description sn_grc.business_user A GRC role for users who actively work on risk, compliance, and policy tasks. They can create/update issues, take/approve assessments, respond to evidence requests, and request/approve policy exceptions. Intended for broader participation in GRC processes. sn_grc.business_user_lite A limited-scope role for business stakeholders needing basic GRC interaction. They can report/read issues, respond to assigned tasks (attestations, evidence, questionnaires), and view/submit policy exceptions, but with fewer permissions than full business_user. 4. Process Flow Diagram for Policy Exception 5. Policy Exception – FORM View Navigate to All > Policies and Compliance > Policies Exceptions > My policy Exceptions > New Sections 6. Policy Exception All Fields   Field Description Number Unique identification number. Requester Person requesting the policy exception, usually the control owner. Approval group Group that has the compliance manager role. You cannot edit the approval group if the policy exception reaches Review state. If you do not provide an approval group, then the field defaults to compliance manager. Compliance manager is the default role if the policy exception is raised from any upstream application that is integrated with GRC. Approver User from the approval group. If the exception policy moves to the Analyze State, then you must select an approver. State State of the policy exception within the approval workflow. Substate Approval substate of the policy exception within the approval workflow. Priority Approval priority of this policy exception Watch list Users that are notified when the request is updated. Name Unique name of the policy exception. Reason Reason for requesting the policy exception. The requester can change the reason until the policy exception is approved. Justification Statement of explanation for the policy exception. Justification is also displayed in the additional comments. Source type Type of policy exception that you want to create. The options are: Control objective Control objective associated with this policy exception. Issue Issue associated with this policy exception. Target record Target record table on which the policy exception is applied. This table is also referenced in the Policy eception target table field of the Policy Exception Integration Registry Form. Risk rating Select the risk rating as determined by the risk assessment performed on the policy exception. Risk description Description of the risk as performed by the risk manager during risk assessment. Analysis of risk and impact Details on the likelihood of this risk occurring and residual impacts of this risk on the policy exception. Risk mitigation plan The risk mitigation plan for this policy exception. Valid from Day on which the policy exception begins. Valid to Day on which the policy exception ends. Duration Number of days between the Valid From and Valid to dates. Approved extensions Number of times extensions have been requested so far and have been approved. Remaining extensions Number of times extensions can be requested in future. Created Date on which the policy exception was requested. Date approved Date on which the request was approved. Extension date Requested extension date, which is after the Valid to date. Extension reason Reason for extension. Original valid to Date until which the policy exception was originally requested and approved. The original Valid to date is populated only when the extension is approved. Work Notes Work notes can be used by exception reviewers and approvers to share Information about the exception. Additional comments These comments are used by the reviewer to communicate additional information to the exception requester. 7. Policy Exception States and its Lifecycle 7.1. How to request Policy Exception Login to esc Portal > Open ‘Request Extension’ Record Producer > Submit Fill all the required fields Submit the Request 7.2. States of Policy Exception New When creating new policy exception from Native UI then state is NEW An exception request is created because a user, team, or system cannot meet a specific policy requirement. Person involved in this state is the Requestor (business user, system owner, or application owner). Goal is to document the need for the exception, including justification, scope, risk, and proposed compensating controls. Provide all the mandatory information and save the record then , once request gets created then state changs from New to Analyze      2. Analyze When Policy exception record is created then it is in Analyze state. The exception is being evaluated for risk, impact, and validity to determine whether it should move forward. Persons involved in this state are Risk team, Compliance/GRC analysts, and sometimes the Policy Owner. Goal is to review the justification, assess risks, determine required compensating controls, and confirm whether the request is reasonable. Provide Approver and Risk rating then click on ‘Request Compliance Review’ then state will change from Analyze to Review      3. Review Detailed review of the refined exception request after analysis is complete. Persons involved in this state are, reviewers such as department leads, technical SMEs, or policy owners. Goal is to validate accuracy, check completeness, ensure risks are understood, and confirm alignment with business/legal requirements. Click on UI action ‘Request Additional Approval’ but make sure your requester has manager assigned then state will change from Review to Awaiting Approval.    4. Awaiting Approval The exception has passed review and is now pending formal approval. Designated Approvers such as senior leadership, risk committees, compliance managers, or policy owners are responsible in this state Goal is

Service-now Interview Questions

By Omkar BulbulePosted on Posted in UncategorizedNo Comments on Service-now Interview Questions

Service-Now Interview Questions Question & Answers What is difference between UI Policy and Client Script Client Script will execute first than UI Policy. UI Policy has condition but Client script does not (we need to write manually through code) UI Policy has condition where we can access the fields which are not on the form but client script does not, Client script can access only the fields which are on the form. What is import set table? Import set table is a temporary table where we will put the data for temporary purpose and later we can move the import set data to target table using transform map. Whenever we are pulling the data from external source, it is a standard process to get data into import set first and then validate the data using transform scripts and then transform the data into target table. Import set table always extends import set row table. By default import set table fields are of string type. Import set table can be used to debug the integration where we are pulling the data from external source. Update Set? Update set is used to capture the customization i.e. development in servicenow. Update set will capture the versions of every development components. Only the table data, which has update_synch attribute =true, get captured into update set. Only completed update set can be moved to another instance. We should not change the update set state from completed to in progress as per standard practice. Display business Rule? Display business rule will run when the data is getting populated on the form from server. Here we can use g_scratchpad global variable to send the service side information to client side script. For display business rule, we don’t have option like update, insert, query and delete in business rule form. Client Script will execute first than UI Policy. UI Policy has condition but Client script does not (we need to write manually through code) UI Policy has condition where we can access the fields which are not on the form but client script does not, Client script can access only the fields which are on the form. Import set table is a temporary table where we will put the data for temporary purpose and later we can move the import set data to target table using transform map. Whenever we are pulling the data from external source, it is a standard process to get data into import set first and then validate the data using transform scripts and then transform the data into target table. Import set table always extends import set row table. By default import set table fields are of string type. Import set table can be used to debug the integration where we are pulling the data from external source. Update set is used to capture the customization i.e. development in servicenow. Update set will capture the versions of every development components. Only the table data, which has update_synch attribute =true, get captured into update set. Only completed update set can be moved to another instance. We should not change the update set state from completed to in progress as per standard practice. Display business rule will run when the data is getting populated on the form from server. Here we can use g_scratchpad global variable to send the service side information to client side script. For display business rule, we don’t have option like update, insert, query and delete in business rule form.

ITSM

By Pulkit SaraswatPosted on Posted in UncategorizedNo Comments on ITSM

ITSM Question & Answers Processes in Service Operations Incident Management Problem Management Change Management Incident Management Any interruption in service is raised as an Incident Purpose is to restore normal service operations Purpose is to minimise the effect by workaround if restore is not possible Impact and Urgency are defining the Priority Challenges Detect an incident as soon as possible Incident workaround or resolution should get documented Incident assignment for L1, L2 and L3 support Correct assignment of priority in automated generated incidents Example: Not able to login in system Not able to swipe the swipe card Not able to send an emails Problem Management: Two or more incidents will raise problem Problem is to find out permanent solution for incidents through change. Reactive and Proactive Problems Known Error Workaround Examples: If we got more than one incidents like 10 users incidents that they are not able to login into system, it means something wrong with system. If we got more than one incidents for swipe card, it means the swipe machine has an issue rather than the swipe card, so we will raise one Problem for all the incidents and instead of working 10 engineers on incident will assign one engineer on Problem to fix all the incidents. Change Types Change is to enable beneficial changes to be made with minimum disruption to existing services. Definition: Change is “the addition, modification or removal of anything that could have an effect on IT services”. Normal Change – go through routine change go through all the process Any service change that is not a standard change or emergency change. Standard Change –  pre-approved change— relatively low risk A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction. Emergency Change –  must be deployed as soon as possible within 24 hours like system go down, serious defect. IT should have different group of approval(CAB=Change Advisory board) A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch. Incident Management Problem Management Change Management Any interruption in service is raised as an Incident Purpose is to restore normal service operations Purpose is to minimise the effect by workaround if restore is not possible Impact and Urgency are defining the Priority Challenges Detect an incident as soon as possible Incident workaround or resolution should get documented Incident assignment for L1, L2 and L3 support Correct assignment of priority in automated generated incidents Example: Not able to login in system Not able to swipe the swipe card Not able to send an emails Two or more incidents will raise problem Problem is to find out permanent solution for incidents through change. Reactive and Proactive Problems Known Error Workaround Examples: If we got more than one incidents like 10 users incidents that they are not able to login into system, it means something wrong with system. If we got more than one incidents for swipe card, it means the swipe machine has an issue rather than the swipe card, so we will raise one Problem for all the incidents and instead of working 10 engineers on incident will assign one engineer on Problem to fix all the incidents. Change is to enable beneficial changes to be made with minimum disruption to existing services. Definition: Change is “the addition, modification or removal of anything that could have an effect on IT services”. Normal Change – go through routine change go through all the process Any service change that is not a standard change or emergency change. Standard Change –  pre-approved change— relatively low risk A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction. Emergency Change –  must be deployed as soon as possible within 24 hours like system go down, serious defect. IT should have different group of approval(CAB=Change Advisory board) A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch.

Getting Started with Power BI – A Complete Beginner’s Guide

By Omkar BulbulePosted on Posted in UncategorizedNo Comments on Getting Started with Power BI – A Complete Beginner’s Guide

🏷️ Keywords: power bi tutorial, business intelligence course, power bi for beginners 📝 Intro: Power BI is Microsoft’s leading business intelligence tool used to visualize and analyze data.This guide helps you understand its basics and how to create your first dashboard. 🔹 Key Points: 🔚 Conclusion: Power BI empowers professionals to turn data into decisions. Learn it step-by-step to boost your analytics career.