AtomationDocsGetting started guideGetting Started with Atomation Okta Assessment
A practical guide for the first customer setup: sign in, update each Okta org, select frameworks, automate Okta API access, capture Okta SSO metadata when needed, add manual evidence, and review findings.
Overview
Use this guide after the Atomation welcome email arrives. It shows what the customer does in Atomation, what the Okta administrator does in the Okta Admin Console, and where manual evidence or business decisions are recorded.
The setup is intentionally split by surface. Customer-owned decisions stay in the Atomation workspace. Okta application setup stays in the Okta Admin Console. Findings, potential risks, and accepted business decisions stay visible for the report handoff.
Primary admin, security owner, and any customer-approved partner helping with setup.
Org profile, frameworks, automated API setup, optional Okta SSO metadata, and manual evidence are ready.
Each Okta org has its own connection name, Okta URL, framework selection, and API verification.
Use the API guide for assessment access and the SSO/SCIM guide for portal login and provisioning.
Executive Packet
This section is the short version for the sponsor, COO, CISO, or security leader reviewing readiness. It separates customer-owned decisions from Atomation validation so the handoff is clear and defensible.
| Decision area | Customer owner | Atomation output |
|---|---|---|
| Okta org scope | Confirm which production or preview orgs are included. | Per-org settings, evidence, and findings stay separated. |
| Framework selection | Select HIPAA, SOX ITGC, SOC 2, GLBA/FFIEC, ISO 27001, PCI DSS, CIS Controls v8, or NIST 800-53 per org. | Findings and reports map to the selected framework context. |
| Assessment access | Approve the assessment connector setup and temporary Okta API token workflow. | Connection verification, snapshots, potential risks, and evidence trail. |
| Business decisions | Accept, remediate, or track recommendations where the choice is risk-based. | Report notes explain accepted decisions without hiding potential risks. |
Executive summary: the customer controls scope, access approval, framework selection, and accepted business decisions. Atomation validates the technical setup, records evidence, identifies potential risks, and packages the report for review.
Roles and Responsibilities
| Role | Owner | Responsibility |
|---|---|---|
| Atomation operator | Atomation | Create tenant, verify setup, run scan, review findings, and publish reports. |
| Customer sponsor | Customer | Confirm scope, recipients, approval, and report handoff expectations. |
| Customer Okta administrator | Customer | Run the Okta API Services app setup and optional Okta SSO/SCIM provisioning. |
| Partner lead | Approved partner | Coordinate co-delivery or remediation only after customer approval. |
Where Work Happens
| Surface | Customer action | Why it matters |
|---|---|---|
| Atomation workspace | First login, MFA, org contacts, framework selection, Okta Metadata URL capture, manual checklist, scans, and reports. | Keeps customer-owned scope and evidence attached to the right Okta org. |
| Okta Admin Console | API Services app, SAML SSO app, SCIM provisioning, group linking, app assignments. | These settings are controlled by the customer's Okta administrator. |
| Findings review | Review potential risks, add notes, accept business decisions, or track remediation. | Creates the report context behind each recommendation. |
Getting Started Steps
Complete these steps in order for each customer workspace. Multi-org customers should repeat the organization profile and framework step for every connected Okta org.
Open the welcome email
Open the Atomation welcome email from [email protected], click the workspace button, and create your account. The email button points to the customer's own workspace slug.
Sign in and complete MFA
Complete first login and MFA before setup work begins. This confirms the primary customer contact can reach the tenant workspace.
Update each Okta org profile
Open Orgs & connections. For each connected Okta org, confirm the connection name and Okta URL. Production and Preview are detected from the Okta domain. Each Okta org has its own manageable row.
If you have an .oktapreview.com org, connect and scan it before production so your team can validate setup, findings, framework mappings, and the report workflow. A Preview org counts toward your connected-org allowance.
Select frameworks for the org
In the same org card, check the frameworks that apply to that Okta org: HIPAA, SOX ITGC, SOC 2, GLBA/FFIEC, ISO 27001, PCI DSS, CIS Controls v8, and NIST 800-53. Use customer or auditor controls for scopes not listed in Atomation.
Automate Okta API access
Use the Okta API access guide to run the automated API Services app setup. This creates/configures the connector in Okta, assigns Super Administrator to the permanent connector app, grants 31 assessment reads plus okta.appGrants.manage, verifies the exact list, and revokes the temporary Okta API token (SSWS) before setup can succeed. The temporary token inherits full Super Administrator privileges while active. Routine scans request only the reads; Atomation reserves the org-level management scope for a future reviewed workflow targeting the configured connector app.
Save Okta SSO metadata when portal access is needed
If the customer wants Atomation sign-in and provisioning through Okta, use Okta SSO guide. Create a SAML 2.0 app in Okta with the Atomation service provider values. Then copy the Okta Metadata URL from the app's Sign On page, select the matching org in Settings -> SSO / SAML, and save that org's own Metadata URL before assigning users or pushing groups.
This step is separate from the Okta API Services app used for the assessment. The API connection does not need the SAML Metadata URL.
Add manual evidence and answers
Some controls are not fully visible through Okta APIs. Use the Security Checklist to answer manual org-level questions, and use notes for policies, control evidence, or exceptions requested by Atomation.
Review potential risks and business decisions
Atomation shows potential risks and recommendations after the first scan. Some are direct security gaps. Others are business decisions, such as whether lockout emails notify end users, whether an Okta Early Access feature should be enabled, or whether all admins should be assigned through groups.
Atomation can recommend and explain the tradeoff; the customer decides whether to remediate, accept, or track the item. Accepted decisions should include a short note so the final report explains why the item was accepted.
Okta Preview scan and report retention
An .oktapreview.com org retains only its most recent completed scan and generated report. When a rescan finishes and generates its report, the previously retained Preview scan and report are removed. Download the PDF or Markdown report first if you want to keep that earlier result.
Preview orgs count toward the workspace's connected-org allowance. This applies to direct customers and to partner-managed client workspaces. Production-org history follows the current behavior documented in Plans, retention, and scope.
Admin Console and Manual Evidence
Part of the assessment depends on configuration that is only visible in the Okta Admin Console or in customer-owned evidence. Atomation collects many objects through the assessment API connection, but some settings require a customer answer or separately provided evidence.
Examples include Okta Admin Console setup screens, SSO/SCIM app configuration, business-approved notification choices, monitoring coverage, policy exceptions, and controls that depend on internal process rather than API-visible state.
| Where to go | Use it for |
|---|---|
| Orgs & connections | Connected Okta orgs, framework checkboxes, and API Services app verification. |
| Security Checklist | Manual org-level control questions and business-decision notes. |
| Security & Login | Recommended Okta SIEM alert handoff PDF and workspace access settings. |
| Findings Review | Potential risks, analyst notes, accepted decisions, and remediation context. |
Checking a manual control as meeting the recommended practice removes that manual item from open potential-risk review. Marking it as a gap keeps it visible for follow-up. Use notes for accepted business decisions so the report does not read like an unexplained exception.
Ready for First Scan Criteria
Use this checklist before asking Atomation to run the first customer scan. It gives the sponsor a clean view of what is done and what remains open.
| Criterion | Ready when |
|---|---|
| Workspace access | Primary customer admin has signed in and completed MFA. |
| Org profile | Every in-scope Okta org has the correct connection name, Okta URL, and detected environment. |
| Frameworks | Customer-selected frameworks are checked for each in-scope Okta org. |
| Okta API access | API Services app setup is complete, Atomation verification succeeds, and Okta-confirmed temporary-token revocation is shown. |
| Portal SSO and SCIM, if used | The Primary identity org has SAML metadata and SCIM verified before assignments or Push Groups begin. |
| Manual evidence | Known manual checklist answers and requested evidence notes are complete or explicitly deferred. |
| Business decisions | Accepted decisions have owner notes so the final report explains the risk choice. |
Resources
Understand potential risks, evidence, and remediation notes.
Okta documentation for OAuth service apps and scoped API access.
Okta documentation for enabling SCIM after an SSO integration.
Handoff Package
Use the Markdown template to produce the final customer handoff with tenant slug, recipients, setup status, verification notes, report links, and remaining action items.
Template path: internal/atomation-app/docs/templates/client-onboarding.md