Audit and Reporting in IGA: Evidence That Holds Up and Reports People Use

The request that arrives every year

Sometime in the third quarter, an email arrives from the external auditors. They want a list of everyone who could post journal entries to the general ledger at any time between January and June. They want evidence of approval for 25 people they’ll pick from that list. They want every employee who left in the first half of the year, with the date each one’s access was removed from the ERP, the bank portal, and the consolidation tool. And they want the results of the last two quarterly access reviews for those systems, including proof that the revocations were carried out.

At one company, answering that email takes six weeks. Someone exports user lists from each system, but the exports show who has access today, not in March. Approvals are scattered across ticket comments and email threads. The leaver dates come from HR, the removal dates from three different admins’ memories. The review results exist as spreadsheets with manager replies pasted in, and nobody can show that the revocations happened.

At another, it takes two days, because everything in this module was designed to leave a record, and those records connect. That difference is what this article is about. It closes the module on IGA’s core components because every other component, requests, certifications, roles, policies, and provisioning, produces records, and audit and reporting are where those records either add up to something or don’t.

What to record

An IGA program needs to be able to answer, for any access anyone has ever held: who got it, through which path, who decided, when it arrived, and when and why it went away. That means recording several kinds of events, and recording each with enough context to stand on its own.

Changes to access come first. Every grant and removal, with the identity, the entitlement or role, the target system, the time, the path it came through (a request, a rule, a certification, a manual grant found by reconciliation), and the reference to whatever authorized it.

Decisions come next. Approvals and rejections on requests, with the approver and any comment. Certification decisions, item by item. SoD exceptions, with the compensating control and the expiry date. Each one should record who made the decision and in what capacity, since an approval by a delegate is a different fact from an approval by the owner.

Policy changes need the same treatment. Every change to an assignment rule, an SoD rule, a role’s content, or a birthright bundle, with the old and new versions, who changed it, who approved it, and when it took effect. Without this, the platform can say a rule granted some access but not what the rule said at the time.

Provisioning operations and reconciliation results close the loop: which operations ran, which failed and were retried, which drift was found and what was decided about it.

And finally the actions of the people who run the IGA platform itself. Administrators of the platform can change rules, approve on behalf of others in some configurations, and edit identity data. Their actions are among the most important to record and the most often forgotten.

Logs are not evidence yet

Each of those records is useful on its own, but an auditor rarely asks about a single event. They ask whether a control worked, and that means following a chain. The approval that authorized a grant. The provisioning operation that carried it out. The reconciliation that confirmed it existed in the system. Later, the certification that reviewed it, the revoke decision, the operation that removed it, and the reconciliation that confirmed it was gone.

flowchart LR
  accTitle: The chain of records that makes up access evidence
  accDescr: A request is approved by the entitlement owner, producing an approval record. The approval triggers a provisioning operation that grants the access in the target system. A later reconciliation reads the target system and confirms the access exists. Each record references the one before it, so an auditor can start from any confirmed access in the system and trace it back to the decision that authorized it.
  D[Decision<br/>approval, rule, certification] --> O[Operation<br/>provisioning or removal]
  O --> C[Confirmation<br/>reconciliation]
  C --> E[Evidence an auditor<br/>can trace both ways]

When those records live in different systems, with no shared identifier, building the chain means someone matching ticket numbers to log lines to spreadsheet rows by hand, under deadline, for every sampled item. That’s where the six weeks go. When the IGA platform links them, each operation carrying the ID of the decision that caused it and each reconciliation finding linked to the operation it confirms, the chain can be produced as a report.

The chain should work in both directions. Starting from a decision, you should be able to show what it caused. Starting from access found in a system, you should be able to show what authorized it, or show that nothing did, which is itself a finding.

How auditors actually test

Knowing how testing works makes it much easier to design for it. Most access control testing, whether for SOX IT general controls, SOC 2, or PCI DSS, follows the same pattern.

