Compliance training for tech suppliers: what customers and auditors expect, who needs it, and how to prove it

A financial services prospect's security questionnaire asks what training your staff receive, how often, and for proof of completion. Your honest answer is an annual click-through video and a spreadsheet nobody has opened since March. Compliance training for a tech supplier is judged by the customers, auditors and contracts that ask for it, not by the course catalogue.

This guide is for founders, COOs, CTOs and security leads at UK B2B technology firms selling into financial services, insurance or the public sector. It shows where your training duties come from, who needs which modules, when to run them, and how to keep the evidence current. Then the next questionnaire takes minutes.

What is compliance training for a tech supplier?

For a tech supplier, compliance training is the security, data protection and AI awareness training that customers, auditors and contracts require, matched to each role and proven with records. Run security and data protection awareness for every member of staff at induction and each year, add role-based modules for engineers and anyone handling customer data, and keep completion evidence ready.

Much of what is sold as compliance training is aimed at HR teams: anti-bribery, health and safety, harassment. Those duties exist, but they are not what an enterprise buyer's security team is testing. The buyer wants to know that the people who can touch its data understand how to protect it, and that you can prove it.

The ISO 27001 version of this duty sits in Annex A 6.3, information security awareness, education and training and Clause 7.3 on awareness. This page builds one programme that serves that control and every other source at once.

Where do compliance training requirements come from?

A tech supplier's compliance training requirements come from six places: customer security questionnaires, SOC 2, ISO 27001, UK GDPR, DORA contract terms passed down by EU financial services customers, and the EU AI Act's AI literacy duty. Each asks for slightly different content and evidence, but one role-based programme with good records can satisfy all six.

The table sets out what each source asks of a supplier. It is a planning aid in our words, not the text of any standard or regulation.

A few of these need care. SOC 2 does not prescribe a training course. The AICPA's 2017 Trust Services Criteria list "provides training to maintain technical competencies" as a point of focus under CC1.4. The same document says you do not have to show that every point of focus is addressed. In practice, auditors test whatever training control you describe, so describe one you can evidence. Our SOC 2 overview covers how those criteria fit together.

UK GDPR is indirect. Article 39 gives a data protection officer the task of monitoring compliance, including "awareness-raising and training of staff involved in processing operations". The ICO's guide to data security is plainer: provide appropriate initial and refresher training. Our GDPR page covers the wider regime.

The EU AI Act applies only when your firm provides or deploys an AI system within its reach. Selling AI features to customers in the EU is one example. Article 4 of Regulation (EU) 2024/1689 has applied since 2 February 2025. The Digital Omnibus on AI rewrote it from 27 July 2026. Providers and deployers must now take measures to support AI literacy among their staff, rather than ensure a set level. Our EU AI Act page explains provider and deployer roles.

Who needs which compliance training? A role-based matrix

Every member of staff needs baseline security and data protection awareness. Engineers and DevOps need secure development and privileged access modules. Support and customer success teams with customer data access need data handling and social engineering training. People building or using AI features need AI literacy, and leadership needs incident and accountability briefings.

The matrix below is the shape we recommend for a 25 to 150 person technology firm. It puts the most specific training where the most access sits.

The NCSC's 10 Steps guidance on engagement and training makes the same point in plainer terms: understand and prioritise the knowledge and behaviours each person needs. For the all-staff baseline, the NCSC also publishes free e-learning, Staying Safe Online: Top Tips for Staff, which it says takes under 30 minutes.

When should staff complete compliance training: induction, annual or event-driven?

Staff should complete baseline compliance training at induction, before they receive access to systems or customer data, then refresh it every year. Add event-driven training whenever something changes the risk: a new customer requirement, a security incident, a new framework such as SOC 2, or a new tool that handles customer data or uses AI.

Induction timing matters more than most firms expect. An auditor can compare training completion dates with access provisioning dates. Training finished three weeks after someone was given production access is a gap, even if the content was excellent.

Annual refreshers keep the baseline current, but they are the weakest of the three triggers. Event-driven training tends to land better, because it arrives while the reason is fresh. We recommend these triggers:

1. A new customer requirement. A contract schedule or questionnaire asks for something your programme does not cover, such as a specific module or attendance at the customer's own sessions.
2. An incident or near miss. Brief the teams involved on what happened and what changes, without naming anyone.
3. A new framework or certification. Starting SOC 2 or ISO 27001 adds roles, controls and records that staff need to understand.
4. A new tool or AI use case. Anyone using it needs to know what data may go in and what the output may be used for.

What if a customer's contract requires you to join its training?

