isc-reporter

Reports and change-impact analysis for SailPoint Identity Security Cloud (ISC), from the command line. isc-reporter turns what your tenant holds into Excel dashboards (KPI tiles, native charts, filterable tables), PDF and CSV files people can read, and shows what a configuration change would do before you make it. It only reads from the tenant.

isc-reporter is a community project. It is not affiliated with, endorsed or supported by SailPoint Technologies. SailPoint and Identity Security Cloud are trademarks of SailPoint Technologies, Inc.

What it helps with

• See what ISC holds. Identities with their roles, access profiles, entitlements and accounts on one line each, certification progress and reviewer workload, attribute changes with their old and new values. For IAM operations, managers and auditors.
• Understand the configuration. How every identity attribute is computed, in plain words, where else it is used (transforms, provisioning policies), and checks for likely mistakes. For ISC engineers and architects.
• Change safely. Before replacing a source or enabling attribute synchronization, see what would be impacted or updated, with draft JSON to review. For implementation teams and consultants.
• Keep audit evidence. Every certification decision with its reviewer comment, attribute change history, and the query behind each report, in files you can archive. For audit and compliance.

Commands

Beta: documented and covered by automated tests; needs validation on more real tenants. Experimental: new; its results rest on assumptions still to be confirmed on real tenants, and may change. A command becomes Stable once it has been used on several real tenants without open issues.

Quick start

You need Python 3.10 or later.

1. Install

   python -m pip install isc-reporter
   

2. Try it without a tenant. This writes every report, built from fictional data, to outputs/demo/:

   isc-reporter demo
   

3. Connect to your tenant. Create a personal access token with the permissions of the commands you will use, then set:

   export SAIL_BASE_URL="https://<tenant>.api.identitynow.com"   # PowerShell: $env:SAIL_BASE_URL = "..."
   export SAIL_CLIENT_ID="<client id>"
   export SAIL_CLIENT_SECRET="<client secret>"
   

4. Run a first report

   isc-reporter search identities
   

iscr is a short name for the same command: iscr demo works too. If the command is not found, or is blocked by an application control policy (common on managed Windows computers), run it through Python instead: python -m iscr demo (py -m iscr demo on Windows).

Configuration

Credentials are read from the first of:

1. --config path/to/file.json;
2. the SAIL_BASE_URL, SAIL_CLIENT_ID and SAIL_CLIENT_SECRET environment variables (SAILPOINT_* also work);
3. a config.json in the folder you run from.

{
  "BaseURL": "https://<tenant>.api.identitynow.com",
  "ClientId": "<client id>",
  "ClientSecret": "<client secret>"
}

Every command writes its reports to outputs/ (change with --output-dir, or name the file with -o) and its log to logs/ (--log-dir "" turns it off), and accepts --format (xlsx, pdf, and csv where it makes sense). isc-reporter <command> --help lists every option.

Safety, permissions and privacy

• Read-only. isc-reporter only reads from your tenant: it never creates, changes or deletes anything. migration writes draft JSON to local files for you to review, and analyze-before-sync forecasts updates without sending any.
• Offline where it can be. demo, identity-profiles --from and migration --from use fictional data or exported JSON files and never connect.
• Least privilege. docs/permissions.md lists the endpoints, scopes and user levels each command needs, so the token can have no more than that.
• Credentials. Keep them in environment variables or in a config.json, which .gitignore keeps out of version control. isc-reporter does not write them to its logs or reports.
• Personal data. Reports contain names, emails and access. .gitignore keeps outputs/, logs/, spreadsheets and PDFs out of version control; handle reports under your organisation's data protection rules, and never attach real reports to public issues.
• Load on the tenant. Searches are paged past the 10,000-result limit, and throttled calls are retried after the delay ISC asks for. Commands that make one call per identity or certification have options to narrow them: see load on the tenant.

Command reference

Search reports

isc-reporter types                                        # available report types
isc-reporter search identities
isc-reporter search identities -q "attributes.department:Finance" --expand access
isc-reporter search entitlements -q "privileged:true" --format xlsx csv
isc-reporter search events -q "status:FAILED AND created:[now-7d TO now]"
isc-reporter search identities --columns displayName,email,attributes.location --group-by attributes.location

The workbook has a Summary (key figures and a chart per breakdown), the Data as an Excel table, a Detail sheet with --expand, and the Query used. Any other search index works too, with columns chosen automatically or with --columns. Reports can be saved as JSON and shared: see examples/reports/ and --definition.

Certification campaigns

isc-reporter campaigns                                    # every campaign
isc-reporter campaigns --status ACTIVE
isc-reporter campaigns --since 2026-01-01 --items         # with every reviewed access item
isc-reporter campaigns --campaign "Q3 Manager Certification" --format pdf

Sheets: Dashboard, Campaigns (progress bars, revocation rate, days left), Certifications (one per reviewer), Reviewers (workload, most pending first), with --items Identities (access grouped by decision) and Decisions (every item with its reviewer comment), and Filters. Overdue items are shown in red. Role composition campaigns are listed with their progress but have no reviewer detail (their reviews are not identity certifications).

Identity attribute changes

isc-reporter changes --attributes department,manager --days 30 --format xlsx pdf csv
isc-reporter changes --since 2026-10-01 -q "attributes.cloudLifecycleState:active"
isc-reporter changes --exclude someDailyAttribute

