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.

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.

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:

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.

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.

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

Best Practices