Controls that cannot be seen cannot be trusted. Reporting is how a control becomes visible.

A company may have excellent access rules, thoughtful approvals, and regular reviews. But if nobody can show what actually happened, then to a leader or an auditor those controls might as well not exist. Reporting is the bridge between doing the right thing and being able to prove it. It is also the way a team learns whether its efforts are working.

Four jobs a good report does

• It answers a question: a leader asks, “How many people can approve payments?” and gets a number and a list.
• It proves a control: an auditor asks, “Show me that leavers lose access,” and gets dated evidence.
• It spots trouble early: a rising count of overdue reviews warns of a problem before an audit does.
• It drives action: a list of orphaned accounts goes to the owners who can fix them.

The cost of poor reporting

Without good reports, teams scramble before each audit, collecting screenshots and spreadsheets by hand. The numbers differ from person to person. Nobody is sure which version is right. Problems remain hidden for months. Good decisions are delayed because nobody can see the facts.

The cost of too much reporting

The opposite problem is just as real. A company that produces dozens of long reports nobody reads wastes effort and buries the few facts that matter. A short set of well-chosen reports beats a large pile of data dumps.

A small set of words appears again and again in this topic. Learn them once and the rest reads easily.

Governance

Governance means the rules, roles, and checks that make sure access is appropriate. It covers who may have access, who decides, how often it is reviewed, and how problems are handled.

Event and log

An event is one thing that happened, such as a sign-in, a grant, or a policy change. A log is the ordered record of events. Okta keeps a system log of events, which is the raw material for many reports.

Report

A report is a prepared answer to a question. It selects some data, arranges it clearly, and presents it to a reader. A report should have a purpose, an audience, a date, and a clear description of where the data came from.

Metric and KPI

A metric is a number that measures something, such as the number of open access requests. A KPI, or key performance indicator, is a metric chosen because it shows whether an important goal is being met, such as the average days to give a new joiner access.

Population and sample

A population is everything in scope, such as all active users. A sample is a smaller selection taken from it. Auditors often test samples, so you need to be able to produce both the full population and any chosen sample quickly.

Point-in-time and trend

A point-in-time report shows how things stood on a specific date. A trend shows how something changed over weeks or months. Auditors often ask for point-in-time evidence. Leaders often want trends.

Evidence

Evidence is a record that proves a control happened. A dated approval, a review decision with the reviewer’s name, and a removal confirmed by an application are all evidence. Good evidence is complete, accurate, tamper-resistant, and easy to retrieve.

System of record

The system of record is the place that is officially trusted for a fact. For employee status, it is usually the human resources system. For sign-in events, it is Okta’s log. Reports should name their sources, and conflicting sources should be settled in advance.

Data lineage

Lineage is the trail from a number in a report back to the original records. If someone asks “where does this figure come from?”, lineage lets you answer.

Retention

Retention is how long records are kept. Some rules require records for years. Some systems keep detailed logs for only a limited time, so important evidence may need to be copied elsewhere before it expires.

Before you can report, you must know where the facts are kept. Okta holds them in several places, each with different strengths.

The system log

The system log records events: sign-ins, failures, policy evaluations, administrator actions, provisioning results, and more. It is detailed and time-stamped, which makes it the best source for questions about what happened and when. Its weakness is that detailed events are kept for a limited period, and raw events need interpretation to become a business answer.

Built-in reports

The Admin Console offers ready-made reports on topics such as sign-ins, application usage, and user activity. They are quick to use and need no setup. They may be limited in filters, history, and layout, and the list varies by license and release.

Governance product reports

Where you own Okta’s governance features, they typically offer their own views and reports about entitlements, access requests, review campaigns, and sometimes conflicts. These are designed for governance questions and often include the context auditors want, such as decisions and reviewers.

Directory data

The directory holds users, groups, application assignments, and profile attributes. It answers questions about the current state: who is in which group, who is assigned which application, and who is active or suspended.

Application data

Applications hold the true permissions inside them. Where connected, Okta can import current access. For unconnected applications, you may need exports from the application itself.

Interfaces to extract data

Okta provides programming interfaces and options to stream logs to external tools, so that data can be collected, stored longer, and combined with other sources. Check your release for what is offered and what limits apply to the volume and frequency of requests.

External tools

Many companies send Okta logs to a security monitoring tool or a data warehouse, and build dashboards there. Combining Okta data with human resources, ticketing, and application data allows richer reports than any single source.

