Use Case

Third-party vendor security risk management programme
as a continuous workflow on the engagement record, not a one-off spreadsheet per renewal

Vendor security reviews land on the GRC team every new procurement, every renewal, every contract change, every reported vendor incident, and every regulator-driven recertification. Most programmes run them as one-off questionnaires in a shared spreadsheet, lose the prior assessment by the next renewal, and rebuild the same evidence stack from scratch. Run third-party vendor security risk management as a continuous programme on the engagement record so vendor tiering, intake, recertification cadence, attestation freshness, exception lifecycle, incident notification tracking, and exit-and-decommissioning all read against one durable record the audit lookback can reconstruct.

Get Started Free

No credit card required. Free plan available forever.

Run vendor risk management as a continuous programme on the engagement record

Third-party vendor security reviews land on the GRC team every new procurement, every annual renewal, every contract change, every reported vendor security incident, and every regulator-driven recertification. Most programmes run them as one-off questionnaires in a shared spreadsheet, lose the prior assessment by the next renewal, stockpile stale SOC 2 reports in a folder no one reviews, leave qualified opinions and pentest findings locked inside vendor PDFs, route approvals informally over Slack, and discover at exit that no one recorded the data-return attestation. The workflow below runs the programme as a continuous cycle on the engagement record so vendor tiering, intake, recertification cadence, attestation freshness, exception lifecycle, incident notification tracking, and exit-and-decommissioning all read against one durable record the audit lookback can reconstruct.

This is the inbound GRC workflow that pairs with the outbound vendor security questionnaire response workflow (where the security team is the SUPPLIER answering customer security reviews). For the operational receipt of a single pentest report from a vendor or testing firm, read the third-party penetration test report intake workflow. For the canonical control library that turns vendor self-attestations into a queryable record, read the control mapping cross-framework crosswalks workflow. For the exception register the residual rating references when a vendor is approved with conditions, read the vulnerability acceptance and exception management workflow. For the deal-driven assessment cycle that runs on M&A diligence, read the M&A security due diligence workflow.

Six drift patterns the vendor cycle produces by default

Drift in the vendor risk programme is the default state, not the exception. The six patterns below recur in every programme that maintains more than a handful of suppliers. Each one starts as an operational convenience and ends as an audit-cycle scramble, a missed commitment the regulator notices, or a vendor relationship that closes off-record.

Pattern	Healthy posture	Default failure
Every vendor cycle starts from a blank spreadsheet	Each vendor onboarding, annual renewal, and contract change opens as an engagement on the vendor record. The prior cycle, the open commitments, the residual rating, the requested evidence, and the named owners are visible during drafting. The reviewer reads a delta against the previous cycle rather than rewriting the assessment from a template.	Renewal lands in March and the GRC analyst opens a fresh copy of the assessment spreadsheet, asks the vendor for the same SOC 2 report they sent last March, scores against the same control checklist, and ships a refreshed PDF that contradicts two commitments the prior analyst extracted. Three weeks later the customer success team escalates because the vendor pushed back on the same condition twice.
Attestations get stockpiled rather than scored against a freshness policy	Vendor attestations (SOC 2, ISO 27001 certificate, pentest report, SBOM, sub-processor list, breach attestation) land as structured documents on the engagement with the issue date, the auditor or test firm, the scope, the period, and the next-issue commitment. The freshness policy reads the issue date against the documented cadence so stale attestations trigger a re-request before they reach an external assessor.	A vendor folder on a shared drive holds a 2024 SOC 2 report, an ISO 27001 certificate that lapsed seven months ago, and a pentest summary from a firm that has since dissolved. The auditor opens the folder during fieldwork and asks why the supplier evidence base predates the operating-effectiveness window. The recertification scrambles to refresh five vendors in two weeks.
Findings inside the vendor pentest report stay locked in the PDF	Qualified opinions in the SOC 2 report, open findings in the vendor pentest report, identified exceptions, and disclosed sub-processor changes all become structured findings on the vendor engagement with calibrated severity, the affected control area, the named risk owner inside the buying organisation, and the requested vendor commitment. The remediation queue reads against findings rather than against PDFs.	The vendor delivers a forty-page pentest report. The GRC analyst skims the executive summary, scores the vendor green because nothing in the summary screamed critical, and files the PDF. The audit committee asks at the next quarterly read why a high-severity finding in the body of the report was never tracked. The retroactive remediation scramble creates an exception cycle the security director did not approve in advance.
Approval ladders run informally over Slack and email	Each cycle produces a residual rating and a recommendation, and the approval ladder reads the recommendation against the vendor tier. The decision lands on the engagement with the signing role, the timestamp, the conditions attached, and the recertification trigger date. The activity log captures every step so the audit lookback can reconstruct the approval.	A tier 1 vendor with a medium residual gets approved by an analyst forwarding the assessment to the security director in Slack, the director replies with a thumbs-up emoji, and the customer success team treats the thread as the sign-off. Six months later the vendor experiences an incident, regulators ask for the original approval evidence, and the only record is a Slack archive someone has to recover from retention.
Vendor incident notifications get filed without commitment tracking	Vendor security incidents land on the vendor engagement as in-cycle findings with the reported date, the vendor description, the scope of impact on the buying organisation, the remediation commitment, and the buyer-side response action. Committed vendor remediations track as findings with target dates the recertification cycle reads against.	A vendor emails a breach notification, the security team forwards it to the business owner, the business owner acknowledges, and the thread closes. The vendor never reports closure, the remediation commitment slides past its date, and the next assessment cycle reopens the same gap because no one tracked the commitment to closure between cycles.
Exit and decommissioning happen silently	Vendor exit opens as a documented exit engagement with the data-return or data-destruction attestation, the credential-revocation evidence, the access-removal evidence, the sub-processor unwind plan, and the post-exit retention obligations recorded against the engagement.	A vendor contract terminates, procurement archives the contract record, and the security team never sees a decommissioning trigger. Service accounts remain provisioned for nine months, the vendor still holds a copy of the production extract, and the auditor asks at the next cycle why the supplier termination did not produce a structured evidence package.

