Vendor Risk Management

Vendor Risk Management

Every new integration is a supply chain decision. No vendor gets access without assessment.

Storage

• Vendor assessments: .compliance/​vendors/​VND-YYYY-NNN-slug.json — one file per assessment
• Approved vendor summary: profile.json → suppliers[] — kept in sync after approval

Vendor assessment record

One JSON per vendor assessment. Created on first contact, updated through lifecycle.

{
  "assessment_id": "VND-2026-001-hubspot",
  "vendor_name": "HubSpot",
  "status": "proposed | under-review | approved | conditional | rejected | offboarded",
  "assessed_at": "ISO 8601",
  "assessed_by": "agent | user",
  "type": "saas | infra | service | library | api",
  "data_shared": ["klantdata", "email", "contactgegevens"],
  "criticality": "critical | important | standard",
  "touches_critical_assets": ["Klant-administratiedata (CRM)"],
  "checks": {
    "dpa_signed": false,
    "hosting_location": "EU (Ireland)",
    "hosting_compliant": true,
    "certification": "SOC2 Type II",
    "access_scope": "API read/​write to CRM contacts",
    "least_privilege": true,
    "exit_strategy": "CSV export available"
  },
  "decision": "approved | conditional | rejected",
  "decision_reasoning": "Why this decision was made",
  "conditions": ["DPA must be signed before go-live"],
  "review_date": "ISO 8601 — next scheduled review",
  "timeline": [
    { "timestamp": "ISO 8601", "action": "what happened", "actor": "who" }
  ]
}

Vendor lifecycle

1. Identify

When the agent detects a new vendor (user mentions a tool, code imports a new SDK, API call to unknown service):

• Check profile.suppliers — is this vendor already known?
• If unknown: flag immediately and start the assessment

2. Assess

3. Decide

4. Monitor

• Set contract_review_date — review vendors annually at minimum, critical vendors every 6 months
• When a vendor's certification expires or a breach is disclosed: re-assess
• Track vendor incidents — if a vendor reports a breach, start incident-management lifecycle

5. Offboard

When a vendor relationship ends:

• Revoke all access (API keys, accounts, network access)
• Verify data deletion or return per DPA terms
• Set offboard_date and status: "offboarded"
• Log via audit-logging

Triggers for the agent

The agent flags a vendor risk event when:

• Code imports a new external dependency (pip install, npm install, new API client)
• User discusses integrating a new SaaS tool
• Code makes HTTP calls to a domain not in the approved supplier list
• A vendor's contract_review_date is past due
• The agent discovers an undocumented data flow to an external service

Agent instructions

1. When a new vendor or service appears in conversation or code, check profile.suppliers. Unknown = create assessment record in .compliance/​vendors/ and start the lifecycle.
2. Cross-reference vendor data access against profile.critical_assets. Touches a critical asset = criticality=critical.
3. Check data residency constraints from profile.constraints. Flag hosting location violations.
4. For every vendor decision, log an ADR via audit-logging (policy_ref: "NIS2 Art. 21(2)(d)").
5. On approval: add vendor to profile.suppliers and set review_date.
6. Remind about overdue reviews based on review_date.
7. On offboard: verify access revocation, update assessment record, set status "offboarded".