On May 4, 2026, West Pharmaceutical Services detected a ransomware intrusion and moved to shut down and isolate the affected parts of its network. Within days, the company’s core enterprise systems were back online. Manufacturing, shipping, and receiving operations followed at an uneven pace, with some sites back to normal production within the week and others still working through recovery weeks later, according to the company’s public disclosures.
That staggered restoration is a familiar pattern in multi-site pharma environments, where each site’s IT stack has often been built and maintained under different conditions in the years leading up to an incident. West Pharmaceutical is one of the most recent public examples, but the pattern is much wider than one company.
A System Built Site by Site
Running IT across multiple manufacturing sites tends to produce this kind of unevenness by default, and West Pharmaceutical’s experience fits a familiar pattern across an industry built through acquisition and decades of site-level technology decisions made independently of one another.
A pharmaceutical company with facilities in six countries almost never built those six sites on the same day, with the same vendor, and under the same strategy. More often, sites arrive through acquisition and inherit whatever systems and support arrangements were already in place. New builds get outfitted to whatever standard was current at the time, then run for a decade or more on local updates alone. Contract manufacturers bring their own environments into the relationship entirely. Each of these paths is reasonable considering the company’s growth, and collectively they create an estate where consistency must be intentionally engineered, as it will not occur by chance.
In practice, sites end up running a mix of platforms, vendors, support models, and patch cadences that most patching processes were never designed to handle cleanly. NIST’s guidance on enterprise patch management technologies makes a direct point here. Once an environment moves beyond a single standardized platform and starts accumulating nonstandard systems and legacy computers with configurations nobody planned for, the tools that work well on uniform environments become far harder to apply, and teams fall back on manual processes for whatever doesn’t fit.
There’s also a harder truth in how these events often start. The site running the oldest configuration and the loosest patch cycle tends to become the entry point an attacker finds first and the slowest site to recover once the attack spreads. Inconsistency does more than slow the response after an incident. It shapes where the incident begins.
What an Incident Exposes
Under normal conditions, inconsistency doesn’t announce itself. Systems run, staff manage what’s in front of them, and small variations between sites stay invisible until something forces a comparison, whether that comparison comes from an audit or from an incident.
When West Pharmaceutical’s ransomware event hit, the response depended on what each site’s environment looked like at that moment, including which systems were already patched and which credentials were still active. The sites already running closer to a common standard could be assessed and restored faster, since responders already understood the baseline, and the sites that had drifted further from it needed more discovery work before a fix was possible.
That unevenness tends to show up in the same four places.
- Patching and system updates that run on different schedules from site to site, so no two locations are ever quite in the same state
- Access and identity management that varies by location, leaving some sites with tighter controls than others
- Limited visibility for central IT and security teams into what’s running and who has access to it at any given site
- Monitoring and incident response capability that varies from site to site, so the same event produces a faster response in one location than another
It builds gradually in the background and tends to surface at the worst possible moment, during an incident or during an inspection.
That exposure shows up in the numbers. IBM’s 2026 Cost of a Data Breach Report puts the average healthcare breach at $6.64 million, the costliest of any industry studied for the thirteenth year running, with the average breach now taking 247 days to identify and contain. Pharmaceutical manufacturing carries much of the same data sensitivity and regulatory exposure as the wider healthcare sector, which makes those figures a reasonable proxy for what’s at stake. The same research found that internal IT and security teams identified breaches roughly 15% faster than the global average, largely because they already know the environment they’re defending.
In our experience running IT for pharma sites in this way, a directly employed, in-country technical team that already knows a site’s environment day to day responds noticeably faster when something goes wrong. It’s the same underlying principle IBM’s data points to: familiarity with the environment shortens the response.
The conditions that slow an incident response often overlap with what inspectors flag during a regulatory review, and the operational cost lands first, whether or not an inspection ever happens.
One Operating Model, Applied Everywhere
Closing that distance between sites depends on the operating model underneath every location, built and maintained as a deliberate standard from the start. At Maintech, we’ve spent more than 50 years building an operating model for exactly this problem, and we apply it consistently across pharmaceutical and life sciences sites in the following ways.
- Standardized IT environments at every site, built and maintained to one specification across the entire estate
- One delivery model, applied the same way at every site, so a site added this year runs the same way as one that’s been live for a decade
- Centralized oversight of patching, access, monitoring, and change control, built into everyday operations so nothing needs rebuilding under pressure
- Every site supported by directly employed, in-country technical staff who stay engaged with that environment over time
- Infrastructure that scales with a growing site count, so expansion doesn’t reintroduce the inconsistency of being closed elsewhere
Consistency lowers that risk and changes what a site looks like when something goes wrong, with fewer unknowns and one standard to work from instead of many. For organizations running IT across a growing number of sites, that standard shapes how contained an incident stays.
In multi-site pharma environments, inconsistency is a hidden and significant risk. Maintaining control requires standardization across every system, process, and location.
Speak with a Maintech account executive to assess how consistent your IT environments are across all sites.
Frequently Asked Questions
What is the data center asset lifecycle?
The data center asset lifecycle covers every stage a piece of equipment goes through. Managing it well means keeping accurate records throughout, especially in the stages between installation and decommissioning.
How often should data center asset records be audited?
Most organizations benefit from scheduled physical audits at least once or twice a year, with updates logged continuously as installs, moves, additions, and changes happen. Waiting for an annual review to catch every discrepancy leaves too much room for the record to drift from reality.
What happens to data-bearing components during decommissioning?
Data-bearing components such as hard drives and storage arrays go through documented sanitization or destruction to a defined standard, with each step tied to the device’s serial number. This creates an auditable record that proves the data was handled securely.
Can decommissioned data center equipment be resold or reused?
Yes, decommissioned data center equipment can often be resold or reused. Equipment that’s still functional can be redeployed into a secondary role or resold through a certified reseller. Only assets that have reached the end of their useful life should move to certified recycling.