Six failure modes that quietly stretch every assessment cycle

Vendor risk failures rarely look like failures at the moment they happen. They look like sensible defaults: trust the questionnaire, file the SOC 2 report, approve the renewal, defer the sub-processor change to next cycle, close the vendor relationship silently. The cost arrives later when the auditor finds the gap, the regulator asks for the closure record, or the vendor experiences an incident the buyer-side commitment never tracked.

Treating vendor risk as a procurement checkbox rather than a continuous programme

When the vendor assessment is owned by procurement and the security team is only consulted at onboarding, the cycle becomes a deal-closing checkbox rather than an ongoing programme. The recertification cadence slips because no one on the procurement side reads the SOC 2 expiry calendar. The vendor incident notification never reaches the named risk owner. The programme produces an onboarding artefact and nothing else. Running vendor risk as a continuous workflow on the engagement record gives security ownership of the cycle the procurement record alone cannot sustain.

Scoring vendors only against the questionnaire and not the underlying attestations

Vendor questionnaires are self-attested. The SOC 2 report, ISO 27001 certificate, and pentest report are the assessor-validated evidence the questionnaire claims have to reconcile against. Programmes that score the questionnaire without reading the attestations approve vendors whose self-attested controls do not match the qualified opinion in their SOC 2 report. The discipline is reading both layers and recording the gap between them as a structured finding on the engagement rather than absorbing the discrepancy as analyst judgement.

Letting vendor tiering drift after onboarding

A tier-3 low-risk vendor becomes a tier-1 production-data processor when the buying organisation expands the use case, integrates a new API, or migrates more workloads. Programmes that tier vendors at onboarding and never revisit miss the migration and continue to assess the relationship at the original tier. The cadence, the evidence requirements, and the approval ladder all stay misaligned with the actual risk exposure. Periodic tier-review against the live integration map is part of the programme, not a one-off onboarding event.

Confusing the SOC 2 report with the auditor evidence pack for your own audit

The vendor SOC 2 report is the assessor-validated control evidence for the vendor service. Your own SOC 2 audit reads the vendor relationship through subservice organisation controls or carved-out controls. They are different artefacts in different audits. Programmes that paste vendor SOC 2 reports into their own audit evidence pack without recording the complementary user entity controls (CUECs) overstate their own coverage. The discipline is mapping vendor CUECs onto the buyer-side control library so the audit chain stays defensible.

Allowing sub-processor changes to bypass the assessment cycle

Vendors change sub-processors (a SaaS supplier adopts a new infrastructure provider, a payments processor adds a fraud-detection partner, an AI model provider switches inference backends). Each change introduces fourth-party risk into the buying organisation. Programmes that read sub-processor lists only at annual recertification miss disclosures the vendor made via email in between. The intake rule has to capture sub-processor change notifications as in-cycle findings on the engagement so the residual rating gets a refresh trigger rather than waiting for the next cycle.

No reconciliation between the vendor risk register and the wider risk register

