Operations & Compliance package

Audit evidence collection

Monthly SOC 2 / ISO 27001 evidence run: automated controls are pulled from your systems, owners of manual controls are asked for a link, all logged for the auditor.

ScheduledIntermediate~20 min setupv1.0.0

About this package

What it does

Audit evidence collection keeps your evidence folder current without a scramble before the audit. Each month it reads the Controls data table (framework, reference, evidence type, owner, frequency) and works through the controls that are due: monthly controls every month, quarterly ones in January, April, July and October.

Automated controls are fetched from the Evidence API with the control id and period (access reviews, backups, vulnerability scans, change tickets) and logged as collected with the export link, record and exception counts and a checksum; failed calls are logged as failed. Manual controls get a "requested" row and a Provide audit evidence run, in which the control owner submits a link or marks the control not applicable, which the compliance lead must accept. Reminders and escalation keep requests moving. At the end the compliance lead gets a summary with the counts.

Adapt the Controls rows to your control set, point the Evidence API reference at your evidence service (or one reference per system), and change the schedule and quarter months to your audit calendar.

Scheduled

Monthly on day 2 at 06:00 (UTC). You can also start it any time from the Run dialog, the API or the CLI.

Runs on a schedule (daily, weekly, monthly) in your time zone.

The flow

Step by step

  1. 1

    Monthly run

    On the 2nd the workflow works out the period (YYYY-MM) and lists the active controls.

  2. 2

    Pick the due controls

    Monthly controls run every month; quarterly controls run in the first month of each quarter. The rest are counted as not due.

  3. 3

    Collect automated evidence

    Get control evidence returns the export link, record count, exceptions and checksum; the row is logged as collected, or as failed if the call fails.

  4. 4

    Ask owners for manual evidence

    A "requested" row is logged and the Provide audit evidence run asks the control owner for a link, with reminders and escalation.

  5. 5

    Agree not applicable

    If the owner marks a control not applicable, the compliance lead accepts it or sends it back for evidence.

  6. 6

    Summarise

    The compliance lead gets the counts of collected, requested and failed evidence for the period.

Scheduled evidence collection — Monthly: collects evidence for every automated control from the Evidence API, asks owners of manual controls for theirs, records everything in the Evidence log and emails the compliance lead a summary. The same canvas you get in the designer after installing.

Sub-workflow: Provide audit evidence

Asks a control owner for the evidence of a manual control for one period; "not applicable" needs the compliance lead's agreement. Updates the Evidence log row.

Forms

Inputs and task forms

The inputs a caller passes when it starts a run, and the forms people complete when the process needs a decision.

Start inputs

Scheduled evidence collection

Passed by the calling system

As of date as_of · dateYYYY-MM-DDOptional: collect for the month of this date (YYYY-MM-DD). Empty = this month.
Compliance lead email compliance_lead_email · emailname@company.comWho receives the summary

User Task · Provide audit evidence

Provide evidence

Evidence for {{control.control_id}} {{control.title}} ({{period}})

Evidence link evidence_link · text
Notes for the auditor notes · text
SubmitNot applicable

User Task · Provide audit evidence

Confirm not applicable

Agree {{control.control_id}} is not applicable for {{period}}?

Note review_note · text
AcceptSend back

From your code

Start a run over the API

Every workflow can be started over REST, MCP or the CLI, whatever its trigger, with the sample input below. Runs start straight away on the published version; replace <workflow id> with the id the install created.

REST

shell
curl -X POST "$USERTASKS_URL/api/v1/workflows/start" \
  -H "Authorization: Bearer $USERTASKS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"workflow_id":"<workflow id>","variables":{"as_of":"2026-10-02","compliance_lead_email":"compliance@example.com"}}'

CLI

shell
usertasks workflows inputs <workflow id>          # the start form: keys, types, required
usertasks workflows run <workflow id> --input as_of=2026-10-02 --input compliance_lead_email=compliance@example.com --wait

What's included

7 assets, ready to adapt

