Audit Events in SailPoint IdentityIQ

In any identity platform, knowing what happened is just as important as deciding what is allowed. That is where Audit Events in SailPoint IdentityIQ come in.

It is a built in way of recording actions, decisions, and changes in the IIQ across the platform.

What Is Audit Event?

It is a persistent record of something that happened in IIQ. Audit event will answer these 5 questions:

• Who performed the action?

• What did they do?

• Where did it come from?

• Which object was affected?

• When did it happen, and what was the result of the action?

These events are stored in IIQ database as AuditEvent objects. You can also get these in the IIQ UI through search, or get it via reports.

Why We Need Audit Events

Audit events exist to give you accountability and traceability across the platform. They turn IdentityIQ into a clear source of truth for all identity related activity. Common reasons organizations rely on audit data include:

• Compliance and regulatory evidence:

  • Proof that access requests were approved.

  • Certifications were completed and signed off.

  • Policies were enforced and violations were handled.

  • Administrative changes were logged and attributable.

• When something goes wrong, audit logs help answer questions like:

  • Why did an identity lose access?

  • Who modified this role or entitlement?

  • Which workflow or task triggered a change?

• Security monitoring and forensics:

  • Detect risky or unusual admin behavior.

  • Alert on privileged access changes.

  • Support investigations after incidents.

• Business‑level logging
  Beyond the built‑in system events, teams often log business‑specific information such as:

  • Provisioning tied to a ticket or request ID.

  • Creation of privileged or service accounts.

  • Exceptions, overrides, or special approvals in workflows.

This is especially useful when you have custom workflows driving complex access and provisioning logic.

What Information Do Audit Events Capture?

Each audit event typically includes the following details:

• Action - A short label describing what happened (e.g. “Access approval”, “Provisioning action”, “Workflow step completed”).

• Source - Where the event originated (workflow name, task).

• Interface - How the action was triggered (UI, debug, task).

• Target - The primary object affected, such as an identity, account, role, entitlement, or policy.

• Actor - The user or identity responsible for the action.

• Custom attributes - Flexible key‑value fields where you can store business context, such as:

  • Ticket or request IDs.

  • Operation type.

  • System name.

  • Approver comment.

• Timestamp - When the event occurred, often with sub‑second granularity.

Where Do Audit Events Come From?

Audit events in IdentityIQ are generated in two main ways:

1. Built‑In Auditing

IdentityIQ can automatically generate audit events for many standard activities, such as:

• Access requests and approvals.

• Certification decisions and reminders.

• Policy violations and remediation.

• Identity and account changes.

• Task execution and administrative actions.

2. Custom Auditing from Rules and Workflows

In addition to built-in auditing, IdentityIQ lets you create custom audit events directly from rule.

This is especially useful for logging actions that are unique to your implementation. For example:

• A workflow that provisions an AD admin account might log:

  • The identity involved.

  • The operation (enable/disable, reset password, grant admin rights).

  • The request or ticket number.

  • Provisioning status.

Why Audit Events Matter

Audit events will record every action and change that takes place across the environment, and administration, giving you a clear, time‑stamped picture of what’s going on in the system.

When you configure them with meaningful business context's they:

• Give you a clear view of what’s happening in the platform.

• Help you show auditors and security teams that controls are in place and working.

• Support incident investigations by exposing who did what and why.

• Turn raw log entries into trustworthy, actionable insights.

In a well‑run IdentityIQ implementation, audit events are not just technical logs they’re a core part of how you build trust and accountability for your identity program.