Data protection for manufacturing operations

Protecting data in a factory runs into a constraint most offices never meet: a significant part of the estate cannot be stopped, cannot be patched on your schedule, and in some cases cannot be touched without voiding a support contract with the machine vendor. The design has to start from that rather than work around it afterwards.

The estate is three different problems

Business systems

ERP, CRM, finance, email, design files. These behave like any other business estate and are the easiest part. They are also where most of the regulatory and contractual retention obligations sit.

Machine and line controllers

The PCs attached to production equipment are frequently running an operating system years past support, because the machine vendor validated that version and will not certify another. They cannot be patched and often cannot take an agent. What they can usually take is an image: a full copy of the machine, taken when the line is down, kept somewhere you can restore from quickly. A configuration file backed up without the operating environment it runs in is not a recovery plan, because nobody will be able to rebuild that environment at 2am.

Process and historian data

Time-series data from the line, which grows continuously and is rarely deleted because nobody is certain what quality investigations will need. This is the dataset that quietly becomes the largest thing you own, and the one most improved by an explicit retention schedule.

When there is no backup window

The nightly backup job assumes an idle period. Whether you have one is a function of the shift pattern, and it is worth working out explicitly.

Where the bottom rows apply, the answer is not a longer window. It is changing the mechanism: storage or hypervisor snapshots that capture a consistent state in seconds, replication that streams changes continuously, and application-aware agents that quiesce a database for the moment of the copy rather than stopping it. See also patching without a maintenance window, which is the same constraint applied to a different problem.

3-2-1, and the reason it survived ransomware

Three copies of the data, on two different media, one of them off-site. The rule predates ransomware and turned out to be the right shape for it, provided the off-site copy is genuinely out of reach: a second share on the same network, reachable with the same credentials, is a second copy of the problem. What makes a copy safe is that compromising the primary environment does not grant access to it — separate credentials, and immutability or an air gap so that a copy cannot be deleted or encrypted within its retention period even by an administrator.

The test for whether your off-site copy qualifies is simple and worth running: if the domain administrator account were compromised tonight, could that account reach and destroy the backups? If yes, you have two copies, not three.

A retention schedule somebody can actually follow

Most retention policies fail because they are written as principles rather than instructions. A usable schedule names, for each class of data, exactly three things: how long it is kept, where it is kept, and who is allowed to approve deletion. If a class has no answer to the third, it will never be deleted, which is how a historian database reaches a decade of unreviewed data.

Three things worth stating explicitly:

• Legal and contractual minimums.Quality records, batch records and warranty evidence often have obligations attached that are longer than anything IT would choose.
• A maximum, not only a minimum.Data kept forever is data you are liable for forever, and it is all in scope for the next discovery request.
• What happens to a backup when the retention period ends.Backups holding data past its deletion date are the usual reason a deletion policy does not survive scrutiny.

Where this fits

The service is Data Protection, and the sector context is Manufacturing. It pairs with Disaster Recovery, which covers getting a failed system back rather than keeping copies of it, and with Infrastructure Managed Services where the monitoring and the restore testing are run for you.