Product security strategy, federated operating model and capital allocation rule

Context

Organisation

A global industrial technology group supplying process technology, machinery and plant engineering to the food processing sector. The engagement was run from the group’s headquarters, and the framework it produced was designed to hold across the whole group — more than 160 product lines of significantly different technical character and operational maturity. It formed one stream of a wider group-wide digital transformation programme.

Environment

The engagement ran in 2021, into a regulatory landscape that was forming rather than settled. The revision of the NIS Directive was moving through the European legislative process — the parliamentary committee adopted its report in October 2021, the Council agreed its position that December — and a proposal for a new Machinery Regulation had been published in April. Neither was binding. Both pointed in the same direction: security obligations migrating from the operator of a plant towards the manufacturer of the equipment installed inside it.

The certifiable layer already existed. ISA/IEC 62443-4-1, published in 2018, defined secure development lifecycle requirements for vendors of industrial automation components, with 62443-4-2 covering the components themselves. Across the standard family the framing was security by design rather than security as an added control layer. These requirements were beginning to surface in procurement documents as supplier qualification criteria rather than technical preferences.

Buyer pressure moved faster than the legislation. Operators in food processing had watched technology security incidents propagate through the sector, and had started treating supplier security posture as a condition of purchase. The transformation programme created the opening for a parallel product security stream — not as a compliance response, but as a positioning move: to make the group the default supplier for security-conscious buyers in a market that was starting to price this factor.

Competitive landscape

German industrial engineering entered the digitalisation cycle from a position of unusual operational strength. Decades of process refinement had produced efficiency that was difficult to argue with, and that strength set the bar any alternative had to clear. The early gains from digitalising an industrial line were modest, and they came with added maintenance complexity and new continuity exposure. Against a mechanical process refined over decades, the trade did not look worth making. Those gains, however, compounded quietly, upgrade by upgrade. By the time the gap closed, the transition was no longer a matter of adopting tools; it required organisation-wide change that does not compress into a single planning cycle.

Against that, the commercial opening was specific. Buyers in food processing were watching the threat landscape expand and were increasingly unable to verify what sat inside the equipment they bought — a problem sharpened by recurring reliability issues with the specifications of Asian components. Few suppliers were competing on this axis. Security, engineered into the product lifecycle and evidenced rather than asserted, was justifiable as a competitive position and largely unclaimed.

Problem

Situation

Risk management maturity was high, particularly in terms of business continuity, and set a correspondingly high standard for cybersecurity. This was not a case of meeting new regulatory requirements. The organisation understood how severe operational technology incidents can be, and expected that understanding to propagate among its own customers quickly. It wanted to be the supplier that security-conscious buyers select by default.

Where most organisations treat compliance as the target scope of security measures, here it was a minimum capability state — a floor above which selected at-risk areas were to be raised significantly: integrated into the product lifecycle, used as a commercial differentiator, applied to build accountability within engineering functions, and treated as a signal channel feeding R&D. Increasing product complexity demanded a scalable solution. Portfolio diversity demanded selective capital allocation. Without a coordinating mechanism, doing both would generate commercially unsustainable costs.

Boundaries

• The EU legal landscape as it stood in 2021, with ISA/IEC 62443 as the governing standard family for OT and industrial control systems.

• Scope covered traditional SCADA environments, customer-facing network-connected equipment hosted by the client or by third parties, and proprietary automation frameworks spanning process control, MES and HMI layers.

• The model had to be implementable incrementally and functional at an early stage, rather than complete before returning value.

• Sequencing was set by the wider transformation programme, which compressed timeframes and required the model to anticipate requirement changes rather than react to them.

Constraints

• An extensive network of external component suppliers, some of them not meeting high security standards.

• Operational maturity varied significantly between product lines, as did the product development process itself — which complicated any centralised governance model.

• Risk management approach and maturity were similarly uneven across the group, while the transformation programme was introducing several new requirements.

• Demand for scarce, highly specialised security expertise extended across many distinct technical domains.

Objective

• Product security had to become a unique selling point — capability description moved out of technical documentation and into the sales and marketing narrative, positioning the group as the provider of choice for security-sensitive buyers, on an axis where the scale and cost advantages of lower-cost competitors did not apply.

• To support that claim, security above the compliance-driven market baseline had to be integrated across the whole product lifecycle.

• Financial viability required centralised governance and an explicit allocation rule tying security spending to R&D, holding the risk-to-opportunity balance across the portfolio rather than optimising each product line separately.

• Strategic objectives had to reach into decision-making at individual level, with particular weight on engineering teams. Given the scope of the organisation, no programme could specify every decision that mattered; culture had to carry the depth that process could not.

Solution

My role

Design of the product security strategy, risk management and governance operating models covering the product development and maintenance stages. Strategic and operational advisory to the CTO, managing the transformation stream, on a daily working basis across three months. Alignment with sales and marketing functions. Delivered as part of a third-party engagement.

Reasoning

With this many highly diversified and highly technical product categories, a single centralised security function would have been near-impossible to staff, difficult to manage, and among the most critical bottlenecks in the organisation. Capability had to sit close to the products. Coordination had to sit above them.

Treating security as a selling point also changed what the coordinating function was for. It required not only capable engineers but deliberate capital allocation, and someone able to translate technical specification into arguments that hold in a deal room. That is a different competence from security engineering, and it does not emerge on its own.

Change of this depth generates business opportunity as a by-product: signals about what customers will pay for, where competitors are exposed, where the product roadmap sits out of step with buyer scrutiny. Someone had to gather, verify and categorise those signals, with a direct reporting line into a function able to act on them.

Reframe

The conventional model develops security capability as a function of risk severity. Here, spending was a function of two variables: risk severity and sales improvement potential. That inverts the usual sequence. A lower-severity gap in a product line facing security-conscious buyers could justify more investment than a higher-severity gap in a line where it changed nothing commercially. It demands a perspective spanning risk, engineering and commercial strategy — and centralised decision-making, because the trade-off cannot be resolved inside any single product line.

Solution architecture

The strategy specified target security capabilities across the lifecycle of the full portfolio, with an implementation plan structured for incremental delivery and aligned with the sales and marketing functions. A federated security operating model was designed, covering governance and risk management. The central function held governance, risk, compliance management, the allocation rule and its application across the portfolio, and translation between engineering and commercial departments. Localised end nodes held the technical work: setting security standards, designing target solutions, testing them, deploying them at customer sites and maintaining them.

A large part of node staffing drew on existing experienced engineers who volunteered for additional security training and a changed role. This addressed the specialist scarcity constraint directly — deep knowledge of the product was the harder half of the requirement, and it was already inside the organisation.

The central team was initially scoped around monitoring areas of risk concentration, delivering training, and troubleshooting operational integration — surfacing where integration would need the most additional support. Each newly designed central function was deliberately tested against legacy product nodes: to verify assumptions about integration complexity, and to find similarities across nodes that would allow workflows to be unified without degrading their performance.

Result

Outcome

The strategy and target operating model were accepted in two stages. First by the CTO, who sponsored the work and collaborated on it daily. Then by the programme committee, which included board members and the programme’s external strategy advisors. That session ran approximately two hours. The model was approved without modification at first submission.

Delivered artefacts: the product security strategy including the capital allocation rule, a high-level target operating model, a capability map, and an implementation roadmap. Implementation passed to a separate delivery team under the standard engagement model. The engagement closed at the point of acceptance.