Cyber SecurityReviewed 28 October 2026

How Do We Assess the Security Risks of Third-Party IT Suppliers?

Assess IT supplier risks through service mapping, access reviews, proportionate evidence, contract requirements and ongoing assurance.

Written byCaleb AdohGrowth Marketing Manager, NetMonkeys

What is the quick answer?

Assess an IT supplier by understanding the service it delivers, the access and information it receives, the impact of failure and the controls that reduce those risks. Use proportionate due diligence, verify important evidence, agree responsibilities in the contract and review the relationship as it changes. Certifications are useful evidence inputs, not a substitute for assessing your actual dependency.

Why is an IT supplier risk assessment different from a purchasing check?

An IT supplier can influence far more than the cost of a service. It may administer user accounts, hold business information, connect to core systems or provide a platform that staff cannot work without. A security assessment examines those dependencies and asks what could happen if the supplier makes a mistake, is compromised or cannot continue delivering.

Start with the business outcome. Identify the work the supplier supports and the consequences if that work stops or becomes unreliable. The same supplier may be low risk for one service and critical for another. A public marketing website and an administrator account for your finance environment should not automatically receive the same assessment because the supplier's name is identical.

Keep purchasing, security and service delivery involved from the outset. Commercial colleagues need to understand unresolved risks before agreeing terms, while technical staff need an accurate description of the planned service. Our cybersecurity audit services can provide a structured starting point for reviewing the controls surrounding an important supplier relationship.

↑ Back to contents

What information should we collect before sending a questionnaire?

Create a service record containing the supplier's legal name, business owner, technical contact, contract dates, service description and main dependencies. Record which systems it can reach, the information it handles and the people who approved the arrangement. Include subcontractors where they influence your service, rather than assuming the immediate supplier performs every activity itself.

Map the practical journey of information and access. Does a support engineer sign in remotely? Does a cloud platform receive customer records automatically? Can the supplier export data, alter permissions or disable a service? Use a short diagram or written description internally if it helps clarify the relationship, but keep the assessment anchored to actual activities.

This discovery often exposes gaps before formal due diligence begins. A department may have bought software without identifying an owner, or a former contractor may retain credentials after a project ended. Resolve those basic uncertainties first. An unanswered question about what a supplier can access is itself a reason to investigate, even before considering the supplier's security documentation.

↑ Back to contents

How should we rank suppliers by risk?

Use a small number of meaningful factors: service criticality, access privilege, information sensitivity, concentration of dependency and difficulty of replacement. Describe the consequences for your business rather than relying on an unexplained numerical score. A ranking should help decide the depth of review and the people who need to approve the relationship.

For example, a supplier with no system access and only public information may justify a light check. A supplier that manages privileged accounts or runs an essential application warrants closer scrutiny. Consider combinations: a modest tool can become important if every team relies on it for a time-sensitive process and there is no workable alternative.

Document why the rating was chosen and the assumptions behind it. Avoid designing a complex scoring model that creates precision without better decisions. The NCSC guidance on understanding supply chain risks emphasises knowing what needs protection, who is involved and the risks created by the relationship. Use that context to keep your assessment proportionate.

↑ Back to contents

Which security questions reveal the most useful information?

Ask how responsibility works in practice. Who owns security at the supplier? Who approves customer access? How are changes authorised, supported systems maintained and incidents escalated? Ask for an explanation of the processes that matter to your service rather than requesting every policy in the organisation. A focused follow-up often reveals more than a completed generic questionnaire.

Use scenarios to test vague answers. If a supplier says access is restricted, ask how an engineer receives access to your environment and how it ends. If it says backups are maintained, ask what service is restored, who authorises recovery and what test evidence is available. The aim is to understand operational capability, not to catch someone out with terminology.

The NCSC supplier assurance questions provide an official reference for areas to explore, including responsibility and governance. Tailor your discussion to the actual arrangement. Record where an answer is unsupported, where more evidence is needed and where a control relies on something your own organisation must do.

↑ Back to contents

How do we assess privileged and remote access?

List the access routes the supplier needs and the minimum actions required for its work. Separate routine user access from administrative capability. Ask whether access is named, approved, time limited where appropriate and attributable to an individual. Shared credentials make it harder to understand who acted and to remove one person's access without affecting others.

Check the joining and leaving process for supplier staff. Your business should know how changes in personnel affect its environment and who can revoke access urgently. Review emergency access separately so that an urgent support need does not become a permanent exception. Include remote support tools and service accounts, which can be missed when a review focuses only on visible user accounts.

Coordinate these controls with your own Microsoft 365 administration where relevant. Ask who owns the tenant, how delegated permissions are recorded and how access is reviewed. Do not assume that a familiar support relationship removes the need for accountability. Long-standing suppliers should be able to explain the access they retain and why it remains necessary.

