How to onboard a vendor
For Juno staff who own (or are about to own) a software vendor in the registry.
What "onboarding a vendor" means
Each vendor in the registry needs a configured owner, a classification (criticality + data sensitivity), an approval policy,
and optional training requirements before it can accept requests through the public form.
Until all the required pieces are in place, the vendor stays in draft status — invisible to requesters.
The 7 required steps
1. Be designated owner
An admin adds the vendor in Nova and assigns you as
owner_person_id. You can also be assigned as backup_owner on someone else's vendor.
2. Pick a management mode
One of:
actively_reconciled (we run an API check against the vendor — Phase 4 only),
sprinto_reconciled (Sprinto handles drift detection),
attestation_only (you attest the user list on a schedule),
acknowledged_only (no automated reconciliation, low-risk vendor).
3. Classify criticality
Low / Medium / High / Critical. Drives escalation thresholds — a critical-vendor revocation that sits pending for 1 day escalates to your backup owner; a low-criticality one waits 14 days.
4. Tag data sensitivity
Pick at least one tag (PII, financial, source code, customer data, employee data, secrets, etc.). This is metadata used in audit and reporting — pick honestly.
5. Justify acknowledged-only mode
Only required if you chose
acknowledged_only. Explain why this vendor is low-risk enough to skip reconciliation. The justification is recorded for SOC 2 walkthroughs.
6. Approval policy
Every vendor is auto-created with a default owner-only single-step policy. If you need a multi-step flow (e.g. security review before admin access), add steps in Nova. Approver kinds: owner, backup_owner, requester's sponsor, specific person, or anyone with a Spatie role.
7. Sign off on classification
Run the Sign off Nova action on the vendor. Records that you (the owner) reviewed the criticality, sensitivity, and mode. Required before activation.
Optional but recommended
Training requirements
Attach one or more trainings (created in Trainings Nova) to gate access. Optionally scope a training to a specific grant_role (e.g., SOC 2 training required for
admin tier but not viewer).
Initial user-list backfill
Upload a CSV with the vendor's current users to seed
access_grants. Format: email,grant_role,notes. We match emails against existing person_identities; unmatched rows are reported back for triage.
Attestation cadence
If you picked
attestation_only, set attestation_frequency to monthly or quarterly. You'll get a one-click email when each period is due.
Activating the vendor
Once all 7 required steps are green, run the Activate vendor Nova action. The vendor flips to active status and appears in the public request form.
If anything is missing, the action returns a list of which items are blocking — no need to guess.
Your ongoing responsibilities once active
- Respond to new request approvals (you'll get an email or Slack ping, depending on your notification preferences).
- Click Mark provisioned after you've actually added the user on the vendor's side. This is what creates the
access_grantrecord. - If you're on
attestation_only, click the one-click attest button when the monthly email arrives. - When someone leaves Juno, you'll get a revocation task — click Mark done after revoking on the vendor side. Critical/high vendors are escalated if you don't act within the threshold.