Recurring audit

What it means

A recurring audit is one Enji Guard audit metric with Run automatically when code changes switched on. On its cadence, Enji Guard checks the repository head and reruns that audit only when the head is newer than the last successfully audited commit, so the score describes the current revision.

The schedule belongs to a single metric: turning on recurrence for Security does not schedule Dependency hygiene, Tests, or AI readiness.

A recurring audit is not:

• Continuous auditing as the IIA and ISACA use it: ongoing, technology-enabled assessment of risks and controls by internal auditors.
• Continuous monitoring in the NIST SP 800-137 sense, which watches deployed systems and control effectiveness, not a code revision.
• A cron job. GitHub Actions, GitLab pipeline schedules, and Dependabot intervals fire on the clock whether or not anything changed. Scheduled code scanning runs so newly published vulnerabilities surface even in a repository nobody is maintaining. A recurring audit does the reverse: it waits for a commit.
• A one-time audit, or a check on every push.

How it works

An automatic run needs three things:

1. The cadence slot is open. Cadences are Daily, Workdays, Three times a week, Twice a week, Once a week, or Monthly.
2. The repository head is newer than the last successfully audited head.
3. No run of the same audit is active for that repository.

An unchanged repository keeps its current result instead of a duplicate report. After a run starts, the next commit waits for the next eligible slot.

Where it appears in Enji Guard

Recurrence is set per audit, then summarized at project level:

• On the audit metric. Rerun opens Restart and automation: Run once now for a manual run, Automatic runs for the Run automatically when code changes toggle.
• On the project dashboard. The repository entry’s Automations button opens the same settings for audits and fixes.
• In project automation settings. Recurring audits lists the audits that restart automatically and sets Recurring audit frequency; each audit charges its own price per scheduled run.
• In audit history and the rerun menu. Each run records the commit it checked; the rerun menu shows it as Latest checked commit.

How Enji Guard helps

Recurrence makes green a maintained state rather than a score earned once. After a reviewed improvement is merged, the next eligible run checks the merged revision and records whether the evidence improved. Ordinary feature work gets the same treatment: the metric stayed green, left it, or came back.

A schedule is eligibility, not a promise. Enabling recurrence does not change a completed audit, an unchanged repository is not rerun, and a blocked trigger leaves a disabled-state explanation. Disabling automatic runs ends future eligibility and keeps the completed history.