Dashboard Actions

Create Automated Checks

Learn how to create, assign, and resolve time-driven compliance tasks in Sprinto by using Workflow Checks to track activities, collect evidence, and maintain audit readiness.

This feature allows you to define your own logic-driven compliance checks using entity data available through your integrations or native platform entities. These checks are evaluated regularly, generate evidence for audits, and can be mapped to specific controls to fulfil compliance requirements.

This is especially useful when:

  • The existing Sprinto check library doesn’t cover your checks as per you compliance requirements.
  • You want to enforce custom logic on integrated systems (e.g., AWS, GitHub, Google Workspace).
  • You need to monitor native entities like Risks, Vendors, or Users with specific evaluation rules.

While workflow checks operate on fixed cycles and rely on manual evidence uploads, automated checks use real-time entity data and generate evidence programmatically.

This feature is only available for Advanced and Enterprise plans.


Before You Begin

To create an automated check, ensure:

  • Your integration is complete — only integrated or native entities appear in the entity list.
  • You are an Admin or have permission to access the Monitoring page.
  • Clearly identify the data field or compliance logic you intend to validate to ensure accurate and auditable checks

Steps to Create an Automated Check

1. Open the Check Creation Panel

  1. Log into the Sprinto Dashboard.
  2. Navigate to Monitoring from the left nav.
  3. Click Create check in the top-right corner.
  4. Select Create automated check from the list.

This opens a three-step drawer: Configure check evaluation → Check details → Configure check SLA.


2. Configure Check Evaluation

In Step 1, define the logic and entity scope.

a. Select Entity to Monitor

  • Choose an entity that is either integrated (for example, AWS Redshift Cluster, IAM User and so on) or native (for example, Vendor and Risk).
  • Only entities with data available for your org are shown.

Prerequisite: The integration must be active. If no entities are found, it likely means the source is not integrated yet.

b. View Schema

  • Click Entity schema to see a full list of available attributes and their data types.
  • This is your reference guide to build the check logic.

c. Define Evaluation Rules

Use the rule builder to specify logic:

  • Each rule consists of: Field, Operator (for example, is, is not, contains), and Value.
  • Add multiple rules or nested rule groups using logical operators (AND/OR).

Examples:

SourceCheck DescriptionSpecific Entity/ResourceCheck EvaluationReference Source
GCPProhibit Use of Long-Lived User-Managed Service Account KeysGCP Service Account KeykeyType does not contain user-managedCIS GCP Foundation Benchmark v1.0, v1.2 - 1.4
GCPUse Appropriate Storage Class for Data SensitivityGCP Cloud storage bucketmetaData.storageClass contains STANDARD
OR
metaData.storageClass contains NEARLINE
OR
metaData.storageClass contains COLDLINE
OR
metaData.storageClass contains ARCHIVE
CIS GCP Foundations v1.0: 2.6, 2.9
GCPEnsure Bucket Has Etag for Change TrackingGCP Cloud storage bucketmetaData.etag is not empty


CIS GCP Foundations v1.0: 2.5
AWSKey Must Be EnabledAWS KMS Keyenabled is TrueCIS AWS Foundations v1.4 - 2.6
AWSARN Format Must Be ValidAWS KMS Keyarn matches pattern ^arn:aws:kms:[^:]+:[0-9]{12}:key/[a-f0-9-]+$Recommended best practice
AWSGuardDuty Should Cover All RegionsAWS Guard DutydetectorStatuses[].region contains us-east-1
AND
detectorStatuses[].region contains us-east-2
CIS AWS Foundations Benchmark v1.4 - 3.5
AzureSet Backup Retention to Minimum Required DaysAzureCosmoDBBackupPolicyretentionPolicy.days is greater than or equal to 30

CIS Microsoft Azure Foundations Benchmark v3.0.0, Section 4.1.6
AWSEnable Instance Deletion ProtectionAWS RDSmetaData.DeletionProtection equals trueCIS AWS Foundations v1.4 - 2.8
AWSMulti-AZ Deployment for High AvailabilityAWS RDSmetaData.MultiAZ equals trueCIS AWS Foundations v1.4 - 2.9
AWSRestrict Master UsernameAWS RDSmetaData.MasterUsername doesnot contain root
OR
metaData.MasterUsername doesnot contain admin
CIS AWS Foundations v1.4 - 1.2/2.6
AWSAttach Instance to Security GroupsAWS RDSmetaData.DBSecurityGroups is not emptyCIS AWS Foundations v1.4 - 4.1
AWSCopy Tags to SnapshotsAWS RDSmetaData.CopyTagsToSnapshot is TrueCIS AWS Foundations v1.4 - 2.10
AWSEnable IAM Database Authentication (if needed)AWS RDSmetaData.IAMDatabaseAuthenticationEnabled is TrueCIS AWS Foundations v1.4 - 1.1/2.11

d. Run a Test

