# Create Automated Checks 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. {% hint style="info" %} This feature is only available for Advanced and Enterprise plans. {% endhint %} *** ### 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.

{% hint style="warning" %} Prerequisite: The integration must be active. If no entities are found, it likely means the source is not integrated yet. {% endhint %} **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:**

Source	Check Description	Specific Entity/Resource	Check Evaluation	Reference Source
GCP	Prohibit Use of Long-Lived User-Managed Service Account Keys	GCP Service Account Key	keyType does not contain user-managed	CIS GCP Foundation Benchmark v1.0, v1.2 - 1.4
GCP	Use Appropriate Storage Class for Data Sensitivity	GCP Cloud storage bucket	metaData.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
GCP	Ensure Bucket Has Etag for Change Tracking	GCP Cloud storage bucket	metaData.etag is not empty	CIS GCP Foundations v1.0: 2.5
AWS	Key Must Be Enabled	AWS KMS Key	enabled is True	CIS AWS Foundations v1.4 - 2.6
AWS	ARN Format Must Be Valid	AWS KMS Key	arn matches pattern ^arn:aws:kms:[^:]+:[0-9]{12}:key/[a-f0-9-]+$	Recommended best practice
AWS	GuardDuty Should Cover All Regions	AWS Guard Duty	detectorStatuses[].region contains us-east-1 AND detectorStatuses[].region contains us-east-2	CIS AWS Foundations Benchmark v1.4 - 3.5
Azure	Set Backup Retention to Minimum Required Days	AzureCosmoDBBackupPolicy	retentionPolicy.days is greater than or equal to 30	CIS Microsoft Azure Foundations Benchmark v3.0.0, Section 4.1.6
AWS	Enable Instance Deletion Protection	AWS RDS	metaData.DeletionProtection equals true	CIS AWS Foundations v1.4 - 2.8
AWS	Multi-AZ Deployment for High Availability	AWS RDS	metaData.MultiAZ equals true	CIS AWS Foundations v1.4 - 2.9
AWS	Restrict Master Username	AWS RDS	metaData.MasterUsername doesnot contain root OR metaData.MasterUsername doesnot contain admin	CIS AWS Foundations v1.4 - 1.2/2.6
AWS	Attach Instance to Security Groups	AWS RDS	metaData.DBSecurityGroups is not empty	CIS AWS Foundations v1.4 - 4.1
AWS	Copy Tags to Snapshots	AWS RDS	metaData.CopyTagsToSnapshot is True	CIS AWS Foundations v1.4 - 2.10
AWS	Enable IAM Database Authentication (if needed)	AWS RDS	metaData.IAMDatabaseAuthenticationEnabled is True	CIS 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**. {% hint style="info" %} These timelines help stakeholders prioritise issues and reduce resolution time. {% endhint %}

*** #### 5. Click "Create Check" Once saved: * The check is **Active**. * It immediately evaluates all relevant entities. * Tasks are created if failures are detected. * The check appears under **Automated** in the Monitoring tab.

*** ### 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.** {% hint style="warning" %} 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. {% endhint %} *** ### 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

Category	Supported Entity
Uncategorised	AWS 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
Repositories	GitLab 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 Management	Azure 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
CRM	Accelo User
	Active Campaign User
	Asana Access User
Incident Management	Azure Active Directory Access User
	BambooHR Access User
	Basecamp User
	Box User
HRMS	Calendly User
MDM	Cisco Meraki User
	ClickUp Access User
	Close User
Vulnerabilities	Cloudflare User
Infra	Confluence User
	Copper User
	Databricks Access User
	Datadog Access User
	DocuSign User
Assets	Files.com User
Database	Fireflies AI User
	FreeAgent User
	Freshdesk User
Storage	Fresh Service User
IAM Roles	Front User
	Google Analytics User
IAM Roles	Grafana Access User
Security Groups	HelpScout Access User
IAM Policies	HubSpot User
	Intercom User
Firewall	Jenkins User
VPN	JetBrains User
Load Balancer	Jira Access User
	Keap User
Logging	Keeper Security User
Certs	KnowBe4 User
	LastPass User
	Linear Access User
Container Services	Metabase User
	Microsoft Teams User
	Miro User
Monitoring	Monday User
	Moneybird User
	Netlify User
KMS	New Relic Access User
Others	Notion User
	OneLogin User
	OpenAI User

{% hint style="info" %} Don’t see your entity listed? Reach out to the Sprinto team to request it. {% endhint %} *** ### Best Practices

Tip	Why It Matters
Use schema viewer	Understand available attributes before building logic
Always test the rule	Avoid false positives and unnecessary alerts
Assign a clear owner	Ensures accountability and faster remediation
Set escalation timelines	Keeps failing checks visible to stakeholders
Map to controls	Enables audit evidence generation