How to read it.
- Assessed means the control is checked on every flow in an export, by a fixed rule, and its findings count towards the A to E grade.
- Not assessed means an export cannot prove it either way. The report lists it as not assessed.
- A control and its narrower, checkable part can both be listed. SEC-001 (no secret is hard-coded) cannot be proved from an export, because a secret can sit where no rule recognises it; SEC-002 is the part a rule can check: fields that look like credentials and hold a value.
- The catalogue has 13 families. The score in a report combines them into seven dimensions.
- These are Assay’s own published controls, not an accredited standard. If you think a result is wrong, tell us: a rule that is wrong gets fixed for everyone.
Security (10 of 18 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| SEC-001 | Secrets are not hard-coded Prevent credentials, tokens and passwords from being embedded in workflow configuration. | Critical | Not assessed |
| SEC-002 | Credential-like values are not exposed Detect credential-shaped input fields with populated values. | Critical | Assessed |
| SEC-003 | Custom API calls are reviewed Custom HTTP/API actions require endpoint, authentication and data-flow review. | High | Assessed |
| SEC-004 | Sensitive data exposure is minimised Sensitive personal/authentication data should be limited to what the workflow needs. | High | Not assessed |
| SEC-005 | Sensitive-looking fields are reviewed Identify sensitive fields by exported key names for manual validation. | Medium | Assessed |
| SEC-006 | Endpoints are centrally governed Avoid environment-specific hard-coded endpoints where practical. | Medium | Assessed |
| SEC-007 | Notification targets are governed Avoid accidental personal/test email targets in production workflows. | Low | Assessed |
| SEC-008 | Privileged actions have explicit controls Access-changing operations should have validation and least-privilege controls. | High | Not assessed |
| SEC-009 | Access-changing operations are identified Inventory privileged/access-changing cards for review. | High | Assessed |
| SEC-010 | High-impact actions are auditable Privileged workflow execution should be observable and reviewable. | High | Not assessed |
| SEC-011 | Write actions validate their target Write/access-changing actions should have visible lookup or precondition logic. | Medium | Assessed |
| SEC-012 | External data transfer is justified External calls should have an approved business purpose and data minimisation. | High | Not assessed |
| SEC-013 | Authentication method is reviewable External/API authentication should be identifiable from exported configuration. | High | Not assessed |
| SEC-014 | Headers and parameters are reviewed Custom requests should be checked for authorisation and sensitive headers. | Medium | Not assessed |
| SEC-015 | Environment separation is reviewable Production endpoints and test endpoints should not be mixed. | Medium | Not assessed |
| SEC-016 | Input trust boundaries are explicit Workflow inputs crossing systems should be validated before privileged actions. | Medium | Assessed |
| SEC-017 | Model calls are reviewed Data sent to an external model should be known, minimised and covered by an agreement. | Medium | Assessed |
| SEC-018 | Model output does not decide access A generated value should not drive an access change without validation or a human decision. | High | Assessed |
Reliability (6 of 11 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| REL-001 | External actions have failure handling External/API operations should have deliberate error handling. | High | Assessed |
| REL-002 | Default finish behaviour is reviewed Default finish policies should be consciously accepted for critical actions. | Medium | Assessed |
| REL-003 | Errors are not silently suppressed Ignore-errors behaviour should not hide material failures. | High | Assessed |
| REL-004 | Loops have failure handling Iterative workflows should handle item-level and aggregate failure. | Medium | Assessed |
| REL-005 | Critical writes are recoverable High-impact changes should have retry, compensation or recovery strategy. | High | Not assessed |
| REL-006 | Transient failures have retry strategy Multiple external dependencies should consider bounded retry/backoff. | Low | Assessed |
| REL-007 | Idempotency is considered Repeated execution should not create unintended duplicate changes. | Medium | Not assessed |
| REL-008 | Dependency failures are isolated One dependency failure should not unnecessarily corrupt unrelated steps. | Medium | Not assessed |
| REL-009 | Partial completion is handled Multi-step workflows should define behaviour after partial success. | Medium | Not assessed |
| REL-010 | Long-running work is controlled Large loops and external calls should be bounded and operationally predictable. | Low | Not assessed |
| REL-011 | Model calls have failure handling Model endpoints rate-limit, time out and return malformed content more often than most connectors. | Medium | Assessed |
Error Handling (3 of 5 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| ERR-001 | Critical paths have explicit handlers Critical integration paths should contain deliberate error branches. | High | Assessed |
| ERR-002 | Error messages are actionable Failures should preserve enough context to troubleshoot without exposing secrets. | Medium | Not assessed |
| ERR-003 | Ignored errors are justified Every ignored error path should have a documented rationale. | Medium | Assessed |
| ERR-004 | Error notifications are appropriate Material failures should surface to an operational owner. | Medium | Assessed |
| ERR-005 | Recovery paths are tested Recovery and compensation behaviour should be validated before production use. | Low | Not assessed |
Governance (3 of 12 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| GOV-001 | Every workflow has a description Workflow purpose, scope and assumptions should be documented. | Low | Assessed |
| GOV-002 | Every workflow has an accountable owner Business/technical ownership should be identifiable. | High | Not assessed |
| GOV-003 | Complex logic is commented Non-obvious decisions and integration assumptions should be explained. | Low | Assessed |
| GOV-004 | Change history is governed Workflow changes should be attributable through an external SDLC/change process. | Medium | Not assessed |
| GOV-005 | Production promotion is controlled Production workflows should follow an approved promotion process. | Medium | Not assessed |
| GOV-006 | Dependencies are documented Cross-flow dependencies should be known and maintained. | Medium | Not assessed |
| GOV-007 | Business criticality is classified Critical workflows should be identifiable for stronger controls. | Medium | Not assessed |
| GOV-008 | Data classification is documented Sensitive data handling should have a documented classification. | Low | Not assessed |
| GOV-009 | Dormant flows are reviewed Unused or obsolete flows should be identified and retired. | Medium | Not assessed |
| GOV-010 | Logging posture is deliberate Workflow logging should be enabled or consciously disabled based on risk. | Low | Assessed |
| GOV-011 | Naming conventions are consistent Flow and card naming should support maintainability. | Low | Not assessed |
| GOV-012 | Ownership survives staff changes Operational knowledge should not depend on one individual. | Medium | Not assessed |
Observability (1 of 5 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| OBS-001 | Privileged workflows are monitored High-impact workflows should have monitoring/alerting. | Medium | Assessed |
| OBS-002 | Failures are detectable Operational failures should be visible to support teams. | Medium | Not assessed |
| OBS-003 | Execution evidence is retained Evidence should support troubleshooting and audit needs. | Low | Not assessed |
| OBS-004 | External dependency health is visible Critical dependencies should have operational visibility. | Medium | Not assessed |
| OBS-005 | Monitoring noise is controlled Alerts should be actionable and not overwhelm operators. | Low | Not assessed |
Complexity (4 of 7 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| CMP-001 | Workflow size is controlled Very large workflows should be decomposed. | Medium | Assessed |
| CMP-002 | Branching complexity is controlled Excessive branching should be simplified. | Medium | Assessed |
| CMP-003 | Nested logic is understandable Deep decision structures should be minimised. | Medium | Assessed |
| CMP-004 | Repeated logic is minimised Duplicated logic should be centralized where practical. | Low | Not assessed |
| CMP-005 | Loops are bounded Iteration should have predictable bounds and workload. | Medium | Not assessed |
| CMP-006 | Helper flows are cohesive Reusable flows should have clear, narrow responsibilities. | Low | Not assessed |
| CMP-007 | High structural complexity is remediated Extreme size/branching should trigger redesign. | High | Assessed |
Performance (7 of 7 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| PERF-001 | External calls are minimised Avoid unnecessary repeated API/network calls. | Medium | Assessed |
| PERF-002 | Loops avoid chatty integrations External calls inside loops should be reviewed. | Medium | Assessed |
| PERF-003 | Batching is considered Large populations should use batching where supported. | Low | Assessed |
| PERF-004 | Multiple iteration stages are reviewed Repeated iteration can amplify runtime and API load. | Medium | Assessed |
| PERF-005 | Rate limits are considered Production workflows should account for connector/API throttling. | Medium | Assessed |
| PERF-006 | Timeout behaviour is understood External timeout defaults should be known. | Low | Assessed |
| PERF-007 | Writes inside loops are reviewed Iterative writes should be assessed for scale and consistency. | Medium | Assessed |
Architecture (3 of 10 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| ARC-001 | Flow dependencies are understandable Cross-flow calls should be explicit and maintainable. | Medium | Not assessed |
| ARC-002 | Dependency depth is controlled Deep dependency chains increase failure propagation. | Medium | Not assessed |
| ARC-003 | Standalone flows are intentional Unreferenced flows should be confirmed as externally triggered or retired. | Medium | Not assessed |
| ARC-004 | Responsibilities are cohesive A flow should have a coherent business/technical responsibility. | Low | Not assessed |
| ARC-005 | Shared logic is centralized Common logic should not be copied across many flows. | Medium | Not assessed |
| ARC-006 | Multiple dependencies are reviewed Flows with many dependencies need stronger change management. | Medium | Assessed |
| ARC-007 | Unreferenced flows are reviewed Potentially orphaned flows should be validated. | Low | Assessed |
| ARC-008 | Helper-flow depth is controlled Excessive orchestration depth should be avoided. | Medium | Not assessed |
| ARC-009 | Large flows use decomposition Large flows should consider helper-flow boundaries. | Low | Assessed |
| ARC-010 | Critical architecture paths have resilience Critical dependency chains should have explicit recovery/monitoring. | High | Not assessed |
Build Standards (6 of 6 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| STD-001 | Flow names follow the estate's own convention A dominant naming pattern in the estate should be followed by every flow, so ordering and search work. | Medium | Assessed |
| STD-002 | Cards are named for what they do Okta lets every card carry a display name; a flow of default labels has to be re-read to be understood. | Medium | Assessed |
| STD-003 | One spelling per concept The same concept spelled two ways breaks search, sorting and every downstream reference. | Medium | Assessed |
| STD-004 | Names are clean Stray whitespace and doubled separators in names are invisible in the console and break exact matching. | Low | Assessed |
| STD-005 | Tables are named to a convention Table names should say what they hold and follow the estate's convention. | Medium | Assessed |
| STD-006 | Helper flow inputs and outputs are named for what they carry A caller sees only these names on the Call Flow card; 'output' or 'Object' says nothing about what goes in or comes back. | Low | Assessed |
Portability (2 of 2 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| CFG-001 | Tenant-specific identifiers are not hard-coded An export carries its literal ids; after import they point at the org they came from. | High | Assessed |
| CFG-002 | Literal timings and durations are explained Bare numbers standing for seconds, days or reminder offsets should be named or documented. | Medium | Assessed |
Intent (2 of 2 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| INT-001 | A flow does what its name says The name is the contract a reader and an auditor rely on; behaviour that contradicts it is a latent incident. | High | Assessed |
| INT-002 | Parked and abandoned objects are retired Names saying draft, test, old, copy or not-in-use should be removed or renamed once they are real. | Low | Assessed |
Logic (8 of 8 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| LOG-001 | Inputs are validated before an external or privileged call Okta's own guidance is to verify required values exist before calling an API. | High | Assessed |
| LOG-002 | Timing is not used as synchronisation A fixed wait before reading what an asynchronous helper writes is a race, not a guarantee. | High | Assessed |
| LOG-003 | Table reads are bounded An unbounded read of a table that may hold 500,000 rows runs against a 100 MB instance limit. | Medium | Assessed |
| LOG-004 | Every branch has a defined outcome A path that is empty and has nothing after it ends the flow silently. | Medium | Assessed |
| LOG-005 | Comparisons use operands of the same type An ordering comparison against an empty string has no defined meaning. | Medium | Assessed |
| LOG-006 | Near-duplicate flows are consolidated Two flows that differ in a few cards drift apart and are fixed once. | Low | Assessed |
| LOG-007 | A schedule runs on every date it names Day 31 of a 30-day month does not exist, so the scheduler skips that month's run without saying so. | High | Assessed |
| LOG-008 | Lookup results are checked before they are used A search that finds nothing returns an empty result, not an error, so the next card acts on nothing. | High | Assessed |
Platform Fit (1 of 1 assessed)
| Control | What it requires | Severity | From an export |
|---|---|---|---|
| FIT-001 | Native connector cards are preferred to raw API calls A raw call to an endpoint that has a native card gives up the connector's auth, pagination and error handling. | Medium | Assessed |
Okta and Okta Workflows are trademarks of Okta, Inc. Assay is independent of Okta. A grade states configuration facts as of the export’s time and is not a security certification.