A fifteen-person competence centre or an external architect: how a mid-sized plant covers the skills gap between production, IT and security

The author of the piece on cyber resilience I discussed in the air gap illusion described the staffing problem of the power sector more precisely than I have seen anywhere else. A modern protective relay engineer needs network protocols, cryptography and information security. Graduates with those skills exist, but there is no demand for them, because power companies do not know how to evaluate them. His prescription: large companies should build competence centres of 10 to 15 specialists at the junction of power engineering, IT and security, change the corporate culture and the pay system. Such people will be in demand for the next 10 to 15 years.

For a large utility that is the right prescription, and I will not argue with it. This piece is for those who cannot follow it: a plant of three hundred or a thousand people in metals, chemicals, mining or power distribution, which has a critical infrastructure object by the sector list, a transition plan to trusted platforms handed down by the ministry, a predictive maintenance model on the line, an IT department of five, and security handled by the sysadmin on the side.

Such a plant faces the same requirements as the large company. It will never have a competence centre. The question is how to close the gap, and I have a structure that works. Readers outside Russia will find the regulatory references local but the problem universal: mid-sized industrial companies everywhere are being asked to meet enterprise-grade security obligations with a handful of people.

Why a competence centre is out of reach for a mid-sized plant

Four reasons, none of them about the owner's willingness.

Money. Fifteen specialists at the junction of three disciplines at market rates is a payroll comparable to the budget for modernising a line. For a holding company it is a line item; for a plant it is a choice between people and equipment.

The market. By estimates from the digital ministry and industry studies, the shortage of information security specialists in Russia is now around 50,000 people, rising to 55,000 to 65,000 by 2027. At the junction with industry and energy the shortage is deeper, because only a handful of universities train such people. Large companies with competence centres take them first and pay more. A plant in a regional city stands last in that queue.

Workload. Even if the hiring succeeds, the plant does not have steady work for fifteen people. Categorisation happens every few years, the transition plan once a year, an incident, fortunately, rarely. A specialist who spends most of the time waiting leaves for where the work is. I wrote about this for analysts in do we have to keep expensive data scientists on payroll, and with security it is exactly the same.

Evaluation. That author writes that power companies cannot evaluate the needed skills. A plant can even less. An owner who cannot tell an industrial control security specialist from an administrator with a firewall certificate will hire whoever interviewed better. On how the market actually values experience, see experience in IT does not appreciate on its own.

What must stay inside

The structure I propose starts not with hiring but with appointment. Inside the plant there must be two people, and both, as a rule, already exist.

First: the risk owner. The chief engineer or the production director. The person who knows the line, understands what will stop and what will break, and has something to lose. They do not understand security, and that is fine. Their job is to sign: categorisation, the transition plan, the digital trace regulation, the response plan. And to demand that before signing they are told what they are signing, in the language of downtime and damage rather than regulator's orders.

Second: the map owner. Someone from the IT department who knows where each controller sits, how the network between the corporate and process segments is built, who has remote access. Usually that is the sysadmin on the side. Their job is not to protect but to know and maintain the map: the inventory with the four attributes I described in 187-FZ nine years on and trusted platforms and the legacy plant.

These are not two new hires. They are two roles that have to be assigned, written into job descriptions and, importantly, given time. A map owner who maintains the inventory between printer tickets does not maintain the map.

I do not advise a mid-sized plant to hire a staff industrial security specialist. Not because one is not needed, but because on this market the plant will not keep them, and a structure that rests on one person collapses the day they resign.

What comes from outside, and how it differs from an integrator

The expertise that is not inside comes from outside in the form of an external architect with a team for the project. I am describing my own way of working, and I will say so plainly in the caveats, but the structure does not depend on who executes it.

What the architect does. Assesses risks and prepares the categorisation materials the plant's commission signs. Designs protection built into the systems rather than bolted on. Draws up the transition plan to trusted platforms with four node classes and dates tied to shutdowns. Implements with the team: segmentation, logs, configuration snapshots, compensating controls for the irreplaceable. Builds the digital trace I described in an accident investigation needs a digital trace. Translates the regulator's AI requirements into architecture, as in section 3.18 in practice. After the project, stays on call: support, participation in the accident commission, incident reporting duty under contract.

How this differs from an integrator and from a managed monitoring service. The integrator sells security products, and its interest is in there being more of them. The monitoring centre sells monitoring, and its interest is in more sources being connected to it. Both can be good contractors, but neither is on the plant's side when deciding what to buy. The architect sells neither boxes nor subscriptions, and their only interest is that the structure works and holds up before the ministry and the owner. On how to spot a contractor who complicates a project for the sake of their own scope, see how to tell when your vendor is making the project more complicated.

