TLDR
Spirit AeroSystems saved $230M by discovering security problems before closing their ASCO Industries acquisition. Most PE firms aren’t that lucky. Standard compliance questions miss the technical vulnerabilities that destroy portfolio value post-acquisition. Here are the six questions that reveal whether you’re buying defensible infrastructure or expensive security debt, and how the answers should inform your valuation.
The $230 Million Question Hidden in Your Term Sheet
In May 2018, Spirit AeroSystems announced plans to acquire Belgian aerospace manufacturer ASCO Industries for $650 million. The deal made strategic sense: ASCO supplied wing components and assemblies for Airbus, Boeing, and Lockheed Martin’s F-35. Due diligence presumably found acceptable risk. Integration planning began.
Then in June 2019, while the deal was still pending regulatory approval, ASCO was hit by a large-scale ransomware attack that forced the company to shut down production across all its facilities in Belgium, Germany, Canada, and the United States [1][2]. The 1,400-employee company went dark. Production stopped. Systems were quarantined.
The final acquisition price: $420 million. That’s a 35% discount, or $230 million less than the original deal, with Spirit citing “adequate compensation from any potential impact stemming from the cyberattack” [3].
Spirit got lucky. They discovered the security problems before the deal closed and could renegotiate. Most PE firms aren’t that fortunate. They discover post-acquisition that their “audited and compliant” target was running critical systems with inadequate backups, no incident response capability, or infrastructure that couldn’t survive a weekend ransomware attack.
Here’s what makes this dangerous: security vulnerabilities don’t wait for deal closing. A company that can’t detect or respond to attacks today won’t magically become secure because you bought them. And unlike Spirit, you probably won’t get a $230 million discount. You’ll just inherit a company whose operations can be shut down by attackers who may already be inside.
M&A activity is projected to increase 10% in 2025, and so is ransomware targeting of companies in transition. Attackers know acquisitions create visibility gaps and distracted security teams. The six-month integration window is when targets are most vulnerable, and when you own the consequences.
Compliance certificates tell you what policies exist on paper. They don’t tell you whether the company can actually defend itself or recover from an attack that could destroy the value of your investment before your first board meeting.
The Cost of Getting It Wrong:
- Average breach cost: $4.88M globally
- M&A-related breaches cost 15-20% more due to integration complexity
- Median ransomware downtime: 21 days of lost revenue
- Post-acquisition security remediation: $2-5M for mid-market targets
The due diligence questions most firms ask were designed for a different era. Here’s what actually matters when you’re betting your capital.
How to Structure Your Technical Diligence
Week 1-2: Architecture & Breach Risk Assessment
Week 3: Integration & Recovery Capability Review
Week 4: Final technical risk scoring and pricing impact analysis
Questions That Reveal Architecture, Not Paperwork
Instead of: “Are you SOC 2 compliant?”
Ask: “Show us your architecture diagram and explain your blast radius if any single component is compromised”
What this reveals: Whether they actually understand their own infrastructure. A company that can produce current architecture documentation and articulate attack paths has security leadership that thinks like defenders. A company that can’t is running on autopilot. They passed an audit, but nobody actually knows what happens if the payment processing server gets compromised or if an attacker pivots from the VPN to production databases.
If they’ve thought through segmentation, you’ll hear specifics: “Customer data lives in this isolated environment, these are the only services that can access it, and here’s how we monitor those access patterns.” If they haven’t, you’ll hear: “Everything is in AWS so it’s secure by default.”
Red flags to listen for:
- “Everything is in the cloud so our vendor handles security”
- Inability to produce current architecture documentation (not last year’s, not the one from the initial deployment; what’s running right now)
- “Our MSP manages all that” (translation: nobody internally knows the architecture)
The absence of segmentation means a single compromised laptop can become a foothold into your entire acquisition. Every connected system is one hop away from an attacker who gets in anywhere. This isn’t theoretical: it’s how ransomware spreads, how data exfiltration happens, and how companies lose control of their infrastructure.
Instead of: “Do you have a vulnerability management program?”
Ask: “What’s your mean time to patch critical vulnerabilities in production, and what exceptions currently exist?”
What this reveals: Whether they can actually execute security, not just document it. Every company has a patch management policy. The question is whether they can deploy fixes without breaking production, and whether “patch management” means “we patch quarterly” or “we patched the critical authentication bypass within 48 hours.”
The answer tells you their operational resilience. Companies with real vulnerability management give you specifics: “Critical patches deploy within 72 hours, we have 14 current exceptions all with documented compensating controls and executive signoff, here’s our tracking system.” Companies with policy theater say: “We patch during our quarterly maintenance windows” or “Our policy requires patching within 30 days.”
Red flags:
- Any answer that treats all vulnerabilities the same (quarterly patching for everything means critical flaws sit exposed for 90 days)
- No tracking of current exceptions or understanding of what’s unpatched right now
- Can’t distinguish between patching development versus production (these have completely different risk profiles and timelines)
The companies that answer “we patch everything quarterly” are the ones where a public exploit drops on Monday and they’re still vulnerable on Friday. That’s who you’re buying.
Questions That Expose Hidden Breach Risk
Instead of: “Have you had any security incidents?”
Ask: “Walk us through your logging and monitoring coverage. Where do you have visibility gaps?”
What this reveals: Whether they would even know if they’d been breached. A company with mature security operations will give you a map of their visibility: “We have full logging on authentication systems, database queries, and network traffic. Our blind spots are these three legacy applications that we’re migrating next quarter, and here’s our compensating control.”
A company without real visibility says: “We have a SIEM” or “Our firewall logs everything.” That’s not an answer. That’s evidence they don’t understand the question. Logs mean nothing if nobody’s watching them, if they’re not retained long enough to investigate, or if critical systems aren’t even generating logs.
Why this matters for PE firms: You’re potentially buying a company that’s currently compromised and doesn’t know it. Attackers dwell in networks for an average of weeks or months before being detected. If the target can’t tell you what they can see, assume they can’t see breaches. Post-acquisition disclosure creates immediate value destruction: customer notification costs, regulatory fines, remediation expenses, and reputational damage. All now your responsibility and your portfolio risk exposure.
Instead of: “Do you encrypt sensitive data?”
Ask: “How do you manage encryption keys and secrets, and who has access?”
What this reveals: Whether encryption provides actual protection or just checks a compliance box. Encryption with poor key management is security theater. If keys are stored next to the encrypted data, or if 50 employees have access to production secrets, the encryption bought you nothing.
Companies with real key management describe their approach: “Keys live in a hardware security module, rotation happens automatically every 90 days, and access requires MFA plus approval. Five people can access production keys, all actions are logged and reviewed.”
Companies doing it wrong say: “AWS handles encryption automatically” (doesn’t address key access), “Keys are in our configuration management system” (probably means they’re in Git repositories where developers committed them), or can’t actually tell you who has access to decrypt production data right now.
Red flags:
- Encryption keys stored in code repositories (even “private” ones; developers clone these to laptops that get compromised)
- No key rotation procedures or inability to rotate without breaking applications
- “Our vendor manages the keys” (means they’ve outsourced responsibility but not risk)
- Developer access to production secrets without audit trails
The practical test: ask them to walk through rotating a production encryption key today. If the answer involves downtime, manual coordination across teams, or “we’ve never actually done that,” their encryption is brittle. When you need to rotate keys post-breach or for compliance, you’ll discover the encryption implementation creates its own risk instead of reducing it.
Questions That Predict Integration Headaches
Instead of: “What’s your identity management approach?”
Ask: “If we need to integrate your authentication with our portfolio companies, what’s required and what breaks?”
What this reveals: Technical debt hiding in authentication systems. Companies built for integration give you architectural answers: “We use standard OAuth/SAML, our identity provider can federate with external systems, and we’ve done this twice before with partners. Migration would take 2-3 weeks with minimal user disruption.”
Companies built in isolation say: “We have our own user database” or “Authentication is built into the application.” Translation: they hardcoded authentication, there’s no centralized identity management, and integration means either rebuilding their auth system or maintaining parallel user directories indefinitely. Both options are expensive.
Why integration architecture matters: Most value creation requires some level of technical integration: shared services, consolidated security monitoring, unified identity management across portfolio companies. A target that can’t integrate without rebuilding core systems forces you to choose between leaving them isolated (missing synergies) or spending 6-12 months on integration work that should take weeks.
Instead of: “Do you have disaster recovery procedures?”
Ask: “When did you last restore from backup, and how long did it take?”
What this reveals: Whether disaster recovery is real or hypothetical. Every company has a disaster recovery plan. Almost none have tested whether it works. The difference becomes obvious when you ask about actual restoration.
Companies with tested DR give you dates and metrics: “We restored our production database from backup three months ago during our DR drill. Full restoration took four hours, RTO target is six hours. We test quarterly and our last test identified two issues we’ve since fixed.”
Companies with untested DR say: “We back everything up nightly” or “Our RTO is four hours” (based on what calculation?) or “We’ve never needed to restore” (which means they don’t know if their backups work).
Red flags:
- Never actually restored from backup in production (test restores don’t count; production has complexity that test environments don’t)
- Can’t tell you actual restoration time, only theoretical RTO from documentation
- Backups exist but nobody’s verified they’re complete or uncorrupted
- No understanding of dependencies (they can restore the database but not the 12 other components required for the application to function)
The integration reality: Post-acquisition, you’re inheriting their recovery capabilities. If ransomware hits three months after closing and you discover their backups don’t work or restoration takes three weeks instead of three hours, you own that problem. The Spirit AeroSystems discount happened because ASCO’s production went dark. If you can’t restore operations quickly, you’re negotiating your own discount in the form of lost revenue and customer defection.
Ask them to show you documentation from their most recent restoration: what they restored, how long it actually took, what broke, what they learned. If they can’t produce this, their disaster recovery plan is fiction.
What Sophisticated Firms Do Differently
Leading PE firms structure technical diligence in three phases:
Phase 1 (Week 1): Technical screening call with the target’s engineering leadership. If they can’t answer these six questions with specifics, that’s a pricing signal.
Phase 2 (Week 2-3): Review actual documentation: recent DR tests, patch logs, architecture diagrams, incident response records. Documents reveal what interviews obscure.
Phase 3 (Week 4): Quantify remediation costs and timeline. Build this into your valuation model and post-acquisition integration plan.
The difference: these firms catch problems at LOI stage, not six months post-close.
Sophisticated PE firms are now bringing offensive security expertise into due diligence teams. Former NSA operators and red team professionals are increasingly involved in technical diligence, not to run assessments, but to ask questions that reveal whether a target’s security claims match reality.
Due Diligence as Competitive Advantage
In competitive processes, the winner isn’t always the highest bidder. It’s often the firm that can move fastest with confidence. Technical diligence that uncovers real risk (not just compliance checkboxes) lets you make faster decisions and negotiate better terms.
Spirit AeroSystems asked the right questions (or got lucky with timing) and saved $230 million. Most PE firms discover security problems after closing, when the only negotiation left is with insurance companies and incident response firms.
Compliance frameworks were built to satisfy auditors. Your diligence needs to satisfy your LP’s return expectations. Ask questions that reveal whether you’re buying defensible infrastructure or inheriting someone else’s security debt disguised as a growth opportunity.
The answers separate targets that can withstand attacks from those that are one ransomware incident away from shutting down production across four countries. Know the difference before you wire the funds.
Red Flags Checklist: Immediate Signals That Should Adjust Valuation
Use this checklist during technical diligence calls. Each checked box represents portfolio risk that should be quantified in your valuation model:
Architecture & Vulnerability Management:
- □ Cannot produce current architecture diagram within 24 hours
- □ No network segmentation between critical systems
- □ Critical patches deployed quarterly or slower
- □ No tracking system for current unpatched vulnerabilities
- □ Cannot distinguish patching approach between dev and production
Breach Detection & Response:
- □ No logging on critical authentication or database systems
- □ Cannot articulate current visibility gaps
- □ Log retention under 90 days
- □ No SIEM or equivalent monitoring in place
- □ Cannot name who reviews logs and how often
Encryption & Key Management:
- □ Encryption keys stored in code repositories
- □ No key rotation procedures or schedule
- □ Cannot list who has access to production encryption keys
- □ Developers have unrestricted access to production secrets
- □ Has never performed a production key rotation
Integration Risk:
- □ Authentication hardcoded into applications
- □ No support for OAuth/SAML or federation
- □ Has never integrated with external identity providers
- □ Integration would require rebuilding core systems
Disaster Recovery:
- □ No tested disaster recovery in past 6 months
- □ Has never performed production restoration from backup
- □ Cannot specify actual restoration time (only theoretical RTO)
- □ Backups not tested for completeness or corruption
- □ No documentation of dependencies required for restoration
General Operational Maturity:
- □ Security decisions made by MSP or vendor, not internal team
- □ No dedicated security leadership or point person
- □ Incident response plan exists but never tested
- □ Cannot demonstrate recent security improvements or investments
Scoring Guide:
- 0-3 checked: Normal risk for size/maturity stage
- 4-7 checked: Elevated risk; factor $500K-$2M remediation into valuation
- 8-12 checked: High risk; factor $2M-$5M remediation and 6-12 month integration delay
- 13+ checked: Critical risk; reconsider valuation or walk away
References
[1] “Ransomware disrupts worldwide production for Belgian aircraft parts maker,” Help Net Security, June 13, 2019. Available at: https://www.helpnetsecurity.com/2019/06/13/asco-ransomware-attack/
[2] “Asco breaks silence on ransomware attack,” Computer Weekly, June 2019. Available at: https://www.computerweekly.com/news/252465178/Asco-breaks-silence-on-ransomware-attack
[3] “Spirit AeroSystems secures another discount on Asco purchase,” Flight Global, October 31, 2019. Available at: https://www.flightglobal.com/airframers/spirit-aerosystems-secures-another-discount-on-asco-purchase/135125.article