Procurement and Security in the Public Sector: Who Does What Before, at and After Contract Award

Most public bodies don’t have a supplier security problem so much as a handoff problem. Security is expected to answer for supplier risk, but it rarely chooses, contracts or manages the supplier. Procurement, contract managers and the service that wanted the product do that, so they see both the buying decision and the later changes first.

Security leads we speak to describe the same three consequences:

• Security hears about a supplier after the contract is signed, if it hears at all.
• Security hears about a supplier after the contract is signed, if it hears at all.
• After signing, nobody is watching for the changes that matter, like a new subcontractor, a move to new hosting or a lapsed certificate.

One council we work with described its assurance as happening after contract approval. By the time its ICT team assesses a supplier, the council has already paid for it. Any findings stop being a question of whether to proceed. They become a question of whose risk register they land on.

This guide sets out a working split for each stage, from first intake to exit, and it’s written to be forwarded to procurement colleagues. Procurement doesn’t need to become a security assessment team, and security doesn’t need to approve every purchase by hand. Both need an agreed route for which suppliers get checked, what evidence counts and who decides on the risk that’s left.

The split is a recommended model, not a regulatory requirement. Job titles and delegated authority vary between bodies, so map the roles onto your own governance.

‍

Who does what between procurement and security?

Procurement and security divide supplier assurance by stage. Security sets the criteria and judges the evidence. Procurement and contract managers route suppliers through the checks and keep them current after award. The service owner decides whether the remaining risk is acceptable, so every stage ends with a named person making that call.

Most arguments about supplier security blur two separate things...

The first is who does the work: asking suppliers the questions, reading their evidence and chasing their answers.

The second is who makes the decision once that work is done.

Procurement and security can share the work. The decision needs one named person for each engagement, or it ends up with whoever raised the concern.

Central government’s commercial standard already points this way. GovS 008 describes commercial specialists working with the business unit that needs the service. Commercial usually leads the procurement. Once the contract is agreed, overall responsibility for managing it may sit with that business unit, with commercial support continuing. The standard also defines a senior business owner accountable for each contract, and a contract manager who runs day-to-day delivery and reports to that owner. Security isn’t one of the roles it sets out, so each organisation has to decide for itself where security joins the process.

The NCSC fills in the accountability side. Under principle A4 of the Cyber Assessment Framework, an organisation that relies on third parties remains accountable for protecting any essential function. The “achieved” level includes proactive contract management, with customer and supplier responsibilities defined in contracts. That accountability sits with the organisation. It doesn’t sit automatically with its security team, which is why the table below gives the risk decision its own row.

Run the table once per engagement, not once per supplier. The same company might sell one team a low-risk software licence and run a case-management system holding sensitive records for another. Those two contracts carry very different exposure, even though the supplier’s name, certificates and security policies are identical. Security leads we work with describe their job as assuring the engagement rather than the company, and the distinction matters most at renewal.

A supplier that passed a light-touch check for its first contract can quietly pick up a second, higher-risk service without anyone triggering a fresh look. Keeping one record per engagement makes that visible. It also tells the contract manager which review dates and change triggers apply to which piece of work. A single supplier-level score can’t do that.

The table is a recommended model, not a requirement. GovS 008 applies to central government departments and their arm’s length bodies. Other public bodies, devolved or local, may adopt it in full or use it for benchmarking. In smaller bodies one person often covers contract management and service ownership. That works, as long as the decision row still has a name in it.

‍

Who owns residual supplier risk: procurement, security or the service?

Residual supplier risk is the exposure left once due diligence is done and any agreed fixes are in place. It belongs to the authorised owner of the service that the supplier supports. Security assesses it and recommends what to do. Procurement makes sure the decision is taken before award. The owner then accepts, treats or escalates it within their delegated authority.

Two jobs get treated as one here. Recommending what to do about a finding needs security expertise. Deciding whether the service can live with what’s left needs authority over the service, its budget and its fallback options. Security usually has the first and rarely the second.

