Operate
Role-based security training
Separate training for developers, finance, HR, legal and executives — because the realistic attack on each is different, and a single all-staff module is pitched to be relevant to nobody in particular.
Duration
Half a day to two days per role group
Built on
ISO/IEC 27001 Annex A · GDPR · EU AI Act · PCI DSS where applicable
Indicative price
On request
Who this is for
CISO
Knows the all-staff module does not reach the people who matter most.
Finance director
Owns the process an attacker will actually target.
Head of engineering
Needs secure development habits rather than security awareness.
Executive assistant or office manager
Is the gateway to every senior person in the building.
The same module for everyone is pitched at nobody
An all-staff module has to be comprehensible to a warehouse operative and useful to a developer, which is impossible, so it ends up being neither. It teaches everyone to spot a suspicious link, which is worth something, and teaches nobody the specific thing that would have stopped the incident their role is actually exposed to.
The realistic attack differs completely by role. Finance faces payment and supplier-change fraud, which is a verification problem, not a link-spotting problem. Developers face dependency and secrets exposure, which no awareness module addresses. HR receives attachments from strangers as a core job function and cannot simply stop. Legal holds the most sensitive material in the organisation and the weakest habits around sharing it. Executive assistants hold delegated authority and are impersonated constantly. Executives are the payload.
So we train them separately, with material that assumes they know their own job. The finance session is about verification procedure and the psychology of urgency. The developer session is about secrets, dependencies and what the pipeline does and does not catch. The executive session is forty minutes and mostly about impersonation, delegated authority, and what you personally will and will not ever be asked to approve by message.
Each session ends with something written down: the verification rule, the escalation route, the decision the group has agreed. Awareness that produces no artefact produces no change, because a month later nobody can say what was decided.
How we do it
- 01
Role mapping
3–5 days
Which populations carry which exposure, based on what they actually touch rather than on the org chart.
- 02
Scenario building
1 week
Real scenarios per role group, drawn from your own incidents where possible and your sector where not.
- 03
Delivery
half a day to two days per group
Small groups, practical, with the group's own processes on the table.
- 04
Artefact
within the session
Each group leaves with a written rule: the verification procedure, the escalation path, the approvals that will never be requested by message.
- 05
Process follow-through
1–2 weeks
Where the session exposes a process problem — and it usually does — we write it up for the process owner rather than leaving it in the room.
- 06
Refresh
annually, or on change
Shorter each time, triggered by a change of process, tooling or threat rather than by the calendar.
Named artefacts
What you receive
- Role exposure map across the organisation
- Scenario set per role group, from your own material where available
- Delivered sessions, in English or French
- A written rule per group — verification, escalation, approval boundaries
- Process findings referred to their owners
- Attendance and assessment records by role, usable as evidence
- Refresh plan
What we need from you
- Access to the processes, not just the people. The finance session is only useful with the actual payment procedure on the table.
- Small groups. Above about fifteen people the discussion stops and it becomes a lecture.
- Executives for forty minutes. This is the hardest to schedule and the highest value in the programme.
- A process owner willing to act on what the sessions surface.
What changes
- 01Each group has been trained on the attack that will actually be used against it.
- 02Verification rules exist in writing, per function.
- 03Process weaknesses surface in a training room rather than in an incident.
- 04Executives know what they will never be asked to approve by message.
- 05Evidence by role, which is what an auditor asks for.
What it costs
On request
All prices exclude VAT.
Questions
Does this replace all-staff awareness?
No, it sits on top. Everyone needs the basics and a reporting route; the high-exposure roles need something specific as well. The continuous programme covers the population, and this covers the roles that carry the risk.
Our developers say awareness training is not for them.
They are usually right about the generic version. The developer session is about secrets in repositories, dependency risk, what your pipeline actually catches, and the specific ways AI coding assistants introduce vulnerable patterns. It is a technical session delivered by people who write code.
How do we get executives to attend?
Make it forty minutes, make it about impersonation of them specifically, and have it requested by the CEO rather than by security. When it is framed as 'here is how someone will pretend to be you', attendance stops being a problem.
What does it cost?
On request. Priced per role group and per session. Most organisations run four to six groups.
Leave with your top three risks documented
Thirty minutes with a senior practitioner. No slideware, no sales engineer.