User Decisioning

Use Sprinto’s user decisioning interface to mark users as in-scope or not-in-scope, resolve compliance gaps, and ensure platform-specific controls like MFA are enforced.

User decisioning in Sprinto refers to the process of classifying users based on their risk and relevance to compliance monitoring. By mapping users to specific platforms, systems, or roles, Sprinto allows you to determine whether they are in-scope for checks like multi-factor authentication (MFA), access reviews, or login protection.

This article outlines how user decisioning works in Sprinto, which platforms are covered, and how to take appropriate actions on detected users.

---

What is User Decisioning

When Sprinto integrates with platforms such as AWS, GitHub, Google Workspace, or Azure, it automatically pulls user lists and maps them to relevant checks. User decisioning allows you to:

• Mark users as In Scope or Not in Scope

• Determine if a user requires resolution (e.g., MFA not enabled)

• Filter users by role, activity status, or platform

• Focus remediation efforts only on relevant accounts

---

Supported Platforms

Sprinto supports user decisioning on the following platforms:

1. Cloud Infrastructure:

   • AWS (IAM Users, Root Users)

   • GCP, Azure

2. Identity Providers & SaaS:

   • Google Workspace

   • Microsoft 365 / Azure AD

   • Okta, OneLogin

   • Zoho

3. Version Control & DevOps:

   • GitHub

   • GitLab

   • Bitbucket

   • Azure DevOps

   • AWS CodeCommit

4. Database & Cloud Services:

   • MongoDB Atlas

   • Oracle Cloud (select entities)

---

How to Perform User Decisioning

1. Go to Monitoring > Check History

2. Click into a check that involves users (e.g., “MFA not enabled for GitHub users”)

3. Click View Users

   • A table will show:

     • Username or email

     • Role or group (if available)

     • Whether MFA or other controls are enabled

     • Last login or activity (if available)

4. Take Action per User

   • Click on the dropdown next to the user

   • Choose:

     • Resolve – If control is now enforced (e.g., MFA enabled)

     • Not in Scope – If the user does not require enforcement (e.g., service account, inactive user)

     • Remind – Use for pending controls awaiting end-user action

---

Use Case Examples

Platform	Action
GitHub	Mark inactive contractors as Not in Scope
AWS	Exclude service-linked IAM users
Google Workspace	Flag shared mailboxes as Not in Scope
Okta	Confirm MFA setup and resolve users

---

Best Practices

• Periodically review in-scope user lists for each integration

• Exclude users only when fully justified (e.g., unused, service accounts)

• Ensure evidence (e.g., user export, policy assignment) is available for review

• Use platform-native MFA policies to enforce compliance at scale