Skip to content

Collectors

Where to find it: Controls & Assurance, then Evidence Fabric (/evidence/fabric), then Collectors.

A Collector (COL-YYYY-NNNN) defines what evidence to gather from a connected source, about which subjects, and how often. Each execution is a Collector Run (CRN-YYYY-NNNN).


Collector and run

CollectorCollector Run
What it isA definitionAn execution
ReferenceCOL-YYYY-NNNNCRN-YYYY-NNNN
Changes over timeEdited deliberatelyImmutable once complete
ProducesNothing on its ownEvidence assertions

The distinction matters for audit. When an assessor asks "how do you know MFA was enforced on 14 March?", the answer is a specific run with a timestamp, an outcome and the assertions it produced — not "we have a collector for that".


Collector statuses

StatusMeaning
draftBeing configured; does not run
activeRuns on its schedule
pausedRetained but not running
retiredNo longer used; history preserved

Run statuses

StatusMeaning
queuedWaiting to execute
runningIn progress
succeededCompleted and produced assertions
partial_successCompleted with some subjects unresolved
failedDid not complete

partial_success is the status to watch

A partially successful run produces assertions for the subjects it reached and nothing for the rest. The unreached subjects simply have no fresh assertion, so coverage falls — quietly, without anything failing. Review partial runs rather than treating them as successes.


Defining a collector

A collector definition specifies:

ElementPurpose
ConnectionThe configured source it reads from
Subject resolutionHow collected records map to scope subjects
Observation mappingWhat constitutes pass, fail, partial or inconclusive
Freshness windowHow long an assertion from this collector stays current
FrequencyHow often it runs
StatusDraft, active, paused or retired

Subject resolution is the hard part

An assertion is about a subject. For coverage to work, the identifier the source system uses must resolve to a scope member.

If the identity platform reports account UPNs and your scope holds asset records keyed by hostname, nothing matches, and coverage reads zero while the collector reports success.

Getting subject identity aligned between your source systems and your Scope Registry is the main implementation effort in setting up automated evidence, and it is worth doing carefully once.


Scheduling

Collectors run on a defined frequency. They can also be triggered manually and replayed.

Manual run executes immediately, outside the schedule. Useful for validating a new definition and for gathering evidence ahead of an assessment.

Replay re-executes a previous run. Useful when a run failed for a transient reason.

Both require collector.run.

Collector schedules are technical, not governance events

Collector runs, sweeps and freshness evaluations are machine schedules. They deliberately do not appear on the GRC Calendar, which is reserved for meaningful governance obligations — review dates, attestation deadlines, expiry dates. A calendar full of hourly collector runs is a calendar nobody reads.


Setting up a collector

  1. Confirm the Connection is active and tested.
  2. Confirm the target Scope exists with its members.
  3. Create the collector in draft.
  4. Define subject resolution and observation mapping.
  5. Set the freshness window to match the real cadence of the underlying evidence. A control that operates quarterly should not have a 24-hour freshness window.
  6. Run it manually and inspect the assertions produced — check the subjects resolved and the states are what you expect.
  7. Set the status to active.

Requires collector.manage; running requires collector.run.


Reading run history

Run history is the evidence trail for your automated evidence. For each run you can see when it ran, its status, how many subjects were resolved and how many assertions were produced.

A collector whose run history shows a long tail of partial_success is telling you something about either the source system or your subject resolution.


Permissions

ActionPermission
View collector definitions and run historycollector.read
Create and configure collectorscollector.manage
Trigger manual execution or replaycollector.run

All require the continuous_assurance entitlement.


Example

Collector COL-2026-0003 — MFA enforcement, privileged accounts

ElementValue
ConnectionCON-2026-0001 Identity platform
Subject resolutionDirectory account object ID, matched to scope members in SCP-2026-0012
Observation mappingpass where MFA is enforced and registered; fail where enforcement is off or no factor is registered; inconclusive where the account is disabled
Freshness window48 hours
FrequencyDaily
Statusactive

Recent runs:

RunStatusSubjectsAssertionsNote
CRN-2026-1841succeeded214214211 pass, 3 fail
CRN-2026-1842succeeded214214211 pass, 3 fail
CRN-2026-1843partial_success19819816 accounts unresolved after a directory reorganisation
CRN-2026-1844succeeded216216Subject resolution updated; two new accounts included

Run 1843 is the interesting one. Coverage fell from 100% to 92.5% for a day. Nothing failed — 16 accounts simply stopped resolving. The fix was to subject resolution, not to the control.


Troubleshooting

"The collector succeeds but produces no assertions." Subject resolution is not matching. Compare the identifiers the source returns against your scope members.

"Coverage fell but nothing failed." Either assertions went stale, or a run was partial_success, or scope members were added. Check run history first.

"Assertions go stale between runs." The freshness window is shorter than the run frequency. A collector running weekly needs a freshness window longer than a week.

"A run failed." Check the connection status first. Most run failures are connection or credential problems rather than collector configuration.

"Collectors are unavailable." Requires the continuous_assurance entitlement and collector.read.


OrviQ Enterprise Governance, Risk & Compliance Platform