How to conduct a vendor risk assessment for ICT services

An ICT supplier can influence an organisation’s systems, data, operations, and public reputation long after a contract has been signed. Cloud hosting providers, software vendors, managed service companies, telecommunications operators, consultants, and support partners may all receive privileged access or become essential to service delivery.

A vendor risk assessment provides a repeatable way to understand that exposure before procurement decisions are finalised. It combines due diligence, cybersecurity review, privacy analysis, business continuity planning, and contract management. The purpose is not to eliminate every risk, since that is rarely practical, but to identify material threats and decide how they will be controlled.

The process is especially important in digital government and enterprise environments, where one supplier may support several departments or connect to shared platforms. A structured assessment helps decision-makers compare suppliers consistently, document exceptions, and maintain accountability throughout the vendor relationship.

Define the service and its risk boundary

Begin by describing exactly what the supplier will provide. A vague service description makes it difficult to determine which controls are relevant. Record the applications, infrastructure, interfaces, locations, data types, user groups, support arrangements, and subcontractors connected with the service.

The assessment should identify whether the vendor will access personal information, financial records, confidential policy material, authentication systems, source code, or operational technology. Consider access methods as well. A supplier with continuous administrative access presents a different risk profile from one that receives limited, supervised access during scheduled maintenance.

Classify the service according to business importance. A public website, internal collaboration tool, payroll system, and emergency communications platform should not be reviewed using identical assumptions. Criticality can be based on availability requirements, legal obligations, financial impact, public trust, safety considerations, and the time the organisation can operate without the service.

Useful scoping questions include:

• What business process would stop if the service became unavailable?
• Which information would the provider store, process, or transmit?
• Can the supplier access production environments?
• Does the service depend on fourth parties or overseas infrastructure?
• What would happen if the contract ended unexpectedly?

Set assessment criteria before reviewing evidence

A consistent vendor evaluation starts with defined risk criteria. Establish minimum requirements before examining a preferred supplier so that commercial urgency does not quietly weaken the review. The criteria may cover information security, privacy, resilience, legal compliance, service quality, financial stability, and ethical conduct.

Security evidence can include independent audit reports, penetration-test summaries, vulnerability-management procedures, identity and access controls, encryption standards, security policies, incident records, and staff awareness arrangements. Ask for enough evidence to validate important claims, while respecting confidentiality and avoiding unnecessary collection of sensitive documents.

Standards and certifications can support a review, but they should not replace judgement. A certification may cover only a particular site, service, or period. Confirm its scope, expiry date, exclusions, and relationship to the contracted service. Likewise, a policy document may describe an intention rather than demonstrate consistent operation.

The organisation should also define risk tolerance. For example, a supplier handling low-sensitivity information may be accepted with ordinary security controls, while a provider connected to a government identity platform may require stronger assurance, formal testing, rapid incident notification, and approved subcontractors. Risk acceptance should belong to an authorised business owner rather than being left to the procurement team alone.

Collect evidence and test the supplier’s claims

Send the vendor a tailored questionnaire rather than a generic form containing irrelevant questions. Organise it into domains such as governance, access management, infrastructure security, software development, data protection, resilience, incident response, subcontracting, and regulatory compliance. Request explanations for “not applicable” responses instead of treating them as automatically acceptable.

Evidence should be rated for quality. An independently verified report usually carries more weight than a marketing statement. A recent penetration-test executive summary is more useful than an undated claim that testing occurs regularly. Interviews and demonstrations can clarify how controls work in practice, while contract language is needed to make important commitments enforceable.

Pay close attention to gaps between the supplier’s standard service and the organisation’s actual requirements. A cloud provider may offer encryption, for example, but the customer may still be responsible for key management, access configuration, retention settings, or logging. This shared-responsibility boundary should be documented in plain language and assigned to named parties.

Training and capability are also relevant. If a supplier’s personnel administer ICT systems, assess their qualifications, privileged-access procedures, and ongoing awareness activities. Organisations building wider digital-governance capability may also consult YTS learning resources as part of a broader professional development context, while keeping the supplier’s own competence evidence separate from general learning material.

Use a consistent scoring model

A scoring model makes different vendors easier to compare and helps explain why a decision was reached. It should combine the inherent risk of the service with the strength of the supplier’s controls. Avoid a system that produces a precise-looking number without showing the assumptions behind it.

Assessment area	Evidence to examine	Warning signs	Possible treatment
Data protection	Data map, privacy terms, retention rules, breach process	Unclear processing locations or indefinite retention	Restrict data, add contractual limits, require deletion proof
Cybersecurity	Audit reports, access controls, testing, monitoring	Shared accounts, weak MFA, overdue remediation	Mandate corrective actions and privileged-access controls
Resilience	Recovery objectives, test results, continuity plans	No recent recovery exercise or single point of failure	Require tested recovery targets and exit planning
Subcontracting	Supplier register, approval process, flow-down terms	Unapproved fourth parties or opaque hosting chain	Require notification, approval, and equivalent controls
Service performance	SLA history, support model, escalation process	Vague targets or slow incident communication	Define measurable service levels and remedies
Financial and operational viability	Accounts, ownership, staffing, dependency analysis	High concentration or unstable operating model	Use safeguards, transition plans, or alternate suppliers