The vendor risk register reads the residual rating, the open commitments, and the exception backlog by vendor. The wider enterprise risk register reads the risk landscape by business risk theme (data protection, operational resilience, third-party concentration, regulatory exposure). Programmes that operate the two registers independently end up with vendor risks that no enterprise risk theme tracks. The reconciliation cadence rolls vendor-level findings into enterprise risk themes so the audit committee reads one risk picture rather than two parallel views.

Six fields every vendor risk policy has to record

A defensible vendor risk policy is six concrete fields on the engagement record, not an abstract paragraph in a security handbook. Anything missing from the list below is a known gap in the programme primitive rather than a detail that surfaces later when the auditor opens the supplier file.

Vendor onboarding intake rule

How a new vendor enters the programme: the named business owner inside the buying organisation, the named security counterpart on the vendor side, the contract reference, the data-handling scope, the system-impact scope, the proposed assessment tier, and the requested evidence list. Without an intake rule, vendors get onboarded by procurement before the security team sees the contract, and the first assessment cycle catches up with a production deployment already in flight.

Vendor tiering framework

The tiering definition: tier 1 for data-processing or production-access vendors, tier 2 for limited-scope vendors that touch internal systems but not customer data, tier 3 for low-risk vendors. Tiers carry their own cadence, evidence requirements, approval ladder, and notification expectations. Programmes that operate one cadence for every vendor either overspend on tier 3 assessment effort or underspend on tier 1 attestation freshness.

Evidence freshness policy

How recent each attestation has to be to support an approval: SOC 2 Type II reports within the documented window, ISO 27001 certificates with a documented surveillance audit since last cycle, penetration test reports within the documented test cadence, SBOMs updated against the current product version, sub-processor lists with a documented review date. Programmes that stockpile stale attestations create audit-cycle scrambles; programmes with a freshness policy refresh evidence before the auditor reads it.

Approval ladder by tier and residual rating

Who signs off on what: tier 1 vendors at medium or higher residual require security director and business owner co-sign, tier 2 vendors at high residual require the same, tier 3 vendors at low residual approve by the GRC reviewer alone. The ladder lives on the engagement record so role changes, vacation cover, and reorganisations land as a single mapping update rather than a per-vendor propagation problem.

Incident notification and commitment tracking rule

How vendor security incidents enter the programme: notification intake within the documented hours, the buyer-side response action recorded on the engagement, the vendor remediation commitment captured as a finding with a target date, and the closure evidence required before the commitment is marked complete. Programmes that record notifications without commitment tracking cannot demonstrate continuous monitoring under NIS2 Article 21, DORA Article 28, or NIST SP 800-161 expectations.

Exit and decommissioning rule

How a vendor relationship closes: the trigger event, the data-return or data-destruction attestation with named signatory, the credential-revocation evidence with timestamp, the access-removal evidence covering both human and service accounts, the sub-processor unwind plan, and the post-exit retention obligations recorded against the engagement. Without an exit rule, decommissioning happens silently and the audit lookback cannot demonstrate the supplier relationship closed on a documented baseline.

Vendor risk programme checklist

Before every assessment cycle opens and at every quarterly reconciliation, the security lead and the responsible GRC owner walk through a short checklist. Each item takes minutes; missing any one is the source of the failure modes above and the supplier-side scrambles that follow.

Every in-scope third-party is onboarded as a vendor record with a documented tier, named business owner, and named security counterpart before contract signature.
Each cycle opens a structured engagement on the vendor record with the trigger, the deadline, the requested evidence list, the named GRC reviewer, and the named approver.
Vendor-provided attestations land as structured documents with issue date, auditor or test firm, scope, period, and next-issue commitment captured.
The freshness policy is enforced at intake so stale attestations trigger a re-request before scoring rather than absorbing into the recommendation.
Qualified opinions, identified exceptions, and open findings in vendor attestations become structured findings on the engagement with calibrated severity and a named risk owner.
Sub-processor changes received between cycles open as in-cycle findings rather than waiting for the next recertification.
Each cycle produces a residual rating and an approval recommendation that runs the documented approval ladder for the vendor tier and residual.
The approval decision lands on the engagement with the signing role, timestamp, attached conditions, and recertification trigger date.
Vendor incident notifications land on the engagement with reported date, vendor description, scope of impact, remediation commitment, and buyer-side response action.
Committed vendor remediations from prior cycles track as findings the recertification reads against, with closure evidence required before completion.
Tier review happens against the live integration map at a documented cadence so vendor scope changes do not bypass the tiering framework.
Vendor risk register entries reconcile into the enterprise risk register on a documented cadence so the audit committee reads one risk picture.
Exit engagements record data-return or data-destruction attestation, credential-revocation evidence, access-removal evidence, sub-processor unwind plan, and post-exit retention obligations.
The activity log captures every intake, draft, approval, incident notification, and exit event with timestamp and user attribution so the audit lookback resolves from one record.

