## Why It Matters

A review cycle is the unit your auditor thinks in: one named period ("H1 2026"), one question set, one register of who was reviewed by whom. SOC 2 Type II tests operation *against your stated policy* — if your policy says annual reviews and a cycle gets skipped, that's a control exception. Kit makes the cadence explicit on every cycle and hard-gates each lifecycle transition, so the register you hand the auditor is complete by construction rather than by diligence.

The lifecycle is deliberately strict: a draft cycle can be reshaped freely, an active cycle accepts review writing, and a finalized cycle is frozen evidence that can never be edited or deleted. Every state change is a button with its blockers listed next to it — nothing transitions silently.

## Creating a Cycle

Go to [Performance > Review cycles](/performance/cycles) and press **New cycle**. A cycle needs:

| Field | Notes |
|-------|-------|
| Name | e.g. "H1 2026" — this exact string is snapshotted into every evidence record |
| Review template | Must be a **published** template; drafts don't qualify |
| Cadence | Annual, Semi-annual, Quarterly, or Ad hoc — a policy label, not a scheduler |
| Period start / end | The review period being assessed; the end must follow the start |
| Due date | Drives reviewer reminder emails (nudge, then last call) |
| Include self-reviews | On by default — each participant reviews themselves |
| Include peer reviews | Off by default — enables adding named peer reviewers per participant |

> [!NOTE]
> Cadence is a label that documents your policy on the evidence — Kit does not auto-create the next cycle. Put "quarterly" in your review policy only if you will actually run four cycles a year; a Type II auditor checks the register against the stated cadence.

## Adding Participants

On the cycle page, press **Add participant** and pick a team member. Each participant gets an optional **Role expectations** field — a short statement of the responsibilities this review measures against. Fill it in: auditors look for "assessment against documented role expectations," and this text is snapshotted verbatim into the participant's evidence record.

When a participant is added, Kit assigns their default reviewers automatically:

- **Manager** — pulled from the [Managers](/performance/manager_assignments) map (one report→manager edge per person). Map managers before building cycles and every participant arrives pre-wired.
- **Self-review** — added when the cycle includes self-reviews; it's the same review form, written by the participant about themselves.
- **Peers** — never automatic. If the cycle includes peer reviews, add named peer reviewers per participant from the cycle page. Peers are named, not anonymous — the evidence trail requires knowing who said what.

Participants can join a **draft or active** cycle (late joiners mid-cycle are fine), but a finalized or archived cycle refuses new rows. A reviewer can't be assigned to review themselves except through the self-review role, and every reviewer must belong to your account.

## Activation

Activating is what opens review writing — and it freezes the template's question set into the cycle, so later template edits can't drift under reviewers mid-cycle. Press **Activate** on the cycle page. If the cycle isn't ready, the button is replaced by a blocker list ("Before this cycle can go live"):

| Blocker | Fix |
|---------|-----|
| The review template isn't published yet | Publish the template in [Performance > Templates](/performance/templates) |
| The review template has no questions | Add at least one question, then publish |
| Add at least one participant | Add the people being reviewed |
| Every participant needs at least one reviewer | Map their manager, enable self-review, or add a peer |

After activation, reviewers are notified and each assignment appears in their [My reviews](/performance/reviews) queue. Made a mistake? **Back to draft** reverts an active cycle — but only while no review has been submitted, so nobody's work disappears behind a closed gate.

## Finalize and Archive

When every assigned review is submitted, press **Finalize…** to reach the confirmation screen. Finalization is a hard block on unsubmitted reviews: Kit lists exactly who still owes what ("Ana still owes a review of Ben"), and you either chase the reviewer or remove the assignment — the evidence never silently omits an expected reviewer. Confirming mints one immutable evaluation record per participant in a single transaction and freezes the cycle; see [SOC 2 Evidence and Exports](/docs/performance-soc2-evidence-exports).

> [!WARNING]
> Finalizing cannot be undone. Reviews become read-only, and the cycle can no longer be deleted — a finalized cycle holds evidence, so its endpoint is **Archived** (hidden from the working list, register still available), never deletion. Only cycles with no evidence records can be deleted at all.

## Cycle Lifecycle at a Glance

| Status | Reviews editable | Participants changeable | Can delete | Exits to |
|--------|:----------------:|:-----------------------:|:----------:|----------|
| Draft | — (not open yet) | Yes | Yes | Active |
| Active | Yes | Yes (late joiners) | Yes | Draft (if nothing submitted) or Finalized |
| Finalized | No | No | No | Archived |
| Archived | No | No | No | — |

## Quick Checklist

- [ ] Map every report to a manager in [Performance > Managers](/performance/manager_assignments)
- [ ] Create the cycle with a period and a due date
- [ ] Add all current employees as participants — auditors sample from the *full* population
- [ ] Fill in role expectations per participant
- [ ] Activate, then watch progress on the cycle page and the [evaluation register](/docs/performance-soc2-evidence-exports)

## Next Steps

- [Templates and Questions](/docs/performance-templates-and-questions) — build the question set before your first cycle
- [Writing Reviews](/docs/performance-writing-reviews) — what reviewers see once the cycle is live