You're on a call with manufacturing leadership, legal, and quality assurance. A cyberattack just forced you to shut down production systems. IT says they've contained the threat and restored the servers. Now everyone's looking at you: "Can we turn it back on?"
In regulated industries, that's not a simple yes-or-no question. It's a validation problem.
Understanding the Challenges
These challenges became evident after Boston Scientific announced a cyberattack affecting their global operations, impacting their ability to ship and process orders. This incident highlights the collision between cyber response and regulatory requirements. Industries like medical device manufacturing, pharmaceutical production, and aerospace can't just restore from backup and resume operations. They need to prove their quality systems still produce trustworthy data.
Here's what compliance managers need to consider.
Why Restarting Production Systems Is Complex in Regulated Industries
The systems themselves are part of your compliance posture.
In medical device manufacturing, software involved in producing and tracking FDA-regulated devices is part of a validated quality system. You've documented how those systems work, validated their outputs, and established that they consistently produce accurate records. This validation allows you to ship products that get implanted in human bodies.
When a cyberattack compromises those systems, you can't assume validation still holds. Restoring a server is one thing. Establishing that the data coming out of that system can still be trusted is another.
ISO/IEC 27001 Clause 8.1 (Operational Planning and Control) requires you to plan and control processes needed to meet information security requirements. For validated systems, that means having documented procedures for verifying system integrity after an incident before resuming production.
What's Missing in Your Incident Response Plan?
Your incident response (IR) plan probably focuses on stopping the attack, removing the threat actor, and restoring systems to a known-good state. That's necessary but not sufficient.
You need a parallel track for quality system revalidation. This includes:
- Evidence of data integrity: Can you demonstrate that production records, batch logs, and quality data weren't altered during the attack? You'll need audit logs, checksums, or other integrity controls that survived the incident.
- Change control documentation: Every modification made during incident response needs to go through your change management process, even emergency patches.
- Revalidation protocols: Documented test procedures that verify restored systems still meet their original validation criteria.
SOC 2 CC7.4 addresses system monitoring to detect anomalies. In a regulated context, you're not just monitoring for threats; you're creating an audit trail that proves your quality systems remained in a validated state or were properly revalidated before resumption.
Network Segmentation: A Key Defense
This is the architectural challenge that determines whether an attack becomes a production shutdown.
Strict logical boundaries between corporate administrative networks and production environments don't mean complete isolation. They mean controlled, monitored pathways with explicit allow-lists and logging.
Consider your data flows:
- Production systems need to send quality data to corporate databases.
- Corporate IT needs to push security updates to production systems.
- Users need to access production interfaces from corporate workstations.
Each of those flows should traverse a segmentation boundary with:
- Dedicated jump hosts or data diodes for one-way transfers where possible.
- Application-layer proxies that validate protocol conformance.
- Separate authentication domains so compromising corporate AD doesn't grant production access.
ISO/IEC 27001 Control 8.22 (Segregation of Networks) requires you to separate groups of information services, users, and information systems. For regulated production, that's not optional. A cardiac device that misses its ship date can mean a cancelled surgery. Network segmentation prevents an email compromise from cascading into a supply chain crisis.
Targeted vs. Opportunistic Attacks: Does It Matter?
Not for your technical response, but it matters for your risk assessment.
Opportunistic attacks exploit vulnerable systems as soon as they're discovered. Targeted attacks involve reconnaissance, custom tooling, and persistence mechanisms tailored to your environment. The distinction affects:
- Threat modeling: Opportunistic attacks suggest you have unpatched vulnerabilities or weak perimeter controls. Targeted attacks suggest someone values your IP, customer data, or supply chain position enough to invest in breaching you specifically.
- Containment scope: Opportunistic attackers usually follow predictable lateral movement patterns. Targeted attackers may have established multiple persistence mechanisms and exfiltration channels.
- Future controls: If you were targeted, you need to assume the attacker studied your defenses and will return with different methods.
ISO/IEC 27001 Clause 6.1.2 requires information security risk assessment. Post-incident, reassess whether your threat assumptions still hold. Were you breached because you had weak controls against commodity threats, or because a sophisticated actor decided you were worth the effort?
Maintaining Evidence Continuity
This is where your evidence collection procedures meet your incident response procedures, and they often conflict.
When you isolate a compromised system, you're disrupting normal logging, backup schedules, and monitoring integrations. That creates gaps in your audit trail. To maintain evidence continuity:
- Activate your incident-specific logging: Before you isolate, ensure you're capturing forensic-level detail to a separate, write-once destination.
- Document every action: Your IR team's activity log becomes part of your compliance evidence. Time-stamped records of who did what, when, and why.
- Preserve chain of custody: If you're imaging systems or collecting memory dumps, follow your evidence handling procedures so those artifacts remain admissible for both legal and audit purposes.
SOC 2 CC7.2 requires monitoring of the system to detect security events. When you're in incident response mode, you're not just detecting; you're creating a parallel evidence stream that proves you maintained control even while under attack.
Enhancing Tabletop Exercises
Most tabletop exercises focus on detection, containment, and communication. Add these scenarios:
- Quality hold decision: Who has authority to place production on quality hold during an active incident? What's the notification chain?
- Revalidation gate: IT says systems are restored. Quality says they need three days of revalidation testing. Manufacturing says customers are waiting. Who decides when to restart?
- Manual failover to offline backups: Can your teams actually execute the manual procedures you've documented? Have they done it recently enough to know what's changed?
- Regulatory notification timing: At what point does the incident become reportable to FDA, customers, or other regulators? Who makes that determination?
ISO/IEC 27001 Control 5.24 (Information Security Incident Management Planning and Preparation) requires planning for incidents. In regulated industries, that planning must account for the intersection of cyber response and quality system requirements.
Next Steps
If you're building incident response capabilities for regulated environments, start with ISO/IEC 27035 (Information Security Incident Management) and map it to your industry-specific quality system requirements. For medical devices, that's FDA 21 CFR Part 11 and Part 820. For pharmaceuticals, it's 21 CFR Part 210/211.
Your IR plan and your quality management system aren't separate documents. They're Complementary Subservice Organization Controls that both need to work during the same incident. Test them together.
