Post-Acquisition Integration Under a Certified Veneer
You are CISO of a listed European payments processor (4,200 staff, €1.9bn revenue) regulated as a significant financial entity dependent on ICT third parties. Three weeks ago you closed the €210m acquisition of a 400-person analytics SaaS company serving the retail-bank segment you want to cross-sell into. The target holds ISO 27001 certification and passed its last surveillance audit. Your due diligence found: no MFA on three administrative consoles, 14 end-of-life servers in production, two critical findings open for over 180 days with no assigned owner, no data-loss protection, and a production AWS account whose root credentials are shared with a channel partner. Nothing suggests an active compromise. The deal thesis requires cross-selling into your regulated bank customers by Q3 - roughly six months - and those contracts will impose your own outsourcing and data-protection clauses on the acquired entity. The board approved €600k for integration security and wants full network integration within 90 days. The target's CTO opens every meeting with 'we are certified, we are fine.'
1. Within the first 30 days, how do you sequence the open critical gaps against the 90-day integration deadline? State your logic and what you tell the board.
Read the worked answer
Sequencing principle: fix what integration will amplify, not what the certificate happens to miss.
Split the findings into three buckets:
- Trust-boundary amplifiers - the shared root credential with the channel partner, the unauthenticated admin consoles, anything internet-reachable. These get fixed in days, cost almost nothing, and their risk multiplies the moment the two estates touch. Rotate the root credential, move the partner to scoped IAM roles, enable MFA on the three consoles in week one.
- Contained but material - the 14 EOL servers. Inventory what they do and what data they touch before acting; isolate them on a dedicated VLAN with deny-by-default egress, restrict management access, and put them on a funded replacement plan with dates. Isolation buys time; it does not close the risk.
- Ownership debt - the two orphaned critical findings. Assign named owners with remediation dates this week. A finding without an owner is not being managed.
What I tell the board: ISO 27001 is a point-in-time opinion about a defined scope, not a statement that controls work. I present three risk scenarios - partner-mediated access to customer data, ransomware propagating across the merged estate, breach of outsourcing clauses - each with current and target residual rating, the date the target is reached, and the executive who owns the residual. Then I ask for one decision: a gate, meaning no production connectivity to the regulated estate until the trust-boundary items are evidenced. Certification is an input to assurance, not a substitute for it.
2. The commercial team wants the acquired network connected to yours in 30 days to hit the Q3 date. What is your decision framework, and what do you propose?
Read the worked answer
Decision: refuse a flat network merge, but do not refuse the business outcome. The question is what actually has to flow.
Framework:
- What is the minimum data and trust flow the cross-sell needs? Typically federated identity, an API path to specific customer records, and reporting - not routing between two flat networks.
- What is the blast radius if either side is compromised? Today it is one company; after the merge it is the regulated entity and its bank customers.
- What is reversible? Brokered connectivity can be tightened or cut in minutes; a merged network cannot be un-merged quickly.
Proposal: a brokered pattern - separate identity domain with federation and conditional access, API gateway with schema validation and rate limits, no direct routing, all acquired-entity authentication and egress logged into the parent SIEM, and data-classification gates on which datasets may traverse.
Governance: publish entry criteria (privileged MFA, EOL systems isolated, logging live). If the business wants to proceed before the criteria are met, that is a formal, time-bound risk acceptance signed by the accountable executive - not a verbal waiver - recorded in the risk register and reported to the risk committee. I would also confirm with Legal whether the bank contracts require notification or audit rights before the acquired entity processes their data; that constraint may bind harder than my opinion does.
3. Which assurance metrics would you put in front of the board quarterly, and why those rather than a fuller dashboard?
Read the worked answer
Four metrics, each tied to a named risk scenario:
- Privileged MFA coverage in the acquired estate (percentage of admin consoles and admin accounts). Cheap, binary, and it directly reduces the most likely path to domain compromise.
- EOL systems in production with evidenced compensating controls - a count and a trend, not a percentage. Each line names the system, the isolation control, and the replacement date.
- Critical findings: count open, median age, and percentage with a named owner. The owner metric matters more than the age; it predicts whether the number will move.
- Percentage of acquired-entity identity and data flows that are brokered and logged against the integration plan. This is the gate metric - it tells the board whether integration is proceeding safely or merely proceeding.
Why not more: the board reads one page. Metrics that cannot change a decision are noise. These are leading indicators of the two scenarios that matter - lateral compromise and regulatory breach - they are hard to game, and each has an owner who can be asked a follow-up question.
What I avoid: a composite 'security score', raw vulnerability counts without severity and exposure context, and training completion rates presented as risk reduction.