Every fast-growing tech company hits the same wall: onboarding and offboarding that used to be "good enough" quickly turn into a security risk and an endless ticket queue.

New engineers wait days for GitHub and Notion access. Departed staff linger in Jira. Your lean IT team becomes the human provisioning layer between people and tools.

One study of former employees in the US, UK, and Ireland found that 83% kept access to at least one company account after leaving.1beyondidentity.com That's not just sloppy workforce management-it's a direct hit to security, compliance, and SaaS spend.

This guide walks through a practical, step-by-step approach to:

  • Turn ad-hoc provisioning into repeatable onboarding automation
  • Build offboarding that actually closes access
  • Cover contractors, bots, and every "new species of identity"
  • Do it all without increasing headcount-with Iden when you want complete coverage

What you need before you start

You don't need a dedicated IAM team. But you need:

  • An identity backbone - SSO or IdP like Okta or Microsoft Entra, or at least a central directory
  • A people system of record - HRIS (BambooHR, Personio, Workday, etc.)
  • An app inventory - the 20-40 apps your tech team actually uses (Slack, GitHub, Jira, Notion, Figma, etc.)
  • Clear team structures - basic roles (Backend Engineer, SRE, Data Engineer, Contractor, etc.)
  • Executive support - agreement to standardize access management

Tip
If you have none of this, start with app inventory and basic roles. You can't automate chaos.

Step 1 - Map the real lifecycle of your tech workforce

Most onboarding and offboarding issues start with not knowing what actually happens today.

  1. Document joiners, movers, leavers.
    • Joiners: new hires, interns, contractors.
    • Movers: promotions, team changes, manager/location changes.
    • Leavers: resignations, layoffs, contract ends.
  2. Capture current triggers.
    • Who tells IT about a new hire? HR, a ticket, a Slack ping?
    • For leavers, what's the first system that knows-HR, manager, payroll?
  3. List every touchpoint.
    For a recent engineer hire, document every step from contract signed to first deploy: accounts, groups, repos, SaaS tools provisioned.

Common mistake
Skipping this and jumping to tooling. If you don't understand your real process, you'll just automate the wrong one faster.

Step 2 - Standardize roles and access profiles

You can't scale provisioning if every person is a special case.

  1. Define a handful of standard roles.
    Example:
    • Backend Engineer
    • Frontend Engineer
    • SRE / Platform
    • Data Engineer
    • Customer Support Engineer
    • External contractor (engineering)
  2. Create "birthright access" profiles for each role.
    For each role, specify:
    • Apps they always get (email, Slack, Confluence, Jira, GitHub, feature flag tools, etc.)
    • The access level for each (Slack channels, GitHub repos, Jira projects, data warehouse roles)
  3. Add context rules.
    • Location (e.g., EU vs US data access)
    • Team (Platform vs Product Engineering)
    • Seniority (who can approve production access)

Tip
Keep profiles opinionated and simple. "Engineer (Product)" plus a few add-ons is far easier to automate than 50 micro-roles you'll never maintain.

Step 3 - Connect your sources of truth and define lifecycle events

Onboarding automation depends on clean events.

  1. Pick your primary source of truth for people.
    For most tech companies, this is your HRIS (Personio, BambooHR, Rippling, Workday, etc.).
  2. Wire it into your identity layer.
    • New hire in HRIS -> creates identity in IdP (Okta/Entra)
    • Role or department change -> updates groups/roles
    • Termination date set -> triggers deprovisioning
  3. Define events in plain language.
    Example:
    • event = new_employee AND department = Engineering -> assign "Engineer (Product)" profile
    • event = employment_status = terminated -> run full offboarding workflow

Common mistake
Relying on managers to open tickets for offboarding. That's how orphaned accounts happen.

Step 4 - Automate onboarding in phases

Here's how to move from provisioning to true onboarding automation.

  1. Prioritize first-week apps.
    Start with 10-15 tools every engineer needs: SSO, email, Slack/Teams, GitHub/GitLab, Jira/Linear, Notion/Confluence, CI/CD, observability.

  2. Decide how each app is provisioned.

    • SCIM-capable apps: connect via IdP or IGA platform
    • API-only apps: use a modern IGA tool or custom automation
    • No SCIM, no API: use universal connectors or agentic workflows (AI-driven, autonomous workflows that act like a human operator)

    An analysis of 721 popular SaaS apps found that 57% offer no SCIM support at any price point, explaining why so many stacks hit the "SCIM wall."2stitchflow.com

  3. Choose your automation engine.
    Script it yourself, use your IdP's lifecycle features, or pick a complete platform like Iden.

    • Iden connects to both SCIM and non-SCIM/non-API tools via plug-and-play connectors.
    • Policies select the right access for each hire; agentic workflows run the full provisioning.

  4. Pilot with one team.
    Start with Product Engineering, track time-to-first-commit and ticket volume, then expand.

Tip
Instrument everything. Measure "HRIS creation -> engineer has access" and "tickets per hire." If automation doesn't improve these, it's not finished.

Step 5 - Make offboarding instant and complete

Most breaches from former staff are the result of unfinished offboarding.

