

When to use this service
You've lost track of what's connected
The installation has evolved through projects, integrators, and maintenance handovers. No one has an up-to-date inventory or a reliable flow diagram between the shop floor, supervision, and the corporate network.
A regulatory deadline is approaching
Your entity falls within NIS2 scope, a client requires a security level aligned with IEC 62443, or your group is asking for a site-by-site assessment. You need a documented baseline before committing to anything.
An incident or a lingering doubt
A supervision station restarted with no identified cause, an antivirus raised an alert on a control room PC, or a remote maintenance connection was left open after an intervention. You want to know what's exposed, and since when.
An interconnection or modernization project
Production data flowing up to IT, a new building management system, adding vendor remote maintenance, migrating a control system. The audit serves as a starting point before opening new data flows.


An industrial system wasn't designed to be audited. PLCs in service are sometimes twenty years old, field protocols provide for neither authentication nor encryption, and the original documentation no longer describes the actual installation after years of extensions, maintenance handovers, and successive integrator interventions. The first task is almost always to establish what's actually connected.
The second difficulty is the operating constraint. An active scan, a malformed request to an old PLC, and the line stops. This is why data collection relies on passive observation of network traffic, with no injection into the production network. Methods inherited from business IT don't transfer as-is to a substation or a control room.
Finally, an OT audit isn't judged by the number of vulnerabilities listed. On a live installation, many technical weaknesses can't be fixed right away: a PLC isn't updated outside a shutdown window, a supervision station stays on a system validated by the vendor. The value of the work lies in the prioritization: what needs to be addressed immediately, what waits for the next scheduled shutdown, what falls under an investment plan.

