When Analog Devices reported unauthorized access and data exfiltration on June 23, the company activated incident response, engaged external cybersecurity experts, and coordinated with law enforcement. Despite the ransomware group ExfilSquad claiming to have stolen more than 570,000 customer records, Analog Devices stated it doesn't expect material business impact.
That outcome isn't luck. It's what happens when you execute incident response correctly.
But most organizations don't. Your security team can deploy every control in ISO/IEC 27002, pass a SOC 2 Type II audit, and still fumble when an actual intrusion occurs. The gap isn't technical capability. It's how you respond when detection alerts fire and your assumptions about perimeter defense collapse.
Why These Mistakes Keep Happening
Incident response failures stem from a fundamental misalignment: you build security programs for auditors, not for adversaries. Your Statement of Applicability documents controls you've implemented. Your tabletop exercises follow sanitized scripts. Your runbooks assume rational threat actors who follow predictable patterns.
Real incidents don't work that way. Attackers move laterally through systems your architecture diagrams don't show. They exfiltrate data from repositories your asset inventory missed. They exploit trust relationships your zero-trust implementation hasn't reached yet.
The semiconductor industry faces particular pressure. Companies like Microchip Technology, Applied Materials, Trio-Tech International, and Foxconn have all dealt with attacks that disrupted production or compromised data. When your manufacturing processes depend on industrial control systems and your customers include critical infrastructure operators, you can't afford response failures that extend dwell time or expand blast radius.
Mistake 1: Treating Incident Response as IT's Problem
Your Computer Security Incident Response Team reports to the CISO. When they detect an intrusion, they contain systems, preserve evidence, and begin forensics. Meanwhile, your legal team learns about the breach from a regulatory filing draft, your communications team scrambles to write holding statements, and your customer success team fields angry calls with no approved talking points.
This happens because you've defined incident response as a technical function instead of an enterprise capability. The NIST Cybersecurity Framework 2.0 maps incident response across Detect, Respond, and Recover functions, but it assumes cross-functional coordination your org chart doesn't support.
The fix: Build your incident response plan as a business continuity document, not a security runbook. Map decision rights for customer notification, regulatory disclosure, ransom negotiation, and public statements before you need them. When Analog Devices filed with the Securities and Exchange Commission, someone had already determined materiality thresholds and disclosure timing. That doesn't happen during the incident.
Assign a crisis management owner outside IT who can convene legal, communications, operations, and executive stakeholders within one hour of declaring a confirmed incident. Your CSIRT handles containment. This person handles everything else.
Mistake 2: Delaying Containment While You Assess Scope
You detect lateral movement from a compromised endpoint. Your first instinct is to watch and learn: What systems is the attacker accessing? What data are they targeting? How did they get in?
While you're building that timeline, they're exfiltrating customer records.
This mistake stems from treating incidents like investigations instead of emergencies. You want complete understanding before you act, so you preserve evidence and avoid tipping off the attacker. Meanwhile, your 72-Hour Notification Requirement clock is ticking under the General Data Protection Regulation, and every hour of dwell time expands your breach notification list.
The fix: Implement a containment-first protocol. Isolate affected systems immediately when you confirm unauthorized access, even if you don't know the entry point. Yes, you might disrupt legitimate business processes. That's acceptable. What's not acceptable is allowing continued data exfiltration while your forensics team builds a perfect attack timeline.
NIST SP 800-61 defines Containment, Eradication, and Recovery as distinct phases for a reason. You contain first to stop the bleeding. You investigate after you've stopped active compromise. Analog Devices discovered "certain files" had been exfiltrated, but the scope remained unknown at disclosure. That's normal. You report what you know when you know it, not after you've completed a six-week forensic analysis.
Mistake 3: Assuming Your Backups Will Save You
Your disaster recovery plan specifies Recovery Point Objective and Recovery Time Objective for every critical system. You test restores quarterly. You've implemented air-gapped backups specifically to defend against ransomware.
Then you discover the attacker has been in your environment for 47 days, and your "clean" backups contain their persistence mechanisms.
This happens because you've designed backup strategies for hardware failures and natural disasters, not for adversaries who deliberately corrupt your recovery capability. Ransomware groups now routinely target backup infrastructure first. They delete snapshots, corrupt backup catalogs, and plant backdoors in the images you'll restore.
The fix: Implement forensic validation of backup integrity before you restore anything. When you detect an intrusion, assume your backups are compromised until you've verified otherwise. That means scanning restored images for indicators of compromise before you bring them online, not after they've reinfected your production environment.
Add immutable backup snapshots with retention periods longer than your typical dwell time. If attackers spend 30 days in your environment before you detect them, you need backups older than 30 days that they couldn't modify. The NIST Cybersecurity Framework 2.0 Recover function assumes you can restore to a known-good state. Make sure "known-good" actually means verified clean.
Mistake 4: Treating Ransomware as a Negotiation
The ransomware group demands payment and threatens to publish exfiltrated data if you don't comply. Your crisis team debates: Do we pay? Do we negotiate? What's our liability if customer data gets posted?
You're asking the wrong questions. The moment attackers exfiltrated your data, you lost control of it. Paying ransom might prevent publication, but it doesn't guarantee deletion. ExfilSquad claimed to have stolen more than 570,000 Analog Devices customer records. Whether those records get published depends on ExfilSquad's business model, not your payment.
The fix: Build your response plan assuming data exfiltration equals data exposure. When you detect unauthorized access, immediately assess what data the attacker could have reached, not what you've confirmed they took. Notify affected parties based on access, not confirmed exfiltration. This approach aligns with General Data Protection Regulation requirements, which focus on likelihood of risk to data subjects, not proof of harm.
Don't wait for the ransom demand to start breach notification analysis. By the time attackers contact you, they've already been in your systems long enough to map your data stores and identify high-value targets.
Mistake 5: Running Incident Response Without Legal Privilege
Your CSIRT documents everything: forensic findings, containment decisions, root cause analysis, security control failures. You're building an evidence trail for your investigation.
You're also building a discovery goldmine for plaintiff attorneys and regulatory enforcement actions.
This happens because you've designed incident response as a technical process without considering litigation risk. Every Slack message, every forensic report, every post-incident review becomes discoverable evidence. Opposing counsel will use your own documentation to prove you knew about vulnerabilities, delayed notification, or mishandled customer data.
The fix: Structure your incident response under attorney-client privilege from the first moment of detection. Engage outside counsel immediately, and route all investigation findings through legal. This doesn't mean lawyers run incident response, it means your forensic reports and root cause analyses get protected as attorney work product.
When Analog Devices brought in "outside cybersecurity experts," that engagement likely ran through legal counsel to preserve privilege. Your internal security team handles containment. External forensics firms engaged by your attorneys handle investigation. The technical work is identical. The legal protection is dramatically different.
Prevention Checklist
Before your next incident, verify you can answer "yes" to each of these:
- Your incident response plan assigns decision rights for customer notification, regulatory filing, and public disclosure to named individuals outside IT
- You can convene your crisis management team within 60 minutes, 24/7, including legal and communications stakeholders
- Your containment protocols authorize immediate isolation of compromised systems without waiting for complete scope assessment
- You maintain immutable backup snapshots with retention exceeding your industry's average dwell time
- Your backup restoration process includes forensic validation before systems return to production
- Your breach notification analysis begins at detection, not after confirming exfiltration
- Your incident response engagement letter with outside counsel is signed and ready to activate
- Your forensics vendors are pre-qualified and can be engaged through legal counsel within four hours
Analog Devices reported its breach, engaged experts, and coordinated with law enforcement. The company stated no expected material impact despite a ransomware group's claims of significant data theft. That outcome reflects preparation, not fortune. When your incident happens, the mistakes you've prevented determine whether you contain the damage or amplify it.
