PCI DSS training: who needs what, and the records that prove it

Why PCI DSS treats people as a control

Many card data compromises begin not with a clever exploit but with a convincing e-mail to a finance clerk, a call-centre agent reading a card number aloud near an open window, a skimmer fitted to a terminal nobody inspected, or a developer who never learnt how injection attacks work. PCI DSS responds by treating the knowledge of your people as a control in its own right, alongside firewalls and encryption,.

The training obligations sit mainly in Requirement 12, which covers organisational policies and programmes, but they surface elsewhere too: in Requirement 5 on phishing, Requirement 6 on secure development, Requirement 9 on the physical protection of payment devices and the incident response parts of Requirement 12. Under v4.0.1 the formerly future-dated items, several of them about what people must be taught, have been mandatory since 31 March 2025.

Security awareness for everyone in scope

The baseline is a formal security awareness programme covering all personnel. "Personnel" in PCI DSS is broad: full-time and part-time employees, temporary staff, contractors and consultants who are resident on your sites or who otherwise have access to the cardholder data environment.

When it happens

Each person is trained on hire and at least once every twelve months afterwards. The interval is personal, so someone who joined in July cannot wait for a January refresher that falls eighteen months later. The programme itself must also be reviewed at least once a year and updated for new threats and vulnerabilities that affect your environment.

What it covers

Version 4 expects the awareness content to address phishing and related social engineering attacks, and the acceptable use of the end-user technologies people handle, such as laptops, tablets, mobile phones and payment terminals. Beyond those points, the content should reflect your own card data flows: where card numbers enter the business, what staff must never do with them (write them down, send them by e-mail or chat, store them in spreadsheets), how to recognise a suspicious request and whom to call.

Acknowledgement

Personnel must also acknowledge, at least once a year, that they have read and understood the information security policy and procedures that apply to them. The acknowledgement can be electronic, but it has to identify the person and the date.

Role-based training: matching the lesson to the control

Once everyone has the baseline, the question becomes which people operate controls that need deeper knowledge. The standard is explicit about several groups; for others, the need follows from the controls they run.

Software developers

People who build or maintain bespoke and custom software in scope must be trained at least once every twelve months in secure software design and coding techniques relevant to their languages and roles, including how to avoid common vulnerabilities and how to use security testing tools.

Point-of-sale and front-line staff

Where card-present terminals are used, the staff in those environments must be trained to recognise attempted tampering or replacement of devices: unexpected attachments, broken seals, changed labels, and people claiming to be repair technicians. They should know how to report a suspect device before using it again.

Incident responders

Personnel with responsibilities under the incident response plan must be trained periodically, at a frequency your organisation sets and justifies, so that they know their part when a compromise is suspected.

System administrators and security staff

People who configure firewalls, harden servers, manage keys, review logs or run vulnerability scans need competence in the tools and procedures they use. PCI DSS asks you to define roles and responsibilities for each requirement; the competence behind those roles is best evidenced by relevant training, vendor qualifications or supervised experience recorded against the person.

Managers and executives

No separate requirement names them, but the executive who signs the Attestation of Compliance should be briefed on what that signature declares.

A training matrix for a typical PCI DSS scope

The table below shows how a merchant or service provider can lay out its obligations.

The ISA and QSA qualifications: what they are and who needs them

Two qualifications are often confused with staff training. Both are PCI Security Standards Council programmes, and neither is a Sterling course.

The Qualified Security Assessor qualification is held by assessors employed by QSA companies listed by the Council. A QSA performs the independent assessment, writes the Report on Compliance and signs the assessor section of the Attestation of Compliance. Your own staff do not need to become QSAs; you engage a listed QSA company.

The Internal Security Assessor programme is for an organisation's own experienced auditors or security professionals, sponsored by their employer. An ISA can carry out internal assessments, recommend remediation and act as the organisation's liaison with its QSA. The Council requires ISAs to requalify every year. Whether an ISA is worth having depends on your size, your merchant or service provider level and what your acquirer expects; how an ISA fits into testing your own controls is covered in our guide to PCI DSS internal audit and the ISA: testing your own controls.

How to evidence training so the assessor accepts it

Assessors test training by sampling. They pick names from the personnel list, often recent joiners and contractors, and ask for proof that each one was trained and acknowledged the policies within the required interval. Interviews check that the content stuck.

• A training register linked to the personnel list, showing for each person the module, the completion date and the next due date.
• Content under version control, with the date of the last annual review and a note of the threats added.
• Policy acknowledgements tied to the policy version, collected at least yearly.
• Role rosters for developers, terminal users and responders.
• Justifications for any frequency your organisation defines itself, written as part of your risk analysis.

The policies and records a QSA asks for more generally are described in the documentation guide, and the Effivity guide shows how the register, reminders and acknowledgements are held in one place.

For people who need structured learning beyond the engagement, Contact us about Academy access.

PCI DSS training: questions buyers ask