How the audit unfolds
Five steps, scheduled around your operating constraints: no interruption to production, no operational downtime. The operations teams are involved at every step.
Defining the scope: sites, workshops, substations, control systems involved. We list operating constraints, possible intervention windows, equipment not to touch, and points of contact on the operations, maintenance, and IT sides.
Review of architecture diagrams, equipment lists, wiring plans, operating procedures, maintenance contracts, and remote access accounts. This step mainly serves to measure the gap between what's documented and what's in service.
Passive observation of network traffic, no injection into the production network. In parallel: OT asset inventory, PLCs, HMIs, supervision stations, network equipment, remote access, review of cabinets and racks, interviews with the operations and maintenance teams.
Reconstruction of the actual architecture and observed flows, then zone and conduit segmentation under IEC 62443. Each finding is tied to a risk level, a remediation effort, and an owner.
Two-part presentation: a technical session with the operations teams to validate findings point by point, a summary for management focused on operational risks and decisions to be made.
What you receive
The audit report
The detailed findings by system and by zone, each with a risk level, an estimated remediation effort, and an identified owner. Written to be read by a control engineer and a CISO alike.
The OT asset inventory
PLCs, HMIs, supervision stations, network equipment, remote access: make, model, firmware version, addressing, role in the process. Delivered as a file your teams can keep up to date.
The flow map
Diagrams of the architecture actually observed, exchanges between OT and IT, remote entry points, and the proposed zone and conduit segmentation under IEC 62443.
The remediation plan
A remediation plan prioritized across three horizons: immediate, 6 months, 18 months. Each action indicates the expected security gain, the operating window required, and who can own it in-house.
[ Help & support ]
Frequently asked questions
Can't find your answer here? We're available to talk about it. Tell us about your environment, constraints, and security challenges.
The consultant works under your operating rules, not their own. No action on production equipment is undertaken without the operator's approval and without going through your internal lockout and change management procedures.
For anything involving data collection on sensitive networks, the method stays the same as on our audits: traffic analysis from a mirror port, with no action on the process. Active testing is reserved for test environments, spare equipment, or planned shutdown windows.
No. The survey phase is done through data collection with no solicitation of field equipment, supplemented by interviews and configuration reviews. We work under real operating conditions, with no interruption to production.
Some actions in the remediation plan, however, will require a shutdown window: changing a network architecture or updating a PLC's firmware can't be done while running. That's precisely why the plan is split into three horizons: actions that require a shutdown are scheduled around your planned shutdowns, never imposed outside of them.
No. The survey relies on traffic capture in listen-only mode, with nothing sent to the equipment: traffic is captured via a mirror port or a TAP, with nothing sent to the PLCs. No active scan, no query to a piece of field equipment is launched without your written approval and outside production hours.
Physical work in cabinets and racks is scheduled with operations, and someone from your side is present. If an action carries the slightest risk to the process, it's postponed or dropped.
No. No action touches a live system without your approval and an agreed intervention window. Surveys are conducted through passive monitoring, with no queries sent to the PLCs.
Fixes that touch a PLC, a network, or a supervision system are scheduled around your shutdowns and carried out by your teams or your integrators. We prepare, we verify, we don't cut anything.
The risk is never zero on an industrial network, and no one serious will tell you otherwise. That's exactly why the method is built around this constraint: during normal operation, with no shutdown window.
In practice, the discovery phase is done by analyzing traffic from a mirror port, with no action on the process. Active actions are planned with operations, governed by written stop conditions, and a member of your team stays reachable throughout the engagement. Anything that can't be run without risk is run on a test bench, on a spare PLC, or during a scheduled shutdown. Anything that remains too risky isn't run at all: the scenario is documented and its impact described, without being executed.
That's actually the most common case. The first module is built to settle this point: Annex I and II sectors, size criteria, the case of subsidiaries and foreign groups. You leave with a written, justified qualification. We provide a technical and operational reading of the text, not a legal opinion: if your situation presents genuine ambiguity, it will need to be confirmed by your legal department or counsel.
No. The session is held in a classroom, with production maintained throughout, and no exercise is run on the production network. The setup adapts to shift changes: two identical sessions on the same day to cover two shift teams, or two spaced-out half-days. Control room positions stay staffed during the training.
Yes. The content covers mechanisms common to all ranges: lack of authentication in industrial protocols, protecting the project and programming mode, account management on the HMI, filtering between zones. The training rig uses specific hardware to make the demonstrations concrete, then each measure is transposed onto the equipment present at your site. If your fleet is homogeneous, we align the training rig and configuration sheets with your main vendor.
No. The day starts from the sensor and rebuilds the entire chain, with no assumed prior experience in PLC programming. The only useful prerequisite is general IT literacy: IP addressing and basic local network concepts. Your site's control engineers get value from it too, since the networks and protocols section covers points rarely addressed in vendor training.
Yes. No prior reading is required. The first module starts from the structure of the standard and the split of roles between operator, integrator, and vendor. What matters is knowledge of the installation: being able to read a schematic, and knowing the PLCs, links, and access points in service.
We don't place a generalist profile on an industrial need. The consultant we propose has already worked on control systems, knows the protocols involved, and understands what an availability constraint means on a live installation.
Another difference: the consultant isn't alone. They draw on the rest of the team for topics outside their scope, an architecture review or protocol analysis for instance, without changing your point of contact.
It depends on your sector of activity, your size, and the role you play in a critical chain. The national transposition specifies the categories of essential and important entities, and the obligations aren't identical for the two. Some of the operators concerned haven't yet been formally notified.
The first scoping step is used to settle this point, based on the evidence. If the applicable regime remains uncertain, we say so and tell you which obligations are worth putting in place regardless of classification.
Concretely: a few hours to gather existing documentation, 45-minute to 2-hour interviews per contact (operations, maintenance, automation, IT), and someone accompanying us on site during the survey phases, mainly for access and safety.
The workload is concentrated in the survey week. The rest of the work happens off-site, and the presentation needs two slots: one technical, one for management.
The pace is set during scoping, based on the size of your fleet, the number of sites, and ongoing projects. The typical pattern combines a periodic review meeting, scheduled on-site days, and availability for one-off questions between meetings.
There's no single format: a site running in a stable regime and a multi-site group in the middle of a supervision migration don't have the same needs.
An audit answers the question “where do we stand”: it covers the entire scope, architecture, configurations, and operating practices, and produces a complete assessment. A penetration test answers a different question: “how far can you go,” on a limited number of paths, with evidence.
The two complement each other, and the usual order is the audit first, then the test. A test launched with no prior knowledge of the installation costs time in discovery and needlessly increases operational risk.
There are no technical prerequisites. The day is designed for a mixed group: site management, production, maintenance, IT, compliance. It's actually the most useful setup, because the NIS2 scope gets decided at the intersection of these functions. A maintenance manager brings knowledge of the PLCs and integrator interventions that IT generally doesn't have.
Yes, that's exactly the intended audience. The day's thread starts from the process and the equipment participants handle: PLC, HMI, supervision station, network rack. Security concepts are introduced progressively, based on what they change in operations. An operator who knows their installation has more to contribute in modules 2 and 3 than an IT person who has never seen it.
No. All hands-on work happens on an isolated training rig brought by the instructor: PLC, HMI, supervision station, and network equipment. No action is taken on your production network, neither read nor write. The exercises that involve your actual installations are done on paper and on your diagrams.
Awareness training is aimed at all site personnel and covers behavior: USB drives, fraudulent messages, reporting, physical access. It requires no technical background. This day is aimed at people who work on the systems or make decisions about them, and it goes into the actual workings of the equipment, networks, and protocols. The two are complementary and can be taken in that order.
No. It's a hands-on practical training, not a certifying program. Participants receive a certificate of attendance and all the deliverables produced during the day. A personal certification comes from an accredited body, a product or process certification comes from a certification body.
Assignments range from a few days a month on a specific topic to continuous presence over several months to hold a position. The pace is set during scoping and can be revised if your workload changes.
We prefer to state real availability rather than theoretical availability: if the requested profile isn't available for the period you want, we say so at the scoping stage.
No, IEC 62443 is a standard, not a regulation. It becomes binding when a client, an insurer, or a contract requires it, which is increasingly common in the energy sector and among large industrial operators.
Its value lies elsewhere: it provides the vocabulary and method that NIS2 lacks on the technical side. NIS2 requires appropriate risk management measures, IEC 62443 says how to structure them on a control system. The two work well together, which is what we do within a single assignment.
No, and it's actually the most common case. On an installation that's been running for fifteen or twenty years, the gap between the original diagrams and reality is one of the expected findings, not an obstacle.
Reconstructing the actual architecture is part of the assignment: it's often even the deliverable teams reuse the longest after the audit.
No. We don't operate your installations and we don't have permanent access to your industrial network. Our role is analysis, trade-offs, and preparing decisions, not running the plant.
When access is needed for a survey, it's named, time-limited, and logged, following your internal rules. The operations teams are involved at every step.
On an industrial environment, a fully blind test yields little and carries a lot of risk. Without knowing the equipment present, a tester probes PLCs they shouldn't be touching.
We favor an informed approach: you provide the schematics, addressing plans, and inventory you have, and we check the gap against what's found on the ground. The “blind” part is kept where it makes sense, meaning at the starting point of the scenario, for instance from a standard office workstation with no special privileges.
No, and we don't present it that way. One day lets you define the scope, measure the gaps, and write a prioritized plan. Implementation is a project measured in months: network segmentation, remote access management, PLC program backups, vendor clauses. The training gives you the framework and the order of the work. Depending on the gaps found, the next step is an industrial cybersecurity audit or long-term support.
Yes, and it's preferable as long as the group doesn't exceed 12 people. The three trades don't see the same signals: operations sees a setpoint drift, maintenance sees a piece of equipment restarting, supervisors see an unplanned contractor intervention. It's by comparing these observations that the reporting chain gets built. For a large headcount, it's better to split by shift team than by trade.
It's built for them. The prerequisite is knowing your installation, not knowing IT security. The necessary networking concepts are introduced over the course of the day, starting from the control system chain that participants have drawn themselves. Feedback shows the difficulty tends to run the other way: a participant coming from IT discovers the process's availability constraints.
It's actually the most useful setup. A good part of the difficulties we observe during audits comes from a shared vocabulary that covers different realities, and from operating constraints that IT isn't aware of. The exercises in modules 4 and 5 are designed to bring together profiles that rarely cross paths day to day. A mixed group of 10 to 12 people works well.
It's the format we prefer, because the workshops become directly useful. The documents are shared beforehand under a confidentiality agreement, used during the session, then returned or destroyed as you instruct. If they can't leave the site, the session is held at your premises, on your own workstations. A sample installation is available as a fallback.
Part of the work is done remotely: configuration analysis, documentation drafting, compliance file preparation, diagram review. Anything that requires seeing the installation, understanding an operating mode, or interacting with the field teams is done on site.
The split between on-site presence and remote work is set during scoping, and it takes your remote access rules for OT networks into account.
Yes. A significant part of the industrial fleet is built on equipment designed before security entered the specifications. No one expects it to be replaced immediately, and the standard accounts for this case.
The answer lies in compensating measures: isolating the PLC in a dedicated zone, strict filtering of the conduits leading to it, controlling maintenance access, monitoring traffic. The requirement shifts to the perimeter, not the equipment. These measures are documented as such in the report, along with the residual risk they leave.
Yes, because the fix is almost never the patch. On a PLC that can't be patched or that's under a vendor contract, you act on what surrounds it: segmentation, flow filtering, removing unnecessary remote access, hardening engineering workstations, controlling USB drives and maintenance computers.
The audit tells you precisely which equipment can't be fixed, and which compensating measures reduce its exposure until it's replaced.
Yes, it's a significant part of the work. A good part of OT security issues plays out in specifications, installation acceptance tests, and remote maintenance conditions.
We review specifications, take part in technical meetings, and draft requirements verifiable on acceptance. We remain independent: we don't sell equipment or licenses and aren't tied to any vendor.
In practice, full isolation rarely holds up under scrutiny. The paths we find most often are remote maintenance access left open by an integrator, external contractors' laptops plugged directly into the industrial network, firmware update USB drives, 4G routers installed by an equipment vendor for its own monitoring, and production data servers that talk to both sides.
The test exists precisely to verify this assumption rather than take it for granted. For a substation operator, the assumed isolation was real on paper; a single engineering workstation shared between two zones was enough to bypass it.
Yes. The day is held in a classroom at your site, without touching process availability. The exercises are based on your plans, your inventories, and your organization, not on handling equipment. If you'd like, a short visit to the control room or a technical area can be included in the early afternoon, respecting your access rules and prevention plan. We keep the group at 8 to 12 participants: beyond that, the small-group exercises lose their value.
Modules 1, 4, and 5 follow a common thread, illustrated with anonymized cases from audits on comparable installations. Modules 2 and 3 are built around your site, based on a preliminary discussion with the operations manager: architecture diagram, type of PLCs and supervision, list of remote access and contractors. It's your architecture that gets drawn on the board, not an example.
It's the format we recommend. We ask beforehand for your schematics, your addressing plan, and the list of your remote access, under a confidentiality agreement. The zone segmentation and hardening exercises then work on your own installation, and the remediation plan produced at the end of the day is directly usable. Failing that, we work on a sample case close to your sector.
No. All hands-on work happens on the training rig brought by the instructor, isolated from your network. The traffic captures and diagrams used in the exercises come from real assignments and are anonymized. If the day is held on your site, an installation visit can be arranged at the end of the program, for observation only, with the agreement of operations and under their supervision.
Yes, it's the most useful format. Zone segmentation is decided between those who run the process and those who run the network, and the day is also meant for that confrontation. We limit the group to 12 people so the workshops stay manageable. Beyond that, we split the session in two.
No, and the setup is built to avoid it. The operations teams are involved at every step, documentation is produced as the assignment progresses rather than at the end, and a handover is organized with the people taking over the topics.
If you'd like to keep a connection after the consultant leaves, that falls under our long-term support and expertise offer, not an automatic extension of the reinforcement.
No, and it needs to be said clearly: compliance isn't a permanent state. A line extension, a new integrator, a supervision change, or an update to the standard call part of the file back into question. NIS2, in fact, requires an ongoing approach, with incident management and risk review over time.
What the assignment leaves you with is a reusable foundation. You stay in control: the report, flow diagrams, and configuration files remain usable in-house after the assignment. Your teams can update the zone segmentation and the evidence file without starting from scratch. If you'd prefer long-term support, that's the purpose of our long-term support and expertise offer.
No. You stay in control: the report, flow diagrams, and configuration files remain usable in-house after the assignment. Your teams or your regular integrator can handle the remediation plan without us.
If you'd like support to drive the actions, follow up with vendors, or prepare a compliance program, that falls under our long-term support engagements, and it's decided after the report, not before.
You carry on without us. You stay in control: the report, flow diagrams, and configuration files remain usable in-house after the engagement. Nothing is locked into a tool you can't access.
The goal, in fact, is to build your teams' autonomy on the subject, not to create a dependency.
No, and it needs to be said clearly. NIS2 requires risk management, technical and organizational measures, governance, and incident notification capability. IEC 62443 requires zone and conduit segmentation, target security levels, and component-level requirements. No penetration test covers all of that on its own.
That said, the test feeds into these efforts: it provides evidence of the effectiveness of measures in place, it documents the attack scenarios used in the risk analysis, and it gives the compliance file a factual element rather than a declarative one. It's part of a compliance program, not a replacement for one.
All the working materials are delivered in editable format: qualification grid, OT asset inventory template, Article 21 gap matrix, early-warning template, three-horizon plan table. They're designed to be picked up and updated by your teams. The day's content is revised with every update to the national transposition and implementing texts, and we flag during the session the points still likely to change, so you don't build your plan on an unstable reading.
No, and it needs to be said clearly. Staff awareness is one of the expected measures, but not the only one: governance, incident management, supply chain control, and technical measures require separate work. The session provides the elements to add to your file: detailed program, list of participants, attendance certificate, rules sheet drafted on site. The rest relies on an audit and a three-stage roadmap, from the immediate fix to the investment plan.
Technical Fundamentals lays out the OT landscape as a whole and is aimed at a broader audience, including non-technical staff. IEC 62443 in Practice covers the standards-based approach and its application at the scale of a site or an organization. This one focuses on a single subject, the control system, and on the configuration steps that protect it. The three follow in that order, but each can be taken independently.
Each participant leaves with the full course materials, the asset inventory template, the intervention checklist built during the session, and the captures used in the exercises. A certificate of completion is given to each participant, and a session summary is sent to the training manager. The logical next step depends on your needs: IEC 62443 in Practice for architecture and compliance, NIS2 for the regulatory side, or an audit if the goal is to establish the actual state of an installation.
The segmentation produced in the workshop is a starting point, not a compliance file. The usual next step is a survey of the installation to compare that segmentation against the actual flows, under real operating conditions, through data collection with no solicitation of field equipment. Your teams can also carry on alone: the files and templates remain usable in-house.
[ our other services ]
Our other industrial cybersecurity expertise
From the initial audit to long-term support, we cover the full cycle of securing your industrial systems. Every engagement is tailored to your environment and operating constraints