When the two get merged, security ends up carrying the risk by default. Security leads we speak to describe a specific version of this. Once they’ve reviewed a supplier’s evidence, or shared their assessment with another team, it feels as though they’ve signed off the risk themselves. Nobody else wrote their name down, so theirs is the one on file.

A cleaner split separates four steps.

• Security assesses and recommends: It reviews the evidence and recommends a response. That might be accepting the risk as it stands, requiring a fix before go-live, reducing the data or access the supplier gets, or not proceeding.
• The service owner decides: They make the call within their delegated authority.
• Someone records the decision: This is usually security, or whoever keeps the governance records. The record shows who decided, why, and on what conditions.
• Procurement times it: It makes sure all of this happens before award, while every option is still open.

The model mirrors how GovS 008 treats commercial decisions. It expects them to be delegated to a single point of accountability at the lowest appropriate level, with risk managed within the organisation’s appetite and tolerance. This is a recommended model, not a rule every public body has to follow. Its value is that acceptance becomes explicit, named and dated rather than assumed.

If the service owner won’t decide, the gate stays closed. Escalate to whoever your governance names as the next level of risk authority, and don’t award until a decision is recorded.

Two limits apply to any acceptance. First, accepting risk can’t waive a legal obligation or make a mandatory procurement requirement optional. Second, GovS 008 allows commercial assurance to be conditional only where someone is assigned responsibility for meeting each condition.

Disagreements between procurement and security take the same route. The agreed tiering criteria decide which checks apply, not whoever argues hardest. Disputes about a supplier’s controls get settled with evidence. Anything still unresolved goes to the service owner, and the outcome is recorded either way. For the broader question of where cyber risk ownership should sit across the organisation, see who should own cyber risk.

What does a residual risk sign-off look like?

A residual risk sign-off is a short record of who accepted the remaining risk on an engagement, on what evidence and until when. It should be brief enough for a contract manager to read at renewal and understand why the supplier was approved.

A record doesn’t prove the decision was right. What it shows is who decided, what they knew at the time, which conditions they set and when they agreed to look again. That is exactly what a board or auditor asks for when they want to know whether appropriate steps were taken on a critical supplier.

‍

Before award: which suppliers would hurt you most if compromised?

Tiering by harm ranks each engagement by the damage a supplier compromise could cause, rather than by contract value. That damage is judged on the data involved, the access granted and how much a service depends on the supplier. Security sets the criteria. Procurement applies them at intake, using five short questions on every new purchase.

Contract value tells procurement how much commercial attention a purchase needs. It says little about what a breach would cost. A school transport contract can be one of the smallest a council signs and still hold the home addresses and collection arrangements of the children it carries. Tier by spend alone and that contract sits near the bottom of the pile.

The commercial standard already allows for a different approach. GovS 008 says tiers may be aligned to value, risk or business impact, so adding a harm dimension fits the framework procurement already works within.

NCSC guidance recommends three to five supplier security profiles, each representing a higher level of impact, with criteria tailored to what matters to your organisation. In practice, four questions do most of the work:

• Data. What information could be exposed, changed or lost?
• Service dependency. Which service would stop, and who would be affected?
• Access. Can the supplier connect to or administer your systems?
• Replaceability. How long would it take to move to someone else safely?

Security leads we speak to often find that assurance has been treated as something for ICT contracts only. Following data, access and dependency instead is how a small care provider or a school taxi firm ends up in a higher tier than a large software licence. For the full method, see our guide to supplier criticality.

Procurement doesn’t need security expertise to spot these engagements. It needs five questions it can ask on every new purchase, before the requirement goes out.

What due diligence evidence is proportionate for small suppliers?

Proportionate due diligence matches the evidence you ask for to the harm an engagement could cause, not to the supplier’s size. A sole trader holding sensitive data still needs checking. The right route is a short, targeted request about that data, not a full enterprise questionnaire.