The auditor starts with a population: all leavers in the period, all users with a sensitive entitlement, all access granted in the period, all changes to a critical rule. They select a sample from it, often 25 items for a control that operates many times, fewer for controls that run quarterly. For each sampled item they look for the evidence that the control operated: the approval existed before the access was granted, the approver was appropriate, the leaver’s access was removed within the defined window, the certification decision was carried out. They may also do a walkthrough, following one instance of the process end to end with the people who run it.

The important part is that the population comes from the organization. And that makes the population itself something the auditor has to test.

Different audits, different emphasis

The testing pattern is similar everywhere, but different audits care about different things, and it helps to know which one you’re preparing for.

A SOX audit of IT general controls focuses on the systems that feed financial reporting. The auditors want to see that access to those systems is approved, reviewed, and removed, and that changes to them are controlled. They test both whether each control is designed well and whether it operated throughout the year, and they pay particular attention to privileged access and to anyone who could change financial data or the systems that hold it.

A SOC 2 audit is shaped by what the company has promised its customers. A Type I report checks the design of controls on a single date; a Type II report checks that they operated over a period, usually six to twelve months, which means evidence for the whole period, not just the end of it.

A PCI DSS assessment, performed by a qualified security assessor, is specific about requirements: who can access cardholder data, how accounts are managed, how long logs are kept. It tends to be less forgiving of missing evidence, because the requirements spell out exactly what must exist.

An ISO/IEC 27001 certification audit looks at the management system as a whole: whether access control is defined in policy, whether the policy is followed, and whether records show it. It cares as much about the documented process and its review as about individual samples.

Internal audit, finally, often tests the same controls ahead of the external auditors, and is the best friend an IGA program has. A finding from internal audit in March is a chance to fix something before it becomes an external finding in September.

The report is evidence too

Auditors call it IPE, information produced by the entity: any report, query, or extract the organization hands over as the basis for testing. If the list of leavers is missing the people who left from one subsidiary, the sample drawn from it can’t include them, and the test proves nothing about them. So auditors check that the report is complete and accurate before they rely on it.

In practice that means they’ll want to understand how a report is produced (the query, its filters, its parameters), see it run, or see evidence that it was run with the right parameters, and compare its totals with another source, such as the HR system’s own count of terminations. A report that someone builds by hand each year in a spreadsheet is hard to defend. A standard report, generated by the platform with documented logic and a record of when and how it was run, is much easier.

Point-in-time questions

The opening email asked who could post journal entries at any time between January and June. That’s a different question from who can post them today, and it’s one of the most common things IGA programs can’t answer.

Answering it requires history. Either the platform keeps every assignment with its start and end dates, so it can reconstruct the state on any past date, or it takes regular snapshots of access and keeps them. Exports taken today from target systems can’t answer it, because people who had the access in March and lost it in May won’t appear, and those are often exactly the people the auditor is interested in.

The same applies to rules and roles. “What did the AP Clerk role contain on April 1?” and “what did assignment rule AP-02 say when it granted this access?” are fair questions, and the answers depend on versioning having been in place at the time. Designing for point-in-time questions early is cheap; retrofitting history that was never kept is impossible.

Five questions every program gets asked

Most audit requests, and most questions from security investigations and business owners, turn out to be variations of the same five. It’s a useful exercise to check, before anyone asks, whether the program can answer each one from its own records.

The third column is the to-do list. Each gap is a place where an auditor’s request, an investigator’s question, or a business owner’s doubt would currently have to be answered by asking people to remember. Closing those gaps one by one, starting with the systems that matter most, is a reasonable way to plan the reporting side of an IGA program.

Reports for different readers

An IGA platform can produce hundreds of reports. The useful ones are designed for a specific reader who will do something specific with them, and they tend to fall into four groups.

Operational reports are for the people running the processes, often daily. Failed provisioning operations and their age. Approvals waiting longer than their service level. Manual tasks overdue. Connectors that haven’t completed an aggregation recently. These reports exist to be worked through and emptied.

Compliance reports show that controls operated, usually for a period. Certification campaigns completed on time, with revocation rates and confirmed remediation. Leavers with their termination time and the time access was removed from each in-scope system. Access granted in the period with its approval. These are the reports that become IPE.

