Governing Dependency: Baseline Capabilities for Operating with Third-Party Clouds
The first two installments described the problem and the relationship with providers. This final part focuses on what depends on each organization: the capabilities that turn invisible dependency into governed risk without stalling digitalization or requiring extraordinary budgets. There are five capabilities; they can be built in a matter of months, and none require new technology, only method.
First capability: An inventory that speaks the language of production
Everything starts with knowing what you depend on, and the determining factor is how it is cataloged. A list of contracts sorted by vendor serves procurement, whereas an inventory that serves business continuity is organized by production function and incorporates the duration each process can sustain itself without that service. For each external service, it is worth recording which process it supports, what happens if it is unavailable for four hours, twenty-four hours, or a week, and whether that downtime halts production, slows it down, or is simply an inconvenience. This exercise, which a mid-sized plant can complete in just a few sessions bringing together operations, IT/OT systems, and procurement, yields a short list of critical dependencies that rarely exceeds ten.
Second capability: Degraded mode, decided in advance
When ransomware halted Norsk Hydro’s systems in 2019, several of its plants continued producing because teams reverted to manual procedures and retained staff with enough experience to operate without screens. The company itself later acknowledged that such continuity owed more to the veteran expertise of its operators than to documented planning. Degraded mode almost always exists, though it only saves production if it has been decided, documented, and rehearsed before the incident. For each critical process in the inventory, it is essential to document whether it allows for temporary manual or local operation, for how long, with what loss of throughput or traceability, who authorizes entering that mode, and how to return to normal operations without corrupting data.
A process that does not support a degraded mode does not invalidate the exercise; rather, it highlights precisely where external dependency calls for redundancy, a reinforced contract, or redesign.
Third capability: Verifiable evidence
The relationship with a critical vendor matures when conversations stop revolving around trust and begin relying on evidence. There is a baseline set that any industrial organization can request without seeming unreasonable: starting with the committed timeline and channel for incident notification, followed by the vendor’s own recovery objectives and the date of their last test, the list of sub-processors and processing locations, the data export format in the event of an exit, and the actual scope of their active certifications, which does not always match what the marketing logo implies.
The vendor’s reaction to the request provides valuable insight in itself, as any provider operating with rigor already has these answers prepared for their best clients.
Fourth capability: Rehearsing with the cloud switched off
Industrial continuity drills traditionally simulate fires, power outages, and, increasingly, internal ransomware. The scenario this series proposes adding is simple to simulate: consider internal systems operational and declare the external service unavailable. A half-day tabletop exercise in which the traceability platform or the manufacturer’s remote support access is removed, walking through the response hour by hour, typically yields more actionable findings than a full audit. It reveals who detects the outage and how long it takes, whether contract emergency numbers are answered, whether degraded mode works in practice, and whether the return to normal operations was planned for.
The advanced version includes an actual restoration drill of the data held by the third party, which is the only way to know if backups truly serve their purpose.
Fifth capability: An owner for the risk
The first installment noted that this risk often gets lost in the seam between OT, IT, and procurement. Consequently, the final capability is organizational, closing that gap without creating new corporate structures. It is enough to assign risk ownership to a specific role with a cross-functional mandate, integrate the inventory and its metrics into the committee that already oversees operational risks, and equip it with a concise dashboard tracking: the number of identified critical dependencies, the percentage with a documented and rehearsed degraded mode, the percentage with a data restoration test completed in the last twelve months, and the maximum tolerable downtime per process compared to what the contract guarantees.
Closing thoughts
Industrial digitalization will not be reversed, and framing it as a threat would be a mistake, as the capabilities it has brought to the factory floor are genuine and competitively necessary. What this series has sought to argue is that an organization’s digital maturity is reflected as much in what it has deployed as in what it understands about what it depends on, and how many times it has rehearsed its response before actually needing it.
Making dependency visible is the first step toward managing it. From there, it becomes standard management practice, the very domain where industry has proven its competitive edge for decades.
Maribel Perozo
Business Development Manager at Aire, member of the Industrial Cybersecurity Center community.