PPN 014 makes this explicit for the bodies it covers: central government departments, their executive agencies, non-departmental public bodies and NHS bodies. Other public bodies may choose to apply the same approach. In-scope organisations must not take a blanket approach to Cyber Essentials. Controls must be relevant and proportionate to what’s being bought, and suppliers shouldn’t be over-burdened or put off from bidding, particularly small businesses and voluntary sector organisations.

The note’s own examples include a driving instructor service for ten people, delivered by a sole trader whose IT use is limited and incidental. It treats that as a contract where Cyber Essentials isn’t relevant. It also expects the decision to be recorded even when the risk is judged very low.

Certificates help, within their limits. Cyber Essentials checks five baseline technical controls and doesn’t assure the specific product or service being bought. An ISO 27001 certificate won’t automatically cover those same five controls. The NCSC adds that compliance with a standard doesn’t necessarily mean a supplier is secure, which is why the tier should decide what you ask for:

• High harm: targeted questions on the data and access involved, backed by evidence, with follow-up on access and recovery claims and a review date set.
• Moderate harm: a short, service-specific request, with evidence for the controls that matter most.
• Low harm: a brief declaration or basic checks, where the exposure justifies it, with the decision recorded.

One council we work with moved away from a long procurement questionnaire after its commercial team pushed back. Bidders found the document heavy going, and commercial colleagues didn’t like sending it. Commercial became the team asking for a lighter route, which made security’s job easier rather than harder.

A short request has its limit, though. For a high-impact engagement it may not be enough, and a small supplier in that position may need support to provide better evidence rather than a lighter check.

What should a pre-award security gate check?

A pre-award security gate is the go/no-go check before contract award. Security confirms the tier, reviews the evidence and makes a recommendation. The award waits until the service owner’s risk decision is recorded.

The gate only works if suppliers knew the requirements from the start. The NCSC advises communicating minimum security requirements as early as the invitation to tender. PPN 014 says Cyber Essentials requirements should ideally be raised during preliminary market engagement, and must be specified in the tender notice for a competitive tendering procedure. For in-scope contracts, evidence of certification or equivalent controls is required before award. A supplier can’t fairly respond to criteria it first sees at the gate.

A gate isn’t a pass-or-fail exam either. Where a supplier falls short but you still want to work with them, the NCSC recommends a security management plan. The plan sets out controls met and not met, the actions required, timescales and the next assessment date. That plan, and the owner’s decision on it, become part of the record.

‍

At award: which security requirements belong in the supplier contract?

Security requirements in a supplier contract turn the assurance agreed before award into obligations the supplier must meet during delivery. They should be tool-neutral, setting out the assurance you need and the acceptable ways to demonstrate it. Security, procurement, the service owner and Legal should agree them before the tender is published, so award confirms them rather than introducing them.

There are two halves to every security requirement. The first is what the supplier has to do: maintain certain controls, tell you about incidents, flow obligations down to its own subcontractors. The second is how you’ll know it’s happening: the evidence, notifications and rights that let you check. Contracts often cover the first half well and leave the second vague. When that happens, the obligation exists on paper but nobody on your side can see whether it’s being met.

That second half is the lever security leads tell us they lack. Suppliers can become harder to engage once the contract is signed. Without a notification duty, an evidence requirement or an audit right, there’s little to point to when security asks for an update.

The NCSC recommends a standard set of security clauses that can be inserted as part of any acquisition. GovS 008 expects contracts to cover sub-contractor appointment, flow-down of terms, managing exit, and proactive assurance measures such as right-to-audit clauses and management information. For large, complex services, the government’s Model Services Contract already has a Security Management schedule, and PPN 014 notes that it requires Cyber Essentials or equivalent from the supplier and relevant subcontractors. If you use it, start there.

Write the requirement, not the tool: Specify the assurance outcome and the evidence that would satisfy it, such as current evidence of named controls through a route agreed with the buyer. Don’t name a particular product or platform. Tool-neutral wording keeps the competition open, lets suppliers reuse evidence they’ve already produced for other customers, and still gives you something enforceable. Exact wording is Legal’s call, and the areas below are topics to agree, not ready-made clauses.