TypeNameDetails
Email templateEvidence collection summarySent to the compliance lead after the monthly collection run.
Data tableControlsYour control set: framework, reference, evidence type and owner. Automated controls are collected from the Evidence API; manual controls ask the owner for a link.
Data tableEvidence logOne row per control and period: what was collected or requested, the evidence link and its status. This is what you hand the auditor.
IntegrationEvidence API
API referenceGet control evidenceGET /evidence/{{evidence_source}} — Generates or fetches the evidence export for one control and period from the system that runs the control (access reviews, backups, vulnerability scans, change tickets).
WorkflowProvide audit evidence9 steps — Asks a control owner for the evidence of a manual control for one period; "not applicable" needs the compliance lead's agreement. Updates the Evidence log row.
WorkflowScheduled evidence collection25 steps — Monthly: collects evidence for every automated control from the Evidence API, asks owners of manual controls for theirs, records everything in the Evidence log and emails the compliance lead a summary.

Controls · 8 sample rows

Control IDFrameworkFramework referenceControlEvidence typeSystemEvidence feed (automated)Owner roleOwner emailOwner user id (optional)FrequencyActive

Evidence log · schema only

PeriodControl IDFrameworkControlEvidence typeStatusEvidence linkRecordsExceptionsChecksumCollected atOwner emailNotes

Requirements

What you connect it to

Credentials never travel in a package. The install wizard asks for what your environment must provide, or installs it incomplete until you finish setup.

Needs

  • REST API — A REST API integration: set its base URL and credentials on install.
  • Assignees — People in your workspace to receive the User Tasks (picked on install).
  • Email — Email delivery configured for the instance (EMAIL_PROVIDER), used for notifications.

After installing

  1. Evidence API integration: set the base URL of the service that exports control evidence and an API token. Get control evidence expects GET /evidence/{feed}?control_id=…&period=YYYY-MM returning evidence_url, record_count, exceptions and checksum; adjust it in Integrations, or add one reference per system.
  2. Assignees: pick the default control owner (used when a control has no owner user id) and the compliance lead who confirms "not applicable" and receives escalations.
  3. Replace the sample rows in Controls with your control set. For automated controls set the evidence feed name your API expects; fill owner user id to route a manual control to its owner.
  4. Set compliance_lead_email on the workflow, and change the schedule or the quarter months in the "Due this period?" condition if needed.
  5. Email: configure EMAIL_PROVIDER on the instance so the summary is delivered (the step continues on error).

Asked for on install

  • Integration “Evidence API”Required

    • Tokenconfig.auth_config.token
    • Base urlconfig.base_urldefault https://evidence.example.com/api· optional
  • Workflow “Provide audit evidence” assigneesRequired

    • User for step “Provide evidence”nodes.3.config.assignee_id
    • User for step “Provide evidence”nodes.3.config.escalation_user_id
    • User for step “Confirm not applicable”nodes.5.config.assignee_id

Install

Install it in your workspace

Works on UserTasks cloud and on any self-hosted instance. Installing creates the assets above; nothing runs until you complete setup and start it.

In the app

  1. Download audit-evidence-collection-1.0.0.utpkg.
  2. Open Automations → Packages and drag the file onto the page (or choose Import package). Browse gallery there lists every gallery package without downloading by hand.
  3. Pick the file. The wizard verifies the checksum, every file hash and the signature, and shows the readme.
  4. Review the changes (what is created) and the data rows.
  5. Fill in the requirements, or tick Keep incomplete and finish later with Complete setup.
  6. Done: the workflow is published and active once setup is complete.

With the CLI

shell
curl -fLO https://usertasks.com/gallery/audit-evidence-collection-1.0.0.utpkg
usertasks packages inspect audit-evidence-collection-1.0.0.utpkg       # offline: checksum, hashes, signature
usertasks packages install audit-evidence-collection-1.0.0.utpkg --dry-run
usertasks packages install audit-evidence-collection-1.0.0.utpkg       # prompts for each requirement
usertasks packages install audit-evidence-collection-1.0.0.utpkg --keep-incomplete --yes   # in CI; finish with:
usertasks packages complete audit-evidence-collection -f values.yaml

Verify the download

File SHA-256
e6e306850577e9dc599f6b7bfd3403f2016e7a78b7d854f166d0b332497108b1
Package checksum (what is signed)
sha256:b9feefe29ce6a1df9b63c58827f3f837c57509aaa3c244f8e6ea575d32bfba83
Signer
Unsigned preview build — compare the SHA-256 above

shasum -a 256 audit-evidence-collection-1.0.0.utpkg should print the file SHA-256. How gallery packages are signed.

Versions

Version 1.0.0

  1. v1.0.02026-10-26First release.

Installing a newer version upgrades in place: local credentials and requirement values are kept, and changes you made are flagged first. How packages work

More packages

Related

Browse the whole gallery