Vendor Onboarding & Offboarding SOP

Step-by-step procedure to onboard a new vendor, run the periodic reassessment, and cleanly offboard when the engagement ends.

Vendor Onboarding & Offboarding SOP

Field Value
Document ID SOP-010
Classification Internal
Owner Compliance + Operations
Effective Date April 2026
Review Cycle Semi-Annual

1. Purpose

Operationalises the Third-Party & Vendor Management Policy (POL-022) and the Vendor Security Assessment Standard (STD-015). Gives the internal vendor owner a single runbook for onboarding, in-life management, and offboarding.


2. Roles

Role Responsibility
Vendor Owner (internal) Day-to-day relationship; drives the steps in this SOP
Compliance Team Maintains the Vendor Risk Register, reviews assessment scores
SRE Technical assessment, access provisioning, integration monitoring
Legal Contract and DPA review
CTO (interim CISO) Final approval for Critical vendors

3. Onboarding

3.1 Intake (Day 0)

  1. Vendor owner raises a request with a short scope note: what the vendor will do, what Wealthy data they will touch, why another existing vendor can’t do it.
  2. Compliance classifies the vendor against STD-015 Β§4 risk categories.
  3. An entry is created in the Vendor Risk Register with status Pending Assessment.

3.2 Send the checklist (Day 1)

  1. Vendor owner opens the Vendor Security Assessment Checklist template in the Security Drive folder.
  2. File β†’ Make a copy into the same folder; rename to VSA β€” <Vendor Name> β€” YYYY-MM-DD.
  3. Share the copy with the vendor’s security/compliance contact with Commenter access (Editor after NDA if the vendor asks).
  4. Send a covering email from security@wealthy.in stating the 10-business-day SLA and the Wealthy technical contact.

3.3 Review the response (Day 5–15)

  1. When the vendor returns the completed checklist, Compliance + SRE review against STD-015 Β§3.3 scoring bands.
  2. Follow-up questions go in the sheet as comments; responses must land before scoring is finalised.
  3. Score is recorded in the Vendor Risk Register (Assessment Score + Last Assessment Date).
  4. Critical / High vendors require CTO sign-off; Medium/Low can be approved by Compliance.

3.4 Contract & DPA (Day 10–20)

  1. Legal drafts or negotiates the Master Services Agreement and Data Processing Addendum using the vendor’s answers in Tab 6 as the starting position.
  2. Mandatory clauses (per POL-022 Β§5) must be present before sign-off:
    • DPA aligned to DPDP Act + GDPR-style
    • Breach notification SLA (24 h general, 2 h for CERT-In-reportable)
    • Right to audit
    • Data-return + destruction within 30 days of termination
    • Sub-processor consent β€” 30 days advance notice
    • No ML training on Wealthy data without written consent
  3. Executed contract + DPA + signed checklist are filed together in the Security Drive under Vendor Evidence / <Vendor Name> /.

3.5 Access provisioning (Day after contract signed)

  1. SRE provisions the minimum necessary access β€” never standing broad access.
  2. Integration health check is configured and subscribed to the on-call channel.
  3. Vendor Risk Register entry moves to Active with Next Assessment Date = +12 months (Critical: +6 months).

4. In-life management

4.1 Integration monitoring (continuous)

  • SRE monitors vendor API health, SLA, and error rates.
  • Any SEV-1/2 involving the vendor goes through the Incident Response SOP (SOP-004) and an entry is added to the vendor’s register row.

4.2 Compliance monitoring (continuous)

  • Compliance tracks certification-validity dates (from Tab 2 of the checklist) and flags expiries 60 days in advance.
  • Public breach disclosures affecting the vendor trigger immediate review (not waiting for the next cycle).

4.3 Quarterly register review

  • CTO + Compliance review the Vendor Risk Register at each quarterly ISRMC.
  • Critical-vendor material changes (breach, ownership change, regulatory action) are reported within the quarter they occur.

4.4 Reassessment

Trigger Action
Category = Critical, 6 months elapsed Full reassessment β€” new copy of the checklist, new score
Category = High, 12 months elapsed Full reassessment
Category = Medium/Low, 12/24 months elapsed Self-attestation β€” ask vendor to confirm nothing material has changed since last response
Vendor publicly discloses a breach Immediate reassessment regardless of schedule
Scope materially expands (new data type, new data class) Immediate reassessment

5. Offboarding

Triggered by: contract non-renewal, early termination, vendor replacement, or a breach that kills the relationship.

5.1 Day 0 β€” Decision to offboard

  1. Vendor owner notifies Compliance, SRE, and Legal in writing.
  2. Vendor Risk Register entry moves to Offboarding.

5.2 Day 0–7 β€” Access revocation

  1. SRE revokes all vendor access on the effective termination date (earlier if the termination is for cause).
  2. API keys, service accounts, VPN accounts, and shared credentials are rotated or destroyed.
  3. Shared Google Drive / Slack / JIRA / docs access is removed.
  4. Confirmation that no access remains is captured as a screenshot/log entry and filed.

5.3 Day 0–30 β€” Data return & destruction

  1. Wealthy formally requests data return in the format agreed in the contract.
  2. On receipt, the returned data is verified (row counts, checksum if applicable).
  3. Vendor provides a Certificate of Destruction per the contract; Compliance files it in the vendor folder.
  4. If the vendor cannot produce a CoD within 30 days, Legal is engaged.

5.4 Day 30 β€” Close-out

  1. Final entry in the Vendor Risk Register: Offboarded β€” <YYYY-MM-DD>, with links to CoD + access-revocation evidence.
  2. The vendor folder in Security Drive is locked (view-only) but retained per regulatory retention.
  3. Post-engagement notes (what worked / what didn’t) added to the register for future-vendor selection.

6. Artefacts Retained

Per regulatory retention (IRDAI / SEBI / DPDP):

  • Signed vendor checklist (all versions)
  • Executed MSA + DPA
  • Certifications, audit reports, pen-test summaries
  • Integration health / incident history
  • Access provisioning + revocation evidence
  • Certificate of Destruction (offboarding)

All filed under Security Drive β†’ Vendor Evidence / <Vendor Name> /.



Reviewed semi-annually. Last revision: April 2026. Contact: security@wealthy.in.