Boston Scientific, a major medical device manufacturer, suffered a cyberattack this week that disrupted its order processing and shipping operations. The company disclosed it cannot yet determine the financial impact of the incident. For compliance managers maintaining SOC 2 or ISO/IEC 27001 certifications, this disruption illustrates a critical control gap: the difference between having an incident response plan and having one that actually protects operational continuity.
What Happened
Boston Scientific experienced a cyberattack that knocked out its ability to process orders and ship products. The company's public disclosure acknowledged the operational impact but noted it couldn't quantify financial losses at the time of announcement. This uncertainty about business impact suggests gaps in either business continuity planning or impact assessment capabilities.
Timeline
The public facts are limited:
- Cyberattack occurred
- Order processing systems disrupted
- Shipping operations affected
- Financial impact undetermined at time of disclosure
What's notable here isn't what we know, but what the company apparently didn't know: the scope of operational and financial damage. That gap matters for compliance.
Which Controls Failed or Were Missing
Based on the operational disruption and the company's inability to assess financial impact, several control categories appear to have been insufficient:
Business Impact Analysis (BIA) Controls
If you can't quickly determine financial impact, your BIA isn't operationalized. It's sitting in a document somewhere, not embedded in your incident response workflow. ISO/IEC 27001 Annex A 5.30 requires ICT readiness for business continuity, which includes knowing what each system's downtime costs you per hour.
Operational Resilience Controls
Order processing and shipping aren't back-office systems you can restore over a weekend. They're revenue-critical. The disruption suggests either inadequate system redundancy or insufficient failover procedures. SOC 2's CC9.1 requires you to identify and assess risks that could impair system availability. If a single attack can halt order processing, you haven't mitigated availability risk adequately.
Incident Detection and Response Controls
The public timeline suggests reactive rather than proactive response. ISO/IEC 27001 Annex A 5.24 through 5.28 cover information security incident management planning, assessment, response, and learning. Your incident response plan should include predefined escalation paths, communication templates, and impact assessment runbooks.
Supply Chain Continuity Controls
Medical device shipping involves regulatory compliance, cold chain requirements, and just-in-time delivery to healthcare facilities. Disrupting this isn't like delaying a software license renewal. ISO/IEC 27001 Annex A 5.19 and 5.20 address information security in supplier relationships, but your business continuity plan (Annex A 5.30) must account for supply chain dependencies.
What the Standards Require
ISO/IEC 27001 Annex A 5.30: ICT Readiness for Business Continuity
You must identify ICT services supporting critical business processes, determine acceptable downtime, and implement redundancy or recovery procedures. "We'll restore from backup" isn't a plan if order processing downtime costs you six figures per hour. You need either system redundancy that keeps orders flowing during an incident, or documented recovery time objectives (RTOs) with tested procedures.
SOC 2 CC9.1: Risk Mitigation
The criteria require you to identify, analyze, and respond to risks that threaten system availability. This means documented risk scenarios (ransomware, system compromise, data corruption), assessed impact, and implemented mitigations. Your auditor will ask: "What happens if your order management system is compromised?" You need a specific answer with evidence you've tested it.
SOC 2 CC7.4 and CC7.5: Incident Response and Communication
CC7.4 requires incident response procedures including detection, analysis, containment, eradication, and recovery. CC7.5 requires communication protocols -- internal escalation and external stakeholder notification. If you're publicly disclosing an attack but can't tell stakeholders the financial impact, your incident classification and impact assessment processes aren't working.
ISO/IEC 27001 Annex A 5.26: Response to Information Security Incidents
This control requires you to respond to incidents according to documented procedures. Those procedures must include impact assessment, not just technical containment. If your IR plan says "isolate the affected system" but doesn't say "calculate revenue impact within 4 hours," you're missing half the requirement.
Lessons and Action Items for Your Team
Map financial impact to system downtime before an incident occurs.
Build a matrix: system name, dependent business processes, revenue per hour of downtime, maximum tolerable downtime. Update it quarterly. When your order processing system goes down, you should be able to tell your CFO within two hours what it's costing, not "we'll get back to you."
Test your business continuity plan under attack conditions, not just system failure.
Most BC tests simulate hardware failure or facility loss. Run a tabletop exercise where your order management system is compromised and potentially corrupted. Can you fail over to a clean backup? Can you process orders manually? How long does each option take? Document the answers and build runbooks.
Implement operational resilience, not just disaster recovery.
Disaster recovery gets you back online. Operational resilience keeps critical functions running during the incident. For order processing, that might mean a manual order queue, a secondary system with read-only access to customer data, or pre-authorized emergency procedures with your logistics provider. Define what "degraded but functional" looks like for each critical process.
Embed impact assessment in your incident response workflow.
Your IR plan should include a step: "Within [X] hours, complete initial impact assessment using BIA matrix." Assign this to a specific role (not the same person doing technical containment). Create a template. Practice filling it out during tabletop exercises.
Review your evidence collection procedures.
If you can't determine financial impact, you probably also can't demonstrate to your auditor exactly which controls were operating during the incident. Your logging, monitoring, and evidence retention must survive the attack. Store security logs and business continuity evidence in separate, protected systems.
Align your RTO with your compliance scope.
If order processing is in your SOC 2 system description, its availability is a trust services criterion. Your RTO for that system must be short enough to meet CC9.1's risk mitigation requirement. If your RTO is 72 hours but customers expect 24-hour order turnaround, you've got a control design gap your auditor will flag.
The Boston Scientific incident is a reminder that compliance isn't about passing an audit -- it's about whether your controls actually work when you need them. If a cyberattack can halt your core operations and leave you unable to assess the damage, your ISMS and SOC 2 controls aren't meeting their purpose, regardless of what your last audit report said.
