Merger Integration With a Refusing Business Unit
You lead security integration for a merger that creates a 30,000-employee company. The target has 14 business units, three identity providers (Okta, Azure AD, and legacy LDAP), 210 applications, and no central logging. The deal terms require integration within 18 months. The target's largest business unit, representing 40% of revenue, refuses to migrate to the acquirer's zero-trust architecture, citing customer contractual data-residency obligations. The acquirer's board wants a single risk dashboard by month 6. Only six security FTEs are allocated from the acquirer; the target has 22 security staff with overlapping roles. A red-team exercise found three exploitable paths from target to acquirer networks. The integration budget is fixed at $4.2M. The target's CISO resigned last week, and two of the target's security managers are rumored to be leaving. You must present a plan to the integration steering committee.
1. How should you sequence the integration, and what tradeoffs must you make explicit?
Read the worked answer
Sequence by risk reduction, not by org chart. First, contain the three red-team paths: segment target networks from acquirer networks, restrict identity trust, and deploy central logging for the target's critical assets. Second, stabilize identity: inventory the three identity providers, federate rather than consolidate immediately, and enforce MFA everywhere. Third, migrate applications in waves by data sensitivity and business dependency, not by business unit size. The refusing business unit should get an architecture exception only with compensating controls: a data-residency-preserving tenant, federated identity, no cross-network trust, and local logging forwarded to the parent. Tradeoff: the board's month-6 single dashboard will be incomplete; present a dashboard with confidence levels and known gaps rather than false precision. The fixed budget means prioritizing cross-network containment and logging over wholesale migration. The program manager should state that integration is a risk program, not a migration project; delaying one business unit may be safer than forcing it without resolving data residency.
2. What governance and metrics should support the board dashboard by month 6?
Read the worked answer
Dashboard metrics: red-team path closure rate, percentage of target assets with central logging, identity provider coverage and MFA enforcement, high-risk application migration status, open architecture exceptions with expiry, control effectiveness tests, and integration milestone variance. Avoid vanity metrics such as 'applications migrated' without risk weighting. Add a risk trend and the top three residual risks. The program manager should define data sources and confidence levels before month 6; if data is not available, show 'unknown' rather than zero. The reasoning: the board needs decision-grade information, not a complete but misleading green dashboard. Include the refusing business unit as a named exception with business impact, and assign an executive sponsor for each open risk. This governance structure also helps retain target staff because roles and decision rights become clearer during uncertainty.
3. How should you handle the refusing business unit and the red-team findings?
Read the worked answer
Separate the contractual data-residency claim from the security risk. Validate the business unit's contracts; if residency is genuine, design a compliant architecture with a dedicated region or tenant, a local identity broker, and no cross-border data flows, and document compensating controls. If the claim is a negotiating position, escalate with legal evidence. In parallel, close the red-team paths immediately because they are urgent regardless of the business unit's stance. Present the steering committee with options: forced migration with contract breach risk, exception with controls and residual risk, or delayed migration with interim segmentation. Recommend the exception-plus-controls path with a 90-day review and an executive sponsor. The reasoning: a refusing business unit cannot be allowed to block cross-network containment, but ignoring a real contractual obligation creates legal risk; the program manager's role is to make the tradeoff explicit, assign ownership, and set a review date rather than let the conflict drift.