↑ Back to contents

What evidence should we ask a critical supplier to provide?

Choose evidence that addresses the main failure scenarios. A current certificate may support part of the assessment, while an incident process summary, recovery test result or recent independent assessment may address other concerns. Confirm which entity and service the evidence covers and when the relevant work was completed. Read scope and exclusions before treating a document as reassuring.

Ask how important findings were handled. The presence of a test report does not tell you whether significant issues remain open. A supplier may appropriately share a summary rather than a sensitive full report. Agree what you need to see to reach a decision, and protect the material you receive using a controlled review process.

Our Cyber Essentials support can help frame baseline control discussions, but avoid treating a badge as the entire risk assessment. Your dependency may include business continuity, data portability or privileged support access that needs additional consideration. Write down what each item of evidence demonstrates and, just as importantly, the questions it leaves unanswered.

↑ Back to contents

How should we review a supplier that handles personal information?

Establish what personal information is involved, why it is used and the parties' roles in that processing. Involve the people responsible for privacy and contracts. The security assessment should support their decision, not replace the wider review of lawful processing, retention, individual rights and international transfers where relevant.

Check the practical controls around the information. Identify who can access it, where copies are created, how support staff view it and what happens when the service ends. Ask whether test and development environments contain real customer information. Consider whether the supplier needs the entire dataset or whether a reduced or anonymised example would support the task.

Keep the answer linked to your actual service configuration. A supplier's general privacy statement may not describe a specific integration, support option or subcontractor arrangement. If the relationship changes, reassess it. Avoid accepting an answer once and then allowing new categories of information or new access methods to appear without the same scrutiny that applied to the original purchase.

↑ Back to contents

How do we evaluate cloud and software supplier responsibilities?

Describe what the supplier operates and what your team must configure or maintain. A platform can provide security features while leaving important choices to the customer. Identify responsibility for identity, permissions, endpoint devices, application settings, backups, monitoring and incident coordination. The exact split depends on the service and contract, so avoid assumptions based on the word cloud alone.

Ask the supplier to explain the boundaries using your planned use case. If data is deleted accidentally, who can restore it and from which point? If an employee account is compromised, who investigates the application activity? If a service stops, how will your business receive updates? These questions expose gaps that a feature list may not reveal.

Where you use managed cloud services, create a responsibility record covering the cloud platform, the managed provider and your own staff. Test that record against a realistic incident or change. Any action that has no owner should be resolved before the service becomes a critical dependency, with the agreed arrangement reflected in operational documents.

↑ Back to contents

What should we establish about incident response and communication?

Agree how each party raises a concern and who receives it outside normal working arrangements where required. Specify the information needed for an initial notification and how updates will be coordinated. Check that emergency contacts are maintained somewhere accessible even if the main service or usual email account is unavailable.

Avoid negotiating a notification promise without understanding how events are detected and classified. A supplier may discover a technical issue before it knows whether your information is affected. Your contract and incident plan should support useful early communication while allowing facts to be confirmed. Involve appropriate advisers when defining legal or contractual notice obligations, rather than copying a single time limit from another agreement.

Connect supplier escalation to your internal process. A message received by procurement needs a route to the people who can assess business impact and authorise action. Our managed security services can support the technical response discussion, while business leaders decide customer communication and operational priorities. Where a supplier uses remote IT support, confirm how emergency sessions are authorised and how the access can be ended. Confirm those handoffs before an urgent event tests them.

↑ Back to contents

How should security requirements appear in the contract?

Translate important assessment outcomes into clear commitments. State the service boundary, responsibilities, required evidence, access conditions and escalation arrangements in language that both parties can operate. Identify how changes are approved and what happens if a material requirement cannot be met. A questionnaire response may inform negotiation, but it should not be the only record of an important commitment.

Review vague wording carefully. Terms such as industry standard security or immediate response may sound reassuring while leaving different expectations on each side. Ask what action is required, who performs it and how completion will be demonstrated. Obtain suitable contractual advice for obligations that create legal or financial exposure.

Build in a workable review route. Your business may need to ask further questions after a service change or an incident, but a broad demand for unrestricted audit access may be impractical for a shared cloud environment. Agree proportionate alternatives where appropriate. The objective is dependable assurance and a usable remedy, supported by terms that reflect the service being purchased.

↑ Back to contents

How do integrations and subcontractors change the assessment?

An integration can create a new route into systems even when the individual applications have already been reviewed. Identify the information transferred, permissions granted, authentication method and people able to change the connection. Ask what happens when a connection fails, repeats a transaction or sends information to the wrong destination.