Click Test to simulate the logic on a sample set of entity records.

  • Entities that pass/fail the criteria will be shown.
  • This evaluation isn’t considered in evidence, and a failed check here won’t generate any tasks

3. Add Check Details

In Step 2, define metadata for the check:

  • Name: Descriptive title for the check (for example, "S3 Buckets Must Be Encrypted").
  • Description: What the check evaluates
  • Instructions: Guidance on how to resolve failures. This information would be shown in task drawers for anyone whom the check is assigned to.
  • Owner: Person responsible for fixing failed tasks

Once the check is created, Sprinto will automatically assign any failed entities to the owner.


4. Configure SLA and Escalations

In Step 3, define how Sprinto should track and escalate failed tasks:

  • Due: The number of days the check will remain in the Due state, indicating that action is needed.
  • Critical: The number of days the check will remain in the Critical state before failing. During this time, it can be escalated to a specific user (for example, InfoSec Officer) after X days.
  • Failing: The number of days after which the check will be marked as Failing.

These timelines help stakeholders prioritise issues and reduce resolution time.


5. Click "Create Check"

Once saved:

  • The check is Active.
  • It immediately evaluates all relevant entities.
  • Tasks are created if failures are detected.

Understand What Happens After

Once automated checks are created they work like other pre-built checks within the system and are evaluated regularly:

  • Appears in the Monitoring table under "Automated Checks".
  • Triggers pending tasks for failing entities.
  • Tasks are routed through the full lifecycle: Due → Critical → Failing.
  • Tasks appear on the Tasks Dashboard and can be fixed via Fix It drawers.
  • The check is visible across:
    • Monitoring page
    • Control Health Dashboard
    • CHDB and audit reports (when mapped to a control)
    • Entity Detail pages, Overview pages, and Data Library.

Evidence begins collecting from the moment a check is created and evaluated. However, for this evidence to be included in an audit, the check must be mapped to a control, and that control must be linked to an audit.

For example, if a check is created on 2nd September and mapped to a control on 20th September—while the control is already part of an audit spanning August to December—the audit will reflect evidence from 2nd September onwards, not just from the mapping date.


Supported Entities

You can write checks against:

  • Integrated entities (for example, EC2 instances, GitHub repos, GWorkspace users and so on)
  • Native Sprinto entities (for example, Risks, Vendors, Users, Policies and so on)

The supported entities table contains:

  • A list of all entity types
  • Attributes and data types for each
CategorySupported Entity
UncategorisedAWS Security Hub
Codacy
Crowdstrike Spotlight
Deepsource
Intruder
Jira Vuln Provider
Microsoft Defender Endpoint
Socket
Tenable
AWS Inspector (Finding)
Azure Defender
Dependabot (Vulnerability Alert)
Google Security Center (Finding)
Halo Security
Qualys
Rapid Fort
Semgrep
SL Scan
Snyk
Sonarcloud
Sonarqube
RepositoriesGitLab Repo Group
GitHub Repo Group
Bitbucket Repo Group
Azure DevOps Repo Group
AWS CodeCommit Repo Group
GitLab Repo
GitHub Repo
Bitbucket Repo
Azure DevOps Repo
AWS CodeCommit Repo
Access ManagementAzure DevOps User
Azure User
Bitbucket User
AWS CodeCommit User
GCP User
GitHub User
GitLab User
GSuite User
MongoAtlas User
Office365 User
Okta User
Zoho User
AWS User
Bitbucket Access
GitHub Access
GitLab Access
CRMAccelo User
Active Campaign User
Asana Access User
Incident ManagementAzure Active Directory Access User
BambooHR Access User
Basecamp User
Box User
HRMSCalendly User
MDMCisco Meraki User
ClickUp Access User
Close User
VulnerabilitiesCloudflare User
InfraConfluence User
Copper User
Databricks Access User
Datadog Access User
DocuSign User
AssetsFiles.com User
DatabaseFireflies AI User
FreeAgent User
Freshdesk User
StorageFresh Service User
IAM RolesFront User
Google Analytics User
IAM RolesGrafana Access User
Security GroupsHelpScout Access User
IAM PoliciesHubSpot User
Intercom User
FirewallJenkins User
VPNJetBrains User
Load BalancerJira Access User
Keap User
LoggingKeeper Security User
CertsKnowBe4 User
LastPass User
Linear Access User
Container ServicesMetabase User
Microsoft Teams User
Miro User
MonitoringMonday User
Moneybird User
Netlify User
KMSNew Relic Access User
OthersNotion User
OneLogin User
OpenAI User

Don’t see your entity listed? Reach out to the Sprinto team to request it.


Best Practices

TipWhy It Matters
Use schema viewerUnderstand available attributes before building logic
Always test the ruleAvoid false positives and unnecessary alerts
Assign a clear ownerEnsures accountability and faster remediation
Set escalation timelinesKeeps failing checks visible to stakeholders
Map to controlsEnables audit evidence generation