Two clauses oblige training and neither describes its record: the four fields the texts imply for who, which material, when and how often, and the honest name for what a completion tick proves.
The most prescriptive training clause I know in EU law says nothing about a record. Art. 13(6) of Regulation (EU) 2022/2554, DORA, makes awareness programmes and resilience training "compulsory modules", applies them to "all employees and to senior management staff", scales their complexity to "the remit of their functions", and then stops without a word about what gets written down. If you run the programme, that gap is yours: every question a reviewer brings to a training scheme is a record question. Who was in scope, which material each person was given, when they completed it, and how often it comes round. GDPR Art. 39(1)(b) leaves the same gap on the data protection side. Read as record requirements, the two clauses fix four fields and leave room for an honest name for the completion tick.
Art. 13 is headed "Learning and evolving", and paragraph 6 reads in full:
"Financial entities shall develop ICT security awareness programmes and digital operational resilience training as compulsory modules in their staff training schemes. Those programmes and training shall be applicable to all employees and to senior management staff, and shall have a level of complexity commensurate to the remit of their functions. Where appropriate, financial entities shall also include ICT third-party service providers in their relevant training schemes in accordance with Article 30(2), point (i)."— Regulation (EU) 2022/2554, Art. 13(6)
Who. "All employees and … senior management staff" is universal, and "commensurate to the remit of their functions" makes the depth of the content depend on what a person does. Nothing in the text asks for a list of names.
How often. "Compulsory modules in their staff training schemes" implies repetition but names no interval, while the neighbouring Art. 13(5) has senior ICT staff report "at least yearly" to the management body. The only cadence attached to training in DORA is Art. 5(4), which binds a different group: members of the management body "shall actively keep up to date with sufficient knowledge and skills to understand and assess ICT risk … including by following specific training on a regular basis, commensurate to the ICT risk being managed."
Which material. The paragraph names a subject, ICT security awareness and digital operational resilience, and no material, module or document.
When. "Record", "log" and "evidence" appear nowhere in Art. 13(6), Art. 5(4) or the simplified framework's training point.
The paragraph binds fewer entities than DORA covers. Art. 2(2) makes points (a) to (t) of the scope list "financial entities" and leaves the ICT third-party service providers of point (u) outside that term, so the "financial entities shall" of Art. 13(6) reaches them only through its third sentence. Art. 16(1) then disapplies Arts. 5 to 15 for small and non-interconnected investment firms, exempted payment and electronic money institutions, certain institutions exempted under Directive 2013/36/EU, and small institutions for occupational retirement provision. It gives them a softer duty in Art. 16(1)(h): "develop, according to needs and ICT risk profile, ICT security awareness programmes and digital operational resilience training for staff and management". "Compulsory", "all employees" and "commensurate to the remit" are all absent from it. So the DORA security awareness training duty in Art. 13(6) binds financial entities outside the simplified framework, and the Art. 16 entities carry a needs-based version of the same duty.
The GDPR's training clause sits in the data protection officer's task list, so it applies wherever a DPO exists, whether Art. 37(1) required one or the controller or processor designated one under Art. 37(4). Art. 39(1) opens "The data protection officer shall have at least the following tasks", and point (b) reads:
"(b) to monitor compliance with this Regulation, with other Union or Member State data protection provisions and with the policies of the controller or processor in relation to the protection of personal data, including the assignment of responsibilities, awareness-raising and training of staff involved in processing operations, and the related audits;"— Regulation (EU) 2016/679, Art. 39(1)(b)
The grammar carries two readings and the text settles neither. The governing verb is "to monitor compliance with", and the "including" list hangs off it. On the first reading the DPO monitors that responsibilities are assigned, that awareness-raising and training happen, and the audits of both; on the second, "awareness-raising and training" are things the DPO delivers. Two clues lean toward the first. A DPO does not do "the assignment of responsibilities", its list-mate, so the list reads most naturally as objects of monitoring. And Art. 47(2)(h), which binds only groups transferring data under approved binding corporate rules, again pairs the DPO with "monitoring training". The delivery-shaped duty toward staff sits in Art. 39(1)(a): "to inform and advise the controller or the processor and the employees who carry out processing of their obligations". Under either reading the record consequence is the same: something must exist for the DPO to monitor and for "the related audits" to audit, and neither point says what it contains.
The audience is again a predicate: "the employees who carry out processing" in point (a), "staff involved in processing operations" in point (b), and, for the same binding-corporate-rules groups, Art. 47(2)(n)'s "personnel having permanent or regular access to personal data". None is a list of names.
Where the burden sits is a separate clause. Art. 5(2) says "The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 ('accountability')", and paragraph 1 is the six processing principles, so training reaches it only as one of the "appropriate technical or organisational measures" Art. 5(1)(f) names for security. Art. 24(1) covers such measures directly: the controller "shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. Those measures shall be reviewed and updated where necessary." If staff training is one of those measures, "be able to demonstrate" turns "we trained them" from a statement into a claim that needs something behind it.
Put the two texts together and a training record needs four things. Both regulations define the audience by what a person does; neither names a material; neither fixes a cadence for staff. Each silence is a field the record has to fill, and the shape of each field follows from the text: a predicate for who, a pointer captured at completion for what, and the cycle a completion satisfies for when. A completion is a dated record with a cycle, the currency clock from the retention-and-currency post applied to people instead of documents.
| Field | Clause that implies it | Form it has to take | What breaks without it |
|---|---|---|---|
| Who | DORA Art. 13(6), "commensurate to the remit of their functions"; GDPR Art. 39(1)(b), "staff involved in processing operations" | A role or activity predicate resolved when the record is read, so a role change enrols or retires a person by itself | The list goes stale at the first role change: people in scope with no record, records for people out of scope |
| Which material | DORA Art. 13(6) names a subject, no material; GDPR Art. 39(1)(b) names "training" and "the related audits" | A pointer to the exact item shown, captured at completion | Replacing the material rewrites every past completion |
| When | GDPR Art. 24(1), "be able to demonstrate"; DORA Art. 13(6) silent | A timestamp per person per cycle, one completion satisfying one cycle | One flag with a date reads as complete forever; the next cycle inherits the last one's tick |
| How often | DORA Art. 5(4), "on a regular basis", management body only; Art. 13(6), no interval; GDPR Art. 24(1), "reviewed and updated where necessary" | A schedule the organisation sets, plus a reminder that fires per cycle and never repeats for the same one | Either the cycle lapses unchased, or people are chased for a cycle they already completed and stop reading |
The fourth row is where both regulations leave the most to the organisation: DORA fixes "regular" only for the management body and the GDPR's "where necessary" fixes nothing, so the interval is the organisation's own decision, and a record without a cycle cannot show that the decision was kept. That is what makes "how often" a record field.
Here is my position. A completion tick records that a person attested, on a date, for a cycle, against a material. Put a gate in front of it, a reader that waits for the last page or a player that waits for the end of the video, and it still records that. The gate raises the cost of an empty tick; it does not turn the tick into proof that anyone learned anything. Whether they learned is a different fact, produced by a different act: a test with a score, an observed task, a certificate from an external body. Those produce a second record, the one to bring when the question is competence rather than participation. The honest name for the first record is an attestation, and a register that labels it "training completed" claims more than the record holds.
devguard stores the four fields like this, and the section after is what that costs. A training is a pointer at material you already have, a YouTube or Vimeo video, a link to an external course, or a PDF you upload. Each training carries at most one assignment, whose audience is named people plus business roles, resolved live whenever it is read. Adding someone to a targeted role enrols them; archiving a role or deactivating a person removes them from the audience and the reminders. There is no "everyone" option. Every assignment has a first due date and, if it recurs, a schedule the organisation defines. Each cycle's due date and each person's status for it, Pending, Completed or Overdue, are worked out from the schedule and the completions whenever they are read, so when the schedule rolls over the person is Pending again.
Reminders follow the cycle: one ahead of the due date with a lead that grows with the cycle (a week ahead of a one-off, up to a month ahead of a yearly training), one the day before or on the day, and one once overdue. None is sent twice for the same cycle and stage. A completion writes one record per person per cycle: who confirmed, which assignment, which cycle it satisfies, when, and a snapshot of the link that person was shown. The confirmation stays locked until the PDF reader has reached the last page, the video player has reported the end (or, when the player never answers, that playback began), or the external link has been opened. The employee's side of this belongs to a separate post.
There is no export, report or API for completion records. A reviewer sees them on screen, on the assignment card's per-person list and on the Deadlines page as "x of y completed", or does not see them at all; the CSV export covers training rows only. For a PDF training the record keeps no pointer to the file: the snapshot is of a link a PDF training does not have, and replacing the PDF deletes the old file, so a past completion says "the PDF" and cannot say which one. The pointer row above holds for video and link trainings only. The engagement gate only holds the confirmation back; nothing about the reading, the playback or the click is stored with the completion, so the record does not certify that the video was watched or the document read. "When" and "which cycle" are recorded facts, while "read" and "watched" rest on the person's word. There are no quizzes, scores, pass marks, certificates or SCORM. Marking a training complete creates no evidence and changes no control coverage; evidence, if any, is attached by an admin on the training's Evidence tab. Each absence follows from the same two choices: a training is a pointer, and a completion is an attestation.
Whatever holds your training records today, the check is four fields and one name. Is the audience a predicate that follows role changes, or a list someone has to remember to edit? Does each completion point at the exact material shown? Does it carry the cycle it satisfies? Is there a reminder that fires once per cycle? And is the record labelled as what it is, an attestation, with competence evidenced elsewhere? DORA and the GDPR ask for the training; the record is the organisation's, and those five questions are what it has to answer.
The platform overview at devguard.ch/platform shows how trainings, assignments and completions sit alongside the rest of the register.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.