The short version.
- Auditors ask which automations can change access, who reviewed their logic, and what shows they ran as designed.
- A screenshot of a flow is not evidence of what it does. A reviewed export with a hash is.
- Say the gaps yourself. An honest gap list is stronger than a pack with a hole in it.
1. What the auditor asks
- Which automations can change access? An inventory of every flow that changes a user, a group or an app assignment, and what starts it.
- Who reviewed the logic, and who approved changes to it? Change management: the difference between versions, a reviewer who is not the author, a decision on record.
- What shows it ran as designed? Run and failure records for the period, and what happened when a run failed.
These are commonly filed under change management (ISO/IEC 27001:2022 A.8.32, SOC 2 CC8.1), identity and access rights (A.5.16, A.5.18, CC6.2, CC6.3) and logging and monitoring (A.8.15, A.8.16, CC7.2). Your auditor decides what satisfies a control.
2. Why the usual evidence falls short
Okta Workflows keeps a flow’s own version history but not a history of a folder, not a comparison between two versions, and not a record of who agreed to a change. Giving an auditor console access to look for themselves is something most security teams refuse, with reason.
3. An evidence checklist
- An export of each folder at the start and end of the period, with a hash of each file.
- For each flow that changes access: what starts it, what it changes, and whether a failure is recorded.
- For each change in the period: what differed, who reviewed it, who approved it, and when it went to production.
- Runs and failures per flow, and the follow-up on each failure.
- Connections: which account each uses and what that account is allowed to do.
- Flows nothing calls and nothing starts.
- The gaps, in your own words.
What a line of evidence looks like. Each answer names where it came from and what it cannot show.
| Question | Evidence | Comes from | Does not show |
|---|---|---|---|
| What can change access? | “Leaver: remove access” removes users from the groups in the table “Leaver groups”, on a schedule. | The folder export | Whether the flow is switched on |
| Who approved the last change? | Version 7: two cards changed, reviewed and approved by a named person on a date. | The change request | A change made in the console and never exported |
| What ran, and what failed? | 214 runs in the period; 3 failed, each with a follow-up note. | Runs your org sent | Runs before sending was switched on |
4. Assemble it with Assay
Assay builds this from exports. The assessment grades each folder and can be signed, so its conclusions can be verified later. Changes keeps a version each time an export differs and shows the difference card by card, with a change request someone else decides. The audit evidence pack puts the inventory, the assessment, change control, runs and a plain list of gaps into one page and one PDF for the period. It holds no Okta credentials and connects to no org; it does not attest that a control works.
Sources
- ISO/IEC 27001:2022, Annex A (A.5.16, A.5.18, A.8.15, A.8.16, A.8.32).
- AICPA Trust Services Criteria (CC6.2, CC6.3, CC7.2, CC8.1).
- Okta Workflows documentation: exporting and importing flows and folders, and flow history and execution history.
Okta and Okta Workflows are trademarks of Okta, Inc. Assay is independent of Okta. Card names and limits change: check Okta’s current documentation and test in a preview org before you rely on any pattern here.