Data protection terms are a separate requirement: When the public body is a controller and the supplier processes personal data on its behalf, UK GDPR requires a written contract with specific terms. The ICO lists them.

They include:

• appropriate security measures
• using sub-processors only with prior authorisation and under a written contract
• helping with breach notification
• deleting or returning the data at the end of the contract
• submitting to audits and inspections

A security schedule doesn’t replace these terms, and “sub-processor” is a data protection role, not another word for every subcontractor. The ICO notes this guidance is under review following the Data (Use and Access) Act, so check the current version with your data protection officer.

Agreements that aren’t contracts need Legal’s input: Some arrangements, particularly between public bodies, run on a memorandum of understanding rather than a contract. Cooperation and notification expectations still need writing down there, but Legal should decide how they’re worded and which, if any, can be enforced.

‍

After award: which supplier changes should trigger another review?

Post-award supplier assurance keeps the pre-award decision current. Each critical engagement is reviewed at an agreed date, and again whenever something material changes. Contract managers usually see those changes first. They pass them to security, security assesses how significant they are, and the service owner decides whether the original decision still stands.

One council we work with described its old model plainly. A supplier completed a questionnaire at contracting or recontracting, supplied its certificates and listed its subcontractors, and the answers went into a file. Nothing prompted anyone to look again until the next contract. The council has since changed its approach, but the old pattern is common: assurance is thorough up to signature and then stops.

The problem isn’t that the original check was poor. Evidence describes a moment, and suppliers keep changing after it. PPN 014 makes the point about its own scheme. Cyber Essentials gives assurance only at the time of testing, so a supplier that stops patching or loses control of its configuration can fall out of compliance well within a year.

The NCSC says evidence-based assurance should continue for the whole contract, not just at onboarding. How often depends on a few things:

• the supplier’s security profile
• what the contract lets you ask for
• the type of assessment
• how much resource you have

CAF principle A4 expects proactive contract management but doesn’t set a review interval, so each organisation decides its own cadence and records why.

A review date is only the backstop. Most of the useful signal comes from events, and the person best placed to see them is usually the contract manager, not security. That’s why the triggers below name who notices each change as well as who acts on it.

Three distinctions keep this proportionate:

• A review falling due isn’t a certificate expiring: It only means it’s time to check what’s current.
• A change in an external security rating is a signal, not proof: Validate it before acting.
• A supplier that doesn’t respond has left an assurance gap: That isn’t evidence of safety, and it isn’t evidence of compromise either. Escalate it like any other open finding.

Which suppliers should you contact first when there’s an incident?

Start with the suppliers that have a credible link to the incident and the greatest consequence for your services. Use your existing tiers as the starting order, then adjust as facts emerge. Security leads the assessment. The service owner and procurement are told early, and procurement uses the notification and audit terms in the contract.

The tiers you set before award already give you most of the answer. The council mentioned above has gone a step further. It ranks its contracts by restoration priority, with social care systems first, and keeps that ranking in its contract register. The business then knows the order of recovery before anything goes wrong.

The same council has also looked one step further down the chain. A data centre that its suppliers rely on, but that it doesn’t contract with directly, could take out several services at once. That led it to ask each supplier how it would notify the council if it lost access to its own systems.

A workable sequence:

• Identify what’s affected: Pin down the affected products, suppliers and the providers behind them.
• Map the impact: Connect each one to the services, data and access it touches.
• Contact the supplier: Reach its incident team through the agreed channel, and separate confirmed facts from open questions.
• Bring in the right people: Involve the service owner and procurement, and use the contract’s notification and information rights.
• Decide protective action through the incident process: Cutting a supplier off can itself stop a service, so don’t do it by reflex.
• Record and reassess: Log each update and look again as facts change.

CAF principle A4 expects incident management to consider incidents that start in the supply chain. Where appropriate, it expects your process and your suppliers’ processes to support each other in resolving them. For the full response workflow, see our third-party incident response playbook.

