Vendor Onboarding Security Checklist twelve sections that turn vendor go-lives from informal sign-offs into a defensible onboarding artefact
A free, copy-ready vendor onboarding security checklist for GRC, vendor risk, AppSec, internal security, vulnerability management, and security operations teams who own the security side of bringing a new third-party SaaS, cloud, or embedded vendor into production. Twelve structured sections covering header and scope, pre-onboarding security review, contract and data processing terms verification, tenant and environment configuration, identity, access, and credential provisioning, integration and API security, data flow, classification, and residency verification, logging, monitoring, and detection enablement, vulnerability and patch posture confirmation, incident response and notification readiness, the four-signature go-live security gate, and the post-go-live verification and reassessment cadence. Aligned with ISO/IEC 27001 Annex A 5.19 through 5.23 and 8.30 supplier and cloud-services controls, ISO/IEC 27036 supplier relationships standard, SOC 2 CC9.2 vendor and business partner management, PCI DSS Requirement 12.8 service providers and 12.9 service provider acknowledgement, HIPAA 164.308(b) and 164.314(a) business associate provisions, NIST SP 800-53 SR family supply-chain risk management and SA-12, NIST SP 800-161 cybersecurity supply chain risk management, NIST CSF 2.0 GV.SC supply chain risk management category, CSA Cloud Controls Matrix STA domain, NIS2 Article 21 supply-chain risk, DORA Articles 28 to 30 ICT third-party risk management, GDPR Article 28 processor obligations, UK PRA SS2/21 outsourcing and third-party risk management, FFIEC outsourcing booklet, and APRA CPS 230 service provider management where in scope.
Run vendor onboarding on the live workspace, not on a side spreadsheet
SecPortal pairs each new vendor onboarding to a versioned engagement record so the in-scope vendor, the named integration endpoints, the named identity provisioning steps, the named monitoring sources, the named four-signature go-live gate, and the named post-go-live verification cadence live on one workspace with a named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn vendor go-lives from informal sign-offs into a defensible onboarding artefact
A vendor onboarding security checklist is the operational, task-by-task artefact a security team runs alongside procurement and legal when a new third-party vendor moves from contract signature into production use. It is not the formal vendor security risk assessment workbook (the scoring artefact that captures vendor profile, control posture, residual risk score, and acceptance decision). It is the operational follow-through: the named sequence of pre-onboarding, contract verification, tenant configuration, identity provisioning, integration security, data-flow verification, monitoring enablement, vulnerability baseline, incident response readiness, go-live gate, and post-go-live verification tasks the security team owns so the audit, the GRC team, the AppSec team, the procurement team, the relationship owner, and the CISO can read on one page that the security side of the onboarding was actually run rather than waved through.
Copy the full checklist (all twelve sections) as one block.
1. Header, scope, and authority
Open the checklist artefact with the vendor identity, the onboarding window, the named relationship owner, the named buyer-side security lead, the named scope of the integration the onboarding covers, and the framework obligations the artefact evidences. A reviewer should be able to read in the first lines which vendor this is, who owns it on the buyer side, which scope is covered, and which framework controls the checklist is run against. ISO 27001 Clause 7.5 expects documented information with controlled identification and review; the onboarding checklist is what makes the vendor onboarding evidence traceable across audit cycles rather than a scattered set of procurement emails.
Onboarding checklist identifier (cross-referenced from the vendor record and the third-party risk programme record): {{ONBOARDING_IDENTIFIER}}
Vendor under onboarding:
- Legal entity name: {{VENDOR_LEGAL_NAME}}
- Trading name (if different): {{VENDOR_TRADING_NAME}}
- Headquarters jurisdiction: {{VENDOR_HQ_JURISDICTION}}
- Primary processing region(s) on the contracted service: {{VENDOR_PROCESSING_REGIONS}}
- Public registry identifier (Companies House, EDGAR, equivalent): {{VENDOR_REGISTRY_ID}}
- Service category (one of: SaaS application, IaaS or PaaS, embedded software, connected product, professional services, managed security service, payment processor, data processor, AI or model API): {{VENDOR_SERVICE_CATEGORY}}
- Internal vendor record reference: {{VENDOR_RECORD_REFERENCE}}
Onboarding window:
- Onboarding start date: {{ONBOARDING_START_DATE}}
- Target go-live date: {{TARGET_GO_LIVE_DATE}}
- Onboarding tier (one of: top-tier critical regulated data, standard regulated data, standard production, low-criticality production, sandbox): {{ONBOARDING_TIER}}
In-scope use case and integration (a one-paragraph plain-English description of what the buyer will use the vendor for and how):
- {{IN_SCOPE_USE_CASE}}
Out-of-scope use cases and integrations (prevents scope creep):
- {{OUT_OF_SCOPE_LIST}}
Data classification anchor for the onboarding (named data classes the vendor will process under this scope): {{DATA_CLASSIFICATION_ANCHOR}}
Named buyer-side roles:
- Relationship owner (business unit lead carrying the vendor relationship):
- Role: {{RELATIONSHIP_OWNER_ROLE}}
- Named person at time of publication: {{RELATIONSHIP_OWNER_NAME}}
- Buyer-side security lead (the role accountable for the security side of this onboarding):
- Role: {{SECURITY_LEAD_ROLE}}
- Named person at time of publication: {{SECURITY_LEAD_NAME}}
- GRC reviewer:
- Role: {{GRC_REVIEWER_ROLE}}
- Named person at time of publication: {{GRC_REVIEWER_NAME}}
- Procurement contact:
- Role: {{PROCUREMENT_CONTACT_ROLE}}
- Named person at time of publication: {{PROCUREMENT_CONTACT_NAME}}
Named vendor-side contacts:
- Vendor primary security contact: {{VENDOR_SECURITY_CONTACT_NAME}}, {{VENDOR_SECURITY_CONTACT_ROLE}}, {{VENDOR_SECURITY_CONTACT_EMAIL}}
- Vendor incident notification contact (if different): {{VENDOR_IR_CONTACT_NAME}}, {{VENDOR_IR_CONTACT_ROLE}}, {{VENDOR_IR_CONTACT_EMAIL}}
- Vendor implementation engineer (technical onboarding counterpart): {{VENDOR_IMPLEMENTATION_CONTACT_NAME}}
Framework expectations evidenced by the onboarding artefact (ISO 27001 Annex A 5.19 supplier relationships, A 5.20 addressing security within supplier agreements, A 5.21 managing security in the ICT supply chain, A 5.22 monitoring and review of supplier services, A 5.23 information security for cloud services, A 8.30 outsourced development; ISO/IEC 27036 supplier relationships standard; SOC 2 CC9.2 vendor and business partner management; PCI DSS 12.8 service providers and 12.9 service provider acknowledgement; HIPAA 164.308(b) and 164.314(a) business associate provisions; NIST SP 800-53 SR family supply-chain risk management and SA-12; NIST SP 800-161 cybersecurity supply-chain risk management; NIST CSF 2.0 GV.SC supply chain risk management; CSA Cloud Controls Matrix STA domain; NIS2 Article 21 supply-chain risk; DORA Articles 28 to 30 ICT third-party risk management; GDPR Article 28 processor obligations; UK PRA SS2/21 outsourcing and third-party risk management; FFIEC outsourcing booklet; APRA CPS 230 service provider management where in scope):
- {{FRAMEWORK_EXPECTATIONS_LIST}}
Cross-references:
- Vendor record reference: {{VENDOR_RECORD_REFERENCE}}
- Most recent vendor security risk assessment record: {{VRA_RECORD_REFERENCE}}
- Third-party risk management programme record: {{TPRM_PROGRAMME_REFERENCE}}
- Vendor contract reference and effective date: {{CONTRACT_REFERENCE}}
- Data processing agreement reference: {{DPA_REFERENCE}}
- Compliance tracking record identifier: {{COMPLIANCE_RECORD_IDENTIFIER}}
Revision history (each entry: checklist version, effective date, trigger, author, signed-off-by):
- v{{PRIOR_VERSION_1}} effective {{PRIOR_DATE_1}}, trigger {{PRIOR_TRIGGER_1}}, author {{PRIOR_AUTHOR_1}}, signed {{PRIOR_SIGNATORY_1}}
- v{{PRIOR_VERSION_2}} effective {{PRIOR_DATE_2}}, trigger {{PRIOR_TRIGGER_2}}, author {{PRIOR_AUTHOR_2}}, signed {{PRIOR_SIGNATORY_2}}
2. Pre-onboarding security review
Capture the security review that has to happen before the vendor is given any access, any credential, any integration target, or any data class. The block reads against the prior risk assessment, the freshness of vendor attestations, and the named pre-onboarding decision. Without a named pre-onboarding gate the rest of the checklist becomes optional work, which is how vendors quietly enter production without security ever signing off.
Vendor classification confirmation (pulled from vendor record and confirmed at onboarding):
[ ] Tier confirmed (top-tier critical regulated data / standard regulated data / standard production / low-criticality production / sandbox)
[ ] Data class set confirmed against the in-scope use case
[ ] Criticality rating confirmed against business continuity ranking
[ ] Residency commitment confirmed against regulated-data jurisdiction
Prior assessment status:
[ ] Vendor security risk assessment workbook completed and on file (record reference: {{VRA_RECORD_REFERENCE}})
[ ] Workbook signed off at residual risk inside documented appetite (named approver: {{VRA_APPROVER_NAME}})
[ ] Conditional residual risk acceptances captured on exception register (count: {{VRA_CONDITIONAL_COUNT}})
[ ] Last assessment date within freshness policy (date: {{VRA_LAST_DATE}})
Required attestations on file (named obligation per artefact recorded):
[ ] SOC 2 Type II report received, period ending within last 12 months, scope covers the contracted service (report date: {{SOC2_REPORT_DATE}})
[ ] ISO 27001 certificate valid, scope covers the contracted service (certificate expiry: {{ISO_CERT_EXPIRY}})
[ ] PCI DSS attestation of compliance valid where vendor processes cardholder data (AOC date: {{PCI_AOC_DATE}})
[ ] HIPAA business associate agreement signed where vendor processes protected health information (BAA effective date: {{BAA_EFFECTIVE_DATE}})
[ ] Most recent independent penetration test report received, dated within last 12 months (test date: {{PENTEST_DATE}})
[ ] Vulnerability disclosure programme link recorded (URL: {{VDP_URL}})
[ ] Software bill of materials available on request where applicable (SBOM availability confirmed: {{SBOM_AVAILABILITY}})
[ ] Security incident notification SLA recorded (named hours-to-notify: {{NOTIFICATION_SLA}})
Security questionnaire freshness:
[ ] Buyer-side security questionnaire (or industry-standard equivalent) completed within last 12 months
[ ] Material differences from the assessment workbook reconciled and recorded
[ ] Outstanding control gaps from the questionnaire mapped to onboarding-time mitigations or exception register entries
Pre-onboarding decision:
- Decision (one of: approved, conditional, deferred, rejected): {{PRE_ONBOARDING_DECISION}}
- If conditional, named conditions (each with named owner, named target close date, named compensating control):
- {{CONDITIONAL_LIST}}
- If deferred, named blocker and re-review date: {{DEFERRAL_RATIONALE}}, {{DEFERRAL_REVIEW_DATE}}
- If rejected, named rationale documented for procurement and the relationship owner: {{REJECTION_RATIONALE}}
Named pre-onboarding approver signatures (security lead, GRC reviewer):
- Security lead: {{SECURITY_LEAD_NAME}}, {{PRE_ONBOARDING_DATE}}
- GRC reviewer: {{GRC_REVIEWER_NAME}}, {{PRE_ONBOARDING_DATE}}
3. Contract and data processing terms verification
Capture the verification that the executed contract carries the named security clauses the buyer-side legal and security teams negotiated. The block does not negotiate the contract; it confirms the executed contract is the one the security team signed off on. Without a contract verification gate, the security team can spend onboarding effort against vendor commitments that never made it into the signed agreement.
Executed contract verification:
[ ] Master service agreement effective date confirmed (date: {{MSA_EFFECTIVE_DATE}})
[ ] Order form or statement of work scope matches in-scope use case at Section 1
[ ] Security exhibit or schedule attached (exhibit reference: {{SECURITY_EXHIBIT_REF}})
[ ] Data processing agreement attached (DPA reference: {{DPA_REFERENCE}})
Security clauses present and verified:
[ ] Security incident notification clause with named hours-to-notify, named notification channel, named buyer-side contact (hours: {{NOTIFICATION_HOURS}})
[ ] Breach assistance and forensic cooperation clause (buyer-side audit and investigation rights named)
[ ] Right to audit clause (frequency, scope, cost-bearing party named)
[ ] Sub-processor transparency clause (named sub-processor list maintained, named notification before adding new sub-processors)
[ ] Sub-processor flow-down obligation (vendor required to bind sub-processors to equivalent security obligations)
[ ] Data deletion and return clause (named deletion window after termination, named deletion verification mechanism)
[ ] Termination assistance clause (named transition cooperation, named knowledge handover, named data egress mechanism)
[ ] Insurance clause (named cyber liability minimum, named professional indemnity minimum, named additional-insured posture)
[ ] Confidentiality clause covering buyer data and named buyer personnel data
Data processing agreement verification:
[ ] Processor obligations under GDPR Article 28 documented (where personal data of EU residents is in scope)
[ ] International transfer mechanism named where the vendor processes outside the residency commitment (Standard Contractual Clauses 2021 module identified, Transfer Impact Assessment on file)
[ ] Named processing purposes match the in-scope use case
[ ] Named data subject types and data categories match the data classification anchor at Section 1
[ ] Named retention period per processing purpose
[ ] Named technical and organisational measures referenced or attached
Regulated-data-class clauses where applicable:
[ ] PCI DSS Requirement 12.9 written acknowledgement received from service providers handling cardholder data
[ ] HIPAA business associate agreement signed and on file
[ ] Sector-specific clauses present (FFIEC, APRA CPS 230, UK PRA SS2/21, NIS2 Annex II expectations where in scope)
Verification sign-off:
- Buyer-side legal contact: {{LEGAL_CONTACT_NAME}}, {{CONTRACT_REVIEW_DATE}}
- Buyer-side security lead: {{SECURITY_LEAD_NAME}}, {{CONTRACT_REVIEW_DATE}}
4. Tenant and environment configuration
Capture the tenant-level security configuration the buyer has to set on the vendor side. For SaaS vendors this is the named tenant security settings; for infrastructure-as-a-service vendors this is the named account-level guardrails; for embedded-software vendors this is the named device or component configuration. The block produces the named configuration baseline the buyer enforces against the new vendor environment at go-live.
Tenant identifier and ownership:
[ ] Tenant or account identifier recorded ({{TENANT_IDENTIFIER}})
[ ] Tenant-level administrative ownership named (named admin role, named primary admin, named break-glass admin)
[ ] Tenant region selection confirmed against residency commitment
Tenant-level security configuration (SaaS application):
[ ] Default authentication mode set to SSO (vendor-issued local accounts disabled or restricted to documented break-glass)
[ ] Default MFA enforced at tenant level
[ ] Password and credential policy aligned with buyer policy where vendor allows configuration
[ ] Session timeout configured against buyer policy
[ ] IP allowlist configured where required by tier
[ ] Public-link sharing disabled or restricted to documented use cases
[ ] Anonymous access disabled
[ ] Default external collaboration scope set to documented baseline
Tenant-level security configuration (cloud or infrastructure platform):
[ ] Service control policies, Azure Management Group policies, or GCP organisation policies set to documented guardrails
[ ] Root or organisation owner inventory complete with hardware MFA enforced
[ ] Break-glass account inventory documented with named storage of recovery factor
[ ] Region restriction enforced where residency commitment requires it
[ ] Cost guardrails configured to detect runaway exposure
Tenant-level security configuration (embedded software or connected product):
[ ] Device or component inventory recorded with firmware version
[ ] Default credentials changed from vendor default to buyer-set
[ ] Out-of-band administrative interfaces disabled or constrained
[ ] Update mechanism verified and named patch cadence committed
Tenant-level data settings:
[ ] Data residency set to declared region
[ ] Backup and retention configured against buyer policy
[ ] Customer-managed encryption key (CMK or BYOK) configured where vendor supports and tier requires it
[ ] Public dataset, public bucket, or public-link defaults locked down
Tenant-level audit and notification settings:
[ ] Admin notification channel configured and routed to named buyer-side mailbox
[ ] Security alert notification subscription enabled
[ ] Tenant audit log retention configured against the longest applicable framework expectation
5. Identity, access, and credential provisioning
Capture the identity-side provisioning the security team owns. The block reads against ISO 27001 Annex A 5.16, 5.17, 5.18, 8.2, 8.3, 8.5, SOC 2 CC6.1, CC6.2, CC6.3, NIST 800-53 IA and AC families, PCI DSS Requirement 7 and 8. Identity provisioning is where most vendor-onboarding security failures land in incident post-mortems: orphaned accounts, vendor-issued local logins outside SSO, long-lived static API keys, and missing deprovisioning runbooks for the four common departure events.
Authentication mode:
[ ] Single sign-on with named IdP configured wherever vendor supports it (IdP: {{IDP_NAME}})
[ ] SAML or OIDC integration confirmed with named SP-initiated and IdP-initiated flow as applicable
[ ] Just-in-time provisioning configured against documented group mapping where supported
[ ] SCIM provisioning configured against IdP where supported (named provisioning scope, named deprovisioning trigger)
[ ] Vendor-issued local accounts disabled or restricted to documented break-glass with named storage of recovery factor
[ ] MFA enforced at the IdP for every human identity touching the vendor surface
[ ] Conditional access policies enforced (geo, device, sign-in risk, IP allowlist) where IdP supports it
Privileged role posture:
[ ] Named privileged role definition recorded with smallest practical permission set
[ ] Just-in-time elevation or time-bound binding configured for elevated roles where vendor supports it (named elevation pathway)
[ ] Standing privilege inventory documented with named justification per identity
[ ] Privileged session logging enabled and retained against the longest applicable framework
Human identity provisioning:
[ ] Named end-user list recorded with role mapping
[ ] Named end-user MFA confirmed at the IdP
[ ] Named dormant account policy in effect (90-day inactivity threshold or shorter)
[ ] Named departed-user reconciliation runbook confirmed (HR-to-IdP-to-vendor reconciliation; named time-to-deprovision)
Service-account and API-key inventory:
[ ] Named service-account inventory recorded with named owner and named purpose
[ ] Named rotation cadence per service account
[ ] Named API key inventory recorded with named owner and named purpose
[ ] Named API key rotation cadence (target: 90 days or shorter for production-sensitive keys; named rationale where longer)
[ ] Named storage location for each shared credential inside buyer-controlled secrets manager
Machine and workload identity:
[ ] Workload identity federation used where vendor supports it (e.g. OIDC federation rather than long-lived static credentials)
[ ] External workload identity federation inventoried (GitHub Actions OIDC, GitLab CI OIDC, Terraform Cloud OIDC, named cloud-side managed identities)
[ ] Cross-account or cross-tenant trust policies audited
Deprovisioning runbook:
[ ] Named runbook for relationship owner departure
[ ] Named runbook for named end-user departure
[ ] Named runbook for contract termination
[ ] Named runbook for vendor decommissioning
[ ] Named time-to-deprovision target per runbook
[ ] Named verification step after deprovisioning fires (e.g. orphaned-account audit, last-sign-in audit, API key audit)
6. Integration and API security
Capture the technical integration the security team owns. The block reads against ISO 27001 Annex A 5.23, 8.20, 8.21, 8.24, SOC 2 CC6.6, CC6.7, PCI DSS Requirement 4. Integration is where two security boundaries meet. Without a documented baseline, the integration becomes a long-lived implicit trust path the security team never re-reviews.
Integration architecture inventory:
[ ] Named integration endpoints recorded with direction (inbound to buyer, outbound to vendor, bidirectional)
[ ] Named protocol per endpoint (HTTPS REST, gRPC, WebSocket, named message bus)
[ ] Named auth mode per endpoint (OAuth client credentials, OAuth authorisation code, mutual TLS, signed webhook, named API key)
[ ] Named scope per endpoint (smallest practical permission set documented)
[ ] Named data class per endpoint mapped against the data classification anchor at Section 1
TLS and certificate posture:
[ ] TLS minimum version enforced (TLS 1.2 minimum; TLS 1.3 preferred)
[ ] Cipher set confirmed against documented baseline
[ ] Certificate pinning configured where the integration requires it
[ ] Certificate expiry monitoring enabled with named owner
Network posture:
[ ] Source IP allowlist configured on the buyer side where vendor supports outbound destination control
[ ] Named private connectivity used where supported (AWS PrivateLink, Azure Private Endpoint, GCP Private Service Connect, dedicated interconnect, IPSec VPN)
[ ] Named outbound destination allowlist on the buyer side covering vendor endpoints
[ ] Public-facing integration endpoint inventory complete with named exposure rationale
Webhook posture:
[ ] Named webhook receiver authentication mechanism (signed payload, mutual TLS, signed request)
[ ] Webhook signature verification enabled and tested
[ ] Named webhook replay-protection mechanism (nonce, timestamp window)
[ ] Named webhook rate limit and abuse-protection posture
[ ] Named buyer-side ingress route, named WAF policy where applicable
API rate limiting and abuse protection:
[ ] Named buyer-side rate limit enforced against integration calls
[ ] Named alerting on anomalous integration call patterns
[ ] Named runbook for integration credential compromise
Secrets storage:
[ ] Integration credentials stored inside buyer-controlled secrets manager (named secrets manager: {{SECRETS_MANAGER}})
[ ] Named rotation cadence per integration secret
[ ] Named rotation runbook tested at onboarding before go-live
[ ] Named credential never stored in vendor-side configuration that the vendor administers
Pre-go-live integration baseline:
[ ] Named pen-test or scan baseline performed against the integration surface before go-live
[ ] Findings against the integration surface captured on the workspace finding system with named owner and target close date
[ ] Named retest cycle scheduled after go-live
7. Data flow, classification, and residency verification
Capture the data-side reality of the integration. The block reads against GDPR Article 28 processor obligations, Article 32 security of processing, Article 44 cross-border transfers, plus sector residency obligations. Data flow verification is what turns the legal commitment recorded at Section 3 into the actual operating reality the buyer can audit.
Data class inventory for the integration:
[ ] Named data classes confirmed against the in-scope use case at Section 1
[ ] Named data minimisation decision per class (which fields, which records, which retention)
[ ] Data class samples reviewed against actual integration payload definition
[ ] Personal-data sub-class inventory complete where regulated-personal data is in scope (named special-category data per GDPR Article 9, named children's data per GDPR Article 8 where applicable)
Processing region per data class:
[ ] Named primary processing region per data class
[ ] Named backup region per data class
[ ] Named DR region per data class
[ ] Region inventory consistent with the residency commitment recorded at Section 1 and the contractual commitment at Section 3
Sub-processor inventory:
[ ] Named sub-processor list received from vendor (cloud provider, CDN, email provider, analytics tool, support tool, AI sub-processor, monitoring tool)
[ ] Named residency per sub-processor
[ ] Named data class per sub-processor (each sub-processor identified for which class it touches)
[ ] Named sub-processor notification process confirmed (lead time before vendor adds a new sub-processor, named buyer-side review path)
Encryption posture against data class:
[ ] Encryption-at-rest mode confirmed per service used by the integration
[ ] Customer-managed key (CMK) configured where tier requires it (named key reference: {{CMK_REFERENCE}})
[ ] Key separation enforced across environments (separate keys per production / non-production / regulated)
[ ] Encryption-in-transit mode confirmed per integration endpoint
[ ] Internal vendor service-to-service encryption posture documented (named per vendor)
Retention and deletion:
[ ] Named retention period per data class confirmed against contractual commitment and regulatory floor
[ ] Named deletion mechanism (named deletion endpoint, named deletion verification mechanism, named deletion certificate)
[ ] Named time-to-delete target after a deletion request fires
[ ] Named scheduled deletion runs for time-bound retention (named cadence, named audit log)
[ ] Right-to-erasure path confirmed where personal data is in scope (named requestor identity verification, named deletion verification)
Regulatory data residency:
[ ] GDPR cross-border transfer mechanism confirmed where personal data of EU residents is in scope
[ ] Transfer Impact Assessment on file (if SCCs 2021 modules used)
[ ] Sector residency obligations confirmed (banking, health, government, defence as applicable)
[ ] Named national-security or surveillance regime risk reviewed where vendor processes outside the buyer's home jurisdiction
8. Logging, monitoring, and detection enablement
Capture the telemetry the buyer has to receive from the vendor so the audit can read whether the integration produced visibility. The block reads against ISO 27001 Annex A 8.15 logging, A 8.16 monitoring activities, SOC 2 CC7.1, CC7.2, PCI DSS Requirement 10. Without a documented log delivery and a named alert routing path, the integration is a blind spot in the security operations programme.
Vendor-side audit log enablement:
[ ] Tenant audit log enabled at the vendor (admin actions, authentication events, data access events at the granularity the vendor supports)
[ ] Named log retention configured against the longest applicable framework expectation
[ ] Log integrity verification posture documented (tamper-evident storage, named verification mechanism)
Log delivery to buyer:
[ ] Named log delivery mechanism (push to buyer-side log store, pull via API, SIEM connector, named cloud-native delivery)
[ ] Named log destination on the buyer side (centralised log store reference: {{LOG_STORE_REFERENCE}})
[ ] Named log format documented (named normalisation pipeline if reformatting on the buyer side)
[ ] Named delivery cadence confirmed (real-time, near-real-time, batch with named latency target)
[ ] Named gap-detection mechanism (alert if log delivery stops, named on-call owner)
Alert routing for vendor-originated events:
[ ] Named alert classes registered against the integration (authentication failure spike, mass data access, admin action outside hours, sub-processor change notification, vendor incident notification)
[ ] Named runbook per alert class
[ ] Named on-call owner per alert class
[ ] Named mean-time-to-acknowledge target per alert class
Vendor security service posture:
[ ] Named vendor-side security service enabled where vendor offers them (vendor-native threat detection, vendor-native data loss prevention, vendor-native anomaly detection)
[ ] Named output routing from vendor-side security service into buyer-side log store or alerting
Buyer-side observation of the integration:
[ ] Named buyer-side scanning posture for the integration surface (external scanning of the public endpoint, authenticated scanning of the buyer-side integration interface)
[ ] Named buyer-side application performance monitoring includes integration health
[ ] Named buyer-side data egress monitoring includes the integration as a flow source
Status page and incident communication:
[ ] Named vendor status page URL subscribed (named webhook or feed integration into buyer-side notification)
[ ] Named vendor incident notification channel confirmed (named PagerDuty / Slack / email destination per Section 3 contract clause)
9. Vulnerability and patch posture confirmation
Capture the vulnerability-side posture the buyer has to confirm before go-live. The block reads against ISO 27001 Annex A 8.8 management of technical vulnerabilities, SOC 2 CC7.1, PCI DSS Requirement 6 and 11, NIST 800-53 RA-5 and SI-2. Vulnerability posture confirmation is not a one-off scan; it is the named cadence the security team commits to on the integrated surface so the surface stays current.
Vendor-side vulnerability posture:
[ ] Named vendor security patching SLA confirmed (named time-to-patch per severity tier)
[ ] Named vendor vulnerability disclosure programme link recorded
[ ] Named vendor PSIRT advisory feed subscribed where vendor publishes
[ ] Most recent vendor-provided third-party pentest report received and reviewed
[ ] SBOM availability and freshness policy confirmed where vendor exposes one
Embedded-software and dependency posture (where applicable):
[ ] Named vendor-disclosed dependency list reviewed against buyer-side dependency tracking
[ ] Named end-of-life policy confirmed for the vendor-supplied component
[ ] Named buyer-side response runbook for vendor-disclosed CVE in the contracted service
Integration surface vulnerability baseline:
[ ] Named buyer-side external scan against the integration surface completed before go-live
[ ] Named buyer-side authenticated scan against the integration surface completed before go-live where applicable
[ ] Named buyer-side code review or SAST scan against the integration code completed before go-live
[ ] Findings captured on the workspace finding system with severity calibrated to CVSS 3.1, named owner, target close date, named retest cadence
Continuous monitoring cadence:
[ ] Named recurring scan cadence scheduled against the integration surface (named cadence: {{SCAN_CADENCE}})
[ ] Named alert routing for new findings from the recurring cadence
[ ] Named retest cycle for closed findings from the integration surface
[ ] Named owner for the recurring cadence
Vulnerability findings routing:
[ ] Vendor-side advisory findings landed onto the workspace finding system with named severity calibration
[ ] Buyer-side scan findings on the integration surface landed onto the workspace finding system
[ ] Named SLA tier per finding source
[ ] Named escalation path for SLA breach
10. Incident response and notification readiness
Capture the incident response and notification readiness the buyer-side IR team needs to operate when the vendor calls. The block reads against ISO 27001 Annex A 5.24 to 5.28 information security incident management, SOC 2 CC7.3 and CC7.4, PCI DSS Requirement 12.10, NIST 800-61 incident handling guide. Readiness is what turns a contractual notification clause into an operating runbook the IR team can actually execute on day one.
Notification SLA confirmation:
[ ] Named hours-to-notify confirmed against Section 3 contract clause
[ ] Named notification channel confirmed (named buyer-side email, named webhook, named PagerDuty service)
[ ] Named buyer-side recipient confirmed (named role, named escalation lookup)
[ ] Named vendor-side notification contact confirmed (named role on vendor side, named after-hours channel)
Buyer-side intake runbook:
[ ] Named runbook for vendor-originated incident intake (where the notification lands, who acknowledges, who escalates, who scopes impact)
[ ] Named tabletop completed against a vendor-originated scenario relevant to this vendor class
[ ] Named in-scope data classes mapped to regulatory-notification obligations triggered by a vendor-side compromise (GDPR Article 33, sector breach notification laws, customer contractual notification obligations)
[ ] Named regulator-engagement protocol referenced where vendor compromise is in scope
Forensic cooperation readiness:
[ ] Named buyer-side forensic point-of-contact recorded with vendor
[ ] Named scope and timing for vendor forensic cooperation confirmed against Section 3 clause
[ ] Named buyer-side evidence preservation runbook referenced for vendor-originated events
Business continuity readiness:
[ ] Named buyer-side dependency map updated to flag the new vendor
[ ] Named recovery time objective (RTO) and recovery point objective (RPO) confirmed against vendor SLA
[ ] Named fallback path documented (alternate vendor, in-house alternative, named manual workaround)
[ ] Named scenario rehearsed where the vendor is unavailable for the named RTO window
Sub-processor incident readiness:
[ ] Named vendor sub-processor incident notification clause confirmed
[ ] Named buyer-side response if a vendor sub-processor is compromised (named escalation, named data-class impact assessment)
Lessons-learned commitment:
[ ] Named post-incident review process where the buyer-side IR team reviews a vendor-originated incident
[ ] Named feedback loop into the vendor-relationship review cadence
11. Go-live security gate
Capture the named gate the onboarding has to pass before the vendor handles real data on real traffic. The block requires four named signatures, eight named pre-conditions, the named effective date, the named scope, and the named rollback path. A documented gate is what makes the difference between an onboarding that completed and one that quietly slipped into production with security gaps still open.
Gate pre-conditions (each pre-condition must be met or moved onto the documented residual-conditions list with named owner and named expiry):
[ ] Section 2 pre-onboarding decision recorded
[ ] Section 3 contract security clauses verified
[ ] Section 4 tenant and environment configuration applied
[ ] Section 5 identity provisioning complete
[ ] Section 6 integration security baseline complete
[ ] Section 7 data flow, classification, and residency verified
[ ] Section 8 logging, monitoring, and detection live
[ ] Section 9 vulnerability and patch posture confirmed
[ ] Section 10 incident response and notification readiness confirmed
Documented residual conditions (the named "go-live conditional" path; each condition carries a named owner and named expiry so the conditional path does not silently become permanent residual risk):
- Condition 1: {{CONDITION_1}}, owner: {{CONDITION_1_OWNER}}, target close date: {{CONDITION_1_CLOSE_DATE}}, compensating control: {{CONDITION_1_CONTROL}}
- Condition 2: {{CONDITION_2}}, owner: {{CONDITION_2_OWNER}}, target close date: {{CONDITION_2_CLOSE_DATE}}, compensating control: {{CONDITION_2_CONTROL}}
- Condition 3: {{CONDITION_3}}, owner: {{CONDITION_3_OWNER}}, target close date: {{CONDITION_3_CLOSE_DATE}}, compensating control: {{CONDITION_3_CONTROL}}
Named effective date and scope:
- Effective go-live date: {{GO_LIVE_DATE}}
- Initial scope of production traffic and data (named integration endpoints, named data classes, named business units): {{INITIAL_SCOPE}}
- Phased rollout plan (if applicable): {{PHASED_ROLLOUT_PLAN}}
Named rollback path:
- Named rollback trigger criteria (e.g. integration error rate over named threshold, named data exposure detected, named vendor incident notification fires within named window): {{ROLLBACK_TRIGGERS}}
- Named rollback runbook reference: {{ROLLBACK_RUNBOOK_REFERENCE}}
- Named owner of the rollback decision: {{ROLLBACK_DECISION_OWNER_ROLE}}, {{ROLLBACK_DECISION_OWNER_NAME}}
Four named signatures (the named approvers that turn the onboarding into a controlled deliverable):
- Buyer-side security lead: {{SECURITY_LEAD_NAME}}, role {{SECURITY_LEAD_ROLE}}, signature date {{GO_LIVE_DATE}}
- GRC reviewer: {{GRC_REVIEWER_NAME}}, role {{GRC_REVIEWER_ROLE}}, signature date {{GO_LIVE_DATE}}
- Relationship owner: {{RELATIONSHIP_OWNER_NAME}}, role {{RELATIONSHIP_OWNER_ROLE}}, signature date {{GO_LIVE_DATE}}
- Executive sign-off (CISO, security director, security operations leader, risk-committee chair appropriate to onboarding tier): {{EXECUTIVE_SIGN_OFF_NAME}}, role {{EXECUTIVE_SIGN_OFF_ROLE}}, signature date {{GO_LIVE_DATE}}
Named pre-go-live communications:
- Named procurement, legal, IT operations, and business-unit stakeholders notified of go-live date and initial scope
- Named buyer-side help-desk briefed for user-facing onboarding questions
- Named customer-success or programme management notified where the onboarding affects downstream customer commitments
12. Post-go-live verification and reassessment cadence
Capture the named verification and reassessment cadence the onboarding commits to after go-live. The block reads against ISO 27001 Annex A 5.22 monitoring and review of supplier services and SOC 2 CC9.2 ongoing assessment of vendor performance. Post-go-live verification is what catches the slow drift between the onboarding-time posture and the steady-state reality, before the drift becomes the next vendor-originated incident or the next audit finding.
Day-one verification (within 24 hours of go-live):
[ ] Vendor-side audit log delivery confirmed live and landing on the buyer-side log store
[ ] Named alert routing tested with a controlled event
[ ] Integration error rate observed and recorded as the post-go-live baseline
[ ] Named buyer-side monitoring dashboard reviewed against the integration baseline
Week-one verification (within 7 days of go-live):
[ ] Identity provisioning verified against actual user activity (orphaned identities, unused identities, unauthorised identities)
[ ] Service-account and API-key activity baseline recorded
[ ] Named vulnerability scan re-run against the integration surface to confirm steady-state posture matches go-live posture
[ ] Named buyer-side data egress audit against the integration to confirm only documented data classes are flowing
Thirty-day verification:
[ ] Documented residual conditions from Section 11 reviewed against close dates and either closed on evidence or escalated for renewal
[ ] First period audit log retention rollover verified
[ ] First period sub-processor change notification process tested (named vendor change or named buyer-side test)
[ ] First period vendor incident notification process tested (named tabletop scenario)
Ninety-day verification:
[ ] Comprehensive integration review against the original scope at Section 1 (scope drift, data class drift, integration endpoint drift, sub-processor drift)
[ ] Vendor performance against the contracted security obligations reviewed
[ ] Named buyer-side relationship-owner check-in with vendor on outstanding items
Reassessment cadence:
[ ] Named scheduled reassessment cadence per onboarding tier (top-tier critical regulated data: quarterly programme review plus annual full reassessment; standard regulated data: semi-annual programme review plus annual full reassessment; standard production: annual reassessment; low-criticality production: biennial reassessment unless triggered)
[ ] Named scheduled attestation freshness review (SOC 2 renewal, ISO 27001 recertification, PCI AOC renewal)
[ ] Named scheduled penetration test review of the vendor surface
[ ] Named scheduled review of vendor sub-processor list against the named notification clause
Trigger-driven reassessment (each trigger fires a scoped re-onboarding rather than waiting for the calendar cycle):
- Material scope change (new data class added, new processing region added, new integration endpoint added)
- Material identity change (new privileged role pattern, federation source change, departure of named relationship owner without named succession)
- Published vendor security incident
- Material change in vendor sub-processor list or residency
- Material regulatory change in buyer or vendor jurisdiction
- Annual contract renewal that the assessment workbook re-opens
- Vendor merger, acquisition, or change of control
Final framework evidence map:
[ ] Section-by-section evidence map updated against named framework controls (ISO 27001 Annex A 5.19 to 5.23 and 8.30, ISO/IEC 27036, SOC 2 CC9.2, PCI DSS 12.8 and 12.9, HIPAA 164.308(b) and 164.314(a), NIST SP 800-53 SR family and SA-12, NIST SP 800-161, NIST CSF 2.0 GV.SC, CSA Cloud Controls Matrix STA, NIS2 Article 21, DORA Articles 28 to 30, GDPR Article 28, UK PRA SS2/21, FFIEC outsourcing booklet, APRA CPS 230 where in scope)
[ ] Audit-pack export prepared and attached to the engagement record
[ ] Named GRC reviewer signs the post-go-live framework evidence map
Eight failure modes the checklist has to design against
Vendor onboardings fail the audit read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before customising the checklist so the customisation does not weaken the discipline that makes the onboarding artefact defensible across audit, regulator, and customer reads.
Onboarding starts before the pre-onboarding gate fires
The relationship owner is under pressure to go live and provisions access, configures integrations, or pushes data before Section 2 records a pre-onboarding decision. Security finds the vendor in production through an external scanner picking up an integration endpoint or an audit log surfacing an unfamiliar OAuth client. Make Section 2 a documented gate where the named security lead and named GRC reviewer signature is the precondition for the rest of the checklist, and the security team has explicit authority to pause any onboarding that bypasses the gate.
Contract negotiation security clauses do not match executed contract
The security team negotiates strong incident notification, sub-processor transparency, and audit rights clauses, and the executed contract drops or weakens them in final redlines. Section 3 of the onboarding then onboards against the vendor commitments security expected rather than the commitments the contract actually carries. Make Section 3 a verification step where the security lead reads the executed contract and confirms each named clause is present, before any access or integration work starts.
Identity provisioning relies on vendor-issued local accounts outside SSO
The vendor supports SSO but the integration goes live with vendor-issued local credentials because SSO configuration was deprioritised or never assigned to a named owner. Six months later the deprovisioning runbook for relationship-owner departure does not deprovision the vendor-issued local accounts, and the account leaves the company. Make SSO the named default at Section 5 and document any vendor-issued local account as a residual condition with a named expiry, not as a permanent path.
API keys and service-account credentials live in vendor-side configuration
API keys are pasted into the vendor admin console rather than minted from buyer-side credential management with named rotation cadence. When the named owner departs, when a service account is suspected compromised, or when the security team needs to rotate, the buyer side has no source of truth for which credentials are live and who issued them. Make buyer-controlled secrets management the named storage at Section 6 with named rotation cadence per credential.
Webhook receivers verify signature but ignore replay
Webhook receivers verify the vendor-side HMAC signature but accept any timestamp, so a captured payload can be replayed against the receiver weeks later. Make the named webhook replay-protection mechanism (timestamp window plus nonce, or named idempotency key check) a Section 6 pre-condition rather than a downstream hardening initiative.
Log delivery is configured but never gap-detected
Vendor-side audit log delivery is configured and works at go-live, and then silently stops three months later because of a vendor API change, an expired credential, or a misconfigured pipeline. The buyer has no log coverage of the vendor surface until the next incident response cycle discovers the gap. Make the named gap-detection alert at Section 8 a pre-condition for go-live with a named on-call owner.
Sub-processor list is captured once and never refreshed
Section 7 captures the sub-processor list at onboarding and never refreshes it. Vendors add and remove sub-processors quarterly. The named notification clause at Section 3 is the contractual right; the named buyer-side review path is what turns the right into an actually-reviewed list. Pair the contractual notification clause with a named buyer-side review runbook so each new vendor sub-processor lands on a real desk and gets a documented decision.
Go-live gate degrades into a single signature
Over time the four-signature block at Section 11 erodes into a single signature, or the gate fires before all eight pre-conditions are met, with the residual conditions silently accumulating on a spreadsheet that nobody reviews at 30, 60, or 90 days. Enforce the four-signature block on every go-live publication and treat the residual conditions list as a controlled artefact with named owners and named expiries that route to the exception register if the close date slips.
Ten questions a quarterly onboarding programme review has to answer
Per-vendor go-live review keeps each onboarding artefact current. Programme-wide review answers the cumulative question: is the vendor portfolio durably audit-ready, and is the programme on top of the residual conditions, the attestation freshness, and the sub-processor changes. Run these ten questions at every quarterly programme review and capture the answers in the programme-level summary record.
1.How many vendors went live during the period through the documented gate, broken out by onboarding tier, and how many went live through a documented exception path.
2.How many vendors that went live during the period carry documented residual conditions, what is the average age of those conditions, and how many have slipped past their named close date.
3.How many vendors are operating against an attestation set whose freshness has expired (SOC 2 over 12 months old, ISO 27001 certificate lapsed, PCI AOC expired) without documented compensating mitigation.
4.How many vendor-originated incidents fired during the period, what was the mean-time-to-notify and the mean-time-to-acknowledge, and how many of those incidents triggered a scoped re-onboarding under Section 12.
5.How many sub-processor change notifications were received from vendors during the period, how many produced a documented buyer-side review, and how many produced a material onboarding action.
6.How many vendors went through a material scope change during the period and how many of those changes triggered a scoped re-onboarding under Section 12 rather than a silent expansion.
7.How many integration credentials are stored inside buyer-controlled secrets management with named rotation cadence, and how many are still living in vendor-side configuration without a named rotation date.
8.How many vendor surfaces are scanned on a recurring cadence with named owner, and how many integration surfaces have no scheduled cadence at all.
9.How many vendor-side audit log deliveries had a delivery gap during the period (defined as a continuous outage beyond the named latency target) and how many of those gaps were detected by named alerting versus discovered after the fact.
10.How many onboardings during the period closed within the target onboarding window, and where the window slipped, what was the most common blocking section in the checklist.
How the checklist pairs with SecPortal
The template above is copy-ready as a standalone artefact. If the security team already runs finding tracking, document storage, exception management, and framework evidence packaging on a workspace, the checklist becomes the byproduct of the onboarding work rather than a separate document. SecPortal pairs each new vendor onboarding to a versioned record through engagement management so the in-scope vendor identity, the named data classes, the named integration endpoints, the named identity provisioning steps, the named monitoring sources, the named four signatures on the go-live gate, and the named post-go-live verification cadence all live on one record with a single revision history. The findings management feature captures every finding raised during the onboarding (a SaaS misconfiguration discovered during Section 4, an integration failure mode discovered during Section 6, a missing log source discovered during Section 8, a vulnerability identified against the vendor surface in Section 9) under the unified schema with CVSS 3.1 calibration, severity, target close date, named owner, named retest pointer, and named evidence-of-closure expectation, so the onboarding seeds the operational queue rather than producing an isolated document.
The document management feature stores the executed contract, the data processing agreement, the SOC 2 report, the ISO 27001 certificate, the PCI AOC, the most recent vendor pentest report, the named sub-processor list, the named regulator-engagement letter where applicable, and the named tabletop output. The bulk finding import path ingests CSV exports from buyer-side scans run against the integration surface (Section 9) so the vendor-side findings land alongside the wider security backlog under the same workspace finding identity. The finding overrides feature carries the eight-field exception decision chain for residual conditions captured at the Section 11 go-live gate (named approver, named compensating control, named expiry, named renewal cadence, named residual risk owner, named scope, named justification, named review history) so the conditional path stays on the live record rather than on a side spreadsheet that nobody renews.
The activity log captures status transitions on every entity (finding, engagement, document, comment) by named user and timestamp with CSV export, so the onboarding audit chain is recorded automatically as a side effect of the work and the named-actor signature trail at the go-live gate is reproducible. The compliance tracking feature maps findings and controls against ISO 27001 Annex A 5.19 through 5.23 and 8.30, SOC 2 CC9.2, PCI DSS 12.8 and 12.9, NIST SP 800-161, NIS2 Article 21, and DORA Articles 28 to 30 so the framework evidence map at Section 12 can be sliced by framework when an auditor asks for the evidence pack against a specific supplier-management control set. The continuous monitoring feature schedules domain and authenticated scans against the integration surface on a named cadence so the public-facing posture from Section 6 and the vulnerability baseline from Section 9 stay current between reassessment cycles. The retesting workflows feature carries the per-finding retest cycle that Section 9 commits to, so the evidence-of-closure expectation at finding capture becomes an executable workflow rather than a written promise.
The team management feature carries the role-based access control that decides which roles can author each section, which roles can countersign, which roles can publish, and which roles can sign off at the go-live gate. The multi-factor authentication control gates workspace access so the audit reads the access record as a documented control rather than as a hope. The AI report generation workflow can draft the executive summary the relationship owner reads at go-live, the quarterly programme review narrative the audit committee receives, and the per-vendor read-back the CISO uses at leadership cadence from the same engagement data, so the publication path produces multiple consumer-shaped reads of the same underlying onboarding without re-keying.
Honest scope: SecPortal is not a third-party risk management platform, not a security ratings vendor, not a procurement workflow tool, not a contract lifecycle management tool, not an identity provider, not a SCIM provisioning service, not a SIEM, not a SOAR, does not ingest vendor-side audit log streams in real time, does not act as a webhook receiver for vendor-side events, and does not ship native push connectors into Jira, ServiceNow, OneTrust, Vanta, Drata, SecureFrame, Whistic, UpGuard, BitSight, SecurityScorecard, RiskRecon, Panorays, or Black Kite. It serves as the consolidated operating record an internal security, GRC, AppSec, vulnerability management, or vendor risk team uses to track each vendor onboarding artefact, the findings against the integration surface, the exception register for residual conditions, the framework evidence map, and the named go-live and reassessment audit chain.
Internal security teams, AppSec teams, and security engineering teams read the checklist as the named operational procedure that turns vendor onboarding from a relationship-owner workflow into a security-owned discipline. Pair the checklist with the internal security teams persona page and the AppSec teams persona page.
Security operations leaders
Security operations leaders and detection engineering teams read Section 8 as the named telemetry and alert-routing baseline the integration commits to, so the integration enters production with documented visibility rather than as a silent addition to the asset footprint. Pair the checklist with the security operations leaders persona page.
CISOs and security leadership
CISOs, security directors, and security architects read the checklist as the per-vendor go-live deliverable that informs the supplier-management strategic posture and the quarterly governance review. Pair the checklist with the CISOs persona page and the security leadership reporting use case.