How the vendor risk programme looks in SecPortal

Vendor risk management runs on the same feature surfaces the rest of the GRC programme already uses: the vendor record as a workspace client, the engagement record per cycle, document management for received attestations, findings management for vendor-side risks and committed remediations, compliance tracking for the control library, the activity log for the audit chain, and team management for the approval ladder. The discipline is keeping the engagement-record-per-cycle queryable on the vendor record so the next cycle inherits the prior history rather than waiting for a manual rewrite.

Vendor as workspace record

Each third-party is onboarded as a vendor record on the workspace with the named business owner, the named security counterpart, the contract reference, and the documented tier. The record is the join key that connects every cycle, every attestation, every finding, and every approval to one supplier identity.

Cycle as engagement

Each assessment cycle opens as an engagement on the vendor record with the trigger (onboarding, renewal, scope change, incident, regulator request), the deadline, the requested evidence list, the named GRC reviewer, and the named approver. The engagement is the durable home of the cycle.

Attestations on the engagement

Document management holds the received SOC 2 reports, ISO 27001 certificates, pentest reports, SBOMs, sub-processor lists, and breach attestations on the engagement with issue date, scope, period, and next-issue commitment captured against each artefact.

Canonical control library

Compliance tracking maps the canonical control identifier to ISO 27001 Annex A, SOC 2 Trust Services Criteria, PCI DSS requirements, NIST control families, NIS2 obligations, and DORA articles so the same vendor evidence answers assessments across all frameworks.

Findings on the vendor

Findings management holds qualified opinions from SOC 2 reports, open findings from vendor pentest reports, identified exceptions, disclosed sub-processor changes, and committed remediations as structured records with calibrated severity, affected control area, and the named risk owner inside the buying organisation.

Approval ladder routing

Team management and the role-based access controls scope the named GRC reviewer, the security director, and the business owner so the approval ladder reads the recommendation against the vendor tier and the residual rating without a per-vendor routing rebuild.

Incident notification log

Vendor incident notifications land on the vendor engagement with the reported date, the scope of impact, the remediation commitment, and the buyer-side response action. Notifications and alerts route the notification to the named risk owner so commitments do not slip silently between cycles.

AI-drafted assessment report

AI report generation drafts the assessment report from the vendor engagement: the tier, the received attestations and their freshness, the structured findings, the residual rating, and the recommendation. The named GRC reviewer edits and the named approver signs off; the AI accelerates the structured drafting rather than substituting for the GRC reviewer.

Audit trail in the activity log

Every vendor onboarding, cycle intake, attestation receipt, finding capture, approval decision, incident notification, and exit event lands on the activity log with timestamp and user attribution. The CSV export is the evidence trail an external assessor, a regulator, or a customer auditor reads when they ask how supplier relationships are governed.

Five reconciliation views the programme actually drives

The reports that drive vendor risk management are not the static document that lands at the end of a quarter. They are the live views the GRC team, the security director, the procurement office, and the audit committee use between cycles. The five below are the ones every meaningful programme settles on, and they all derive from the live vendor record rather than a parallel TPRM spreadsheet.

Vendor inventory by tier and residual

Vendor count and residual rating distribution broken out by tier (tier 1, tier 2, tier 3) and by data-handling scope. The view the security director reads to spot concentration risk: too many tier 1 vendors processing customer data, residual ratings drifting toward medium on critical suppliers, or an unscored vendor under contract.

Attestation freshness register

The attestations on file (SOC 2 reports, ISO 27001 certificates, pentest reports, SBOMs, sub-processor lists) with issue dates and freshness status against the documented policy. The view a named GRC owner reads quarterly so stale evidence does not surface as an audit-cycle scramble rather than as an internal correction.

Open commitments register

Committed vendor remediations from prior cycles (a planned ISO 27001 audit, a planned MFA rollout for vendor admin accounts, a planned sub-processor change disclosure) and committed buyer-side compensating controls. The register prevents the next recertification from approving the same gap twice.

Vendor incident timeline

Vendor security incidents over the past twelve months by vendor with reported date, scope of impact, remediation commitment status, and buyer-side response action. The view that surfaces vendors with a pattern of repeated incidents and feeds the next recertification with quantitative input.

Exit register