At exit, confirm the supplier has returned or deleted data as the contract requires, remove its access, and check that the transition plan held. GovS 008 expects an exit plan that names roles and responsibilities for each activity. Security closes the assurance record once the closure evidence is in. Anything still open, such as retained data or a dependency the new provider hasn’t picked up, goes back to the service owner.

‍

How do you start if your security team is one to three people?

A small security team should start with the three steps that carry most risk:

1. Name an owner for each critical engagement.
2. Get procurement asking the five intake questions.
3. Set review dates and change triggers for the top tier.

Everything else in this guide can be added once that loop is working, and none of it needs every supplier assessed first.

Security leads we speak to often describe a team of one, or a handful of people covering an entire estate. A model that asks them to assess every supplier in depth, every year, won’t survive its first quarter. The three steps above are chosen because they redistribute work rather than adding to it.

• Intake moves the job of spotting risky purchases to procurement, which sees every purchase anyway.
• Named owners stop security carrying risk by default.
• Triggers replace a blanket annual reassessment with checks that happen when something actually changes.

There’s a cost to starting this way, and it’s worth stating plainly. Lower-tier suppliers will get light coverage for a while. That’s a deliberate choice, not an oversight, and it should be recorded as one. PPN 014 expects bodies in its scope to record their decisions on cyber controls even where the risk is judged very low. A short note explaining why the low tier gets a basic declaration is far easier to defend than an unexplained absence of checks.

How the split changes with your structure

The decision rights stay the same whatever your structure. The service owner decides, security recommends and procurement times it. What changes is who runs intake and how cases reach security.

• Central assurance team: Security or a central third-party risk management (TPRM) team triages directly. Procurement sends every flagged engagement to one place.
• Federated organisation: Directorates or local commercial teams run intake using shared questions and criteria, and escalate defined cases to specialist review. Security leads in NHS trusts have described introducing a short cyber impact assessment before a system is procured, because new systems were reaching the cyber team after the purchase had already been agreed.
• Shared service across bodies: Shared criteria and evidence reduce duplicated work, while each body still makes its own engagement decisions. Two councils we work with run a shared ICT service and often procure jointly, which cuts the number of suppliers each one has to assure. Getting buy-in across both organisations has still taken sustained effort.

The commercial standard supports that last route. GovS 008 expects contracting authorities that identify capability shortfalls to address them, including through collaboration with other authorities or shared services.

Whichever structure you have, write the roles down once so they don’t depend on goodwill between individuals. Our TPRM policy template is a starting point.

‍

What do NCSC guidance and PPN 014 expect of procurement and security?

NCSC guidance expects organisations to do four things:

• tier suppliers by impact
• set proportionate minimum requirements for each tier
• build those requirements into contracts
• keep checking evidence for the life of the contract

PPN 014 adds specific Cyber Essentials rules for central government and NHS bodies. Neither source assigns tasks to named teams, and that allocation is what this guide sets out.

What does NCSC guidance expect of procurement and security teams?

The NCSC’s supply chain assessment guidance is the most practical official source here. It is written for procurement specialists, risk managers and security professionals together. It sets out five outputs a repeatable approach should produce:

• tiered supplier security profiles
• questions to decide which profile a supplier falls into
• the evidence each profile requires
• a supplier security management plan to track compliance
• standard security clauses for contracts

It also says evidence-based assurance should continue for the whole contract, not stop at onboarding. Most of this guide maps onto those outputs. The intake questions are the triage questions. The tiers are the profiles. The decision record and trigger list are how the management plan stays current.

CAF principle A4 adds the accountability point. An organisation that relies on third parties remains accountable for protecting its essential functions. CAF describes outcomes, not a review timetable, so it sets no review frequency. Each organisation decides how often to review and records why.

What does PPN 014 require on Cyber Essentials?

PPN 014 applies to central government departments, their executive agencies, non-departmental public bodies and NHS bodies. Other public bodies may choose to apply its approach. For contracts with higher-risk characteristics, such as handling citizens’ personal information, in-scope organisations must make sure suppliers meet certain technical requirements. Cyber Essentials, or equivalent controls, is the quickest route.