If a regulated customer's contract requires your staff to take part in its own security awareness programme or resilience exercises, treat that as a tracked obligation. Record which staff must attend, how often, and the evidence the customer expects. Then add each session to your training register like any internal module.

DORA, Regulation (EU) 2022/2554, applies to EU financial entities such as banks, payment institutions and insurers. Article 13(6) requires those entities to run ICT security awareness programmes and digital operational resilience training. Where appropriate, they must include their ICT third-party service providers. Article 30(2)(i) then requires their ICT services contracts to set out the conditions for that participation.

Unless you are designated a critical ICT third-party service provider, DORA does not regulate you directly. Your customer is regulated, and the obligation reaches you through the contract. What the clause asks of you depends on its wording, so read it with whoever owns your contracts.

The practical steps are short:

• Keep a list of every contract that includes a training or exercise participation clause.
• Name the staff each clause covers, usually the team that supports that customer.
• Ask the customer for session dates early, and log attendance as evidence.
• Review the list whenever a contract is signed or renewed.

A training clause you signed and never tracked is a finding waiting for the customer's next supplier audit.

How do you measure whether compliance training works?

Measure compliance training by behaviour, not completion. Use short assessments after each module, track phishing simulation trends over time rather than single results, and watch incident and near-miss reports for the patterns training is meant to change. Report these to leadership with the actions taken, not as a score to celebrate.

Completion rates prove the training happened. They say nothing about whether anyone changed what they do.

Three measures are worth tracking, and none needs an external benchmark:

• Assessment results by module. A question most people get wrong points to unclear content, not careless staff. Fix the content.
• Phishing simulation trends. Track reporting rates as well as click rates, over several cycles. Rising reports matter more than a single good month.
• Incident and near-miss patterns. If the same kind of mistake keeps appearing, the training for that role is not working.

The NCSC's guidance warns against stigmatising mistakes or singling people out for blame, and notes that awareness campaigns can take time to show an effect. Use simulations to find content gaps, not to punish people who click.

What evidence do auditors and customers ask for?

Auditors and customers ask for completion records with names, roles and dates, the version of the content each person completed, the training plan or policy, and attendance at any customer-led sessions. The strongest evidence comes straight from your HR and training systems, because a record your systems create is harder to dispute than a spreadsheet.

The evidence pack we recommend holds six items:

1. The training policy or plan, naming the role groups, modules and frequencies from your matrix.
2. Completion records for every person, including contractors, with the date and the module.
3. Content versions, so you can show what someone was trained on at the time.
4. Induction timing, showing completion before or alongside access provisioning.
5. Customer-led session attendance, matched to the contracts that require it.
6. Effectiveness reviews, such as assessment results and phishing trends, with the changes they led to.

In a SOC 2 Type 2 audit, the auditor samples completion across the whole observation period, so evidence must exist all through the period, not appear just before fieldwork. For ISO 27001, Clause 7.2 on competence asks you to keep evidence that people whose work affects information security are competent. Training is one route to that; education and experience count too.

Collect these automatically wherever you can. Your HR system knows who joined, who left and which role each person holds. Your training platform knows who completed what and when. Connecting the two lets you flag anyone overdue and anyone given access before completing induction, without a monthly chase.

How should you answer compliance training questions in a security questionnaire?

Answer training questions in a security questionnaire with specifics: what modules staff complete, when (induction and annually, plus event-driven), who is covered including contractors, how you check it works, and what evidence you can share. Pull the figures from your live records, so the answer is current on the day you send it.

Questionnaires tend to ask the same few things in different words:

• Do all employees and contractors receive security awareness training?
• How often, and is it completed before access is granted?
• Do privileged users and developers receive additional training?
• Do you run phishing simulations?
• Can you provide evidence of completion?

Keep one approved answer for each question, with the evidence that supports it, and review the wording each quarter. If a figure is not true today, do not send it. A buyer who later finds a gap between your questionnaire and your audit report trusts neither.

What are the common mistakes in compliance training?

The most common compliance training mistakes are a single annual video for everyone, no records for contractors, and training promised in a contract but never tracked. Each one looks fine until an auditor samples a named person or a customer asks for evidence of a specific commitment.

One annual video for everyone. It satisfies a policy line and nothing else. Engineers with production access and support staff with customer data need training that fits what they do.

No records for contractors. Contractors often join outside the HR process, so they miss induction and never appear in the register. Route them through the same onboarding and the same records as employees.

Training promised in a contract but never tracked. A participation clause in a DORA-driven contract needs an owner and a record. So does a module named in a customer's security schedule. Without one, nobody knows the commitment exists until the customer asks.

Compliance training that only exists in a policy is a promise, not a control.

Frequently asked questions