Risk reports show exposure, regardless of whether any control failed. Who holds privileged access, and how that number is trending. Orphan accounts and unowned service accounts. Accounts unused for 90 days. SoD exceptions, their compensating controls, and how many are past their expiry. These reports are for owners and for the security function, and they should lead to decisions.

Executive reporting is a short set of trend numbers for the governance forum from the program roles article and for leadership: a handful of the metrics from each article in this module, shown as trends rather than single values, with a sentence on what changed and why.

A report nobody acts on is noise, and noise trains people to ignore reports. Before building one, it’s worth writing down who reads it, how often, and what they’re expected to do when a number moves. If there’s no answer to the last question, the report probably doesn’t need to exist.

Dashboards that don’t mislead

The same numbers can tell very different stories depending on how they’re defined. A certification report that says “97% complete” sounds healthy until you discover the missing 3% is the privileged-access portion, the only part that really mattered. A “time to remove leaver access” average of two hours can hide one leaver whose bank-portal access stayed active for a month.

A few habits keep reporting honest. Every metric should have a written definition, including what counts in the denominator and what’s excluded. Numbers that mix risk levels should be split by risk tier, since the privileged slice is usually the one people care about and the one most likely to be hidden by an average. Averages should come with the worst cases, or with percentiles, so a single long outlier is visible. And every report should show when its data was last refreshed, because a dashboard drawing on a connector that stopped aggregating last week will happily show last week’s healthy numbers.

Reporting a control that failed

Sooner or later a control doesn’t operate as designed. A leaver keeps access for a week because a manual task was missed. A certification campaign closes late. An approval is found to have been given by someone without the authority to give it.

How the program handles that matters a great deal. The worst response is to hope nobody notices. Auditors sample, and a deviation they find on their own, unexplained, raises questions about every other control. The better response is to treat the deviation as a record in its own right: what happened, how it was found, the root cause, the impact (did the leaver actually use the access?), the immediate fix, and what changes so it doesn’t happen again. A deviation that the program found, explained, and fixed before the auditor arrived is usually treated as evidence that monitoring works. The same deviation found by the auditor, with no record, often becomes a finding.

Testing controls continuously

Most of the tests an auditor runs once a year can be run by the program every day. If the control is “leaver access is removed within one business day,” a daily query that lists every leaver from the last 30 days with any access still active after 24 hours is the same test, run continuously, with the auditor’s sample replaced by the whole population. The same idea works for approvals (any access granted in the last day without a linked approval), for SoD (any new conflict without an approved exception), and for privileged groups (any member not granted through the program).

This is usually called continuous controls monitoring, and it changes the relationship with audit. Problems are found within a day instead of months later. The yearly audit becomes a review of whether the monitoring ran and what it found, rather than an investigation from scratch. And the program’s own metrics stop being self-reported claims, because the same queries that produce them are the ones the auditors could run themselves.

Starting small works best: pick the two or three controls auditors test every year, write each test as a scheduled query with an owner for its results, and let the evidence of those runs accumulate. After a year, the program has twelve months of evidence that the controls worked, produced as a side effect.

An evidence calendar

Some evidence can’t be produced on demand later. A quarterly review needs its scope snapshot taken on the day the campaign starts. A point-in-time report for a period needs history that was being kept during that period. A SOC 2 Type II period needs evidence from its first week as much as from its last.

An evidence calendar lists, for each control, what evidence it produces, when, and where it’s stored, and assigns someone to check each quarter that the evidence exists. It’s an unglamorous document, and it’s the difference between collecting evidence as it happens and trying to reconstruct it under deadline.

Protecting the audit trail

Records are only evidence if they can’t be quietly changed. An audit trail that an IGA administrator can edit is a trail that proves nothing about what IGA administrators did.

The basics are well established. Audit records should be append-only, so entries can be added but not modified or deleted, and ideally forwarded as they’re created to a separate system the IGA team doesn’t administer, often the organization’s security information and event management (SIEM) platform. Time on every system involved should be synchronized, because a chain that depends on comparing timestamps across systems falls apart when clocks disagree by minutes. And access to the audit records themselves should be limited and logged.