Map important subcontractors and the tasks they perform. Focus on those that affect your information or the service you depend on. Ask how the immediate supplier selects and oversees them, how changes are communicated and whether commitments flow through the chain. You may not need a separate full review of every remote dependency, but you do need enough visibility to understand material risk.

Use system integration expertise to connect technical design with supplier oversight. Record ownership of credentials, interfaces and error handling so that accountability survives personnel changes. Review the arrangement again when a new data feed or subcontractor is introduced; an earlier approval should not silently cover every future extension of the service.

↑ Back to contents

How do we judge resilience and the ability to exit?

Ask what your business would do if the supplier were unavailable for a day, several days or permanently. These are planning scenarios rather than predictions. Identify the work that can pause, the work that needs a manual alternative and the information required to resume elsewhere. The assessment should reveal your own preparation as well as the supplier's capability.

Check data export, administrative ownership, documentation and transition assistance. A technically available export may be difficult to use without structure, history or integration details. Test a sample before relying on it for an urgent exit. Understand which costs and responsibilities apply when the relationship ends and who confirms that access and retained information have been handled appropriately.

For infrastructure dependencies, infrastructure management support can help document systems and recovery requirements. Avoid placing all essential knowledge with one supplier or one employee. The business should retain enough ownership and accessible records to make informed decisions, even when specialist operational work is outsourced.

↑ Back to contents

What do we do when a supplier has an unresolved weakness?

Describe the weakness as a business risk with a realistic scenario. Explain the affected service, the likely consequence and the controls already in place. Ask whether the gap can be corrected before access is granted, whether the service can be limited or whether a temporary workaround reduces exposure. Avoid reducing the decision to a red or green label without context.

Create an action record with an accountable supplier contact, your internal owner, a completion date and acceptable evidence of closure. If the business decides to proceed before closure, record who approved the risk, why the decision was made and when it must be reviewed. An exception without an expiry can quietly become the normal arrangement.

Some gaps justify choosing another supplier or changing the proposed service. Others may be manageable through a phased rollout or restricted access. Make that decision deliberately. Security reviewers should explain the risk and options clearly enough for the accountable business owner to decide, rather than assuming that procurement or an external IT provider has automatically accepted it.

↑ Back to contents

How often should we reassess IT suppliers?

Set a review rhythm based on importance, but use events as triggers too. A new service, acquisition, significant incident, contract renewal, changed access or different subcontractor may justify reassessment before the calendar review. A supplier that was once low risk can become critical as departments adopt it more widely.

Keep the review focused on changes and evidence that has become stale. Confirm current owners, access, information flows, service dependencies and unresolved actions. Ask whether your assumptions about recovery or replacement remain realistic. Document the outcome even if the decision is that no material change is needed, so the next reviewer understands what was considered.

Your managed IT support arrangements can contribute current technical information, such as access records and application inventories. Procurement and business owners still need to maintain the relationship record and approve material changes. Treat supplier assurance as a shared management activity rather than a questionnaire that disappears into a folder after the contract is signed.

↑ Back to contents

What should our first supplier risk review deliver?

Choose one important IT supplier and produce a short, usable decision record. Describe the service and dependencies, identify the main failure scenarios, list the evidence reviewed and state the remaining gaps. Assign actions and record who approved the relationship. The result should be understandable to a manager who did not attend the technical discussions.

Test the record against a simple question: if this supplier were compromised tomorrow, would you know what it can access, who to contact and what your business would do next? If the answer is no, prioritise those missing elements. Do not delay basic improvements while designing a perfect organisation-wide scoring system.

Finally, schedule the next review and link actions to contract and service management. If you need help turning scattered supplier information into a practical assessment, contact NetMonkeys with the service description and the concerns you want to resolve. A focused review should produce clearer decisions and responsibilities, rather than simply a larger collection of supplier documents.

↑ Back to contents

What else do businesses ask?

Is a supplier certificate enough to approve it?

No. Check the scope and relevance, then assess your actual dependency, access, data handling and recovery needs. Certification can support part of the evidence but does not answer every risk question.

Should every supplier receive the same questionnaire?

No. Match the depth of review to the access, information, criticality and consequences involved. Record why a lighter or deeper assessment is appropriate.

Who accepts an unresolved supplier risk?

A named business owner with appropriate authority should make and record the decision, supported by security, technical and contractual advice. Define interim controls and a review date.

Who wrote this guide, and how was it checked?

Written by Caleb Adoh, Growth Marketing Manager at NetMonkeys. Official NCSC supply chain principles and supplier assurance questions were checked on 28 October 2026. The assessment workflow and scenarios are original editorial guidance. Personal data, sector and contract obligations require a separate review of the relevant circumstances.

How can NetMonkeys help your business?

Talk to our team about your priorities and agree a practical next step.

Speak to NetMonkeys