Register Sign in Need help? FAQ SailPoint directory
Help
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Best practices for Sarbanes-Oxley (SOX) compliance, reporting, and auditing in IdentityIQ

Best practices for Sarbanes-Oxley (SOX) compliance, reporting, and auditing in IdentityIQ

 

In today’s world, employees, contractors, partners and even consumers require access to strategic applications and data, which may reside on-premises or in the cloud. As a result, it’s becoming more challenging for organizations to ensure that workers’ access is appropriate and in compliance with business, legal and regulatory policy. Without enterprise-wide visibility and control over users and their access, organizations can have serious gaps in their ability meet regulatory requirements.

Achieving transparency and managing risk around identity management requires organizations to inventory, analyze and understand the access privileges granted to their workers – and to be ready to, at any time, answer the critical question: “Who has access to what?” Failure to effectively manage user access to sensitive resources places companies at increased risk for sabotage, fraud and data breaches.

The Sarbanes-Oxley Act, often abbreviated as SOX, places compliance and auditing requirements on all public companies traded on United States exchanges, including international companies. Entities are responsible for ensuring the accuracy of financial information and the reliability of systems that generate it. Section 404 of the act requires management to assess internal controls and obtain attestation from external auditors annually.

Important: This document discusses some suggested best practices for maintaining regulatory compliance. This document should not be construed as offering legal advice or a comprehensive compliance solution.

About links in this document: Links to product guides, white papers, and training courses included here are current as of the time of this writing. Check Identity University and Compass for updates to our training courses, and for links to the product guides for your release of IdentityIQ.

 

The key to compliance success is defining measurable steps to build a repeatable, sustainable compliance process across all identity tasks and activities. Here are some steps you can consider as part of your SOX compliance program.

 

Assess your current state

A good starting point for any identity governance project is to understand the current state of user access within the organization by centralizing identity data. This stage involves creating a single repository for user and access information by extracting data from authoritative sources and all target resources, both on-premises and in the cloud, then performing initial access certifications to clean up that data.

 

Identify applications of interest

SOX compliance typically focuses on financial applications. Non-financial applications that support financial applications, or other systems that provide access to sensitive business information, may also need to be included in your SOX compliance program. Note that access can mean physical controls, such as doors and badges, as well as electronic controls. Work with your organization's business experts and compliance team to identify all applications that should come under SOX compliance controls.

 

Aggregate and correlate identity data

The aggregation and correlation process resolves inconsistencies between your various sources of identity data, creating an enterprise-wide view of identities that enables the organization to implement appropriate controls and to better manage risk. This process provides visibility into accounts that do not correlate to users in authoritative sources (such as orphan accounts or system/service accounts) and enables removal of those accounts, or their assignment to owners for ongoing management.

Auditors typically ask for a report of accounts or identities in the governance system (IdentityIQ) and compare that to a report obtained directly from the authoritative source. Auditors may also ask for an explanation of the aggregation process (such as a query for JDBC connectors) of the authoritative source(s).

To learn more about aggregating data in IdentityIQ, see:

 

To learn more about correlating data in IdentityIQ, see:

 

Conduct baseline access certifications

After data aggregation and correlation, the next step is to perform an initial “data cleanup” certification on the newly-centralized identity data. At this stage, data/application owners and people managers should review access privileges for all users. These initial certifications should be used to establish a reliable baseline of data. It’s not unusual for organizations performing a baseline certification to find that 10 to 25 percent of user access privileges are inaccurate or inappropriate and should be revoked. After revocations are performed, this cleansed data will be used in other identity management functions, including ongoing access certifications, policy enforcement, access requests, and provisioning.

Auditors may require an audit trail showing an entitlement that was removed from an applications following a revocation action that stemmed from a certification in IdentityIQ. Various elements of IdentityIQ can be used to provide this evidence including the certification objects, identity entitlement and history, and reports.

To learn more about certifications and access reviews in IdentityIQ, see:

 

Build a governance model

Once you have a clearer picture of the current state of your data, and have made it centrally visible, you need to define the policies and controls your organization will use to ensure that all identity processes are performed in accordance with your organization’s policies and risk management strategy. The governance model covers important components such as access policies, roles, and risk.

 

Define policy models

As part of configuring controls for identity governance, your organization will need to define the identity policies that are required for meeting corporate and regulatory requirements across all critical resources. Identity policies that can be defined at this stage include separation-of-duty (SoD) rules that prevent users from holding potentially dangerous combinations of roles or entitlements, password policies, and other access policies that can enforce rules such as “no user can hold more than one account on a resource."

To learn more about policies in IdentityIQ, see:

 

Define role models

Roles are an important component of identity governance because they gather lower-level entitlements into groups, making it easier for business staff to review and approve user access privileges. The process of creating roles can be pursued incrementally, based on your organization’s needs; many enterprises begin by focusing on a defined set of departments or applications based on compliance or other business drivers. Once roles have been defined, they can be leveraged by many components of identity governance, including access certifications, policy enforcement, and access request management.

To learn more about defining a role model in IdentityIQ, see:

 

Define risk models

