What runs automatically, and when
| Trigger | What happens | Cadence | Plan |
|---|---|---|---|
| A control is assigned | Email to the assignee | Immediately | All plans |
| A control is due within 7 days | "Due soon" email to the assignee | Once per due date; sent again if the due date moves | All plans |
| A control is overdue | Overdue email with the number of days overdue | At most once every 7 days until it is done | All plans |
| A recurring control is completed | The next instance is created with the next due date | Per control cadence (e.g. 3, 6 or 12 months); your own interval per control on Enterprise | All plans |
| A policy version is published with acknowledgement | Request email to everyone in the audience | On publish; manual reminder at any time | Pro, Enterprise |
| The acknowledgement deadline has passed | Reminder to each person who has not acknowledged | Every 7 days | Pro, Enterprise |
| Evidence validity date (per control or per file) | Item in the expiry digest | 30 days before, 7 days before and on or after the date | Basic and up |
| Vendor next review or contract end date | Item in the expiry digest | 30 days, 7 days and on the day | Pro, Enterprise |
| Every day | Coverage snapshot: % of controls covered, open and overdue controls | Daily, 365 days kept | All plans |
- Reminders are claimed atomically before they are sent, so overlapping runs never email twice.
- The expiry digest is one email per workspace per day: admins get every item, assignees get their own evidence items.
- Controls marked not applicable in the Statement of Applicability get no reminders and stay out of the trend.
- Each person can switch off assignment, due-soon, overdue, policy and expiry emails individually; all are on by default.
What the dashboard watches
- What needs you now: one list, oldest first, of overdue controls, controls due this week, policies to read, evidence that has expired or is about to, vendor reviews and contract ends, and the live incident clocks. Filter by overdue, this week or to read.
- Controls covered: a control counts as covered when its latest cycle is done, or when it was done before and the next cycle is not yet overdue. Expired evidence on the last completion makes it uncovered again, so lapsed evidence shows up in the number.
- Coverage over time and sparklines on each stat, from the daily snapshots.
- Expiring soon: everything that lapses within 30 days, from the same selection as the digest.
- Audit readiness (Enterprise): the Prepare for Audit score as a card, recorded in the trend.
Webhooks and the REST API
On Enterprise the workspace pushes events to your own tools and exposes its registers to them.
| Details | |
|---|---|
| Webhook events | task.created, task.assigned, task.completed, risk.created, risk.updated, incident.created, incident.status_changed, intake.submitted, vendor.created |
| Signing | HMAC-SHA256 over timestamp.body in X-Dazr-Signature, with X-Dazr-Timestamp; a separate secret per webhook |
| Endpoints | Up to 10, HTTPS only, public addresses only; a test button and the last delivery status per webhook |
| Delivery | Best effort: 5-second timeout, delivered once, no retries |
| REST API | Read-only, Bearer key: workspace, readiness score, controls (filter by framework, status, assignee, updated since), risks (filter by status, minimum score), incidents, vendors, assets, activity log |
| Limits | 240 requests a minute and 60,000 a day per key; rotate the key at any time |
What is not automated
To be precise about it: Dazr automates the schedule around your evidence, not the collection of the evidence itself.
- There are no built-in connectors that pull configurations, logs or user lists from cloud, identity or HR systems. People attach files, links or notes to a control.
- Controls are not tested automatically; a control is complete when its owner completes it.
- Webhooks are delivered once, without retries.
- Connections to your own systems can be built on the REST API and webhooks, or by the Dazr team on request on the Custom tier.