Four points matter most for procurement and security working together:

• Raise requirements early: They should be discussed in preliminary market engagement and must appear in the tender notice for competitive procedures.
• Get evidence before award: It is also essential at the point data is passed to the supplier.
• Keep it proportionate: No blanket approach, and decisions are recorded even where risk is judged very low.
• Know its limits: Cyber Essentials doesn’t assure the specific product or service, and it isn’t designed for advanced, targeted attacks.

Framework buying doesn’t remove the check. G-Cloud suppliers must comply with the government’s Cloud Security Principles, but the framework doesn’t require them to hold Cyber Essentials. PPN 014 expects in-scope organisations to satisfy themselves that a supplier is managing relevant cyber risks before awarding a call-off contract.

What guidance applies to councils?

Councils aren’t in PPN 014’s scope, though they can adopt its approach. The most directly relevant resource is the Local Government Association’s guidance on embedding cyber resilience in local government supply chains. It was developed with PUBLIC and DAINTTA and interprets the NCSC’s supply chain principles for councils. It works through each stage of the procurement lifecycle (strategy, planning, tender, contract and management), and comes with a free e-learning course. It is aimed at anyone involved in the procurement cycle, which makes it a useful companion to send procurement colleagues alongside this guide.

‍

How we support procurement and security at Risk Ledger

We built Risk Ledger so that a supplier completes one standardised security assessment, keeps it updated and shares it with every customer that needs it. Each buyer still applies its own requirements and makes its own decision on the engagement. For procurement and security, that means less time chasing evidence and a shared record of what was checked, when and by whom.

There are two separate problems in this guide, and we address them differently.

The first problem is duplicated work: Public bodies often buy from the same suppliers. Security leads we speak to regularly ask why each of them has to run its own due diligence on a supplier that several neighbouring bodies have already assessed. The supplier ends up answering near-identical questions over and over, and small suppliers feel it most. On Risk Ledger, a supplier already on the network shares its existing profile instead of starting a new questionnaire. Because every profile uses the same assessment framework, security can compare like with like across suppliers.

The second problem is the decision, and the decision isn’t something a platform should take over: Shared evidence reduces the homework. It doesn’t tell you whether that evidence covers your service, whether your contract terms are in place, or whether your service owner accepts what’s left. Those stay with you, engagement by engagement. That answers the worry many security leads raise, that reviewing or sharing an assessment means accepting someone else’s risk.

How this maps onto the split

• Before award: One council we work with puts the link to its Risk Ledger assessment straight into its procurement documentation. Its commercial team, which had disliked the old questionnaire, now works with security on clarifications when a submission comes back incomplete. The council has used this approach on large and small procurements.
• After award: Suppliers keep their profile updated, so the evidence you rely on doesn’t freeze at signature. Security can review what’s changed against the triggers in the contract.
• During an incident: When a new vulnerability or attack emerges, we map it across the network so you can see which connected suppliers are affected and where to act first. The council in Section 6 keeps its restoration-priority ranking in Risk Ledger as well as in its contract register. The business then knows the recovery order before anything goes wrong.
• Beyond direct suppliers: Once intake, tiers and owners are working, you can see which suppliers depend on the same underlying providers. That covers dependencies like the data centre the council never contracted with directly. We’d start with the basics first, because dependency visibility is only useful once it’s connected to a decision someone owns.

‍

What security teams ask next

• Supplier Criticality Explained: Assessment, Examples and Where Most Programmes Miss Risk
• Why CISOs Shouldn’t Be the Sole Risk Owners
• Third-Party Incident Response Playbook: From Supplier Alert to Safe Recovery
• How to Develop a TPRM Policy: Outlining Frameworks, Roles and Procedures
• Breaking Silos: The Power of Cross-Team Collaboration in TPRM
• Every Link Matters: The State of Supply Chain Security in the UK Public Sector

‍