Keep six things: a register of tasks, the access each holds, run history, change records for prompts and permissions, review sign offs, and test results for kill switches. Together they let you show an auditor who owned what, what it could touch and what it did. This is general guidance, not legal advice.
Why auditors care
Scheduled tasks act on systems in scope without a person present. Questions an assessor may ask are familiar ones: who authorized this access, how often is it reviewed, what did it do, and how do you stop it. Your answers should come from records, not memory. The same logic as evidence for AI agent decisions and actions applies, with scheduling added.
The evidence list
| Evidence | What it proves | Source |
|---|---|---|
| Task register | Inventory exists and has owners | Your register, refreshed monthly |
| Access record per task | Least privilege decisions were made | Connector list, repositories, permission mode, sandbox level |
| Run history | Tasks ran, skipped or failed as stated | Product run history, exported or screenshotted with dates |
| Transcripts for writing tasks | What it actually did | Product session logs, with secrets excluded |
| Change records | Edits to prompt, schedule or access were controlled | Pull requests, tickets or the product edit history |
| Review sign offs | Periodic review happened | Dated review notes from the sponsor |
| Kill switch test | You can stop it | A dated test showing a pause or disable took effect |
Product facts that help
Several products expose useful records. Claude Code Desktop shows every past run including skipped ones with reasons, and lists saved tool approvals per task that can be reviewed and revoked. Claude Code routines list past runs with sessions you can open. Cowork lists upcoming and past runs in the Scheduled section. Always check what your own plan retains and for how long, since retention and export options vary and some are not stated in vendor help pages.
Gaps to plan for
- The Cowork help article does not describe notifications, usage limits or permission details beyond the approval mode setting, so do not assume them in a control description.
- Routines belong to individual accounts, so central admins may not see them. Your register has to carry that load.
- Run status can be green without a successful outcome. Evidence should include an outcome check, not only a status.
Writing the control description
Keep claims small and testable. "Scheduled AI tasks are registered with an owner and reviewed quarterly" is better than "all automation is governed". Attach the last review as proof. Avoid describing any control as a certification or attestation, and do not imply that tooling alone satisfies a framework.
Automating collection
Collect on a schedule, store in one folder with dates, and keep a single index. Where it fits, map the evidence to the framework controls you report against, then check coverage each quarter.
Worked example: answering an auditor's sampling request
An assessor reviewing your change and access controls asks: "Show me three automated agents that act on production systems, who approved their access, when it was last reviewed, and one example of what each did last month."
With the evidence list in place, the answer takes an afternoon.
From the register, you pick three tasks that write: a docs update routine, a ticket triage routine and a CI workflow that files findings. For each, you hand over the register row (owner, sponsor, trigger, access), the access approval, which is the ticket where the sponsor approved the connector list, and the most recent quarterly review note with its date. For one example of activity, you export a run from the product history and attach the downstream record, such as the pull request or ticket created. For the kill switch question you provide the dated test where a task was paused and confirmed to stop.
Without the register, the same request becomes a scramble to reconstruct who created what, and the answers rest on memory.
Evidence quality ladder
| Level | Example | Comment |
|---|---|---|
| Strong | Export or log from the system, dated and attributable | Hard to dispute |
| Medium | Screenshot with visible date and account | Fine if the system cannot export |
| Weak | A statement in a document with no record behind it | Treat as a claim, not evidence |
Linking tasks to control themes
Without naming any specific framework requirement, these themes recur across most security frameworks, and scheduled tasks touch each:
- Access management. Who approved the task's access, and is it least privilege?
- Change management. How are edits to prompts, schedules and connectors controlled?
- Logging and monitoring. What records exist, and who reviews them?
- Incident response. Can you stop a task and reconstruct what it did?
- Vendor and third party management. Which vendors run these tasks and process your data?
Mapping evidence to themes first, then to your specific framework controls, keeps the work manageable. Check your mapping with your assessor instead of assuming.
A monthly evidence routine
- Export the register and save it with the date.
- Save the run history summary for tasks that write.
- Record connector and permission changes since last month.
- Note any incidents and the pauses performed.
- File the review sign off.
- Spot check three tasks against their register entries and record the result.
Thirty minutes a month beats a week before the audit.
What not to claim
Do not describe a run history screenshot as continuous monitoring. Do not say every task was reviewed if only a sample was. Do not imply that using a vendor's feature satisfies a control without showing how you configured it. And keep out any statement about certifications your organization does not hold.
Try it yourself
Click through it at your own pace, or open it full screen.
See how one piece of evidence maps to several framework requirements.
Where Safeguard fits
Safeguard offers compliance and evidence automation as a GA capability, aimed at gathering records like these on a regular cadence.
Quick check
Is a screenshot of run history enough evidence?
It can help if it is dated and attributable, but exports or logs from the system are stronger.
How long should I keep run transcripts?
Set it in your logging policy, balancing audit needs against the sensitive content transcripts can hold.
Should evidence include the prompt text?
Keep the version of the prompt in force during the period, since it defines intended behavior. Keep secrets out of prompts so the stored copy is safe to share.
Sources
- Schedule recurring tasks in Claude Code Desktop
- Automate work with routines (Claude Code docs)
- Schedule recurring tasks in Claude Cowork (Help Center)
Last reviewed: 19 October 2026.