Vendor relationships that closed in the period with the trigger, the data-return or data-destruction attestation, the credential-revocation evidence, and the post-exit retention obligations. The view the regulator reads under NIS2 and DORA exit-strategy obligations and that the audit committee reads alongside operational resilience metrics.

What auditors and regulators expect from a vendor risk programme

Vendor risk evidence shows up in audit reads whenever an external assessor reviews the supplier relationship process, whenever a regulator under NIS2 or DORA reviews the supply-chain controls, or whenever a customer auditor asks how the buying organisation governs the third-parties that process its data. The frameworks below all expect documented evidence of the supplier relationship being managed against an information-security baseline. A documented vendor risk policy without an enforcement record reads as a process gap rather than as a control.

Framework	What the audit expects
ISO 27001:2022	Annex A 5.19 (information security in supplier relationships), A 5.20 (addressing information security within supplier agreements), A 5.21 (managing information security in the ICT supply chain), and A 5.22 (monitoring, review, and change management of supplier services) together expect documented evidence of supplier identification, tiering, contractual security clauses, ongoing monitoring, and change management. The vendor engagement record, the documented tier, the freshness policy, the approval ladder, the incident notification log, and the activity log audit trail satisfy the evidence expectation when an external auditor reviews supplier relationships.
SOC 2	Common Criteria CC9.2 (vendor and business partner risk assessments) and CC2.x (communication and information) expect documented assessments of vendors and ongoing communication with them. Programmes that operate the assessment as a structured engagement with calibrated findings, approval ladder, and incident notification tracking produce the operating-effectiveness evidence CC9.2 reviewers ask for. The complementary user entity controls (CUECs) declared in vendor SOC 2 reports map onto the buyer-side control library so the audit chain stays defensible.
PCI DSS	Requirement 12.8 (managing risk associated with third-party service providers) expects a written agreement, an information-security policy for service providers, documented engagement, and a process to monitor service provider compliance at least annually. The vendor engagement record, the annual recertification cycle, the freshness policy on attestations, and the activity log audit trail satisfy the evidence expectation under PCI DSS 4.0 assessment.
NIST SP 800-161 and SP 800-53	NIST SP 800-161 (Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations) and SP 800-53 SA-9 (external system services) and SR-x (supply chain risk management) controls expect a documented process for external service relationships, tiering, ongoing assessment, and incident response coordination. The vendor engagement record mapped to NIST control families and the activity log export covering the cycle provide the evidence the assessor asks for under federal contracts.
NIS2 (EU)	NIS2 Article 21 (cybersecurity risk-management measures) expects documented supply-chain security including the security of direct suppliers and the relationships with them, considering the specific vulnerabilities of each supplier. The vendor risk programme that records tiering, attestation freshness, incident notification, and committed remediations on the engagement record produces the supply-chain evidence the national competent authority expects to review.
DORA (EU)	Articles 28 to 30 of the Digital Operational Resilience Act expect a documented register of contractual arrangements with ICT third-party service providers, ongoing monitoring of the risks, contractual provisions for critical functions, and an exit strategy for each ICT service. The vendor engagement record, the tier classification, the recertification cadence, the incident notification log, and the exit engagement together satisfy the evidence the competent authority expects to review under the harmonised supervisory framework.

Where vendor risk management sits in the GRC lifecycle

Vendor risk management is the inbound GRC workflow that sits next to the outbound questionnaire response workflow, the auditor-facing compliance audit workflow, and the internal control gap remediation workflow. It composes with the rest of the GRC lifecycle on the same engagement primitive so vendor cycles stay connected to the canonical control library upstream and the leadership read downstream.

Upstream and adjacent

Vendor risk management depends on control mapping cross-framework crosswalks (the canonical control library that vendor attestations map onto), compliance audits (the assessor-facing event that reads the supplier control set), third-party penetration test report intake (the operational workflow for a single vendor pentest report), and audit evidence retention and disposal (the lifecycle that keeps the underlying attestations available with the right freshness).

Downstream and reporting

Vendor risk findings roll up into the security leadership reporting workflow where vendor coverage, attestation freshness, and incident notification volume become headline indicators on the monthly and quarterly leadership cadences. The exception management workflow holds the granted exceptions the residual rating references when a vendor is approved with conditions, the outbound questionnaire response workflow uses the same control library in reverse, and the SBOM management and VEX publishing workflow consumes inbound vendor SBOMs as part of the assessment evidence.

Pair the workflow with the long-form guides and the framework references