flowchart TD
    LOG["System log
events"] --> COL["Collection layer"]
    BIR["Built-in reports"] --> COL
    GOV["Governance reports
requests, reviews, conflicts"] --> COL
    DIR["Directory
users, groups, assignments"] --> COL
    APP["Applications
actual permissions"] --> COL
    HR["HR system
employment facts"] --> COL
    COL --> STO["Longer-term storage"]
    STO --> REP["Reports and dashboards"]
    

The same facts must look different to different readers. A report built for everyone usually serves no one.

Executives and risk leaders

They want a few trend lines and a clear sense of whether risk is rising or falling. They read in minutes. Give them a one-page summary with five or six measures, a plain-language comment, and the top issues needing a decision.

Entitlement and application owners

They want to know who holds access to their systems, what is overdue, and what needs a decision. Give them lists specific to their area, sorted by urgency.

Managers

They want to see their people: what access each holds, what reviews are waiting, and what requests need approval. Give them short action lists, not statistics.

Auditors and compliance teams

They want evidence: complete populations, dated records, samples with full history, and an explanation of how the data was gathered. Give them exportable, consistent, well-labelled evidence packs.

Security operations

They want unusual activity: sudden spikes in administrator actions, failed provisioning, use of emergency access. Give them alerts and detailed event views.

The identity platform team

They want operational health: failed grants, stuck workflows, connection errors, import freshness. Give them technical dashboards.

The help desk

They want to answer a person’s question quickly: why do I not have access, when was it granted, who approved it? Give them a lookup view for one person.

flowchart LR
    DATA["Trusted data"] --> EXE["Executive summary"]
    DATA --> OWN["Owner lists"]
    DATA --> MGR["Manager action lists"]
    DATA --> AUD["Audit evidence packs"]
    DATA --> SEC["Security alerts"]
    DATA --> OPS["Platform health"]
    DATA --> HLP["Help desk lookup"]
    

Most governance reporting falls into a handful of families. Knowing them gives you a ready menu.

Access reports

These show who can reach what. Examples include a list of all holders of a sensitive entitlement, applications with the most users, users with access to many sensitive systems, and accounts not used for a long time.

Lifecycle reports

These show how joiners, movers, and leavers are handled. Examples include time from start date to working access, time from departure to full removal, accounts still active after a leave date, and movers who kept old access.

Request and approval reports

These show how access is asked for and decided. Examples include requests by status, average time to approve, requests escalated or timed out, approvals by each approver, and reasons given for high-risk requests.

Review and certification reports

These show how well periodic reviews work. Examples include campaign completion rates, items kept and removed, reviewers who are late, and the share of decisions made within seconds.

Conflict and exception reports

These show risky combinations and how they are managed. Examples include open conflicts by severity, active exceptions and their expiry dates, and conflicts resolved over time.

Administrator activity reports

These show what administrators did. Examples include role assignments, policy changes, changes to governance rules, and uses of emergency access.

Authentication reports

These show how people sign in: failures, strong versus weak factors, risky sign-in patterns, and use of legacy methods. They support security rather than governance directly, but often appear in the same evidence set.

Data quality reports

These show whether the underlying facts are healthy: users missing a manager, odd department values, orphaned accounts, imports that failed or returned little data.

flowchart TD
    GR["Governance reporting"] --> A["Access"]
    GR --> L["Lifecycle"]
    GR --> R["Requests and approvals"]
    GR --> V["Reviews and certifications"]
    GR --> C["Conflicts and exceptions"]
    GR --> D["Administrator activity"]
    GR --> S["Authentication"]
    GR --> Q["Data quality"]
    

Anything can be counted. The skill is choosing numbers that tell you something worth knowing.

Good metrics have a purpose

A good metric ties to a goal, can be measured the same way each time, and leads to an action when it moves. “Number of accounts” is just a count. “Accounts of people who left more than seven days ago” is a measure of risk that someone can fix.

Leading and lagging

A lagging metric shows what already happened, such as incidents last quarter. A leading metric shows what is likely to happen, such as the number of reviews overdue now. Use both: lagging metrics prove results, leading metrics let you act early.

Speed, risk, and quality

A balanced set covers speed (how quickly people get what they need), risk (how much dangerous access exists), and quality (how well controls are performing). Reporting only speed may hide risk. Reporting only risk may ignore the cost to users.

Ratios beat raw counts

“Three hundred overdue reviews” means little unless you know how many reviews there are. “Four percent of reviews overdue” is easier to judge and compare. Use percentages where the total matters.

Thresholds and targets

Agree what is good, acceptable, and bad. A target of “leavers fully removed within one day” turns a number into a signal. Without targets, a number is just a number.

Beware gaming

People change their behavior to make numbers look good. If you measure only how fast reviews are completed, people click approve quickly. Pair speed metrics with quality metrics, such as the share of items removed, so gaming is visible.

flowchart TD
    G["Goal"] --> Q["Question: how will we know?"]
    Q --> M["Metric defined clearly"]
    M --> T["Target and threshold"]
    T --> O["Owner who acts when it moves"]
    O --> R["Reviewed regularly"]
    R -.->|"Adjust or retire"| M
    

Access reports answer the oldest governance question: who can do what?

Who holds a sensitive permission

The most requested report is a list of everyone who holds a given sensitive permission, such as releasing payments or administering a system. It should show the person, their manager, how and when they received it, whether it came by rule or by request, and when it was last used. Showing last use turns a bare list into a useful one.

What one person holds

The reverse view lists everything a single person holds across applications. It supports reviews, investigations, and help desk questions. It must include indirect access through groups and bundles, or it will understate the truth.

Dormant access

Dormant access is access that has not been used for a long time. It is a prime candidate for removal. A dormant report lists such holdings with the date of last use, sorted by sensitivity. Be careful: some access is rarely used by design, such as emergency access, so mark those for separate treatment.

Orphaned accounts

An orphan is an account in an application with no matching active person in Okta. Orphans often belong to people who left, or to test and shared accounts that nobody owns. They are risky because nobody notices when they are misused. A regular orphan report, sent to the owners of each application, is one of the most valuable outputs of a governance program.

Privileged access

Create a dedicated view of powerful access: administrators, owners of critical systems, holders of emergency access. Review it more often than other views, and compare it with an approved list.

Access by group of people

Leaders often want to know how access compares across departments or roles. Show averages and outliers: a person holding far more than their peers is worth a conversation.

flowchart TD
    ALL["All accounts in applications"] --> M{"Matches an active person in Okta?"}
    M -->|"No"| ORP["Orphan: send to application owner"]
    M -->|"Yes"| U{"Used recently?"}
    U -->|"No"| DOR["Dormant: candidate for removal"]
    U -->|"Yes"| P{"Privileged?"}
    P -->|"Yes"| PRV["Privileged view: review often"]
    P -->|"No"| OK["Normal access"]
    

Joiners, movers, and leavers are where access most often goes wrong. Lifecycle reports show how well you handle them.

Joiners: time to working access

Measure the time from the start date, or from the moment the human resources record is created, to the moment the person can do their work. Break it down by department, application, and fulfilment method. Slow cases often point to a specific application that is not connected, or a request that waits for an absent approver.

Movers: leftover access

For people who changed department or role, list the access they held before and after. Highlight permissions that were requested, not assigned by rule, and still present after the move. These are the seeds of privilege creep.

Leavers: time to full removal

This is the most important lifecycle report. For each leaver, measure the time from the departure event to the removal of each account and permission. Report the average, the slowest cases, and any account still active after a set period. Include applications that rely on manual tickets, since they are the slowest.

Leave of absence

People on long leave may need access suspended, and then restored. Report on accounts of people on leave, and on whether the right action was taken.

Contractors and temporary staff

Show contractors by sponsor, contract end date, and access held. Report on those past their end date who still have access.

Reconciliation with HR

Regularly compare the list of active people in Okta with the human resources list. Differences show where the feed is late or wrong, and where an account may exist for someone who has already left.

sequenceDiagram
    participant HR as HR system
    participant O as Okta
    participant A as Application
    participant R as Report
    HR->>O: Departure recorded at time T0
    O->>A: Remove access at time T1
    A-->>O: Confirmed at time T2
    O->>R: Log T0, T1, T2
    R->>R: Compute T1 minus T0 and T2 minus T0
    R-->>R: Flag if above target
    

Requests show how people experience governance. Slow or confusing requests drive workarounds.

Volume and status

Count requests by status: submitted, approved, denied, expired, granted, failed. A large number stuck in the middle indicates a bottleneck. A large number of failures indicates a connection problem.

Time to decision and time to grant

Measure the time from submission to approval and from approval to actual grant. These are different problems with different owners. Slow approval is a people problem. Slow grant is a technical problem.

Approver behavior

Report approval times and decisions by approver. Look for approvers who are consistently late, who never deny, or who approve in seconds. These patterns suggest rubber-stamping or overload.

High-risk requests

Create a separate view of requests for sensitive access: who asked, who approved, the reason given, and whether the access was time-limited. This is a favourite sample for auditors.

Denials and reasons

Denials are valuable. A high denial rate for a particular item suggests people are asking for the wrong thing, perhaps because its description is unclear. A low denial rate for a risky item may suggest approvers are not looking.

Popular requests

If many people keep requesting the same item, it may belong in a role bundle. Reporting on popular requests helps improve the design and reduce requests.

Escalations and timeouts

Count requests that escalated or timed out. A request that quietly expires leaves a person without access and without an answer, which breeds frustration.

stateDiagram-v2
    [*] --> Submitted
    Submitted --> Approved : "Approver agrees"
    Submitted --> Denied : "Approver refuses"
    Submitted --> TimedOut : "No answer in time"
    Approved --> Granted : "Application confirms"
    Approved --> Failed : "Grant fails"
    Granted --> [*]
    Denied --> [*]
    TimedOut --> [*]
    Failed --> [*]
    

A review that is not reported on cannot be improved, and cannot be defended in an audit.

Campaign progress

During a campaign, show how many items are decided, pending, and overdue, by reviewer and by application. Send progress to campaign owners daily so that gaps are chased early.

Campaign outcomes

After a campaign, report the totals: items reviewed, kept, removed, and escalated. Compare with earlier campaigns. A campaign with a zero percent removal rate across thousands of items raises questions.

Reviewer quality

Look at how long each reviewer spent per item, whether they decided in bulk, and how their removal rates compare with peers. Handle this sensitively. The aim is to find reviewers who need better information or training, not to punish.

Follow-through

A review decision to remove access is only meaningful when the access is actually removed. Report on how many removals were completed, how long they took, and which failed. This is the evidence auditors value most.

Coverage

Report on what the campaign covered: which applications, which entitlements, which people. Gaps in coverage are findings waiting to happen.

Exceptions in reviews

List items where reviewers asked for exceptions, who approved them, and for how long.

flowchart TD
    CAM["Campaign closes"] --> OUT["Outcome totals: kept, removed, escalated"]
    CAM --> QUA["Reviewer quality: time and patterns"]
    CAM --> COV["Coverage: what was included"]
    OUT --> FOL["Follow-through: removals completed and confirmed"]
    FOL --> PCK["Evidence pack for audit"]
    QUA --> IMP["Improvements: training and better context"]
    COV --> PCK
    

Reports about risky combinations show whether your highest-risk controls are working.

Open conflicts

List current conflicts by severity, application, department, and age. Show the trend. A steady fall shows the control working. A sudden rise points to a cause, such as a role change or a reorganization.

Resolution progress

Report how long conflicts take to resolve, and who owns the delays. Show the share resolved by removal, by reassignment, and by exception.

Active exceptions

List every approved exception with the pair, the person, the reason, the approver, the safeguards, and the expiry date. Highlight those near expiry and those past expiry.

Safeguard evidence

For each exception, show proof that its safeguards are working: that reviews of the person’s work happened, that alerts were checked, and that limits were respected.

Blocked requests

Count requests that were stopped because they would create a conflict. A healthy number shows the control working. Zero for a long time may mean the check is not running.

Coverage of the library

Report how many applications and permissions are mapped to duties, and which are not yet covered. Unmapped areas are blind spots.

flowchart LR
    SCN["Scheduled scan"] --> OPN["Open conflicts"]
    REQ["Request-time checks"] --> BLK["Blocked requests"]
    OPN --> RES["Resolution tracking"]
    OPN --> EXC["Active exceptions"]
    EXC --> SAF["Safeguard evidence"]
    EXC --> EXP["Expiry watch"]
    RES --> TRD["Trend report"]
    BLK --> TRD
    

The people who run the system hold the most power. Their actions deserve their own reports.

Role assignments

List who holds administrator roles, with scope, date granted, who granted it, and last use. Compare with an approved list. Unexpected entries need explanation.

Configuration changes

Report on changes to policies, governance rules, bundles, connections, and exemptions: what changed, who changed it, who approved, and when. Highlight changes made outside business hours or by unusual people.

Use of emergency access

Every use of emergency or highly privileged accounts should appear in a report, with the reason and the review that followed. These uses should be rare. A frequent pattern signals a process problem.

Failed and unusual administrator activity

Repeated failed attempts, access from new locations, and bursts of changes in a short time deserve alerts and a place in the weekly review.

Authentication posture

Show how people sign in: share using strong factors, share still using weak methods, failure rates, and unusual patterns. These support governance by showing whether the assumptions behind access decisions hold.

Policy effectiveness

Report on how sign-in policies are applied: which rule matched, how often access was denied or challenged, and which applications rely on the default. This shows whether policies behave as designed.

sequenceDiagram
    participant ADM as Administrator
    participant O as Okta
    participant LOG as Protected log
    participant SEC as Security review
    ADM->>O: Change a policy or role
    O->>LOG: Record actor, change, time
    LOG->>SEC: Weekly summary of changes
    SEC->>SEC: Compare with approved change requests
    SEC-->>LOG: Note unmatched or unusual changes
    

Reliable reports come from a reliable path. Think of the path as a pipeline with stages, each with a clear job.

Stage one: sources

The sources are the systems that hold facts: Okta’s log and directory, governance product data, applications, and the human resources system. Each source has its own format, speed, and limits.

Stage two: collection

Collection moves data out of the sources. It may be a stream of events pushed continuously, or a scheduled pull of snapshots. Collection must handle failures: if a pull fails, the pipeline should notice and retry, and mark the gap so that nobody mistakes missing data for a quiet day.

Stage three: storage

Storage keeps the collected data for longer than the sources do, in a protected place. It should resist tampering, follow retention rules, and support quick queries. Separate raw storage, which keeps original records untouched, from prepared storage, which holds cleaned and combined tables.

Stage four: preparation

Preparation cleans and combines. It converts times to one standard, matches records across systems using agreed identifiers, removes duplicates, and applies business definitions such as what counts as an active user. This is where most errors creep in, so it must be documented and tested.

Stage five: presentation

Presentation turns prepared data into reports, dashboards, and exports for each audience. It should read from prepared data, not directly from raw data, so that every report uses the same definitions.

Stage six: delivery and action

Delivery sends reports to the right people on time. Action routes findings, such as an orphan or an overdue review, to someone who can fix it, and records that it was done.

The control around the pipeline

Monitor the pipeline itself: did each run complete, how fresh is the data, were record counts plausible? A report built on yesterday’s failed load is worse than no report, because it looks right.

flowchart LR
    SRC["Sources
Okta, apps, HR"] --> COL["Collection
stream or scheduled pull"]
    COL --> RAW["Raw storage
untouched originals"]
    RAW --> PRE["Preparation
standard times, matched people, definitions"]
    PRE --> PRP["Prepared storage"]
    PRP --> PRS["Presentation
reports and dashboards"]
    PRS --> DEL["Delivery and action"]
    MON["Pipeline monitoring
freshness, counts, failures"] -.-> COL
    MON -.-> PRE
    MON -.-> PRS
    

Reports are only as good as the data collected. Gaps in collection become gaps in evidence.

Streaming and pulling

Streaming sends events to an external tool as they happen, which keeps data fresh and is good for alerts. Pulling retrieves data on a schedule, which suits snapshots of the directory and governance data. Many programs use both: a stream for events and scheduled pulls for state.

Snapshots for point-in-time questions

Auditors often ask who had access on a particular date. The current state cannot answer that if people have since changed. Take regular snapshots of the directory, assignments, and entitlements, and keep them, so that you can reconstruct any past date. Without snapshots, point-in-time questions become guesswork.

Handling limits

Okta applies limits to how often and how much you can request. Plan collection to stay within them, use filters to fetch only what you need, and design retries that back off politely. Check current limits in the documentation.

Retention planning

List each source, how long it keeps data, and how long you need it. Where you need longer, copy it. Decide how long reports and evidence packs are kept, and who may delete them. Align with legal and audit requirements, and with privacy rules that may limit how long personal data may be kept.

Protecting the stored data

Logs and snapshots contain personal data and sensitive security information. Restrict access, encrypt, and keep an audit trail of who reads them. Make stored evidence immutable where possible, so that nobody can quietly alter it.

Detecting gaps

Count records per day and alert when the number drops sharply. Compare against expected volumes. A missing day of logs should be recorded as a known gap, not left silent.

flowchart TD
    D1["Day 1 snapshot"] --> ARC["Protected archive"]
    D2["Day 2 snapshot"] --> ARC
    D3["Day 3 snapshot"] --> ARC
    EVT["Event stream"] --> ARC
    ARC --> Q["Question: who had access on a past date?"]
    Q --> ANS["Rebuild that date from snapshots and events"]
    

Most useful reports combine data from more than one place. Combining wrongly produces confident, wrong numbers.

Match people with a stable identifier

To combine records about the same person, use an identifier that never changes, such as an employee number or an internal user identifier. Do not match on names or email addresses alone, because they change and can be duplicated. If a person has several accounts, link them to one identity.

One clock

Systems record times in different time zones and formats. Convert everything to one standard, usually universal time, before comparing. A leaver report that mixes local times can show someone removed before they left.

Define terms once

Write down exact definitions: what is an active user, what is a leaver, what is dormant, what counts as a working day for service targets. Publish the definitions with the reports. Many arguments about numbers are really arguments about definitions.

Handle the awkward cases

Decide how to treat contractors, people on leave, rehires, service accounts, shared accounts, and test accounts. Make the treatment explicit and consistent.

Track changes to definitions

When a definition changes, trends can jump for no real reason. Record the change date, and restate history if practical, or mark the break on charts.

Reconcile totals

Check that counts agree across sources. If the directory says 10,000 active users and the human resources system says 9,800, find out why before publishing. Differences reveal real issues such as late feeds and orphaned accounts.

Keep lineage

For each number in a report, be able to say which sources, filters, and definitions produced it. Keep that description with the report.

flowchart TD
    A["Okta user record"] --> K["Stable identifier
employee number"]
    B["HR record"] --> K
    C["Application account"] --> K
    K --> ID["One linked identity"]
    ID --> DEF["Apply shared definitions
active, leaver, dormant"]
    DEF --> OUT["Consistent report row"]
    

A true number presented badly will be ignored or misread. Clear design is part of governance.

Lead with the answer

Put the main message at the top in a sentence: “Leaver removal met the target for 98 percent of cases; three cases took longer than a week.” Details follow for those who want them.

Few measures per page

An executive page should hold five or six measures. More than that, and readers stop seeing any of them. Use drill-downs for details.

Show trends and targets together

A line over six months with a target line tells a story at a glance. A single number without context does not.

Use plain labels

Write titles and column names in business language. Explain acronyms. State the date range and the data source on every page.

Make exceptions stand out

Highlight items that need action, such as overdue reviews or expired exceptions. Do not rely on colour alone, since some readers cannot tell certain colours apart. Add words or symbols.

Make action easy

Where possible, link each item to the screen where it can be fixed. A list of orphans with a link to each owner’s task makes action easy.

Keep the numbers honest

Start axes at sensible points, avoid misleading shapes, and show denominators. Declare when data is incomplete.

Layers of detail

Offer three layers: a summary for leaders, a working list for owners, and an evidence view for auditors. Each layer uses the same underlying numbers.

flowchart TD
    L1["Layer 1: Summary
leaders, one page"] --> L2["Layer 2: Working lists
owners and managers"]
    L2 --> L3["Layer 3: Evidence view
auditors, records and history"]
    L3 --> SRC["Same underlying data and definitions"]
    L2 --> SRC
    L1 --> SRC
    

A report that must be remembered will eventually be forgotten. Automation makes reporting reliable.

Rhythm

Choose a rhythm for each report. Operational lists such as failed grants may be daily. Management summaries may be weekly or monthly. Executive and audit packs may be quarterly. Match the rhythm to how quickly action is needed.

Right person, right channel

Send reports where people already work, such as email, chat, or a shared workspace. Address action lists to named owners, not to anonymous mailboxes. Include a short summary in the message itself.

Automating the flow

Okta offers automation features, where licensed, that can run flows on a schedule or in response to events: gather data, build a list, send a notification, open a ticket. Combined with external tools, they can produce a steady stream of routine reports without manual work.

Exception-based reporting

Do not send people a report every week saying “nothing to do”. Send a message only when there are items needing action, and keep a periodic summary so silence is not mistaken for failure. Include a “heartbeat” so that readers know the process is still running.

Access to reports

Reports contain sensitive information. Control who may see what. Managers see their own teams, owners see their own applications, and only a few see everything.

Version and archive

Keep each issued report with its date and the data used. When an auditor asks what you reported to leadership last March, you should be able to show it.

Tracking action

For reports that ask for action, record who acted and when. A report that finds forty orphans is only half the story. The other half is how many were fixed.

sequenceDiagram
    participant S as Schedule
    participant F as Automated flow
    participant D as Prepared data
    participant P as Owner
    participant T as Action tracker
    S->>F: Weekly trigger
    F->>D: Fetch orphaned accounts for this owner
    D-->>F: List of 7 accounts
    F->>P: Send summary and link to fix
    P->>T: Mark accounts resolved
    T-->>F: Resolution counts for next report
    

Reporting projects fail when they try to produce everything at once. A phased path builds trust.

Phase 1: Questions and readers

Interview leaders, owners, managers, auditors, and security. List the ten most important questions. Rank them by value and by how easy the data is to get.

Phase 2: Sources and gaps

For each question, identify the sources, check retention, and note gaps such as unconnected applications. Fix collection problems early, because missing history cannot be recovered.

Phase 3: Definitions and identifiers

Agree on definitions, identifiers, and the treatment of awkward cases. Publish the data dictionary.

Phase 4: First reports

Build a small set of high-value reports, such as leaver timing, orphaned accounts, overdue reviews, and privileged access. Validate numbers by hand against a sample.

Phase 5: Automate and deliver

Schedule the reports, route them to owners, and track actions. Add the pipeline monitoring.

Phase 6: Evidence packs

Assemble repeatable audit packs for the main controls. Test them with internal audit before the real audit.

Phase 7: Improve

Gather feedback, retire unused reports, refine metrics and thresholds, and widen coverage to more applications.

flowchart LR
    P1["Questions"] --> P2["Sources"]
    P2 --> P3["Definitions"]
    P3 --> P4["First reports"]
    P4 --> P5["Automate"]
    P5 --> P6["Evidence packs"]
    P6 --> P7["Improve"]
    P7 -.->|"New questions"| P1
    

Examples make ideas stick. Each one below follows a question from first ask to final answer.

Example 1: “Do leavers lose access on time?”

The head of risk asks whether people who leave the company lose access quickly. The reporting team first writes the exact question: for every person whose employment ended last quarter, how many hours passed between the end date in the human resources system and the confirmed removal of each account? They collect the end dates from the human resources feed, the removal events from Okta’s log, and the confirmation from connected applications. For two applications that are not connected, they use the closing time of the removal tickets.

The result: ninety-six percent of accounts were removed within a day. Four percent took longer, and nearly all of those were in the two ticket-based applications. The report names the applications, shows the slowest cases, and recommends connecting them. The head of risk now has a number, a cause, and an action.

Example 2: “Who can approve payments?”

An auditor asks for the full list of people who can approve payments, as of the last day of the quarter. The team finds the permissions that carry the duty, then looks up the quarter-end snapshot of holders. For each person it shows the manager, how the access was obtained, the approval record, and the date of the last review. A second view compares the list with the approved list of authorized approvers. Two people are on the first but not the second. Both turn out to be old access that was never removed. The team removes it, records the fix, and gives the auditor the list, the comparison, and the fix.

Example 3: “Are managers really reviewing?”

The compliance lead notices that every access review finished on time with zero removals. The team prepares a quality report: median time per item, share of bulk approvals, and removal rate by reviewer. They find that twelve reviewers approved over a thousand items each in under ten minutes. The team does not accuse anyone. They change the review screen to show last-use dates, group reviewers into smaller batches, and add a rule that unused high-risk items need a written reason to keep. The next campaign removes eight percent of items.

Example 4: The quiet day that was not quiet

A weekly report of unusual administrator activity shows zero events for three weeks. Instead of celebrating, an analyst checks the pipeline monitor. The log stream had failed three weeks earlier because a credential expired. The team restores the stream, backfills the missing events from the original source while they are still available, and adds an alert that fires when the daily event count drops below a threshold.

flowchart TD
    Q["Leader asks a question"] --> W["Write it precisely"]
    W --> S["Find sources and check retention"]
    S --> D["Apply shared definitions"]
    D --> C["Compute and validate on a sample"]
    C --> F["Present finding, cause, and recommendation"]
    F --> A["Owner acts"]
    A --> T["Track the result in the next report"]
    

Reports about access are themselves a map of where the valuables are. Protect them accordingly.

Why reports are sensitive

A list of who holds payment approval, which accounts are dormant, or which administrators have emergency access is exactly what an attacker or a dishonest insider would like to see. Reports also contain personal data about employees. Treat them as sensitive documents.

Control who sees what

Apply least privilege to reports. Managers see their own teams. Owners see their own applications. Only a small group sees everything. Remove access for people who move or leave, as with any other system.

Protect the delivery channel

Avoid sending detailed lists by ordinary email to wide groups. Prefer a protected workspace with sign-in and logging. If files must be shared, use expiry dates and restricted recipients.

Protect the stored data

Encrypt stored logs and snapshots, restrict who can read them, and record who did. Separate the people who administer the reporting platform from the people who manage the identity platform, so that nobody can both change access and alter the record of it.

Prevent tampering

Keep raw data and issued reports in storage that does not allow silent edits. Record checksums or use retention locks where available. An auditor should be able to trust that a report from last year is still the one issued last year.

Privacy rules

Employee access data is personal data. Keep only what you need for as long as you need it, follow your organization’s privacy and retention policies, and consider whether summary views can replace detailed lists for broad audiences.

Insider misuse of the reporting tool

People with wide read access to reports could browse out of curiosity or misuse what they learn. Log access to sensitive reports, review the log, and limit exports.

Securing the pipeline

The credentials that collect data from Okta and applications are powerful. Store them in a vault, give them read-only rights where possible, rotate them, and alert on unusual use.

flowchart TD
    DAT["Stored data and reports"] --> ENC["Encrypted storage"]
    ENC --> RBAC["Role-based access to reports"]
    RBAC --> DEL["Protected delivery channel"]
    DEL --> LOGA["Access logging"]
    LOGA --> REVA["Regular review of who viewed what"]
    DAT --> IMM["Immutable copies of issued reports"]
    

Reports can fail silently. Watching the reporting process is as important as watching the controls it describes.

Freshness

For each report, record when its data was last updated and show it on the page. Alert when the data is older than expected. A report that looks current but is days stale can mislead decisions.

Completeness

Compare record counts with expected ranges. If the directory normally has about ten thousand users and today’s snapshot has two thousand, something went wrong. Alert and hold the report until checked.

Accuracy checks

Validate by hand. For a new report, pick a sample of ten rows and trace each one back to the source. Repeat after every significant change. Cross-check totals between sources and between reports.

Reconciliation tests

Run automatic tests that should always hold: the sum of department counts equals the total, no leaver has a removal time before the departure time, every approved request has an approver. Failures point to data or logic errors.

Changes in the underlying systems

Okta, applications, and the human resources system change over time. New fields appear, old ones are renamed, and meanings shift. Watch release notes, and re-test reports after changes. A report that quietly broke after a release is a common surprise.

Data quality of the facts themselves

Report on missing managers, inconsistent department names, duplicate users, and accounts with no owner. These problems weaken every other report.

Usage of reports

Track which reports are opened and acted on. Retire those nobody uses. Ask readers whether they trust the numbers.

flowchart TD
    RUN["Pipeline run finishes"] --> F{"Data fresh?"}
    F -->|"No"| H1["Hold report and alert"]
    F -->|"Yes"| C{"Counts in normal range?"}
    C -->|"No"| H2["Hold report and investigate"]
    C -->|"Yes"| T{"Reconciliation tests pass?"}
    T -->|"No"| H3["Hold report and fix logic"]
    T -->|"Yes"| P["Publish with timestamp and sources"]
    

Auditors do not want dashboards. They want evidence they can test. An evidence pack gives it to them in a repeatable form.

What an evidence pack is

An evidence pack is a prepared bundle for one control. It states the control in plain words, defines the scope and period, includes the complete population, offers a way to select samples, and shows the supporting records for each sample. It also describes how the data was collected and who prepared it.

Typical packs

• Leaver removal: all leavers in the period, times to removal, exceptions, and samples with full history.
• Access review: campaign scope, completion, decisions, removals, and follow-through.
• Privileged access: list of holders, approvals, and the latest review.
• Segregation of duties: conflict library, scan results, exceptions, and safeguards.
• Change control: administrator and rule changes matched to approvals.
• Joiner access: sampled new joiners with request, approval, and grant records.

Population completeness

Auditors will ask how they know the list is complete. Be ready to show how the population was produced, which filters were used, and how its total reconciles to another source, such as the human resources headcount.

Samples with full stories

For each sampled item, assemble the story from start to end: who asked, why, who approved, when it was granted, when it was reviewed, and when it was removed. A one-click view of a person’s access history saves hours.

Walkthroughs

Auditors often ask the team to walk through a control live. Rehearse the walkthrough with internal audit, using real examples.

Different frameworks, same ingredients

Financial reporting rules, security standards, and privacy laws differ in detail, but they ask for similar evidence of access control. Prepare once, map to each framework, and reuse. Your own compliance and audit teams will tell you which frameworks apply and what they require.

sequenceDiagram
    participant AU as Auditor
    participant GR as Governance reporting team
    participant DS as Prepared data
    AU->>GR: Request evidence for leaver removal, last quarter
    GR->>DS: Produce full population with filters documented
    DS-->>GR: 412 leavers, totals reconciled to HR headcount
    GR-->>AU: Population, method note, and sampling tool
    AU->>GR: Select 25 samples
    GR->>DS: Assemble full history for each
    GR-->>AU: 25 case files with timestamps
    

Reporting needs owners, like any service. Without them, reports decay.

Who does what

• Report owner: responsible for each report’s purpose, definitions, accuracy, and retirement.
• Data owner: responsible for the quality of each source, such as the human resources system or an application.
• Reporting team: builds and runs the pipeline, schedules reports, and keeps the data dictionary.
• Control owners: use the reports to run and improve their controls.
• Internal audit: independently tests the numbers and the process.
• Security: sets rules for report access and protects the data.

The report catalog

Keep a catalog that lists every regular report: its name, purpose, owner, audience, rhythm, sources, definitions, and last review date. It prevents duplicates and makes it easy to find the right report.

Service levels

Set targets people can meet: reports delivered by a stated time, data no older than a stated age, corrections made within a stated time. Report on these too.

Change management

Changes to definitions, sources, or logic must be reviewed, tested, and recorded, with the effect on past numbers explained. Use a second person to check, in the same spirit as other controls.

Training

Teach readers how to read the reports and what actions are expected. Teach report owners how to define metrics and avoid gaming.

Retire and refresh

Review the catalog twice a year. Retire reports nobody uses, merge near-duplicates, and add reports for new risks.

flowchart TD
    DO["Data owners
quality of sources"] --> RT["Reporting team
pipeline and catalog"]
    RO["Report owners
purpose and accuracy"] --> RT
    RT --> CO["Control owners
use reports to act"]
    SEC["Security
report access and protection"] --> RT
    IA["Internal audit
independent testing"] -.-> RT
    IA -.-> RO
    

Good reporting repays its cost many times over, and it does have a cost. A fair picture helps you choose how far to go.

Key trade-offs

flowchart TD
    N["A new reporting need"] --> Q1{"Does a built-in report answer it?"}
    Q1 -->|"Yes"| U1["Use the built-in report"]
    Q1 -->|"No"| Q2{"Can governance product reports answer it?"}
    Q2 -->|"Yes"| U2["Use governance reports"]
    Q2 -->|"No"| Q3{"Needs data from several systems or long history?"}
    Q3 -->|"Yes"| U3["Build in the reporting pipeline"]
    Q3 -->|"No"| U4["Reconsider whether the report is needed"]
    

A pattern is a proven answer to a problem that keeps coming back. These patterns keep reporting clear, trusted, and useful.

Pattern: Question first

Begin every report with the question it answers and the reader who asks it. Only then choose the data.

Pattern: One definition, many reports

Keep a single data dictionary and apply it in every report. A leaver is the same thing in the executive summary and in the audit pack.

Pattern: Raw, prepared, presented

Keep original records untouched, do cleaning and joining in a prepared layer, and build reports only from the prepared layer. This keeps numbers consistent and traceable.

Pattern: Snapshot and event

Combine regular snapshots of state with a continuous stream of events. Snapshots answer “what was true on that date”. Events answer “what happened and when”.

Pattern: Exception-based delivery with a heartbeat

Send action lists only when there is something to do, and send a regular status line so that silence is never mistaken for health.

Pattern: Quality gates before publishing

Check freshness, completeness, and reconciliation before a report goes out. Hold it if a check fails.

Pattern: Three layers of detail

Offer a summary for leaders, working lists for owners, and evidence views for auditors, all from the same numbers.

Pattern: Action tracking

Record who acted on each finding and when, and report resolution rates in the next cycle. A finding is complete only when it is fixed.

Pattern: Mock audits

Regularly simulate an audit request. Find gaps in evidence before the real audit does.

flowchart TD
    Q["Question and reader"] --> DEF["Shared definitions"]
    DEF --> PIPE["Raw to prepared pipeline
snapshots plus events"]
    PIPE --> GATE{"Quality gates pass?"}
    GATE -->|"No"| HOLD["Hold and fix"]
    GATE -->|"Yes"| LAY["Three layers: summary, lists, evidence"]
    LAY --> DEL["Exception-based delivery with heartbeat"]
    DEL --> ACT["Action tracked"]
    ACT --> MOCK["Mock audits check the whole chain"]
    

An anti-pattern is a habit that seems sensible but causes trouble later. Each card below shows one, why it hurts, and a better way.

This chapter gathers the habits that separate calm reporting programs from chaotic ones.

Best practices

Common mistakes

These short stories use made-up companies to show how the ideas appear in daily work. They are teaching examples, not descriptions of any real organization.

What the scenarios share

Each story was solved by the same habits: start from real questions, define terms once, keep history, validate numbers, send findings to owners who can act, protect the reports, and test the process before an audit does. None needed anything exotic. They needed patience and honesty about the data.

Short answers to common questions. Where details depend on your license or release, confirm them in your own console and the official documentation.

Here is the whole story in a few lines you can carry with you.

Governance reporting turns the daily record of who has access, who approved it, and what changed into answers that leaders can act on and auditors can test. In Okta, the facts live in several places: the system log, the directory, built-in reports, governance product data where licensed, and the applications themselves. A good program asks real questions first, collects and keeps the data long enough, joins it using stable identifiers and shared definitions, and presents it in layers for different readers.

The craft lies in a few steady habits: choose metrics tied to goals, pair speed with quality, take regular snapshots, validate numbers against sources, send findings to owners who can act, track the results, protect the reports as the sensitive maps they are, and rehearse audits before they happen. With these, controls become visible, trust grows, and the organization can show not only that it governs access, but how well.