The people who run the IGA platform deserve particular attention. They can change rules, adjust approval routing, sometimes grant access directly, and correct identity data. Their actions should be logged in detail and reviewed regularly by someone outside the IAM team, often security or internal audit, with alerts for the most sensitive actions, such as changes to SoD rules, approvals performed as another user, or direct grants that bypass the request process. This is also where the identity threat detection domain later in the site picks up: IGA’s records are one of the richest sources of signal about identity misuse.

How long to keep it

Retention is set by the strictest requirement that applies, balanced against privacy law’s preference for keeping personal data no longer than needed.

PCI DSS requires at least twelve months of audit log history, with the most recent three months immediately available for analysis. The HIPAA Security Rule requires security policies, procedures, and related documentation to be kept for six years. Organizations subject to SOX generally keep access evidence long enough to support audits of prior periods, often several years, guided by legal counsel. On the other side, privacy laws such as GDPR and its Latin American counterparts expect personal data, which audit records contain, to be kept only as long as there’s a purpose for it.

The practical answer is a written retention schedule for IGA records, agreed with legal and compliance, that says how long each kind of record is kept, where, and how it’s deleted at the end. Keeping everything forever is not a policy, and neither is keeping whatever the platform happens to retain by default.

Worked example: a SOX request at a manufacturing company

A publicly listed manufacturer receives the request from the opening of this article. Two years ago, answering it took six weeks. This year, the IAM team runs four standard reports.

For journal-entry access, the team runs the point-in-time access report for the ERP.GLJournal.Post entitlement, for every day from January 1 to June 30. It lists 61 people who held it at some point, including 9 who no longer do. The report’s logic was walked through with the auditors in February, and its total is checked against the ERP’s own change log for the same entitlement. The auditors sample 25, and for each the platform produces the chain: the role or request that granted the access, its approval, the provisioning operation, and the reconciliation that confirmed it. Two of the 25 got the access through a role; for those, the evidence is the assignment rule, its version at the time, and its approval.

For leavers, the leaver removal report lists 214 terminations in the period from HR, with termination time and confirmed removal time in each of the three in-scope systems. The auditors compare its count with HR’s own termination report, then sample 25. Twenty-four were removed within the four-hour window for involuntary terminations and the one-day window for others. One was removed from the bank portal after three days because the manual task was overdue; the report shows the escalation, and the team has already documented it as an exception with its root cause.

For access reviews, the certification report shows both quarterly campaigns for the three systems: scope generated from system state, every decision with its reviewer and time, and reconciliation confirmation for every revocation.

The whole response is delivered in two days. The auditors spend their time testing, not waiting for data, and the single exception arrives already explained.

A shorter example: a startup’s first SOC 2 Type II

A 150-person software company is preparing for its first SOC 2 Type II audit, which covers a six-month observation period. A Type I audit only checks that controls are designed properly on one date; Type II checks that they operated throughout the period, which means evidence for the whole six months.

The company’s IGA is light: an identity provider with SCIM to its main SaaS applications, access requests in a ticketing tool, and quarterly reviews in spreadsheets. Its advisors suggest three changes before the period starts. Access requests move to a form that records the entitlement, the approver, and the end date as structured fields, so they can be reported on. Quarterly reviews keep using spreadsheets but are generated from the identity provider’s export on a fixed date and stored with the reviewer’s sign-off and the ticket for each revocation. And the identity provider’s logs are forwarded to a separate log store with twelve months’ retention, so leaver timing can be shown for any day in the period.

When the auditors arrive after the period closes, every sample they pick has its evidence in one of those three places, and the report comes back with no exceptions on access controls.

None of this requires an IGA platform. It requires deciding, before the period begins, what evidence each control will produce and where it will be kept.

Common mistakes

Building the audit response by hand every year is the most expensive pattern, and it rarely improves, because the knowledge of how it was done leaves with whoever did it.

Keeping only current state makes point-in-time questions unanswerable. Reports without documented logic fail the auditor’s IPE test, and a population that turns out to be incomplete can invalidate weeks of work.

