Study guide
8.3 Configuring and Using Auditing
SailPoint Certified IdentityIQ Engineer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: The IdentityIQ Engineer Exam
1.1 Exam Format, Official Blueprint, and Study Strategy
2 Chapter 2: Infrastructure, Installation, and Extended Attributes
2.1 IdentityIQ Infrastructure Components 2.2 Installation Steps and Procedures 2.3 Creating Extended Attributes and the Objects That Support Them
3 Chapter 3: Build, Deployment, Patching, Access, and Email
3.1 Ongoing Build and Deployment 3.2 Installing Patches and Performing Upgrades 3.3 Configuring End-User Access 3.4 Email Server Settings and Email Redirection
4 Chapter 4: Lifecycle Manager Configuration, Provisioning Policies, and Workflows
4.1 Configuring Lifecycle Manager 4.2 Identity Provisioning Policies 4.3 Configuring LCM Workflows
5 Chapter 5: Lifecycle Events, QuickLinks, Batch Requests, and Rapid Setup
5.1 Lifecycle Events and Their Workflows 5.2 QuickLinks and QuickLink Populations 5.3 Configuring and Using Batch Requests 5.4 Rapid Setup in Lifecycle Events and Identity Operations
6 Chapter 6: Certification Campaigns and Certification Rules
6.1 Configuring and Scheduling Certification Campaigns 6.2 The Purpose of Common Certification Rules
7 Chapter 7: Policies and Policy Violations
7.1 Configuring and Leveraging Policies 7.2 Responding to Policy Violations
8 Chapter 8: Reporting, Advanced Analytics, and Auditing
8.1 Executing and Leveraging Reports 8.2 Leveraging Advanced Analytics 8.3 Configuring and Using Auditing
9 Chapter 9: Rules, Rule Libraries, and the SailPoint API
9.1 The Purpose and Use of Rule Libraries 9.2 Rule Input and Output Arguments 9.3 Common SailPoint API Objects and Methods
10 Chapter 10: Workflow Development
10.1 Workflow Variables, Transitions, and Step Conditions 10.2 Workflow Steps That Generate Work Items 10.3 The Different Workflow Step Usages 10.4 Leveraging Sub-Workflows
11 Chapter 11: Email Templates, Branding, and Localization
11.1 Customizing and Using Email Templates 11.2 Branding the SailPoint User Interface 11.3 Localizing the SailPoint UI
12 Chapter 12: Application Definitions, Connector Settings, and Rapid Setup Aggregation
12.1 Configuring Application Definitions 12.2 Configuring Common Connector Settings 12.3 Configuring Rapid Setup Aggregation Settings
13 Chapter 13: Data-Loading Tasks and Application and Connector Rules
13.1 Scheduling Tasks for Data Loading and Processing 13.2 Common Application Rule Types 13.3 Common Connector Rule Types
14 Chapter 14: Debugging with log4j, Syslog, and the IdentityIQ Console
14.1 Configuring and Leveraging log4j 14.2 Configuring and Leveraging Syslog 14.3 Leveraging the IdentityIQ Console for Debugging
15 Chapter 15: Debug Pages and the Administrator Console
15.1 Leveraging the Debug Pages for Debugging 15.2 Leveraging the Administrator Console for Debugging
16 Chapter 16: Role Model and Identity Attribute Mappings
16.1 Default Role Models and Role Types 16.2 Configuring Roles and Role Options 16.3 Configuring Identity Attribute Mappings
17 Chapter 17: Data Objects, Relationships, and Group Types
17.1 Common IdentityIQ Data Objects 17.2 Relationships Between Common Data Object Models 17.3 The Difference Between Group Types
8.3 Configuring and Using Auditing
Key Takeaways Explain This Topic AI
Audit Configuration (gear icon > Global Settings > Audit Configuration) selects General Actions, Link Attribute Changes, Identity Attribute Changes, Class Actions, and SCIM Resource Actions.
Auditing is selective on purpose, because every captured event costs performance and storage.
Audit records are viewed with Advanced Analytics Audit Search and can be saved as scheduled reports.
Identity snapshots from Maintain identity histories, Access History (from 8.4), and the Provisioning Transaction log provide history that auditing alone does not.
Work item actions and SAML electronic signature details are auditable only when the matching audit options are enabled.
Last updated: September 2026
Configuring and Using Auditing
Objective 3.7 is configure and utilize auditing . In IdentityIQ, auditing means recording audit events : who performed an action, what was acted on, when, and with what values. It is not on for everything by default . The documentation explains that collecting and storing event information affects performance, so a system administrator chooses which actions to audit . Nothing appears in an audit search until auditing is configured.
Audit Configuration
Go to gear icon > Global Settings > Audit Configuration . The page groups auditable actions into five categories:
Category Examples
General Actions Typical actions such as running a task, signing off on a certification, login-related events, and work item actions
Link Attribute Changes Changes to selected account attributes
Identity Attribute Changes Changes to assigned roles, capabilities, authorized and controlled scopes, and passwords; may include extended identity attributes
Class Actions Create, update, and delete on configuration classes, for example editing a role, creating a policy, setting the default email template, or adding attachments
SCIM Resource Actions Create, read, update, and delete on SCIM resources
Select only what your auditors need. An exam scenario may say "the audit team wants to know who modified the Finance Approver role." The answer is to enable the class action for Bundle (role) changes before the change happens. Auditing is not retroactive.
Some features depend on specific options:
Work items: include work item actions in the General Actions to audit, then search them with Audit Search.
SAML electronic signatures: check the Login option so SAML details for electronic signatures (assertion ID, issue instant, issuer, NameID, sign-off validity) are captured.
Attachment pruning: enable the Prune Pending Attachments audit option to record when System Maintenance deletes abandoned attachments.
Using Audit Data
Audit Search (Intelligence > Advanced Analytics > Audit) finds records by action , source (who), target (what), and date range . Selecting an event such as AccessRequestStart , ApproveLineItem , or RejectLineItem shows its details.
Save the search as a report to schedule it and give auditors ongoing evidence.
Audit events are distinct from application activity . The documentation notes that audit log events are not tied to an application data source and may not be tied to a specific identity.
Custom code can write its own audit events, for example from a workflow step, so that business-specific actions appear in the same audit trail.
History Beyond Audit Events
Auditors often ask questions that audit events alone do not answer. Know the neighboring features:
Feature What it records How it is enabled
Identity snapshots and history Point-in-time copies of identities Maintain identity histories in Identity Refresh; certifications also create snapshots. Pruned per Days before snapshot deletion .
Access History (8.4 and later) A timeline of identity access changes in a separate Access History database Disabled by default; the Dispatch Access History task runs daily at midnight by default once enabled
Provisioning Transaction log Each provisioning action and its result Global Settings > IdentityIQ Configuration > Miscellaneous (log all or failures only, retention days); viewed in the Administrator Console
Certification records Decisions and sign-offs Kept with certifications; SailPoint recommends certification reports , not certification archives, to preserve evidence
- Report sign-off Who signed off on report results Require Signoff on the report
- Retention and Performance
Every enabled audit action adds rows. Enable what compliance requires, and review the list periodically.
History objects are pruned by the Perform Maintenance task according to the Miscellaneous tab settings: snapshots, task results, provisioning transactions, certification archives, and syslog events. The documentation warns that pruned objects cannot be recovered without a backup.
What an Audit Record Tells You
An audit record answers four questions:
Action – what happened, such as a role update, a line-item approval, or a login.
Source – who or what performed it, such as a user name or a system process.
Target – the object affected, such as an identity, role, or policy.
When – the timestamp.
Some events also record the attribute name and values involved. Identity attribute changes, for example, can show the old and new value. That is why Link and Identity Attribute Change auditing is chosen attribute by attribute : auditors usually need only a few sensitive attributes, such as manager, department, or capabilities, not every field that aggregation touches.
A good auditing design starts with the auditors' questions. List the evidence each control needs, map each item to an audit action, history feature, or report, and enable only those actions. Then schedule the saved audit searches as reports so the evidence is produced automatically.
Worked Example
The security team asks: "Show every change to capabilities and every role edit in the last quarter, and send it monthly."
Audit Configuration: under Identity Attribute Changes , enable capability changes. Under Class Actions , enable the role (Bundle) actions. Save.
From then on, run Audit Search filtered by those actions and dates.
Save Search As Report and schedule it monthly with an email recipient and PDF attachment (section 8.1).
For "what access did Pat have on March 1?", point auditors to Access History or identity snapshots, because audit events record actions, not complete access states.