TL;DR: Vendor governance is not a procurement function. It is a compliance function with regulatory consequences. Every vendor onboarded, every Data Processing Agreement reviewed, every security assessment completed, every sub-processor registered, every deletion request verified – these are not internal paperwork. They are the evidence chain that regulators will audit when they examine how your organization governs its third-party relationships. In Vietnam's regulatory landscape under the PDPL, Decree 356, and the Cybersecurity Law, vendor governance generates statutory obligations with hard deadlines, mandatory filings, and evidence requirements that must be traceable end-to-end. This article explains how vendor governance actually works as an evidence-generating system, why spreadsheet-based vendor management fails under regulatory pressure, and how building third-party evidence chains as a byproduct of daily operations transforms vendor risk from a liability into demonstrable compliance.
This article is written for DPOs, compliance managers, vendor governance leads, procurement teams, legal counsel, and cybersecurity leads responsible for third-party risk management under Vietnamese regulatory frameworks where vendor decisions carry filing obligations, evidence requirements, and statutory deadlines.
The vendor question you cannot answer
Your Enterprise DPO receives a regulatory inquiry from the Ministry of Public Security. The scope: cross-border data transfers to third-party processors. The regulator wants to see the complete governance chain for three specific vendors – from initial onboarding decision through current compliance status.
The DPO contacts the vendor governance lead. The vendor governance lead contacts procurement, legal, and IT security. Each team searches their own systems. Procurement has the original onboarding approval in an email chain. Legal has the signed DPA in a shared drive. IT security has the vendor security assessment in a separate tracker. The sub-processor register is a spreadsheet maintained by the data governance team, last updated four months ago.
When the vendor governance lead tries to assemble the evidence package, the gaps become visible immediately. The DPA was signed before the latest security assessment was completed. The sub-processor list in the DPA does not match the current sub-processor register. One vendor's periodic review was due two months ago and was never triggered. The onboarding approval email references a risk score that no longer exists in the current risk tracker.
“The regulator does not ask whether you manage vendors. They ask whether you can prove how you manage vendors. The difference is the evidence chain.”
Why spreadsheet-based vendor governance breaks under regulatory pressure
Most organizations manage vendors through a combination of spreadsheets, shared drives, email approvals, and periodic review reminders set in calendars. This works adequately for internal governance. It fails catastrophically when a regulator asks for evidence.
The failure is not about missing documents. Most organizations have their DPAs, their assessment questionnaires, their approval records. The failure is structural:
- Vendor onboarding decisions exist in email chains with no formal approval record linking the decision to the risk assessment that informed it.
- DPA reviews happen in shared drives where version history shows who edited the file but not who formally approved each clause.
- Security assessments are completed in standalone trackers with no connection to the vendor record they assessed.
- Sub-processor registers are maintained separately from the vendor records they relate to, creating divergence over time.
- Periodic review schedules are calendar reminders, not system-enforced triggers – when someone is on leave, the review simply does not happen.
- Deletion verification (confirming vendors actually deleted data when asked) is tracked informally, with no proof chain demonstrating vendor acknowledgment and completion.
“Spreadsheets track vendor governance. They do not prove it. Tracking and proving are fundamentally different capabilities.”
The accountability gap across departments
Vendor governance is inherently cross-departmental. Procurement opens the relationship. Legal reviews the contract. IT security assesses the vendor's controls. The data governance team registers sub-processors. The DPO approves the compliance posture. The vendor governance lead orchestrates the process.
In a spreadsheet model, each department completes their step in their own system. There is no single record showing that all steps completed in the correct sequence, that each approval happened before the next step began, and that the people who approved had the authority to do so.
When a regulator audits the vendor governance chain, they expect to see:
→ Who initiated the onboarding and when.
→ What due diligence was performed and who completed it.
→ What security assessment was conducted and who approved the results.
→ What contractual controls were reviewed and who signed off.
→ Whether sub-processors were registered and authorized.
→ Whether the DPO reviewed and approved the overall compliance posture.
→ When the next periodic review is scheduled.
→ What evidence was preserved at each step.
Producing this chain from disconnected departmental systems requires weeks of manual reconstruction. Producing it from an integrated governance platform takes minutes.
How vendor onboarding becomes an evidence chain
The shift from vendor management to vendor evidence begins at onboarding. Every onboarding step, when captured in a structured governance system, becomes an evidence artifact with contributor lineage, timestamps, and approval records.
Here is what the vendor onboarding evidence chain looks like when built operationally:
- Case initiation: Procurement or the vendor governance lead opens a vendor onboarding case. The platform captures who initiated, when, and the business justification. This is the first link in the evidence chain.
- Service scope capture: The platform records the vendor's service description, data scope, access scope, and hosting jurisdiction. These are not free-text notes – they are structured fields that connect to the organization's data mapping and cross-border transfer registers.
- Due diligence: A formal due diligence questionnaire is completed. In Vietnam's regulatory context, this includes the PDPL/Decree 356 vendor processor due diligence form. The completed form is linked to the case, with the contributor who completed it and the timestamp recorded.
- Security assessment: IT security completes the vendor security assessment and vendor data access register. The security lead's approval is captured as a formal sign-off event – not an email, but a recorded approval with the approver's identity, role, timestamp, and the specific assessment version they approved.
- Contractual review: Legal reviews the Data Processing Agreement and the incident notification clause checklist. Legal counsel's approval is captured the same way – formal sign-off linked to the specific document version.
- Sub-processor registration: If the vendor uses sub-processors, the sub-processor register is completed or updated. The DPO reviews and approves the sub-processor chain.
- Decision gate: The platform evaluates whether onboarding can proceed, whether remediation is required, or whether the vendor's scope triggers regulatory filing requirements (such as the MPS service processing certification path under Decree 356).
- Final approval: The vendor governance lead and Enterprise DPO provide final sign-off. The vendor status is recorded, and the periodic review cadence is scheduled automatically.
Every step in this chain generates evidence. Not because someone documented it separately, but because the governance workflow itself is the documentation system. The contributor lineage – who entered data, who reviewed it, who approved it – is captured automatically through the platform's four-role audit trail: assigned, completed, reviewed, approved.
Due diligence as regulatory submission material
Vendor due diligence is not merely an internal risk exercise. Under Vietnam's PDPL and Decree 356, vendor governance artifacts can become regulatory submission material.
When a vendor qualifies as a processing service provider under Decree 356, the organization may need to apply for a service processing certificate from the Ministry of Public Security. The application requires evidence of vendor governance: the processing instruction document, the service provider governance record, the certification application form – all with official form IDs (Phụ lục IV, V, VI, VIII under Decree 356).
A GRC platform that enforces official form labeling ensures that internal governance records are clearly distinguished from official regulatory forms. The platform maintains both:
- Internal vendor governance artifacts (DPA reviews, security assessments, risk scores) – these support the organization's internal decision-making.
- Official regulatory forms (Annex 4 through Annex 8 under Decree 356) – these are formatted, labeled, and sequenced for regulatory submission.
When the regulatory filing path is triggered, the evidence chain built during onboarding directly feeds the submission package. The due diligence that was completed as an operational governance step becomes a formal exhibit in the certification dossier. No reconstruction required.
“Due diligence done operationally becomes evidence submitted regulatorily. The same work. Different audiences. One evidence chain.”
Security assessments and the approval chain that proves oversight
Vendor security assessments are a common governance step. What distinguishes an assessment from evidence is the approval chain attached to it.
A completed vendor security assessment questionnaire, stored in a shared drive, proves that someone filled in a form. A completed vendor security assessment with a recorded approval from the Cybersecurity and Legal Operations Lead (P-VN-06 in our persona framework), linked to the specific questionnaire version, with a timestamp showing the approval happened before the vendor was activated – that proves oversight.
The evidence value of security assessments depends entirely on the governance metadata surrounding them:
- Who completed the assessment (contributor identity, not just a name in a spreadsheet).
- What version of the assessment template was used.
- When the assessment was completed relative to the onboarding timeline.
- Who reviewed and approved the results (with formal sign-off, not an email "looks good").
- Whether the approval happened before or after the vendor was granted data access.
- What conditions or remediations were attached to the approval.
- When the next reassessment is scheduled.
In an integrated governance platform, this metadata is captured automatically as part of the workflow. The security lead does not need to separately document their approval – the act of approving within the workflow creates the evidence record.
Continuous risk monitoring and automated reassessment triggers
Vendor governance does not end at onboarding. The evidence chain must extend through the entire vendor lifecycle: periodic reviews, risk signal monitoring, scope changes, and eventual offboarding.
Continuous vendor risk monitoring means the platform watches for events that change a vendor's risk posture:
- Certificate expiry approaching or passed.
- Assessment questionnaire overdue.
- News alerts or adverse findings related to the vendor.
- Changes in the vendor's hosting jurisdiction or sub-processor chain.
- Contract renewal dates approaching.
When a risk signal is detected, the platform does not send an email reminder. It triggers a formal reassessment workflow: a new case is opened, tasks are assigned to the appropriate reviewers, and deadlines are enforced based on the risk signal severity.
This automated trigger-and-reassessment cycle creates a continuous evidence chain. The organization can demonstrate not just that they assessed a vendor at onboarding, but that they maintained ongoing oversight with documented reassessment decisions at every significant interval.
The risk portfolio analytics layer aggregates risk across the entire vendor population – heat maps showing risk concentration by jurisdiction, trend lines showing risk posture changes over time, and concentration analysis revealing dependency on specific vendors or sub-processors.
Vendor deletion verification: the evidence chain that closes the loop
When a vendor relationship ends – or when a data subject requests deletion that propagates to vendors – the evidence chain must extend through deletion verification.
Deletion orchestration in a vendor governance context means:
- The deletion request is routed to the vendor with a formal deadline.
- The vendor's acknowledgment is tracked (received or not received, with escalation for non-response).
- The vendor's confirmation of deletion completion is recorded.
- A per-data-subject or per-case completeness dashboard shows which vendors have confirmed deletion and which are outstanding.
- Retention conflicts are flagged (where a vendor claims legal grounds for continued retention).
- Optional cryptographic proof chain provides tamper-evident verification of deletion events.
This closes the vendor evidence chain. The organization can demonstrate, end-to-end: we onboarded this vendor with documented due diligence, maintained oversight through periodic assessments, and verified data deletion when the relationship ended or when a data subject exercised their rights.
The Cross-Border Transfer and Vendor Governance Lead assembling a vendor dossier for MPS filing
Consider the scenario: a large enterprise with Vietnam operations engages a cloud-based analytics provider headquartered in Singapore. The vendor will process personal data of Vietnamese data subjects as part of a cross-border data transfer arrangement. Under the PDPL and Decree 356, this triggers the full vendor governance workflow and may require service processing certification from the Ministry of Public Security.
The Cross-Border Transfer and Vendor Governance Lead opens a vendor onboarding case. The platform captures the vendor's service description, data scope (personal data categories to be processed), access scope (which systems and data environments the vendor will access), and hosting jurisdiction (Singapore, with secondary processing in Japan).
The workflow proceeds through structured stages:
- Procurement completes the service description and business justification.
- The data governance team completes the PDPL/Decree 356 due diligence form, documenting the processing purpose, data categories, and recipient jurisdiction assessment.
- IT security completes the vendor security assessment and vendor data access register, documenting the vendor's technical controls, encryption standards, and incident response capabilities. The Cybersecurity and Legal Operations Lead reviews and formally approves the security posture.
- Legal counsel reviews the Data Processing Agreement, verifying that it includes the required incident notification clause (72-hour notification requirement under PDPL Article 30). Legal signs off on the contractual controls.
- The sub-processor register is updated to include the vendor's own sub-processors (a CDN provider and a backup storage provider), with jurisdiction and data scope documented for each.
- The Enterprise DPO reviews the complete dossier and provides compliance approval.
At the decision gate, the platform determines that the vendor's cross-border transfer scope triggers the MPS certification path. The system automatically assembles the required official forms – the processing instruction document (Annex 6), the service provider governance record (Annex 8), and the certification application (Annex 5) – populated with data already captured during the governance workflow.
The vendor governance lead reviews the submission package. The evidence pack completeness score shows 94 out of 100 – the missing items are two supporting attachments that legal has not yet uploaded. Tasks are assigned to legal with a deadline tied to the 15-working-day supplement response window.
Once complete, the submission package is exported with correct form sequencing, official labels (Phụ lục IV through VIII), and a full audit trail showing who contributed what, who approved what, and when each step was completed.
Total time to assemble the MPS submission: minutes, not weeks. Because the evidence was built operationally, not reconstructed for the filing.
The Enterprise DPO responding to a regulatory inquiry about vendor oversight
A different scenario: the Enterprise DPO receives a regulatory inquiry asking the organization to demonstrate its vendor oversight practices. The inquiry does not target a specific vendor – it asks for the organization's overall governance posture: how many vendors process personal data, what due diligence was performed, what periodic review cadence is in place, and what evidence of ongoing oversight exists.
In a spreadsheet-based organization, this inquiry triggers weeks of work: contacting each department, requesting vendor lists, reconciling duplicates, assembling assessment records from different trackers, and manually constructing a narrative that connects the pieces.
In a platform-based organization, the DPO opens the vendor risk dashboard. The dashboard shows:
- Total vendor population with compliance status (onboarded, under review, remediation required, offboarded).
- Risk portfolio heat map showing vendor concentration by jurisdiction, data sensitivity, and risk score.
- Periodic review compliance – which vendors are current, which are overdue, which are approaching their next review date.
- Evidence pack completeness across the vendor portfolio – a consolidated view showing which vendors have complete governance chains and which have gaps.
- Recent risk signals and reassessment triggers – demonstrating that the organization responds to changes in vendor risk posture, not just to scheduled reviews.
The DPO exports the relevant evidence: the vendor register with current status, the risk portfolio summary, the periodic review schedule with completion history, and sample evidence chains for representative vendors showing the full onboarding-to-current-state governance trail.
The response to the regulator includes not just a vendor list, but proof of operational oversight: continuous monitoring, documented reassessments, formal approval chains, and completeness verification at every stage.
The audit lead producing a cross-framework vendor evidence pack
A third scenario: the Internal Audit Lead is preparing for an inspection that spans the PDPL, the Cybersecurity Law, and the Data Law. Vendor governance is in scope across all three frameworks. The regulator expects to see evidence that vendors are governed not just from a privacy perspective, but from a security and data governance perspective simultaneously.
In a siloed organization, this means requesting evidence from three separate teams: the privacy team's vendor DPA records, the security team's vendor assessment tracker, and the data governance team's sub-processor register. Reconciling these into a coherent cross-framework picture is the audit lead's problem.
In an integrated governance platform, the audit lead selects the three frameworks and the vendor governance scope. The platform pulls all relevant vendor cases, assessments, approvals, and evidence artifacts across all three frameworks simultaneously. The cross-module audit query shows:
- Which vendors have complete governance chains across all three frameworks.
- Where gaps exist – a vendor may have a signed DPA (PDPL compliance) but no security assessment (Cybersecurity Law gap) or an outdated data classification (Data Law gap).
- The contributor lineage for each governance step – who entered data, who reviewed, who approved – with timestamps proving the sequence of events.
- Audit period integrity verification – confirming that no vendor records were altered or deleted within the inspection period.
The evidence pack is assembled with framework-by-framework appendices, a consolidated gap analysis, and a complete audit trail. The audit lead presents a single, coherent picture of vendor governance across all three frameworks – because the evidence was generated from the same operational workflows, not reconstructed from separate departmental systems.
The shift: from vendor management to vendor evidence architecture
Vendor governance is undergoing the same transformation that compliance itself underwent a decade ago. The question is no longer "do we manage our vendors?" Every organization manages its vendors. The question is "can we prove how we manage our vendors, to the satisfaction of a regulator who expects end-to-end evidence chains?"
This is not a technology question. It is an architectural question. The difference between an organization that manages vendors and one that can prove its vendor governance lies in how governance steps connect to each other:
- Does the onboarding decision link to the risk assessment that informed it?
- Does the DPA review link to the security assessment that preceded it?
- Does the approval record show who approved, when, and what specific version they approved?
- Does the periodic review schedule enforce itself, or depend on someone remembering?
- Does the deletion verification prove the vendor actually deleted the data, or just that someone asked them to?
When every governance step generates evidence as a byproduct of daily operations – not as a separate documentation exercise – the vendor evidence chain builds itself. The organization does not reconstruct evidence when a regulator asks. It exports what already exists.
“Vendor governance is not what you do to vendors. It is the evidence trail you produce while doing it.”
Closing
Third-party evidence chains are not a premium capability for organizations with large compliance teams. They are an operational necessity for any organization that processes personal data through vendors – which, in practice, means every organization.
The evidence chain starts at onboarding and extends through the entire vendor lifecycle: due diligence, security assessments, contractual reviews, sub-processor registration, periodic reviews, risk monitoring, scope changes, and deletion verification. Each step either produces traceable evidence or it does not. There is no middle ground.
Building these evidence chains operationally – as a byproduct of governance workflows rather than as a separate documentation project – is what transforms vendor risk from a compliance liability into demonstrable governance.
To explore how vendor evidence chains work in practice, visit AesirX ComplianceOne: https://aesirx.io/compliance-one
Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO @ AesirX.io
Frequently Asked Questions
Laws referenced in this article:
- Vietnam Personal Data Protection Law 2025 (PDPL)
- Decree 356/2025 on Cross-Border Data Transfers and Processor Governance
- Vietnam Cybersecurity Law 2025
Disclaimer: This article provides operational guidance based on publicly available regulatory texts. It does not constitute legal advice. Organizations should consult qualified legal counsel for jurisdiction-specific compliance requirements.