The programme is operational; the surrounding guides explain the enterprise risk model, the regulatory expectations, and the audit evidence stack the programme has to satisfy. Pair this workflow with the third-party vendor risk assessment enterprise guide for the broader programme framing, the DORA ICT third-party risk management implementation guide for the EU regulatory expectations, the software supply chain security guide for the SBOM and component-supply chain context, and the vendor security risk assessment template for the structured assessment artefact the programme runs each cycle against. The framework references that mandate documented supplier risk management include ISO 27001 for supplier and ICT supply chain controls, SOC 2 for vendor and business partner risk assessment criteria, PCI DSS for third-party service provider documentation, NIST SP 800-161 for cybersecurity supply chain risk management practices, DORA for the EU financial-sector ICT third-party register and exit strategy obligations, and NIS2 for supply-chain security obligations across essential and important entities.

Buyer and operator pairing

The vendor risk programme is the workflow GRC and compliance teams run as the inbound read of the supplier estate, internal security teams run alongside compliance audits and exception management, cloud security teams contribute to for cloud-provider attestations, AppSec teams contribute to for SDLC and product-security attestations, and vulnerability management teams contribute to for received vulnerability disclosures from vendors. CISOs and security operations leaders read vendor inventory by tier and residual, attestation freshness, and vendor incident timeline as the leading indicators of whether the supplier risk surface is shrinking or growing.

What good vendor risk programmes feel like

Tier matches the actual exposure

Vendor tiers are reviewed against the live integration map and updated when use cases expand. A tier-3 vendor that grows into a tier-1 production data processor gets re-tiered and the cadence, evidence requirements, and approval ladder shift with the tier change rather than staying anchored to onboarding.

Attestations stay fresh

The freshness policy is enforced at intake. Stale SOC 2 reports, lapsed ISO 27001 certificates, and aged pentest reports trigger a re-request before they reach the recommendation. The audit-cycle scramble that comes from stockpiled attestations stays in the past.

Findings stay tracked between cycles

Qualified opinions, vendor pentest findings, sub-processor changes, and incident notifications all land as structured findings on the vendor engagement with named owners and target dates. The next recertification reads the prior commitments rather than rediscovering the same gap.

Audit reads from one record

The vendor record, the engagement-per-cycle, the attestation freshness register, the approval ladder, the incident notification log, and the exit engagement all read from the live record. ISO 27001, SOC 2, PCI DSS, NIST SP 800-161, NIS2, and DORA reads resolve from one record rather than a multi-system reconciliation sprint.

Third-party vendor security risk management is the inbound GRC workflow that turns supplier diligence from a once-a-year spreadsheet into a continuous programme on the engagement record. Run it as a documented cycle so each vendor carries a tier, each cycle opens an engagement, each attestation lands against a freshness policy, each finding gets calibrated severity and a named owner, each approval runs the documented ladder, each incident notification tracks to closure, and each exit closes on a structured baseline. The companion artefact that runs alongside the programme is the vendor security risk assessment template; the reverse-direction workflow that the same team runs when the supplier role inverts is the vendor security questionnaire response workflow.

Frequently asked questions about vendor risk management programmes

What is a third-party vendor security risk management programme?

A third-party vendor security risk management programme is the continuous workflow by which a buying organisation identifies its third-party suppliers, tiers them by data and system impact, assesses each on a documented cadence, validates received attestations against a freshness policy, tracks vendor security incidents and committed remediations between cycles, routes approval through a tier-and-residual ladder, and closes exits on a documented baseline. SecPortal models the programme as a vendor record with one engagement per assessment cycle so onboarding, attestation receipt, finding capture, approval, incident notification, and exit all read against one durable record the audit lookback can reconstruct.

How is this different from the vendor security questionnaire response workflow?

The vendor security questionnaire response workflow covers the OUTBOUND direction: an internal security team responding to questionnaires sent by customers and prospects during deal cycles. The third-party vendor security risk management programme covers the INBOUND direction: the same security team assessing its own third-party suppliers as a buyer. Both run on the engagement record but the audiences, cadences, evidence requirements, and approval ladders are different. Mature programmes run both sides on the same workspace so the canonical control library stays aligned across inbound and outbound assessments rather than drifting into two disconnected spreadsheets.

How does this differ from the third-party penetration test report intake workflow?

Third-party penetration test report intake is the OPERATIONAL workflow for a specific artefact: a penetration test report from a single testing firm covering a specific scope. The vendor risk management programme is the PROGRAMME workflow that runs the assessment cycle, validates many artefacts (SOC 2 report, ISO 27001 certificate, pentest report, SBOM, sub-processor list, breach attestation), and tracks the relationship continuously between cycles. The pentest report intake workflow is one input into the broader programme; the programme reads the report alongside the other attestations and folds findings into the residual rating.

