Vendor register

The register at /vendors/register is the source of truth for third parties that affect security, availability, confidentiality, or personal-data processing. Records can be created manually and can also be created or linked when integrations observe recognizable SSO applications.

Use this when…

• you’re preparing for audits/certifications that require third-party oversight (SOC 2 / ISO are common examples)
• you need to answer “who are your subprocessors?” and “do you have DPAs?”
• you want vendor risk decisions to be explicit

Recommended workflow

1. Build a vendor inventory focused on:
   • vendors that touch production
   • vendors that process customer/personal data
   • vendors that are critical for availability/security
2. For each critical vendor:
   • capture contract status (including DPA if relevant)
   • capture security posture signals (reports, questionnaires)
   • record risk assessment and mitigations
3. Review critical vendors on a cadence (at least annually, ideally more often for high-risk).

The register and vendor detail

The directory shows name/description, owner, inherent risk, status, residual risk, and creation time. Use search and filters to isolate unassessed, high-risk, unowned, or overdue vendors. You can assign a questionnaire to selected vendors from the register.

Open /vendors/register/[id] for the complete record:

• Overview: owner, status, category, website, contacts, description, and recent activity.
• Risk: inherent probability/impact, residual probability/impact, risk owner, posture, certifications, mitigation, monitoring, and narrative summary.
• Privacy: processing role, personal-data details, legal basis, countries/transfer context, NDA, DPA, retention, and notes.
• Evidence: uploaded due-diligence artifacts and their provenance.
• Assessments: assigned questionnaires, recipient link, response progress, reminders, and review.
• Personnel: canonical people observed using the vendor through connected SSO data.
• Activity: traceable changes such as owner, status, risk, privacy, contacts, evidence, and assessments.

Inherent and residual risk

Inherent risk is exposure before vendor-specific safeguards. Residual risk is the exposure you believe remains after contractual, technical, operational, and monitoring controls. Do not lower residual risk merely because a questionnaire was returned; base it on reviewed evidence and record the rationale.

Connections to other records

• SSO-derived personnel links show observed use, not contractual approval or complete license inventory.
• Privacy processing activities can link vendors as recipients/processors with provenance explaining why.
• Vendor evidence and questionnaire responses support third-party controls and audit packages.
• Vendor risk should inform the central risk register when exposure is material to the organization.
• Trust-center subprocessor content should be consistent with the approved vendor/privacy record.

Compliance angle

• SOC 2 / ISO 27001: you need oversight of third parties that impact your control environment.
• GDPR: DPAs, subprocessors, and cross-border transfer narratives matter.

For GDPR and similar laws, the organization still needs to determine controller/processor roles, Article 28 contract sufficiency, transfer mechanisms, and whether a DPIA is necessary. Noru records and connects those decisions; it does not make them legally binding.