Studies across US and European companies show only about a quarter follow strict post-employment access processes. The majority admit ex-employees can still access accounts.3itgovernance.eu

Offboarding should be a security control, not an HR checklist.

  1. Trigger offboarding from HR or IdP.
    When termination is set (or contract ends):
    • Disable main account (SSO/IdP)
    • Invalidate sessions and tokens
    • Queue deprovisioning across all apps
  2. Deprovision every access path.
    • SSO apps
    • Direct logins
    • Shared accounts
    • Git repos, cloud consoles, CI/CD, monitoring tools
  3. Reclaim licenses and keys.
    • Remove SaaS seats
    • Rotate API/SSH keys and personal tokens
    • Transfer resource ownership (repos, dashboards, projects)
  4. Automate audit evidence.
    Log who was deprovisioned, from which systems, when, and by which policy. Iden stores this in immutable audit logs-so you know "who had access, when."

Common mistake
Treating offboarding as a checklist in someone's Notion. When that person is sick or leaves, your process breaks.

With Iden, offboarding becomes zero-touch: a termination in HRIS or IdP triggers complete deprovisioning-including the SaaS tools left out by SSO. Across Iden customers, automated workflows eliminate 80% of manual access tickets within the first 60 days by cutting manual onboarding and offboarding.

Step 6 - Cover contractors, bots, and other new identities

Fast-growing teams depend on:

  • Contractors and agency engineers
  • Service accounts and CI/CD bots
  • AI agents and automation tools

These rarely fit HR-driven lifecycles.

  1. Add non-employees to a source of truth.
    Use your HRIS's contingent worker model or a lightweight directory with:
    • Owner (internal sponsor)
    • Purpose
    • Expiry date
  2. Apply the same access rules.
    • Standard profiles (e.g., "Contract Engineer - Read-only")
    • Time-limited access for high-risk systems
    • Auto-deprovision on end-date
  3. Require an owner for every non-human identity.
    No owner, no access.

Tip
Grant a bot with production access only with a clear purpose, strict scope, and explicit review-just like a senior engineer.

Iden's unified view for both human and non-human identities makes this practical-all identities, all entitlements, one control plane.

Step 7 - Enable continuous governance and audit-ready evidence

Quarterly access reviews and one-off audits can't keep up with continuous attacks.

Aim for continuous governance instead:

  • Real-time decisions: Access requests evaluated on policy and context-not rubber-stamped by email.
  • Automated access reviews: Managers confirm/revoke access from a single view, with audit evidence generated instantly.
  • Agentic workflows: AI-driven workflows in Iden flag dormant access, Segregation of Duties (SoD) issues, and orphaned accounts-then fix or escalate them.

Automated access reviews free up around 120 hours each year for mid-market teams-making audit season routine.

License reclamation plus avoiding SCIM-gated enterprise upgrades can trim up to 30% of SaaS spend for fast-growing companies.

Next steps: make this real in your org

If you're a lean IT team in a 50-2,000 person tech company, you don't need a year-long IAM project-you need a concrete 90-day plan:

  • Weeks 1-2: Map joiner-mover-leaver flows; define 5-8 roles.
  • Weeks 3-6: Connect HRIS to IdP; automate onboarding for top 10 apps.
  • Weeks 7-10: Roll out zero-touch offboarding, including non-human identities.
  • Weeks 11-12: Add continuous access reviews and evidence collection.

Platforms like Iden deliver complete coverage (SCIM and non-SCIM apps), fine-grained control to channel/repo/project level, and automation that lean IT teams can run easily.

Iden currently automates provisioning for more than 175 apps: GitHub, Notion, Slack, Figma, Linear, and more-with new connectors delivered in as little as 48 hours.

If you're tired of being the human glue between HR tickets and SaaS apps, it's time to let policy-driven, agentic workflows take over the repetitive identity work-so your team can get back to building.

FAQ: Scaling Onboarding and Offboarding

How big do we need to be before this matters?

If you're hiring 5-20 people a month-or running more than ~20 critical SaaS tools-manual onboarding and offboarding start to break. You'll see growing wait times, inconsistent permissions, and zombie accounts. For most US/UK & DACH tech firms, this kicks in between 50 and 300 employees.

Do we need a dedicated IAM team to automate user lifecycle management?

No. Modern platforms like Iden are built for lean IT. Policies and connectors do the heavy lifting; IT defines rules and handles exceptions-not babysitting scripts or building integrations by hand.

Should HR or IT own onboarding and offboarding?

HR owns when events happen (hire, move, leave). IT owns how those events translate into access changes. Cleanest flow: HR updates HRIS, triggering policy-driven changes in your identity layer.

How do we handle employees who change teams or roles?

Treat movers as first-class events, not ad-hoc requests. A role change in HRIS should:

  • Add the new access profile
  • Remove the old one-not just keep stacking rights
  • Trigger a manager review for any high-risk systems

What about bots, CI/CD accounts, and AI agents?

Treat them like users:

  • They live in a source of truth
  • They have an owner and expiry date
  • They get least-privilege, time-bound access
  • They're included in continuous reviews

That's how you stop a "new species of identities" from becoming your biggest blindspot.