As we discussed in the first blog in the series, the ultimate goal of any Governance, Risk and Compliance (GRC) program is to create standardized, measured, controlled, repeatable processes that allow for continual improvement and optimization. In the first phase of this journey, Get Clean, you establish a baseline for the risk environment, including single and cross-application Segregation of Duties (SoD). Then you institute a risk management approach and address the risks detected in the current environment.
SoD is the practice of ensuring that no one user or role can transact every activity within any business process from start to finish without other user involvement or other checks and balances. Or, put more succinctly, no user should be able to perform unauthorized transactions. Sensitive Access (also referred to as Critical Access) is just as it sounds, ensuring only appropriate and approved users/roles have access to transact sensitive or essential business activities (such as provisioning users or setting up the General Ledger). These items are highly regulated and require well-designed controls to help ensure access is appropriate and commensurate with a user’s job responsibilities (least privilege).
The first step toward accomplishing this goal is to “Get Clean” by establishing risk rulesets, executing detective risk reports and usage analysis, and documenting mitigating controls.
Establishing Risk Rulesets
Fine-grained Segregation of Duties (SoD) and Sensitive Access entitlement rulesets for individual applications – and cross-application checks – ensure that the business has a baseline for its customized risk appetite. Customizing the ranking of risks from Low to Critical allows for consideration of industry and company-specific nuances. The established risk rulesets will be the baseline for driving the risk management and governance program forward.
The risk ruleset tells you when you have a Segregation of Duties (SoD) or a sensitive access risk. You can address the risks in SoD reports through either mitigation (applying a control to monitor risk for users) or remediation (removing the access causing the risk). And then, you will need to document the controls that help you address those risks.
A GRC solution with out-of-the-box rulesets puts you ahead of the game. Saviynt’s Application Access Governance (AAG) solution includes such rulesets for all the applications below, and can also build rulesets for custom applications.
In Saviynt AAG,
- Rulesets include key risks for business processes supporting Record to Report, Purchase to Pay, Order to Cash, Acquire to Retire, Cash Management, Supply Chain Management, Human Capital Management, and others
- Rulesets are built to the most granular, fine-grained entitlements that support transacting critical business activities within these applications (tcodes in SAP, Functions in Oracle EBS, Privileges in Oracle ERP Cloud, etc.)
- Rulesets can be built across applications (for example, when Sales Order Management is in Salesforce and Accounts Receivable is in SAP)
Ruleset Configuration into Saviynt AAG
Saviynt AAG analyzes Critical Access and SoD based on the most granular application drivers that enable access to perform business activities within the application, fine-grained entitlements. These fine-grained entitlements are grouped into business functions (e.g., creating a journal entry or a new supplier). These business functions are then grouped into risks and tested to show where potential SoD conflicts might exist when users/roles have access to multiple functions (e.g., creating a vendor and paying a vendor).
SoD Ruleset Creation in Saviynt AAG
Rulesets are fine-tuned to an organization’s specifications accommodating custom functionality and removing risks, functions, and entitlements that are not in scope. These are uploaded directly to Saviynt utilizing easy-to-use templates. Once uploaded, your organization is ready to run SoD assessments in a few hours. Rulesets can be managed in Saviynt along with mitigating controls that might be utilized to accommodate SoD Violations.
Executing Detective Risk Reports and Usage Analysis
Once the company implements risk rulesets, it requires a baseline of the current risk environment. Executing a detective risk report establishes the current state and drives the future state goals. Risk assessment results can be grouped in order of criticality, by process area, or by various other slice-and-dice metrics to determine the order of the cleanup needed.
Documenting Mitigating Controls
When cleaning up a risk, there are three options:
- Remediate (remove) the risk from a user
- Mitigate the risk for a user
- Ignore the risk
The choice each company makes is dependent on its risk appetite and audit requirements. A typical example is that Low ranking risks are reported on but do not require any further action. In contrast, Medium and High risks typically require mitigation or remediation, and Critical Level risks require remediation and are not allowed to remain assigned to users.
Mitigating controls are established processes or reports tied to a user risk when threat remediation is not an option (e.g., monthly review of vendor payments for appropriateness). Mitigating controls should document procedures, control ownership, and the risks that map to the control.
Addressing Risks in SoD Reports
Once the risk environment has been baselined and approved mitigating controls are documented and mapped to approved risks, it is time to clean the environment. Based on the established risk appetite, each user risk should be flagged for reporting, remediated by removing the access causing the risk, or mitigated by applying an approved control.
Addressing SoD Violations in Saviynt AAG
Once the SoD Assessment has been run on all applications, SoD violations can be managed from one central location for all conflicts. SoD Violations for each specific application can be sorted and accommodated by application. SoD Violations can also be grouped into logical sets of data (such as violations by role, risk, entitlement, etc.) to better assist and target remediation. From this screen in Saviynt, violations can be risk accepted, remediated, or mitigating controls can be assigned as appropriate.
The successful completion of this step moves the company into a point in time “clean” environment. From here, you can proceed to the next step, Stay Clean. Our upcoming blog in this series will cover the steps to achieving the Stay Clean and Optimize phases in the application access governance maturity process.
