AtomationDocsGetting started guideGetting Started with Atomation Okta Assessment
A practical guide for the first customer setup: sign in, update each Okta org, select frameworks, connect read-only Okta API access, add manual evidence, and review potential risks.
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, API access, optional SSO/SCIM, and manual evidence are ready.
Each Okta org has its own support contact, phone, email, and framework selection.
Use the API guide for assessment access and the SSO/SCIM guide for workspace login.
Screenshot placeholders identify where approved Okta Admin Console or Atomation workspace captures should be inserted before final customer distribution.
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, or ISO 27001 per org. | Findings and reports map to the selected framework context. |
| Assessment access | Create the Okta API Services app and approve the read-only access model. | 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 | Configure the read-only Okta API service app and optional 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, manual checklist, uploads. | Keeps customer-owned scope and evidence attached to the right Okta org. |
| Okta Admin Console | API Services app, SAML 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.
Atomation first-login screen and MFA setup state.
Update each Okta org profile
Open Settings -> Organizations. For each connected Okta org, confirm the org name, support contact name, support email, and support phone. Each Okta org has its own editable card.
Settings - Organizations card showing org name and support contact fields.
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, and ISO 27001. Use customer or auditor controls for scopes not listed in Atomation.
HIPAA, SOX ITGC, SOC 2, GLBA/FFIEC, and ISO 27001 selected where applicable.
Connect read-only Okta API access
Create the Okta API Services app by following the Okta API access guide. This step happens in the Okta Admin Console and is used for snapshot collection, evidence, potential risks, and reports.
Atomation verification screen after Client ID, scopes, JWKS, and role checks pass.
Set up SSO and SCIM when needed
If the customer wants Atomation sign-in and provisioning through Okta, follow theOkta SSO and SCIM guide. This is separate from the read-only API Services app used for the assessment.
Atomation SSO and provisioning settings after Okta verification is complete.
Add manual evidence and answers
Some controls are not fully visible through read-only Okta APIs. Use the Security Checklist to answer manual org-level questions, and use the monitoring or compliance upload areas for SIEM exports, policies, control evidence, or notes requested by Atomation.
Security Checklist questions that the Okta API cannot derive.
Monitoring or compliance upload area for customer-owned evidence.
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.
Customer dashboard boxes showing potential risks by severity and area.
Findings review showing an accepted business decision with supporting note.
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 read-only API connection, but some settings require a screenshot, export, uploaded document, or an answer from the customer owner.
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 |
|---|---|
| Settings - Organizations | Org support contacts and framework checkboxes. |
| Security Checklist | Manual org-level control questions and business-decision notes. |
| Monitoring | SIEM saved searches, savedsearches.conf, or monitored Okta event types. |
| Compliance Upload | Policies, control evidence, or customer documents requested during review. |
| 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 support contact name, email, phone, and org type. |
| Frameworks | Customer-selected frameworks are checked for each in-scope Okta org. |
| Okta API access | API Services app Client ID is saved and Atomation verification succeeds. |
| Manual evidence | Known manual checklist answers and requested uploads 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