The same incident looks different from a console, a cabinet, a SOC and a board seat. Training that ignores that produces awareness, not capability.
Scope
Four audiences, two mechanics that make them work.
Tracks are selected against the gap that actually exists. Most organizations need two or three of them, not all four, and scoping establishes which before anything is built.
Control engineers and automation staff
Security concepts expressed in the terms this audience already works in: PLC, DCS and SCADA configuration practice, engineering workstation handling, portable media and project file transfer, vendor and OEM access, change control, and what to do with an observation that looks wrong. The emphasis is on the decisions they take every week, not on threat taxonomy.
IT and security teams entering OT
Process context, safety concepts, availability expectations, asset lifecycles measured in decades, and why a practice that is routine on the enterprise estate can be consequential on a process network. IT brings enterprise governance, identity, scale and operating discipline. OT brings process knowledge, engineering context, safety awareness and an understanding of consequence. This track is built so each side can use what the other holds, not so one absorbs the other.
Operations supervisors and shift teams
Short, practical sessions for the people on shift when something looks unusual: what is worth escalating, who to call, what information to capture, what not to change while it is being assessed, and how a cyber-related event differs from the process upsets they already handle well. Built to fit around shift patterns rather than assume classroom availability.
Executives and boards
What cyber-physical risk means for safety, production continuity and regulatory position, what the organization is currently accountable for, what a credible program looks like, and which decisions only leadership can take. Delivered as a working session, sized for a board agenda, with the organization's own exposure as the worked example.
Incident-response tabletop exercises
Scenarios written from your architecture, your vendor arrangements and your escalation routes, run with the people who would actually be involved. The value is rarely the scenario itself. It is discovering which decision has no owner, which contact list is out of date, and which assumption about a recovery path has never been tested.
Competency assessment and capability plan
Where each role stands against the competencies it needs, recorded so it can be tracked, and a written capability plan setting out what the organization can now run without external support, what it should bring in-house next, and where retaining a supplier is the deliberate choice rather than the default one.
People do not act on what they were shown. They act on what they have practiced.
Tracks in detail
What each track asks of a person, and what it leaves them able to do.
Each track states its boundary as plainly as its content. A course that claims to cover everything a role needs is the reason training gets treated as a formality.
Who it is for, and what they leave able to do
Engineers and technicians who configure, maintain and troubleshoot PLC, DCS and SCADA systems, and who take consequential decisions weekly without thinking of them as security decisions.
- Handle project files, portable media and engineering workstations in a way that does not defeat the controls installed around them.
- Recognize which routine actions carry security consequence, and which observations on a system are worth raising rather than working around.
- Supervise vendor and OEM access, including knowing what to insist on before granting it and what to check when it ends.
- Read a zone and conduit model well enough to say whether a proposed change respects it.
- Raise a security-relevant change through change control with the operational reasoning already articulated.
Format, and what it does not cover
Typically one to two days on site, run in blocks around plant commitments, using your architecture and procedures as the worked examples. Delivered to small groups so people can argue with the material.
- Not a security certification, and not a substitute for one where a role genuinely requires it.
- No malware analysis, reverse engineering or offensive technique. Recognition and escalation, not investigation.
- Safety instrumented systems are covered conceptually only and are never used as a teaching environment.
- Equipment controlling a running process is never used for training, which means some behavior is demonstrated on bench, spare or isolated equipment, or described.
Who it is for, and what they leave able to do
Enterprise security, infrastructure and identity staff taking on responsibility for industrial environments, usually competent people whose existing instincts are correct on the corporate estate and occasionally dangerous on a process network.
- Explain what a process does, what a safe state is, and why availability and integrity rank differently here.
- Judge when an enterprise practice transplants cleanly, when it needs adaptation, and when it needs a documented exception with a named signer.
- Ask an engineer a useful question about a system, and understand the answer well enough to act on it.
- Work with asset lifecycles measured in decades, vendor support constraints and maintenance windows as design inputs rather than obstacles.
- Take a security requirement into a plant conversation in language that engineering will engage with.
Format, and what it does not cover
Typically two days, and strongest when it includes a supervised plant walkdown. Frequently run jointly with the control engineering track so both groups hear the same material in the same room.
- It does not make anyone a control systems engineer. It transfers context and judgment, not operating experience.
- No vendor platform configuration training. Product courses belong with the product supplier.
- It will not settle who owns what in your organization. That is a governance decision — see OT CISO Advisory.
- It does not close an architecture gap. Knowing why segmentation matters is not segmentation.
Who it is for, and what they leave able to do
The people actually on shift when something looks wrong, who are already expert at diagnosing process upsets and who have rarely been given any framework for the ones that are not process upsets.
- Tell the difference between a familiar process disturbance and something that warrants a different kind of call.
- Know who to contact, in what order, at what hour, without looking for a list nobody has updated.
- Capture what matters at the time: what was seen, when, on which screen, and what was done next.
- Know what not to change while an event is being assessed, and why a well-meant restart can remove the evidence.
- Raise something uncertain without needing to be sure first.
Format, and what it does not cover
Short sessions built around shift patterns rather than classroom availability, repeated across crews so every shift receives it. Normally under two hours per session, with a one-page reference that stays in the control room.
- No technical investigation or analysis. The objective is accurate escalation, not diagnosis.
- It does not give anyone new authority. Decision rights are a governance matter and this track teaches the ones that already exist.
- It is not generic awareness training, and it will not satisfy an organization looking for a completion statistic.
- Scheduling is agreed with the roster holder before anything is built, so crews can be released for it.
Who it is for, and what they leave able to do
Directors, audit committee members and executive teams who carry accountability for cyber-physical risk and have generally been briefed on threats rather than on the decisions that are theirs to take.
- Describe what a cyber event in the operation could mean for safety, production continuity, environmental exposure and regulatory standing.
- Ask an informed question of a security or engineering report, and recognize an answer that avoids it.
- Identify which decisions only leadership can take: accountability, funding sequence, risk acceptance and the standing of an exception.
- Judge whether a proposed program is a coherent capability or a sequence of purchases.
- Record a defensible decision, including a decision to accept a risk with reasons attached.
Format, and what it does not cover
A single working session sized for a board agenda, normally ninety minutes to half a day, using your own exposure as the worked example rather than an industry anecdote.
- No technical depth. If a director wants the engineering detail, the right answer is a session with your own engineers, not a longer slide pack from us.
- It is not a scare session. Fear produces a budget once and cynicism afterwards.
- It does not substitute for a reporting position leadership can track between meetings — that is R.I.S.E. 360™.
- We will not present a position on your exposure that is more comfortable than the evidence supports.
How the material is built
Your architecture is the worked example, not a generic one.
Generic training produces recognition. Training built on your own systems produces recall under pressure. These conditions are agreed before the material is written.
- Your systems and procedures — examples drawn from your architecture and documented practice where access allows
- Hands-on where it is safe — bench, spare or simulated equipment, or your own equipment while isolated from the running process
- Safety systems out of scope — SIS is covered conceptually, never used as a teaching environment
- Vendor-independent content — no product we teach around earns us a margin
- Material handed over — content, exercises and assessment records remain yours to reuse and re-run
Fit
When this is the right engagement, and when it is not.
Use InnovAKT Academy when
- Controls have been deployed and the people expected to operate them were never trained on them.
- An IT or security team is taking on OT responsibility and needs process and safety context before it does.
- IT and OT teams are working from different assumptions, and the gap is knowledge rather than intent.
- A response plan exists on paper and has never been exercised by the people named in it.
- You are reducing dependence on external support and need to know which capabilities can move in-house.
- A regulator, insurer or customer expects evidence of role-based competency rather than attendance records.
Start with another service when
- The exposure is structural. Segmentation, remote access and control weaknesses are engineering work, and our engineers deliver it through AKTSecure™.
- Nobody has established what the risks actually are. Start with GoSecure™ so the training addresses real exposure.
- What you need is leadership for the program rather than skills for the team — see OT CISO Advisory.
Framework alignment
Grounded in the standards your engineers and vendors already use.
Content is structured around ISA/IEC 62443, including its treatment of roles, responsibilities and competency requirements. The standard is explicit that security is distributed across asset owner, integrator and product supplier, which makes it a natural spine for training organized by role rather than by topic.
NIST SP 800-82 provides the ICS-specific grounding: control system architecture, operational constraints, and why enterprise security practice has to be adapted rather than transplanted. It is the reference that does most of the work in the track for IT and security teams entering OT.
Regulatory awareness modules are included only where a regime actually governs you, and are scoped during planning. Teaching a team the obligations of a framework that does not apply to them consumes the attention they need for the ones that do.
Outcomes
What is different in the organization afterwards.
Work that can move in-house
A written view of which capabilities your teams can now run themselves, so continued external support becomes a decision you take deliberately rather than one you inherit.
A shared vocabulary
IT, security, engineering and operations describing the same exposure in terms all four recognize. A considerable share of IT and OT friction is translation before it is disagreement.
Escalation that happens
Shift teams who know what is worth raising, who to raise it to, and what to preserve while it is assessed. Early reporting depends on people being confident that reporting is welcome.
A plan tested before it is needed
Gaps in ownership, contact routes and recovery assumptions found during a tabletop exercise, where the cost of finding them is an afternoon.
Deliverables
What you receive, in writing.
Track selection, session length and delivery format are agreed in scoping. These four are present in every program.
Role and competency map
Which roles need which competencies, where each currently stands, and which tracks close the gap. The basis for track selection, and reusable as new staff join.
Tailored training material
Session content, exercises and reference material built against your architecture and procedures where access allows, handed over in editable form for you to re-run.
Tabletop exercise pack and findings
Scenarios written from your environment, the facilitation material to re-run them, and a written record of ownership, communication and recovery gaps identified during the exercise.
Capability plan
What the organization can now run without external support, what should move in-house next, what to retain externally by choice, and the refresh cadence required to hold the position.
Engagement process
Five steps, built around your roster.
Duration depends on track count, audience size, shift patterns and site spread. Scoping establishes it before any commitment is made.
Capability gap and audience mapping
Roles identified, current competency established, and tracks selected against the gap that actually exists. Where a recent assessment is available, its findings shape the content so training addresses your exposure rather than a general syllabus.
Material build against your environment
Content written using your architecture, procedures and vendor arrangements as the worked examples, within the data-handling rules agreed in scoping. Material is reviewed by your technical team before delivery.
Delivery, scheduled around operations
Sessions run in blocks that fit shift patterns, maintenance windows and site access arrangements. On-site, remote or blended, agreed in planning rather than assumed.
Tabletop exercise
A scenario from your own environment run with the people who would be involved, including operations and engineering rather than security alone. Findings recorded as they emerge and walked through at the close.
Assessment and capability handover
Competency assessed and recorded, material transferred in editable form, and a working session with leadership to agree the capability plan and the refresh cadence that keeps it current.
Questions we are actually asked
What training managers and shift leads ask first.
Our people have already done awareness training.
Then awareness is probably not the gap. Awareness training tells people that a category of risk exists. It rarely changes what an engineer does with a project file on a Tuesday, or what a supervisor does at two in the morning with a screen behaving oddly.
These tracks are built around the decisions a role actually takes. Where your organization needs awareness coverage only, we deliver that too, as a shorter and lighter engagement.
Will you train people on our live systems?
On your own systems and procedures, yes, but never on equipment controlling a running process. Your architecture, procedures and vendor arrangements are the worked examples, within the data-handling rules agreed in scoping. Hands-on practice runs on bench or spare equipment, in a simulated environment built to mirror your systems, or on your own equipment while it is out of service and isolated from the running process, in a window operations schedules and supervises.
Safety instrumented systems are covered conceptually and never used as a teaching environment. Everything else is planned with operations, so each session is as practical as the plant can safely support.
We cannot release operators for a full day.
The supervisor and shift material is built for exactly that constraint: short sessions, repeated across crews, scheduled around the roster rather than assuming classroom availability. Engineering tracks can be split into blocks across a shutdown or a quiet period.
What does not work is booking training against a roster that cannot support it. It gets deferred twice, then delivered to whoever happened to be available, which is how training ends up recorded as complete and absent from practice. We agree the schedule with the person who owns the roster before anything is built.
Do people get a certificate at the end?
Competency is assessed against the requirements of the role and recorded per person, and that record is yours to hold, reuse and show to a regulator, insurer or customer asking for evidence of role-based competency. It is a competency record rather than an accredited qualification, and we describe it that way.
Attendance is recorded too, for the audit trail. The competency record is what holds when someone checks, and it is what the program is built to produce.
Can you train our IT security team to run OT?
Yes, as a program rather than a single course. The track transfers process context, safety concepts and the judgment to know when an enterprise practice needs adapting, so a capable team can start working in an industrial environment without doing harm while it learns.
The rest comes from supervised time on plant alongside engineers who have it, which our engineers and OT CISO Advisory can provide while your team builds experience. Training shortens the period in which a well-intentioned enterprise practice produces an operational surprise, and engineering accountability and judgment stay in the room.
What stops this becoming a permanent training contract?
The material is handed over in editable form, including exercises, facilitation notes and the tabletop scenarios, so your own people can re-run sessions as staff join and roles change. The capability plan states what you can now run without us and what should move in-house next.
A refresh cadence is normally required and we say so rather than imply a single engagement is permanent. It is modest: content revision when the architecture changes materially, and a re-run of the tabletop on a schedule. If that turns into an annual repeat of the same delivery, the training did not transfer and that is a failure worth naming rather than renewing around.
Next step
Start with one track and one exercise.
A single audience and one tabletop establish the format, the effort and how much of your own environment can be used before anything is committed across the estate. It also shows you quickly where the real gap sits.
- Tracks selected against a real gap — not a standard catalog
- Never on a running process — hands-on work uses bench, spare, simulated or isolated equipment
- Material handed over — yours to re-run as people join and roles change
- Built to reduce dependence — the capability plan says what you no longer need us for
Questions buyers ask
The three things we are asked before we start.
What is InnovAKT Academy?
InnovAKT Academy is the training arm of the firm: OT cybersecurity education for control engineers, IT and security teams, operations staff and executives, taught by consultants who deliver the work rather than by career trainers, and built around the client's own environment where that is possible.
Who should attend OT cybersecurity training?
Training is tailored to four audiences: control and automation engineers; IT and security professionals working with OT; operations supervisors and shift teams; and executives and boards. The selected tracks depend on the capability gaps and responsibilities in your organization. Not every engagement needs all four.
Is InnovAKT Academy training based on IEC 62443?
IEC 62443 and the NIST Cybersecurity Framework provide the structure, because those are the frameworks clients are measured against. The teaching itself is built on field cases, because a standard tells you what to achieve and a case tells you what it looks like when it goes wrong.