An auditor asks who edited the Finance Approver role last month, but Audit Search returns nothing. Auditing was enabled yesterday. What explains the result?

Audit events are recorded only after the relevant action is enabled, so earlier role edits were never captured.. Auditing captures only the actions configured on the Audit Configuration page, and it is not retroactive. Class actions such as role edits must be enabled before the changes happen.

Which Audit Configuration category covers creating a policy or editing a role?

Class Actions. Class Actions are actions on the underlying classes that configure IdentityIQ, such as editing a role, creating a policy, specifying the default email template, and adding attachments.

A compliance team needs to know exactly which roles and entitlements an identity held on a past date. Which IdentityIQ feature is designed for this?

Access History (or identity snapshots), which record access states over time. Audit events record actions. Access History, from 8.4, builds a timeline of identity access in a separate database, and identity snapshots from Maintain identity histories capture point-in-time identity data.

Why does IdentityIQ require administrators to choose which actions to audit, rather than auditing everything by default?

Collecting and storing audit events affects performance, so only needed actions should be captured.. The Audit Configuration documentation says that collecting event information and storing it in the audit logs affects performance, so a system administrator must specify which actions are audited.

Configuring and Using Auditing — Free Study Guide 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.

SailPoint Certified IdentityIQ Engineer

8.3 Configuring and Using Auditing

Key Takeaways