A separate word on the fear "you have not worked with our equipment". It is understandable, and I answered it in the niche stack question: industrial network patterns repeat across vendors, and what is genuinely specific is learned from your own process engineer in two days. An architect who arrives at a plant with a ready solution before walking the line is a bad architect.

The structure of responsibility: who signs what

The main risk of a model with external expertise is not that it is worse than internal. It is that responsibility hangs between contractors. IT points at the integrator, the integrator at the vendor, the vendor at the architect, the architect at IT. To prevent that, the distribution of signatures is fixed before the project starts.

• Categorisation. Signed by the plant's commission headed by the risk owner. The architect prepares the materials and explains the criteria. The operator's responsibility under the law stays with the operator and cannot be delegated; I say that plainly to every client.

• Transition plan. Signed by the risk owner, sent to the ministry by the plant. The architect draws it up and defends it before the ministry together with the map owner.

• Digital trace regulation. Signed by the risk owner, maintained by the map owner, checked quarterly by the architect, who reports to the risk owner.

• Incident reporting. A designated person inside the plant, usually the map owner, with signing authority and access to the channel. An external on-call specialist under contract helps see and describe the incident, but the operator reports.

• Accident commission. The risk owner adds a security specialist by internal regulation. That is an external specialist under contract, called by the same procedure as the vendor's representative.

• Operation of security tools. The IT department. Configuration and rule changes are made by the architect's team on the map owner's request, and each one is logged.

One principle: the signature is always inside, the expertise may be outside, but whoever signs must have access to the expertise before signing, not after the incident.

How this differs from "outsource everything"

Outsourcing everything means the plant receives a binder and a connection to monitoring, and nobody inside can say whether it works. A year later the binder is out of date, the map has drifted from reality, and at the incident it turns out that the only person who understood the scheme worked for the contractor and has left.

The structure with two internal roles differs in that knowledge transfers. After the project the map owner can take configuration snapshots, verify firmware hashes, read the remote access log and understands why the rule at the segment boundary looks the way it does. The risk owner can read the quarterly report and ask questions about it. The architect stays on call, but the plant does not depend on them for daily work. It is the same logic as the second path in the data scientists piece: your people rerun the configured pipelines rather than waiting for the contractor.

Knowledge transfer takes time from the IT department, and that has to be built into the project explicitly. If the map owner was not given hours for training, a year later the plant is in the first scenario.

On money

The comparison I give owners looks like this. A competence centre is fifteen permanent positions, of which three are busy most of the time. The structure with two internal roles is zero new positions, a project of one or two quarters, and support by the hour, whose volume in a quiet year is comparable to one staff position at mid-level.

The difference is not only the sum. The difference is that a project ends and its result stays at the plant, while a position never ends. Investment budgets are being cut, and on this market a project with an end date and knowledge transfer gets approved where headcount does not.

Honest caveats

• For large companies the author is right. A holding with dozens of objects and a steady flow of incidents should have a competence centre inside. My structure is for the mid-sized segment, where that flow is absent and the requirements are the same.

• An external architect does not replace a duty shift. A category-one significant object with a continuous interaction requirement needs round-the-clock monitoring, and that is either an own shift or a managed service. The architect designs what that service should receive and from whom, but does not stand the watch instead of it.

• I am describing my own model and selling it. The conflict of interest is obvious and I do not hide it. The structure can be checked by one sign: does the architect propose buying something before walking the line and reading the inventory. If so, that is not an architect.

• External specialists are in short supply too. The staffing shortage hits consulting as well. That is why the structure assumes the architect is at the plant rarely, while the map owner lives there permanently.

In short

• The prescription of a 10 to 15 person competence centre is right for large utilities and out of reach for a mid-sized plant on money, labour market, workload and the inability to evaluate candidates.
• The shortage of security specialists in Russia is around 50,000 people and growing, deeper at the junction with industry. The plant stands last in that queue.
• Two roles inside are mandatory, not two hires: a risk owner, usually the chief engineer, who signs, and a map owner from IT who knows where everything sits.
• From outside comes an architect with a team for the project, who sells neither boxes nor subscriptions and stays on call after the project.
• Signatures are distributed before the project: categorisation, transition plan, digital trace, incident reporting, accident commission, operation of security tools. The signature is always inside.
• The structure differs from outsourcing by knowledge transfer: after the project the IT department maintains the map and the trace itself, and the architect is not needed for daily work.

If you have a critical infrastructure object, a transition plan and a model on the line, and security is handled by the sysadmin between tickets, I help build this structure: assign the roles, distribute the signatures, run the project and leave the knowledge at the plant. Feel free to get in touch; the first conversation commits you to nothing.