ISC search does not keep previous attribute values, so this report finds the identities modified in the period and reads their history. By identity gives one line per identity with Old <attribute> / New <attribute> columns; Changes lists every change. Manager ids are shown as names. Attributes that change on most days (typically computed from today's date by a transform) are flagged, as they fire an attribute change event every day. One history call is made per modified identity: narrow large tenants with --query or --max-identities.

Identity profile mappings

isc-reporter identity-profiles
isc-reporter identity-profiles --profile Employees --profile Contractors
isc-reporter identity-profiles --from exports/            # offline, from exported JSON

One sheet per profile with, for every identity attribute, the mapping kind, a plain-language explanation ("Value of 'hireDate' from HR System, converted by the transform 'Date to ISO8601' (changes a date format)"), sources, transforms and the definition. Also: a matrix comparing profiles, attribute coverage, the transforms used, and checks: required or common attributes not mapped, missing transforms, lifecycle state copied as is, identical mappings, other sources. --from reads a profile, a list of profiles or a configuration export, with transforms found in the same files.

For every identity attribute the report also shows where else it is used, in the Also used in column of each profile sheet and in two sheets: Attribute usage (one line per attribute: the profiles that map it, the mappings and named transforms that read it, the source provisioning policies that use it, and which sources) and Usage detail (one line per use). Provisioning policies are read from every source of the tenant (a source that cannot be read is skipped with a warning), or from a source export given to --from. Identity attributes used in rules (code) cannot be detected.

Source migration analysis

isc-reporter migration --old-source "HR System" --new-source "New HR"
# complete outputs/source-migration_<ts>/attribute-mapping.csv, then:
isc-reporter migration --old-source "HR System" --new-source "New HR" --attribute-map attribute-mapping.csv

Finds the identity profiles authoritative on or reading the old source, the transforms reading it and those calling them, matches each old account attribute to the new source (mapping file, or same name in the new account schema), shows every mapping before and after, and writes draft JSON for the new identity profiles and transforms. Transforms are copied with a suffix so both sources can run in parallel (--in-place to update them instead).

The Criteria sheet lists what selects identities or matches accounts on the identity attributes computed from the old source (directly, or from another impacted attribute): role and dimension membership criteria, segment visibility, and the account and manager correlation of the other sources. Their result depends on the new values: if department gets new codes, identities gain or lose roles, and their access, at the next identity refresh. Criteria that read the old source itself (account attributes or entitlements in role criteria, and its own correlation) are listed with their rewrite on the new source, and their account attributes are added to attribute-mapping.csv. With --from, roles, segments and sources are read from the export when it contains them. Lifecycle states, provisioning policies and workflows are listed as next steps, not analysed.

Before enabling attribute synchronization

isc-reporter analyze-before-sync "Active Directory"
isc-reporter analyze-before-sync "Active Directory" --map location=physicalDeliveryOfficeName
isc-reporter analyze-before-sync "Active Directory" --map-file extra-mapping.csv --only-map
isc-reporter analyze-before-sync "Active Directory" --format xlsx pdf csv --threshold 5

(analyzebeforesync also works.) Enabling attribute synchronization on a source can send a bulk of updates to the target system. The command changes nothing: it reads the source's provisioning policy, finds the fields mapped directly to an identity attribute (ISC only synchronises those), reads the accounts of the source and the identities they belong to, and counts what ISC could write: values added, changed, cleared (the riskiest) or changed in case only.

--map IDENTITY=ACCOUNT (repeatable) and --map-file (a CSV with identity_attribute;account_attribute) add comparisons that are not in the policy yet; --only-map uses only those; --usage reads other policy usage types than CREATE. A verdict (No update expected, Limited updates, Bulk update expected) is given, a bulk update being flagged when a value would be cleared or when --threshold percent of the accounts (default 10) would be updated.

Sheets: Dashboard, Attributes (per mapped attribute: accounts compared, added, changed, cleared, share, risk), Accounts (worst first), Changes (current and new value of every update; the CSV has them all), Not analysed (policy fields that are not a direct copy), Checks. Every difference is counted, as if ISC evaluated all accounts, so read the figures as an upper bound. The Changes sheet contains real attribute values: protect the file.

Leavers who still have access

isc-reporter leavers                                       # states configured as inactive
isc-reporter leavers --states inactive gardenLeave inactive30j out
isc-reporter leavers --date-attribute endDate --grace 1 --exclude-source "Payslip Portal"

Lists the identities in a leaver lifecycle state that still have enabled accounts. By default the leaver states are the lifecycle states configured as inactive in the identity profiles; give your own with --states. Disabled accounts and accounts of authoritative sources are left out (--include-authoritative keeps the latter), as are the sources given with --exclude-source.

For each enabled account, the lifecycle state's configuration gives the cause: Should be disabled (or deleted) means the state should have done it, so provisioning failed, is pending or was undone; Not covered by the lifecycle state means nothing disables accounts of that source, a configuration gap. With --date-attribute (the identity attribute holding the departure date, ISO 8601, dd/MM/yyyy or yyyyMMdd) the report shows the days since leaving, and with --grace the accounts still enabled after that many days. Sheets: Dashboard, Leavers with access, Enabled accounts (privileged first), By source, Lifecycle states (their account actions) and Settings.

Roadmap and contributing

ROADMAP.md describes where the project is going; the next milestone is one format for every finding, with JSON output for automation. Contributions are welcome: a new check or report, test fixtures, documentation, or simply trying a command on your tenant and telling what you found. See CONTRIBUTING.md and the Code of Conduct. Report security problems privately, as described in SECURITY.md. Changes are listed in CHANGELOG.md.

Development

python -m venv .venv && . .venv/bin/activate       # Windows: .venv\Scripts\activate
pip install -e ".[dev]"
pytest
ruff check src tests

Tests need no tenant: the SDK is replaced by recording fakes and the real SDK models are used to check what would be read.

License

MIT