Does SecPortal integrate with TPRM platforms like OneTrust, ProcessUnity, Whistic, or Vanta?

SecPortal does not integrate synchronously with TPRM platforms. The vendor programme is owned on the SecPortal engagement record, and exchanges with TPRM platforms (uploading received attestations into a separate trust system, exporting vendor scores into a procurement system) happen through file export and manual reconciliation. Programmes that operate a separate TPRM platform reconcile the published vendor register against the SecPortal engagement record on a documented cadence rather than synchronously, which keeps the engagement record the operating source of truth and the TPRM platform the downstream view.

How does vendor tiering interact with the assessment cadence?

Tier 1 vendors (data-processing or production-access) typically run annual recertification with mid-cycle attestation freshness checks and per-event reassessment on contract change, vendor incident, or sub-processor change. Tier 2 vendors (limited-scope, internal access only) typically run annual or biennial recertification with looser freshness checks. Tier 3 vendors (low risk, no production access) typically run lighter-touch onboarding with periodic refresh rather than per-cycle reassessment. The exact cadence is programme-specific, but the discipline is recording the cadence on the engagement so the next cycle reads against the documented expectation rather than analyst judgement.

How should we handle qualified opinions in vendor SOC 2 reports?

A qualified opinion in a vendor SOC 2 report identifies a control area where the auditor found a material exception. The discipline is reading the qualified opinion into the engagement as a structured finding with the affected control area, the qualification scope, the vendor remediation commitment if any, and the buyer-side compensating control. The finding stays open on the engagement until the next SOC 2 report demonstrates the qualification has lifted or until the buying organisation accepts the residual through the approval ladder. Programmes that read qualified opinions as informational without tracking them as findings absorb the gap into analyst judgement and lose the audit chain.

How do we handle fourth-party and sub-processor risk?

Sub-processor changes received between cycles open as in-cycle findings on the vendor engagement with the disclosure date, the new sub-processor, the scope change, and the residual impact. The fourth-party (the sub-processor of your vendor) is read alongside the vendor in the residual rating because the buying organisation inherits the risk through the contractual chain. The discipline is requiring vendors to disclose sub-processor changes at the documented notification cadence and recording each disclosure as a finding rather than waiting for the next annual recertification. Vendor contracts that do not commit to sub-processor change notification surface as a contractual gap at the next renewal.

How does the activity log support vendor risk programme evidence?

The activity log captures every cycle event: vendor onboarding intake, each engagement opening, each attestation receipt, each finding capture, each approval decision with signing role and timestamp, each incident notification with response action, and each exit engagement with destruction or return attestation. Activity log exports with timestamp and user attribution cover the audit reads when an external assessor reviews supplier relationships, when a regulator under NIS2 or DORA reviews the supply-chain controls, or when a customer auditor asks how the supplier relationship is governed. The evidence trail is the same record the programme operates against.

How does the workflow interact with the wider enterprise risk register?

Vendor-level findings on individual engagements roll into the wider enterprise risk register on a documented reconciliation cadence. The vendor risk register reads residual rating, open commitments, and exception backlog by vendor; the enterprise risk register reads the risk landscape by business risk theme (data protection, operational resilience, third-party concentration, regulatory exposure). The reconciliation cadence is what keeps the two views consistent so the audit committee reads one risk picture. SecPortal carries the vendor engagement findings; the enterprise risk register can be operated alongside in SecPortal or in a separate enterprise risk system that reads SecPortal exports.

How does the programme handle vendor exits?

Vendor exit opens as a documented exit engagement on the vendor record with the trigger event (contract termination, vendor switch, vendor failure, regulator action), the data-return or data-destruction attestation with named signatory, the credential-revocation evidence with timestamp, the access-removal evidence covering both human and service accounts, the sub-processor unwind plan, and the post-exit retention obligations. The exit engagement is the durable record the audit reads to demonstrate the vendor relationship closed on a documented baseline rather than dissolved silently. Without an exit engagement, decommissioning happens off-record and the next audit cannot trace the closure to a structured event.

How it works in SecPortal

A streamlined workflow from start to finish.

Onboard each vendor as a durable record with a documented tier

Open each in-scope third-party (SaaS supplier, infrastructure provider, payment processor, data sub-processor, embedded firmware vendor, professional services firm, AI model provider) as a vendor record on the workspace. Capture the named business owner inside the buying organisation, the named security counterpart on the vendor side, the contract reference, the data-handling scope (customer PII, payment data, regulated health information, source code access, production access, none), the system-impact scope (production systems, sandbox, internal back office), and the assessment tier (tier 1 for data-processing or production-access vendors, tier 2 for limited-scope vendors, tier 3 for low-risk vendors). The tier becomes the join key for cadence, evidence requirements, and approval ladder downstream.