One practical approach is to score likelihood and impact separately, then record the resulting inherent risk. Next, assess control effectiveness and calculate residual risk using a simple scale such as low, moderate, high, or critical. The calculation should be supported by written reasoning. A high-impact service should not receive a low residual rating merely because the vendor has supplied several certificates.

Record assumptions, evidence dates, open issues, responsible owners, and target completion dates. If the supplier cannot provide requested evidence, treat that absence as a risk signal rather than silently awarding a favourable score. Exceptions should state what is being accepted, why it is necessary, how long it will remain valid, and who approved it.

Convert findings into contract controls

The assessment has practical value only when its findings influence the agreement. High-priority requirements should be included in the contract, statement of work, service-level agreement, security schedule, or data-processing terms. This prevents important promises from remaining informal and difficult to enforce.

Contract controls may address encryption, identity verification, logging, vulnerability remediation, incident notification, audit rights, data residency, retention, access termination, subcontractor approval, and secure disposal. Specify measurable timeframes wherever possible. “Notify the customer promptly” is weaker than a requirement to notify within a defined number of hours after confirming a security incident.

Business continuity deserves special attention. Establish recovery time and recovery point objectives, backup responsibilities, testing frequency, communication arrangements, and alternative operating procedures. A vendor that performs well during normal operations may still create severe disruption if it cannot restore systems or provide usable data after an outage.

Include an exit strategy before the service begins. Define data export formats, assistance during transition, notice periods, destruction certificates, credential revocation, and continued support during migration. Vendor lock-in is a technology risk and a commercial risk, especially when proprietary interfaces or undocumented configurations make replacement difficult.

Monitor the relationship after approval

Vendor due diligence is a continuing activity, not a one-time procurement form. Risk can change when the provider is acquired, moves processing to a new region, introduces a subcontractor, changes its software architecture, or suffers a security incident. Establish review intervals based on service criticality, with more frequent monitoring for suppliers that hold sensitive data or privileged access.

Track performance indicators such as service availability, unresolved vulnerabilities, incident response times, audit findings, access-review completion, recovery-test results, and overdue corrective actions. Assign an internal relationship owner who can coordinate procurement, ICT operations, cybersecurity, privacy, legal, and business teams.

External signals can also inform monitoring. A supplier’s public-facing environment, including sites that publish unrelated material such as lotto results, may reveal branding, technology, contact, or content-management practices that deserve review when they form part of the organisation’s digital footprint. This does not prove a security weakness, but it reinforces the value of asset discovery and clear ownership across web properties.

Reassess the vendor after major changes and before contract renewal. If the relationship involves digital-governance training or platform-specific capability, publicly available background material such as the e-Pragati Academy certification process may help staff understand related learning pathways. Such material should be treated as unofficial reference information and should not substitute for formal organisational policy or supplier evidence.

Apply these practical safeguards

A risk assessment becomes easier to maintain when teams use a small set of disciplined practices from the beginning:

• Assign a business owner who remains accountable for the vendor’s risk after procurement.
• Match assessment depth to data sensitivity, access privileges, service criticality, and dependency.
• Verify claims with dated, relevant evidence instead of relying on certifications alone.
• Turn serious findings into contractual obligations with owners, deadlines, and remedies.
• Review suppliers after incidents, major changes, acquisitions, renewals, and material control failures.

Keep the assessment record in a controlled repository with version history and access restrictions. It should show the original decision, subsequent changes, accepted exceptions, and evidence of follow-up. This creates an audit trail and reduces the chance that organisational knowledge disappears when staff or suppliers change.

Build the assessment into governance

Vendor risk management works best when it is integrated into procurement, architecture review, project delivery, information security, privacy management, and business continuity processes. Procurement can trigger the initial review, while ICT and security specialists validate technical controls. Legal and privacy teams can address obligations that technical questionnaires may overlook.

Use approval gates for different risk levels. A low-risk software subscription may need a lightweight review, whereas a critical managed service may require executive approval, independent assurance, architecture review, and a tested exit plan. Escalation rules should be clear enough that staff know when a supplier cannot be approved through ordinary delegated authority.

The final decision should explain why the vendor is acceptable, what conditions apply, and what residual risks remain. It may be appropriate to proceed with a supplier while corrective actions are completed, provided those actions are time-bound and formally accepted. A documented decision is stronger than an informal assumption that risk has been “covered” by the contract.

Start with the suppliers that have the greatest operational reach and the most sensitive access. Create a baseline assessment, close the most important gaps, and then establish a regular review cycle. Taking these steps turns vendor assurance from a compliance exercise into a working part of ICT governance. Begin the review with your next critical supplier, document every material assumption, and make the resulting controls visible to the people responsible for operating the service.