Post-Merger Security Operating Model Under a Regulatory Deadline
Two regional banks completed a merger eight months ago. The combined entity has 3,400 employees, 210 branches, and 14 regulated critical systems. Bank A ran a centralized security function with a single SIEM and an ITIL-based service catalog; Bank B ran a federated model where each business unit bought its own tools. Tooling overlap is roughly 60%, and two 24x7 SOCs still operate with separate playbooks. The national banking regulator has issued a 12-month deadline for a single cyber risk framework, common controls, and unified incident reporting. The merger budget is frozen at an 8% reduction, and the CIO wants to avoid a disruptive rip-and-replace. The board risk committee has asked for a target operating model, a sequencing plan, and a decision on a stalled proposal to consolidate onto one SIEM. The CISO role is vacant, with an interim CISO reporting to the CIO.
1. Recommend a target security operating model and governance structure. Justify the choice against at least three alternatives, and explain how it satisfies the regulator without a rip-and-replace.
Read the worked answer
Recommendation: adopt a hybrid model: central standards, risk aggregation, architecture, and engineering; embedded security business partners in each major line of business; a single accountable CISO with delegated execution.
Why not pure centralization or federation? Full centralization gives the regulator one throat to choke but would force Bank B business units to surrender local control during a frozen-budget merger, increasing shadow IT and attrition. Full federation preserves local responsiveness but prevents a single risk register and common incident reporting, which the regulator explicitly requires. A holding-company model with shared services is viable long term but too slow for a 12-month deadline.
Governance: establish a security integration office reporting to the CISO; a risk committee with business-unit CIOs; a RACI that separates risk ownership (business) from control operation (security) and independent assurance (audit). Map the common control library to the regulator's framework, and unify incident taxonomy and reporting before tool consolidation.
Regulatory satisfaction: one risk register, one control library, one incident reporting process, and named accountability. Tool consolidation follows standards, not the reverse. The interim CISO should be made permanent or an accountable executive appointed within 30 days, because a regulator will test ownership first.
2. Sequence the first 90 days and the following nine months. Identify dependencies, quick wins, and the point at which the SIEM decision must be made.
Read the worked answer
Days 0-30: appoint a permanent CISO or formally delegate accountability; charter the integration office; freeze new security tool purchases; inventory the 14 critical systems, both SOC playbooks, and all data flows. Publish a single incident escalation path, even if two SOCs still execute it.
Days 31-90: adopt one risk framework and control library; harmonize incident severity taxonomy; run a joint tabletop across both SOCs; select quick wins that reduce risk and demonstrate merger value, such as MFA coverage for privileged access and EDR agent consolidation where overlap is highest.
Months 4-6: complete the SIEM decision. The decision must precede SOC consolidation because playbooks and data onboarding depend on it. Evaluate retain-and-integrate, replace, or managed detection service against total cost, regulatory data residency, and migration risk. Do not let the tool decision drive the operating model.
Months 7-12: migrate priority log sources, consolidate SOC tiers, decommission duplicate tooling in risk order, and produce the first unified regulator report. Dependencies: identity and asset inventory must be credible before SIEM correlation is trusted; data retention policy must be agreed before decommissioning.
Quick wins: single phishing-report mailbox, shared threat-intel feed, joint vulnerability dashboard. Avoid: big-bang cutover in the final quarter.
3. A business-unit head refuses to migrate from the local SIEM, arguing that his team's fraud-detection use cases will break. How do you resolve this?
Read the worked answer
Treat this as a risk-and-interest negotiation, not a compliance escalation. First, diagnose the real concern: fraud use cases often depend on data the central SIEM does not yet ingest, or on fast local tuning. Ask for the use-case inventory, data sources, detection latency, and false-positive rates.
Then test the claim with evidence. Compare required log sources, retention, and query performance against the target platform. If the use cases genuinely need local context, propose a transition pattern: retain a local feed or dashboard for a fixed period while the central platform proves parity. If they do not, show the cost of duplicate tooling and the regulatory exposure of fragmented incident reporting.
Offer shared ownership: the business unit keeps detection content ownership, security owns the platform and onboarding. Set exit criteria and a review date. If the unit still refuses, escalate to the steering committee with a written options paper: accept the exception with a named risk owner and expiry date, or mandate migration. Document either decision. The regulator cares less about which SIEM wins than about a single risk view and unified reporting, so preserve those outcomes even if a temporary local exception is granted.