Open one engagement per assessment cycle on the vendor record

Every onboarding review, every annual recertification, every contract change, every reported vendor security incident, and every regulator-driven reassessment opens as a structured engagement on the vendor record with the trigger (new procurement, annual renewal, scope change, incident notification, regulator request), the requested evidence list (current SOC 2 report, ISO 27001 certificate, latest penetration test summary, SBOM, sub-processor list, breach history attestation), the assessment deadline, the named GRC reviewer, and the named approver. The engagement is the durable home of the cycle so every artefact, finding, exception, and sign-off binds to one record rather than scattering across email threads.

Receive and validate vendor attestations against a freshness policy

Vendor-provided artefacts (SOC 2 Type II report, ISO 27001 certificate, latest third-party penetration test report, SBOM, sub-processor list, data-processing addendum, security questionnaire response, breach history attestation) land as structured documents on the engagement with the issue date, the auditor or test firm name, the scope statement, the report period covered, and the next-issue commitment. The freshness policy reads the issue date against the documented cadence: SOC 2 reports older than the cycle window trigger a re-request, ISO 27001 certificates approaching surveillance window trigger an early follow-up, penetration test reports older than the documented test cadence trigger a fresh-test request. Programmes that stockpile stale attestations create audit-cycle scrambles when an external assessor reads the supplier control set.

Score control coverage and record vendor-side findings on the engagement

Read each received attestation against the canonical control library to record vendor coverage by control area (access management, data protection in transit and at rest, vulnerability management cadence, incident response time, sub-processor governance, encryption key management, logging and monitoring, business continuity, secure development lifecycle). Gaps, qualified opinions, identified exceptions in the SOC 2 report, open findings in the vendor pentest report, and disclosed sub-processor changes all become structured findings on the vendor engagement with calibrated severity, the affected control area, the named risk owner inside the buying organisation, and the requested vendor commitment. The remediation queue reads against findings rather than against PDFs.

Route the risk decision through the approval ladder

Each assessment cycle produces a residual risk rating and an approval recommendation (approve, approve with conditions, defer pending vendor remediation, reject). The approval ladder reads the recommendation against the vendor tier and the residual rating: tier 1 vendors at medium or higher residual require security director and business owner co-sign, tier 2 vendors at high residual require the same, tier 3 vendors at low residual approve by the GRC reviewer alone. The decision lands on the engagement with the signing role, the timestamp, the conditions attached (committed vendor remediation dates, scoped compensating controls inside the buying organisation, contract clause additions), and the recertification trigger date. The activity log captures every step so the next renewal reads the prior history.

Track vendor incident notifications and remediation commitments between cycles

Vendor security incidents (the vendor notifies of a breach, an identified vulnerability in their service, a sub-processor change, a key personnel departure, a regulatory enforcement action) land on the vendor engagement as in-cycle findings with the reported date, the vendor description, the scope of impact on the buying organisation, the remediation commitment, and the buyer-side response action. Committed vendor remediations from the prior cycle (a planned ISO 27001 audit, a planned MFA rollout for vendor admin accounts, a planned sub-processor change disclosure) track as findings with target dates the recertification cycle reads against. Programmes that record commitments only in renewal slides cannot demonstrate continuous monitoring; programmes that record them as engagement findings can.

Run recertification, exit, and decommissioning as documented events

Recertification opens as a new engagement linked to the previous cycle so prior commitments, open findings, evidence freshness, and tier changes are visible during drafting. Vendor exit (contract termination, vendor switch, vendor failure) opens as an exit engagement with the data-return or data-destruction attestation, the credential-revocation evidence, the access-removal evidence, the sub-processor unwind plan, and the post-exit retention obligations recorded against the engagement. The exit engagement is the durable record the audit reads to demonstrate the vendor relationship closed on a documented baseline rather than dissolved silently.

Features that power this workflow

Orchestrate every security engagement from start to finish

Document management for every security engagement

Vulnerability management software that tracks every finding

Compliance tracking without a full GRC platform

Every action recorded across the workspace

Collaborate across your entire team

Notifications and alerts for the people who carry the work

AI-powered reports in seconds, not days

Multi-factor authentication on every workspace

Run vendor risk management as a programme on the engagement record

Tier vendors, open one engagement per cycle, validate attestations against a freshness policy, record vendor findings on the engagement, route the approval ladder, and reconcile between cycles. Start free.