An identity risk model can be used to strengthen detective and preventive controls, such as access certifications, access approvals, or even authentication factors, for high-risk users and applications. For example, a person with simple read-only privileges and no access to critical applications would likely be considered low-risk, while a person who has numerous policy violations and has not been certified recently, or has access to key applications, would be considered high-risk.

To learn more about managing risk in IdentityIQ, see:

 

Automate detective controls

Once the organization has established a baseline of accurate identity data and built key components of the governance model, it’s time to focus on automating and streamlining your processes for detective controls. This phase consists of two major components: Access Certifications, and Policy Detection and Remediation.

 

Access certifications

Access certifications make it easy to perform regularly-scheduled access reviews by application and data owners, people managers, or a combination of both – or to review user access based on detected events, such as a position or manager change. Building on the policy, role, and risk models already established, these reviews clearly highlight detected roles, policy violations, and any changes from the previous certification (such as new users, new roles, or new entitlements). This information enables reviewers to quickly focus on areas of potential risk and make better decisions.

To learn more about certifications and access reviews in IdentityIQ, see:

 

Policy detection and remediation

After the policy model is defined, the organization can automatically scan and analyze identity data to quickly detect any issues, such as SoD violations. Based on these scans, detailed reports can be generated, showing violations grouped by application, department or geography. In addition, organizations can customize how policy violations are handled once they are detected. For example, low-severity violations can be summarized in reports, whereas high-severity alerts can automatically trigger notifications to managers for immediate remediation.

Auditors may require reviewing these reports and tracing the remediation of a violation to the revocation and removal of entitlements.

To learn more about working with policies and reporting on violations in IdentityIQ, see:

 

Automate preventive controls

Many organizations make the mistake of focusing their compliance efforts too heavily on detective controls: finding areas of non-compliance after the fact, and fixing them. What organizations need is a balance of detective and preventive controls. Preventive controls will help to ensure that compliance violations are not reintroduced into the environment - enabling organizations to not only get compliant, but stay compliant. Areas of user lifecycle management that should incorporate preventive controls include:

 

Self-service access requests

Centralized access request management allows managers and end users to conveniently request new access or make changes to existing access privileges within the constraints of pre-defined identity policy and role models. As a further preventive control, flexible approval workflows can be configured to ensure that manager, application owner, or other approvals are preemptively granted before access is even requested, reducing the time it takes to provision access to a new, approved application.

To learn more about self-service access requests and approval workflows in IdentityIQ, see:

 

Password management

To ensure that strong, secure passwords are in use, the organization should define password policies for all applications. This will enable the organization to ensure password strength, and to ensure that history policies are met when passwords are changed.

To learn more about password management in IdentityIQ, see:

 

Event-based lifecycle management

To certify that access changes such as employee terminations are handled quickly and accurately, organizations should implement automated provisioning based on triggers from authoritative feeds. By applying predefined policy to all provisioning processes, organizations can ensure that users acquire only the most appropriate levels of access for their job function.

To learn more about events and triggers in IdentityIQ, see:

 

Perform closed-loop audits on all changes

The final step in deploying identity governance involves the fulfillment of access changes on target resources such as applications, databases, and systems. In other words, this phase of the project is focused on ensuring that all changes triggered by revocations, access requests, or lifecycle events are successfully implemented within the IT environment.

Closed-loop validation of all access changes involves three steps that can be performed as part of routine operations:

 

Periodic data aggregation

Data aggregation should be scheduled to automatically run on a regular basis, to ensure that all access changes required during access certifications or for policy conformance have been made.

To learn more about aggregating data in IdentityIQ, see:

 

Identify exceptions

As an output of this validation, you should report all exceptions, such as access privileges that were revoked during a certification but have not been removed from a resource. This will enable prompt removal of those accounts or assignment to owners for ongoing management. You can also use the provisioning transaction table in IdentityIQ's Administrator Console to view and report on successes and failures in the provisioning process.

To learn more about handling and reporting on exceptions as part of a certification campaign, see:

 

Provide proof of compliance

As a final step in the compliance process, it's important to generate reports that reflect the decisions made during the governance process, and validate that the access privileges and policy violations that were marked for removal have been successfully remediated.

IdentityIQ's provisioning transaction table (available in IdentityIQ versions 7.1 and later, and accessed through the gear menu > Administrative Console) provides data about the provisioning activities in your system. In the provisioning transaction table, you can view and filter detailed information about all provisioning activities, and download provisioning data to a report that can be saved in PDF or CSV format.

IdentityIQ provides numerous out-of-the-box reports that can help you with your compliance auditing and record-keeping. In particular, you can look at all the reports in the Access Review and Certification Reports category; in the Administrative Reports category, reports such as the Revocation Live Report, Provisioning Transaction Object Report, Mitigation Report, and Work Item Archive Report can provide valuable data about your review and remediation activities.

To learn more about reporting, and about using the provisioning transaction table in IdentityIQ, see:

Version history
Revision #:
16 of 16
Last update:
‎Mar 24, 2023 07:39 PM
Updated by:
Community Administrator
 
View Article History