These are the 8 key points this article covers on how to create a corporate training plan for ISO 27001, NIS2 and GDPR:
- Why training is not “extra”, but a compliance requirement
- What ISO 27001 requires for competence and awareness
- What NIS2 reinforces with training and executive board participation
- What GDPR turns into training for teams that handle data
- How to design the plan by roles: scope, content, and cadence
- What evidence auditors will ask for (records, materials, and evaluation)
- How to keep the plan alive: onboarding and post-incident learning
- Common mistakes that can slow you down—and how to fix them
When an organisation grows, the risk does not grow only in technology.
It also grows in people: what they know, what they repeat without thinking, and what they cannot do when an incident happens.
A well-designed corporate training plan turns that risk into an advantage: it helps you demonstrate control and operate consistently.
What ISO 27001, NIS2 and GDPR require on training
The shared idea is simple.
Regulations do not expect you to “give a talk”.
They expect you to prove that people are competent, aware, and that you know how to maintain training over time.
ISO 27001: competence and awareness (with evidence)
ISO/IEC 27001 states that people under the organisation’s control must be competent and aware of the security policy, their role, and the consequences of not following procedures.
It also follows a continuous improvement approach.
To go deeper into the standard, review ISO/IEC 27001:2022 – Information security management systems.
NIS2: training as part of organisational resilience
With NIS2, training stops being only a “cybersecurity topic” and becomes an element of governance.
Directive (EU) 2022/2555 strengthens training and oversight so the organisation manages cybersecurity risk in an operational way.
You can consult the text in Directive (EU) 2022/2555 on NIS2.
To understand the core NIS2 expectations and whether your organisation is in scope, see what is NIS2 and who needs to comply.
GDPR: practical training for teams that handle personal data
GDPR does not prescribe a single syllabus.
But it does require proactive accountability and that people who process personal data do so with knowledge of their obligations.
In practice, that translates into training that reaches day-to-day work:
- what “personal information” is,
- how to act in incidents,
- and how to execute data subject rights with internal traceability.
To align privacy training with audit expectations, use what should a GDPR audit include.
How the three frameworks fit into one plan (without mixing concepts)
You do not need three separate plans if you define the map of requirements well.
ISO 27001 asks for competence and awareness regarding information security and the consequences of non-compliance.
NIS2 reinforces that cybersecurity is an organisational responsibility and that training forms part of resilience (not an “extra cultural” thing).
GDPR requires that anyone processing personal data does so with judgement and knowledge of basic obligations.
In practice, a solid corporate plan answers three questions in parallel:
Does the person know what to protect? Does the person know how to act when an incident happens? And can you demonstrate it with consistent records?
Design the plan by roles: scope, content, and audit-ready cadence
The first mistake is “a course for everyone”. Role-based training is the most direct way to make it relevant. And relevance is what an auditor recognises as a control.
1) Define the scope: who is included
It is not only internal template work.
It includes people under control: employees, collaborators, contractors, temporary staff, and profiles that handle data or critical systems.
Here, it is key to document which teams are included—and why.
2) Map content by role type
A practical way to structure training is with three layers:
- Corporate layer (minimums for everyone): security hygiene, phishing and reporting, basic information handling, and discipline in the use of approved tools.
- Role layer (what each team truly does): HR, Sales, Support, Operations, IT/SecOps, etc.
- Risk layer (reinforcements): short modules when new vectors appear (changes in tools, new providers, incidents or near-misses).
3) Set a cadence you can actually maintain
A credible plan has frequency.
For it to be auditable, a common reference is:
- Onboarding in the first weeks
- Annual refresh as a baseline
- Quarterly micro-sessions (short and focused on “what is current”)
- Updates after incidents when there is demonstrable learning
You do not need to turn this into an infinite project.
You need it to be repeatable, and the calendar must have an owner.
Example of a minimal matrix per area (guidance)
The matrix does not have to be perfect on day one.
It must be honest and auditable.
So you can start with:
- Leadership / governance body: risks, oversight responsibilities, decision-making under pressure, and communications in incidents (without unnecessary technical detail).
- HR: employee data, lifecycle of the records, secure channels, onboarding/offboarding, and minimum privacy expectations in internal processes.
- Sales and marketing: customer and lead data, external sharing, common “urgent” requests, and limits on what you can promise or send.
- Customer support / support: identity verification, access, resets, escalation, and prevention of data leaks caused by good intentions.
- Operations and administration: shared files, providers, billing, and handling sensitive documentation.
- IT / SecOps: operational controls, incident recordkeeping, privileges, backups, and continuity (aligned to ISMS scope).
If you document which module each area receives, how often, and what evidence it generates, you will have an artefact that holds up when audit questions come.
Evidence an auditor will ask for (and how to prepare before)
Technology can fail. People can fail too.
What ISO, NIS2, and GDPR look for is that you have evidence that you train and that training is maintained and improved.
In an audit-ready approach, prepare at minimum:
- Plan: scope, audiences, objectives per role, periodicity, and responsible owners
- Delivery records: dates, attendees (or onboarding/offboarding events), materials used, and format (in-person, e-learning, short session)
- Evidence of understanding: simple evaluation (short quiz, simulation, scenario responses)
- Evidence of updates: content versioning, changes triggered by incidents, or contextual changes
If your roadmap is aligned with ISO 27001 certification, you may find it useful to review how preparation is structured in how to obtain ISO 27001 certification as a startup in the EU.
In audits, value is about coherence.
If your plan says you train every quarter but records show otherwise, the problem is not “the year”—it is traceability.
What they typically ask in a document review (short checklist)
It is not an exhaustive legal list, but it is often the “minimum credible” set:
- current version of the plan and its approval date
- executed calendar (even if simple) with real dates
- attendance lists or equivalent LMS records
- the materials used (PDF, video, internal script)
- evaluation results or simulations (even if basic)
- onboarding evidence for recent hires
- a record of content changes when you update, and why
If you can reconstruct the history with papers (or tickets) without relying on a single person’s memory, you are on the right track.
Sampling in interviews: what an auditor evaluates
Many audits do not stay in the file.
They ask people in different departments if they know who to notify, where the procedure is, and what they should not do (for example, re-sending sensitive data through unapproved channels).
If the plan exists but reality does not match it, a gap appears.
Onboarding and continuous learning: how to keep training alive
Training that “happened once” is not training.
It is an event.
To make it work as a control, you need a continuous chain: input, reinforcement, learning, and improvement.
Onboarding: minimum from day one
Every new hire should receive a basic package.
The key is not to overwhelm people, but to make sure they understand: which behaviours are expected and how to report risk signals without waiting to “learn more”.
Quarterly micro-sessions (no bureaucracy)
A short micro-session can be enough if it is connected to what happens in the quarter.
Typical examples:
- a phishing campaign observed,
- an improvement in procedures,
- or a change in tools used to share information.
Post-incident learning: training as remediation
When an incident or near-miss happens, the plan should reflect it.
This is not only about “repeating the course”.
It is about demonstrating that you learned:
- what failed,
- what was corrected,
- and what people learned so it does not happen again.
Providers, subcontractors, and temporary access
If a provider accesses relevant systems or data, the human risk also exists outside the employee population.
You may not be able to “train” them the same way as employees, but you can still define minimum requirements: limited access, policy acceptance, mandatory short training where applicable, and compliance evidence when relevant.
This reduces the typical gap: “we train internally”, but the provider enters without briefing.
How to integrate the training plan without duplicating work
A corporate training plan does not live in isolation.
It integrates into your management system and how you manage risk.
The goal is that the same artefact provides both internal coherence and audit readiness.
Integrate with your security and risk management
If you already have an ISMS or risk management system, look for: responsibilities and roles already defined, review calendars, internal audit mechanisms, non-conformities management and corrective actions.
Training fits there as living evidence of competence and awareness.
Unify what overlaps across the three frameworks
Although ISO 27001, NIS2, and GDPR are not the same, they share logic:
train, document, and maintain.
A single role matrix can cover: corporate minimums, team modules, and updates when risk changes.
That prevents each framework from asking you for “another different plan”.
Annual plan review: what must change yes or yes
Once a year (or when the context changes), review:
- whether roles are still the same (growth, new products, new markets),
- whether tools changed (new CRM, new cloud provider, new support channel),
- whether there were incidents or near-misses requiring a new module,
- and whether responsible owners are still correct (rotation, reorganisation).
Document the review as a decision: date, participants, and applied changes.
That is exactly the kind of continuous improvement signal that fits ISO and mature risk management.
Roles and responsibilities: who “owns” the plan
A plan fails when no one owns the calendar.
Define at least:
- an owner for the programme (who maintains the plan and coordinates execution)
- module owners by area or topic (for example, privacy, incidents, access)
- an escalation mechanism when someone detects a gap (employee → manager → security/compliance)
This is not bureaucracy for the sake of bureaucracy.
It is the simplest way to ensure training does not depend on one person—and does not pause during holidays.
Spain: FUNDAE as an execution lever (when it fits)
In Spain, many organisations can leverage subsidised training schemes for programmes aligned with cybersecurity and privacy.
It does not replace plan design or regulatory evidence, but it can help you maintain cadence across large teams.
If you use funding, keep documentary discipline: what was delivered, to whom, when, and with what outcome.
Mistakes that can slow you down
Limiting training to IT or leadership
If you only have IT records or you only train leadership, the plan leaves a visible gap.
Incidents often start in everyday processes and non-technical teams.
Not defining scope and audiences by role
A plan without a role mapping does not allow you to prove proportionality.
The auditor must see why each team receives the content they receive.
Not documenting evidence (attendance, materials, and evaluation)
When there are no traceable records, the plan becomes declarative.
ISO, NIS2, and GDPR rely on your ability to show that training happened and was effective.
Not updating the plan after changes or incidents
If tools, providers, or new vectors appear, training must evolve.
A static plan contradicts the continuous improvement logic.
How PrivaLex can help with a corporate training plan
At PrivaLex we design and structure training plans so you can meet ISO 27001, NIS2, and GDPR in an integrated way.
We focus on ensuring the plan is:
- Relevant by role (not “a generic course”)
- Auditable (with coherent records and evidence)
- Operational (including onboarding and post-incident learning)
- Sustainable (a cadence you can truly maintain)
If you operate in Spain, we also help with the FUNDAE funding part when it applies.
Schedule a strategic session with PrivaLex and review your starting point.
Frequently Asked Questions (FAQs)
Yes, if the plan is role-based, has cadence, and maintains evidence.
The important part is that what you train is coherent with what each framework expects.
In practice, a content map usually works well: each module indicates which requirement it covers (security, cyber-resilience, privacy) and why it applies to that role.
That way you avoid duplicating courses, and you also avoid leaving out a requirement because “that belonged to another department”.
As a baseline, onboarding plus an annual refresh usually works.
Quarterly reinforcements and post-incident updates turn the plan into an operational control.
The actual frequency depends on your risk and how quickly your organisation changes: a scale-up that changes tools every month needs more micro-reinforcement than a stable operation.
Attendance records, materials used, and some form of evaluation mechanism.
Also, the ability to show how you update content when risk changes.
If you can demonstrate coverage (who should have received it and who did) and reasonable effectiveness (evaluation, simulation, or measurable improvement), you typically reduce friction in reviews.
If they operate under your control or process relevant information, they should be included in the scope.
The key is ensuring they receive minimum onboarding and their operational obligations.
If access is occasional, at least document briefing, policy acceptance, and access revocation date once the assignment ends.
It is recommended to deliver a basic package in the first few weeks.
It should cover expected behaviours, reporting risk signals, and tool-use discipline.
Ideally, onboarding connects to the person’s first working day: before someone accesses sensitive data, they already know what they can do and what they must escalate.
If the incident reveals a competence or awareness gap, the training update should reflect it.
Post-incident training is how you demonstrate remediation and prevention.
Sometimes a short module is enough, as long as you can show attendance/comprehension evidence and keep learning traced.
Next step
If your goal is to create a training control that is consistent and demonstrable, start by defining scope, roles, and evidence.
Schedule a strategic session with PrivaLex and we will help you turn it into an audit-ready plan.
Free webinar; 20 of May: Get audit-ready for NIS2, ISO 27001 and ENS with PrivaLex & Factorial IT.
View webinar