Here, third-party risk is scored, not recommended
The ECC has a third-party and cloud domain. The SAMA CSF scores third-party cyber security as a maturity domain. The CST framework covers supplier security. And under the PDPL your processors are your responsibility. In most markets vendor risk is good practice — in the Kingdom it is assessed.
Why this is not optional in Saudi Arabia
From the compliance programmes we build and run in Saudi Arabia: every major framework here treats third-party risk as a requirement rather than a maturity nicety. You are not asked whether you assess suppliers — you are asked to show the assessments, the criteria, and what happened to the findings.
| Framework | How it treats third parties | What that means |
|---|---|---|
| NCA ECC | A third-party and cloud computing domain | Supplier assessment is part of your ECC position, not adjacent to it |
| SAMA CSF | Third Party Cyber Security as a scored domain | Your vendor programme carries a maturity level of its own |
| CST CRF | Supplier security among the control domains | Applied at your assigned compliance level |
| Saudi PDPL | Processor and sub-processor obligations | You remain the controller; your processor's failure is your exposure |
| ISO 27001 | Supplier relationship controls in Annex A | Examined during certification and surveillance |
Note what all five have in common: they ask about your programme, not your vendors. An assessor is examining whether you have a defensible method — criteria, tiering, evidence, follow-up — rather than whether a particular supplier is good.
The questionnaire nobody reads
Worth naming, because it is the most common form of vendor risk management and it provides almost no assurance.
A vendor is sent a questionnaire. They complete it, mostly accurately, mostly from a previous submission. It arrives, is saved to a folder, and is referenced once if procurement asks. Nobody reads the answers against a standard. Nothing is followed up. The vendor is never reassessed, and three years later the file still describes a company that has since changed hosting provider, been acquired, and lost the person who filled it in.
This is not a failure of effort. It is what happens when the questionnaire is the deliverable rather than the input — and it is exactly what an assessor identifies when they ask what you did with the answers.
Assessments that are filed, not read
A completed questionnaire is evidence that you asked. It is not evidence that you assessed, and it is not assurance. An assessor distinguishes between these immediately.
No criteria to read it against
Without defined thresholds — what answer is acceptable, what triggers escalation, what blocks onboarding — reading the response carefully changes nothing, so nobody does.
Findings, owners and dates
An inadequate answer becomes a finding with an owner and a date, exactly like an internal audit finding. That is the difference between a questionnaire and an assessment.
The relationship, not the onboarding
Most vendor programmes assess thoroughly at the start and never again. The risk does not behave that way.
What will this vendor access, host or process. The answer determines how much assessment is warranted, and answering it before the questionnaire is sent saves everyone the wrong questions.
Depth matched to what the vendor touches. A supplier with access to production personal data and a supplier providing office furniture do not warrant the same process, and treating them alike is why the process gets ignored.
The only moment you have real leverage. Security requirements, processing terms, notification obligations and audit rights go in here or they do not go in at all.
What the vendor was actually given, recorded — because at offboarding somebody will need to know, and the person who granted it will have moved on.
Reassessment on a cycle proportionate to risk, plus reassessment on change — acquisition, new sub-processor, incident, change of hosting. Most registers record the first assessment and nothing after it.
Access revoked, data returned or destroyed, confirmation obtained. The step nobody owns, and the one that leaves a former supplier holding your data and a live credential.
The last row deserves attention. In our experience offboarding is the weakest phase in almost every vendor programme, because the commercial relationship ends and the compliance obligations quietly do not.
You are on both sides of this
The same questionnaire flows in both directions, and most organisations here handle the two halves in completely separate ways.
You review your suppliers
Scoping, tiering, assessment, findings and reassessment — a programme your own regulator examines as part of the ECC, the SAMA CSF or the CST framework.
Your customers review you
The same questions arriving from the other direction, answered from the controls and evidence you already maintain. Trust center →
The useful realisation is that both halves draw on the same underlying records. The evidence proving a control operates is what you send to a customer assessing you, and the criteria you apply to your own vendors are the criteria being applied to you. Organisations that run these as two disconnected processes do the work twice and answer inconsistently.
Vendor risk in Govrly
A register that shows the relationship as it is now, rather than as it was at onboarding.
Who they are and what they touch
Each third party recorded with what it accesses, hosts or processes, the services it provides, and its contacts. The scoping answer that determines everything downstream, held where it can be checked.
Scrutiny proportionate to exposure
Vendors classified by what they touch rather than by contract value. A small supplier with access to personal data warrants more than a large one that does not.
Answers read against criteria
Responses assessed against defined thresholds, with inadequate answers becoming findings that carry an owner and a date — rather than a file saved to a folder.
Your vendor's vendors
Sub-processors recorded, because under the PDPL your processor's processor is still your exposure. This is the layer most registers stop short of, and the one a privacy assessment asks about.
On a cycle, and on change
Review dates by tier, plus triggers on acquisition, incident, new sub-processor or change of hosting. The relationship is reassessed because something happened, not only because a year passed.
One programme, four requirements
Your vendor programme evidences the ECC third-party domain, the SAMA CSF domain, the CST supplier controls and the PDPL processor obligations from the same records.
What a vendor list hides
Three patterns that a register shows and a spreadsheet of names does not.
Many vendors, one dependency
A list of forty suppliers can be four failure domains, because most of them run on the same handful of underlying providers. That concentration is invisible until you record what each vendor depends on.
Where it actually goes
A vendor operating outside the Kingdom, or hosting with someone who does, makes the relationship a cross-border transfer question under the PDPL — with its own conditions and its own assessment.
The credential nobody revoked
Vendor accounts outlive vendor relationships more reliably than any other access type, because offboarding sits between procurement, IT and the business, and belongs to none of them.
Small contract, large dependency
Commercial value is a poor proxy for risk. The supplier whose outage stops your service is not necessarily the one with the biggest invoice.
The ones procurement never saw
Tools adopted by a team on a card, holding company data, outside any assessment. Every vendor register discovery exercise finds these, and they are usually the ones with the most access.
A new category of processor
An AI tool processing company data is a processor with the same obligations as any other, and frequently the one nobody assessed because it arrived as a feature rather than a purchase.
Building a programme an assessor will accept
The order matters, and the first step is the one most programmes skip.
- Find the vendors you already haveIncluding the ones procurement never saw. This exercise is uncomfortable and it is the only honest starting point — you cannot assess a population you have not established.
- Record what each one touchesAccess, hosting, processing, personal data. This is the scoping answer that determines tier, depth and reassessment frequency, and it is more useful than any questionnaire response.
- Define your tiers and your criteriaWhat warrants deep assessment, what warrants light, and what answer is unacceptable. Without criteria, reading the responses changes nothing.
- Assess the top tier properly, and the rest proportionatelyA programme that assesses everyone equally assesses nobody well, and exhausts the goodwill you need from procurement.
- Turn inadequate answers into findingsWith an owner and a date, tracked like any other finding. This is the step that converts a questionnaire exercise into an assessment programme.
- Put the requirements into contractsWork with procurement so security and processing terms are standard rather than negotiated per deal. Contracting is the only point of real leverage you have.
- Record sub-processorsYour processor's processors. Under the PDPL this chain is your exposure, and it is the question a privacy assessment reaches faster than most teams expect.
- Fix offboarding before anything elseAccess revoked, data returned or destroyed, confirmed. It is the weakest phase in almost every programme and the cheapest one to repair.
Each third party recorded with what it touches, tiered by exposure rather than contract value, assessed against defined criteria with inadequate answers becoming findings — and the whole programme evidencing the ECC third-party domain, the SAMA CSF domain and your PDPL processor obligations from the same records.
See it in a demo →Vendor and third-party risk — FAQs
Is third-party risk assessment mandatory in Saudi Arabia?
In effect, yes. The NCA ECC includes a third-party and cloud computing domain, the SAMA CSF scores third-party cyber security as a maturity domain, the CST framework covers supplier security, and the PDPL makes your processors your responsibility. You are not asked whether you assess suppliers — you are asked to show the assessments and what happened to the findings.
How is this different from the risk and audit page?
Risk and audit covers your own risks and your own audit findings. This covers risk arriving from outside your organisation through suppliers, processors and service providers. They share the underlying model — findings, owners, verified closure — but the population and the assessment method differ.
Does a completed questionnaire count as an assessment?
No. A completed questionnaire is evidence that you asked. An assessment means the answers were read against defined criteria and inadequate responses became findings with owners and dates. An assessor distinguishes between these immediately, and the distinction is usually where vendor programmes are weakest.
Do we need to assess every vendor equally?
No, and doing so is counterproductive. Scrutiny should be proportionate to what the vendor accesses, hosts or processes rather than to contract value. A programme that assesses everyone equally assesses nobody well and exhausts the cooperation you need from procurement.
What about our vendors' vendors?
Under the PDPL you remain the controller, so your processor's processors are still your exposure. Recording the sub-processor chain is the layer most vendor registers stop short of, and it is a question privacy assessments reach faster than teams expect — particularly where a vendor hosts with a provider operating outside the Kingdom.
How often should vendors be reassessed?
On a cycle proportionate to tier, and on change. The cycle catches drift; the triggers catch what matters — acquisition, incident, a new sub-processor, a change of hosting provider. A programme that only reassesses annually misses the events that actually changed the risk.
Where do most vendor programmes fail?
Offboarding. Access revoked, data returned or destroyed, confirmation obtained — the step that sits between procurement, IT and the business and belongs to none of them. Vendor accounts outlive vendor relationships more reliably than any other access type, and it is the cheapest weakness to repair.
We are also assessed by our customers. Is that the same thing?
It is the same conversation from the other side, and both halves draw on the same records. The evidence proving a control operates is what you send to a customer assessing you, and the criteria you apply to your vendors are being applied to you. Running them as disconnected processes means doing the work twice and answering inconsistently.
What about AI tools our teams have adopted?
An AI service processing company data is a processor with the same obligations as any other, and frequently one nobody assessed because it arrived as a feature rather than a purchase. These surface during a vendor discovery exercise alongside other tools bought on a card, and they usually have more access than expected.
Does this evidence more than one framework?
Yes, and that is the practical argument for running it properly once. The same vendor programme evidences the ECC third-party domain, the SAMA CSF third-party domain, the CST supplier controls and the PDPL processor obligations — from the same register, with each framework scored in its own terms.
Start by finding the vendors you did not know about
Every discovery exercise finds tools nobody assessed. They are usually the ones with the most access.