Summary and recommendation
Scrut Automation user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Scrut Automation is a GRC and compliance automation platform supporting 60+ compliance frameworks.
User and role management is governed by a role-based access control model, though specific role names, permission boundaries, and seat types are not publicly documented.
Admin configuration details are only accessible through direct engagement with Scrut's support or customer success team.
Quick facts
| Admin console path | Public Scrut documentation does not expose a detailed user-admin click path; tenant administration appears to happen in the authenticated Scrut workspace and help-center-guided setup flows. |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Workspace administration and compliance-program setup within the Scrut tenant. | Detailed public permission boundaries are not documented. | Not publicly documented | Custom contract | Public docs do not enumerate the full role matrix. |
| Standard user / collaborator | Participates in evidence collection, control workflows, and assigned compliance tasks as configured in the tenant. | Exact limits are not publicly documented in accessible sources. | Not publicly documented | Custom contract | Role names and permission edges should be verified in the tenant before automation. |
Permission model
- Model type: role-based
- Description: Scrut Automation uses a role-based access control model. Specific role names, permission boundaries, and plan requirements are not publicly documented in accessible official sources.
- Custom roles: Unknown
- Custom roles plan: Not documented
- Granularity: Not documented
How to add users
- Use the authenticated Scrut workspace or the tenant-specific onboarding flow provided by Scrut to invite a new user.
- Assign the appropriate role and workspace access level during invite setup.
- If your contract includes IdP provisioning, configure the supported identity integration before relying on automated onboarding.
Required fields: Work email, Tenant-specific role assignment
Watch out for:
- Public Scrut help content does not expose the exact invite workflow, so production automation should be validated in a live tenant first.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | Unknown | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Official documentation on delete vs. deactivate behavior is not publicly accessible. No verified source explicitly documents this behavior.
- Use the tenant-specific user-management workflow inside the Scrut workspace to revoke access.
- If IdP provisioning is enabled, remove or disable the user in the IdP first so access state stays aligned.
- Confirm whether Scrut performs deactivation or deletion, and how evidence ownership is handled, because public docs do not describe those semantics.
| Data impact | Behavior |
|---|---|
| Owned records | Not documented |
| Shared content | Not documented |
| Integrations | Not documented |
| License freed | Not documented |
Watch out for:
- Delete semantics, restore behavior, and evidence ownership impact are not publicly documented.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Custom contract | Scrut workspace access and compliance automation features defined by enterprise contract. | Custom (contact vendor) |
- Where to check usage: Not documented
- How to identify unused seats: Not documented
- Billing notes: Scrut Automation uses custom pricing. Typical contract range reported as $10,000–$30,000/year. Seat-level billing details are not publicly documented.
The cost of manual management
Scrut Automation uses fully custom pricing; no self-serve plan tiers or public seat-level billing details are available. Typical contract ranges reported by users fall between $10,000–$30,000 per year, and SCIM provisioning is included only at the Enterprise tier.
Because seat-level usage paths are undocumented publicly, identifying unused licenses requires direct coordination with your Scrut account team.
The decision
Manual provisioning in Scrut is viable but opaque: no publicly documented add/remove user steps, no confirmed deactivate-vs-delete behavior, and no accessible admin console path exist at the time of this research. Teams operating at scale should treat Scrut as a high-touch vendor and plan for support-mediated changes.
If your organization requires auditable, repeatable lifecycle management across every app, the absence of documented procedures is a meaningful operational risk.
Bottom line
Scrut Automation is a capable compliance platform, but its admin and user management layer is largely undocumented in public-facing resources. Manual provisioning is possible but requires direct support engagement, and seat-level billing details are opaque without an active Enterprise contract.
Teams should budget for onboarding support and account for the operational overhead of managing access without self-serve tooling.
Automate Scrut Automation workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