Audit records that IGA administrators can edit, or that sit only inside the IGA platform, can’t prove anything about the people who control the platform.

Retention left to defaults means records are either gone when they’re needed or kept long after any purpose has passed.

And operational reports without owners pile up unread, until the one that mattered, a growing queue of failed removals, is noticed by the auditor instead of by the team.

What to measure

A few numbers describe whether audit and reporting are in good shape. The time to produce a standard audit response, from request to delivery, is the most direct; it should fall from weeks to days as the program matures. The number of audit findings related to access, and how many of them were already known to the program before the auditor found them, shows whether the program’s own reporting works. The share of in-scope systems covered by point-in-time history shows how many questions the program can answer. And the share of operational report items worked within their service level shows whether those reports are actually used.

Two more become meaningful once continuous monitoring is running. One is the number of key controls with an automated daily test, compared with the number the auditors test each year; the closer those two numbers get, the less the annual audit depends on reconstruction. The other is the ratio of deviations the program found itself to deviations an auditor found first. A program that finds most of its own problems is one whose reporting can be trusted, and that’s ultimately what this whole article is aiming at.

Where this maps to standards

The audit family of NIST SP 800-53 Rev. 5 maps almost one to one onto this article: AU-2 and AU-3 define which events to log and what each record must contain, AU-6 covers review and reporting, AU-9 covers protecting audit information, including from privileged users, AU-11 covers retention, and AC-2(4) requires account actions to be audited automatically. PCI DSS v4.0 puts logging and monitoring of access in requirement 10, with 10.5.1 asking for audit logs to be kept at least twelve months, three of them immediately available. ISO/IEC 27001:2022, in Annex A 8.15 on logging and 5.33 on protecting records, requires logs to be produced, protected and analyzed and records to be safe from loss and falsification. A SOC 2 Type II report tests how access controls operated over a whole period, which is impossible without evidence of the kind described here. And for SOX, auditors test IT general controls, access among them, under PCAOB AS 2201, the standard for audits of internal control over financial reporting, which is where the email at the start of this article comes from.

Closing the module

This module covered the core components of an IGA program: the request that lets access in, the certification that checks it, the roles that bundle it, the policies that assign it automatically, the provisioning that makes it real, and now the records that prove all of it happened. Each component on its own is a process. Together, with their records linked, they’re a program that can explain any access it governs.

Recap

An IGA program has to record every change to access and every decision behind it, including policy versions, provisioning results, reconciliation findings and what its own administrators do. Those records only become evidence when they form a chain from decision to operation to confirmation that can be followed in both directions; logs someone has to stitch together by hand are raw material. Auditors test a sample drawn from a population you hand them, and they test the report that produced that population too, so the report’s logic should be documented and agreed with them early. History has to be kept so you can say what access existed on a past date, and rules and roles have to be versioned so you can say what they said at the time. Reports are designed for a reader and an action, operational, compliance, risk or executive, with every metric defined, split by risk tier and stamped with how fresh the data is. The program runs the auditor’s tests itself, continuously, and records failed controls with their cause and fix before anyone else finds them. And the audit trail is protected from the people who run the platform and kept for a period agreed with legal and compliance. Do all of that, and the yearly email takes two days to answer instead of six weeks.

Three questions to test yourself

1. An auditor asks for everyone who had administrator access to the payment system at any time last quarter. Your platform can only report current access. What will be missing from your answer, and what would you need to have been doing to answer it fully?
2. Why does an auditor test the report you give them, and not only the items they sample from it? Give an example of a report error that would invalidate the test.
3. Your IGA administrators can approve requests on behalf of absent approvers. What would you log, who would review it, and what would you alert on?

Hands-on exercise

Take one access control you know, such as leaver removal, a quarterly review, or approval of privileged access.

1. Write the auditor’s likely request: the population, the sample size, and what they’ll look for in each item.
2. List every record needed to answer it, the system each lives in, and the identifier that links them.
3. Describe how you would prove the population report is complete.
4. Decide how long each record should be kept and justify it against at least one regulation or standard.