Actions

Overview

Actions can be executed periodically using the Schedules feature in Collections → Schedules. Each Action can be linked to a defined schedule that determines when it triggers.

Overview

Actions automate repetitive compliance activities by allowing you to create tickets or send notifications through external integrations such as GitHub, GitLab, JIRA, Asana, or Slack. They help ensure that important tasks — such as periodic reviews, control verifications, or vulnerability checks — are automatically scheduled and tracked.

Actions can be executed periodically using the Schedules feature in Collections → Schedules. Each Action can be linked to a defined schedule that determines when it triggers.

Core Functionality

Actions bridge the gap between compliance requirements and operational execution. They allow you to automate recurring tasks tied to your frameworks, policies, and controls — ensuring that your organization consistently performs key compliance activities.

Once configured, Actions can trigger:

• Tickets on connected project management tools (e.g., JIRA, GitHub, GitLab, Asana)
• Notifications to communication channels (e.g., Slack)
• Periodic reminders to perform assessments, reviews, or control verifications

Each Action can be linked to a schedule, defining its recurrence (e.g., weekly, monthly, quarterly). When executed, it automatically generates tickets or notifications using predefined templates, helping teams remain proactive.

Evidence Collection and Audit Integration

Every Action creates verifiable evidence of recurring compliance activity. For example, a recurring JIRA ticket to review open vulnerabilities will, once closed, reflect compliance evidence in devguard.

This evidence can later be reviewed or exported for audit readiness, demonstrating that required periodic checks are being performed.

Import and Export

Assets can be imported/exported in CSV format:

name,integration,content
Access Review,GITHUB,Perform a security vulnerability review across repositories and attach the report.
Vulnerability Review,GITHUB,Perform a security vulnerability review across repositories and attach the report.

Fields Explained

Integrations

Integrations define where and how your Actions execute. All integrations can be managed from the Integrations page under Settings, where authentication and configuration options are available.

Best Practices

• Start small: Begin by automating simple recurring compliance tasks, such as reviewing policy adherence or performing asset checks, before scaling to broader automation.
• Leverage schedules: Use the Schedules feature to standardize frequency — e.g., monthly for risk reviews or quarterly for control validation.
• Template for consistency: Use Markdown templates to ensure every ticket or notification contains consistent context and compliance references.
• Monitor completion: Regularly verify that generated tickets or notifications are being resolved. Closed tickets serve as audit-ready evidence of recurring compliance actions.
• Integrate across systems: Combine Actions with your existing tools (e.g., JIRA + Slack) to keep all stakeholders informed without manual coordination.
• Review and iterate: Regularly review your Actions and schedules to adjust frequencies, templates, or integrations as your compliance landscape evolves.

Audit Readiness

By linking automated Actions with your operational tools, you ensure that every recurring review, check, and remediation activity is both scheduled and traceable — providing strong evidence during audits or regulatory reviews.

Compliance Value

Actions transform compliance from a static checklist into an active, ongoing process. By automating routine procedures and tracking outcomes, your organization gains:

• Continuous assurance that required reviews are happening on time
• Verified audit evidence that shows recurring checks and task completion
• Reduced manual effort and improved accountability across teams

When combined with Frameworks, Policies, and Controls, Actions complete the compliance loop — ensuring every standard is not only defined but operationally enforced.

Checks

An action and a check are the two things this page does. An action writes: it opens a ticket or sends a notification on a schedule, and someone does the work. A check reads: it asks a connected tool a question on a schedule and files the answer as evidence, with nobody in the loop.

Use an action when the proof is that a human did something. Use a check when the proof is a setting in a vendor system.

What a check is

A check is one scheduled, read-only question asked of a tool you have connected: is branch protection enforced, is MFA required, is this certificate still far from expiry, is the bucket private. It runs on a schedule you choose, and it writes what it found back into devguard as evidence.

That is the whole point of the feature: the proof an auditor asks for stops being a screenshot someone took once and becomes a record that refreshes itself. A check never writes to your vendor. Every request it makes is a read, over a credential you scoped yourself and can revoke at any time.

Checks live in this list alongside your actions; the tools they run against are connected once under Settings → Integrations.

Enabling a check

Browse catalog lists every check devguard ships, grouped by provider. Each entry states plainly what it verifies and what passing means, so you can decide whether it is worth running before you enable it.

Enabling asks for three things:

• A credential, when the provider authenticates with an API key. If the provider is not connected yet, connect it first from Settings → Integrations; a check cannot go active without the credential it needs.
• A schedule, from Collections → Schedules. Every active check must have one. The schedule is what makes the evidence current rather than a one-off.
• Variables, for some checks: values only you know, such as an organization identifier, a repository name, or the threshold you want enforced.

An enabled check is bound to a piece of evidence in your library, created for it automatically. That evidence is what you then link to the controls the check supports, so a passing run satisfies them and a failing one is visible where the work is tracked.

Statuses and verdicts

A check has a status, which is about the check itself:

• Active — on its schedule and collecting evidence.
• Draft — not yet running. A draft is where a check waits while it is still missing a schedule, a credential, or a required variable.
• Inactive — deliberately paused. Deactivating stops future runs and keeps everything already collected.

Each run has a verdict, which is about what was found:

• Passed — the condition held. The bound evidence flips to done and its review date moves forward.
• Failed — the condition did not hold. The run records one or more findings naming what is wrong, and the evidence is marked failed so it surfaces in your worklist.
• Errored — the check could not reach a conclusion: the credential was rejected, the endpoint was unreachable, the API changed shape. An error is not a failure. It leaves your evidence untouched, because "we could not check" is never the same as "this is broken".

When a check errors three times in a row it is flagged as unhealthy and the evidence owner is emailed. That is the signal that something about the connection needs attention rather than the underlying control.

Reading a run

Opening a check shows its run history. Each run records its verdict, how long it took, the log lines the run emitted, and any findings. On a passing run the collected data is also stored as an artifact and attached to the evidence: the actual proof, not just the word "passed".

Credentials never appear in any of this. They are stripped from artifacts, logs, findings, and error messages before anything is written.

Test run executes a check immediately and shows the full result without writing evidence and without touching the schedule. It is the fastest way to confirm a credential works or to see what a check actually returns before you rely on it.

Building your own check

When the catalog does not cover something, the check builder writes one with you. Describe what you want verified in plain language and it drafts the check, shows you the steps it will run, and lets you test it against your real credential until the result is right.

The builder can draft, revise, and test. It cannot publish: activating a check is always your decision, made in the publish dialog, and the same requirements apply as for any other check — a schedule, a credential where the provider needs one, and every required variable supplied.

A published check is versioned. Editing the logic of a live check is deliberately not possible; you publish a new version instead, and can roll back to a previous one. That way what a check was doing on any given date stays answerable.

Where checks show up

• Dashboard — a card summarising how your active checks are doing.
• Evidence — the record each check maintains, linkable to controls like any other evidence.
• Search — checks are searchable by name.
• Your AI assistant — can read your checks and their results, and help you build new ones.

Comments

Every action's detail view has a Comments tab for discussing it in place, so the reasoning behind a decision stays attached to the record instead of living in a chat thread nobody can find later.

Write a comment with light formatting (bold, italic, underline, lists), reply to any comment (replies cannot be nested further), and edit or delete your own. Deleting a comment that has replies leaves a placeholder so the conversation still reads in order.

Type @ to mention a colleague. They are notified in the app and by email, and can adjust how often they hear about comments under Account → Notifications.