Your institution just closed an acquisition. The integration team has a 90-day plan. Your security team has three weeks and a list of systems you inherited that's already out of date.
The gap between what you think you acquired and what's actually running in production is where the risk lives. This guide walks through what to test first when you inherit an environment and how to structure that testing so you're covering actual exposure, not just documented infrastructure.
Scope - What This Guide Covers
This guide addresses security testing priorities for financial institutions immediately following an M&A close. It covers:
- Rapid attack surface discovery for inherited environments
- Testing prioritization when you have incomplete asset documentation
- Handling inherited vendor relationships and integrations
- Continuous testing triggers that align with post-acquisition integration milestones
It does not cover pre-close due diligence procedures or long-term integration security architecture.
Key Concepts and Definitions
Attack Surface Discovery: Identifying all external-facing assets, services, and connections in an inherited environment, regardless of documentation.
Shadow IT: Systems or services operating without formal documentation. In acquisitions, this includes integrations the acquired institution maintained but never formally inventoried.
Integration Inheritance: Third-party vendor connections, API relationships, and data-sharing agreements that transfer with an acquisition but weren't explicitly identified during due diligence.
Change-Triggered Testing: Security testing that initiates based on environmental change, like new assets or integrations, rather than a calendar schedule.
The Inherited Environment Problem
When you acquire another institution, you're not just buying their documented infrastructure. According to PwC, 80% of dealmakers uncovered cybersecurity issues in at least one-fourth of their targets. Deloitte's data shows 53% encountered critical problems after deal announcement.
The documentation gap is structural. Due diligence evaluates the target's documented controls. It doesn't map every fintech integration they've launched over the past five years or catalog the vendor relationships that came with their last acquisition. You inherit all of it.
Your first 30 days post-close determine whether you discover that exposure through testing or through an incident.
Testing Priorities: First 30 Days
Week 1: External Attack Surface Mapping
Start with what's visible from outside your perimeter. Run active discovery against all IP ranges and domains that came with the acquisition:
- External-facing web applications and portals
- API endpoints (documented and undiscovered)
- Email infrastructure and authentication surfaces
- Cloud service accounts and storage buckets
- SSL/TLS certificates that reveal additional subdomains
Don't wait for the acquired IT team to provide an asset inventory. Their documentation is incomplete. Discovery tools will find assets faster than internal documentation reviews.
Week 2: Authentication and Access Control
Test every system that handles credentials:
- Single sign-on implementations
- Multi-Factor Authentication (MFA) coverage and bypass paths
- Privileged access management for administrative accounts
- Service accounts with elevated permissions
- Legacy authentication mechanisms that predate current standards
The acquired institution's access control standards likely differ from yours. Test what's actually enforced, not what policy documents say should be enforced.
Week 3: Inherited Vendor Integrations
This is where SOC 2 compliance stops helping you. The acquired institution may have vetted their vendors. They probably didn't test the actual integration security.
For each vendor relationship you inherited, test:
- API authentication and authorization controls
- Data exposure through integration endpoints
- Session management and token handling
- Rate limiting and input validation
- Whether the integration can be used to pivot into your core environment
SecurityScorecard's analysis found that 41.8% of breaches affecting fintech firms originated from third-party vendors. The vendors came with SOC 2 reports. The breaches came through integration weaknesses those reports don't cover.
Week 4: Cardholder Data Flows
Map every system that touches Primary Account Numbers (PANs) or other Cardholder Data:
- Payment processing endpoints
- Transaction logging and storage
- Data replication and backup systems
- Development and test environments (where production data often leaks)
- Vendor systems receiving payment data
PCI DSS scoping depends on accurate data flow mapping. The acquired institution's scope documentation is a starting point, not ground truth. Test the actual data flows.
Common Pitfalls
Trusting the Asset Inventory: The acquired institution's CMDB is outdated. Systems get deployed faster than documentation updates. Start with active discovery, then compare against documentation to find the gaps.
Assuming Vendor Compliance Equals Integration Security: A SOC 2 Type II report tells you the vendor has controls. It doesn't tell you whether the API connection between your environment and theirs is secure. Test the integration, not just the vendor.
Scoping Based on Deal Structure: You inherited the attack surface whether it was documented in due diligence or not. The security testing scope needs to match what's actually running, not what the term sheet described.
Sequential Testing: You don't have time to test everything before integration work starts. Prioritize based on exposure and data sensitivity. Test external-facing systems first, then work inward.
Waiting for "Complete" Information: You'll never have complete documentation of the inherited environment. Start testing with what you know and expand scope as you discover additional assets.
Quick Reference: Testing Triggers Post-Acquisition
| Milestone | Testing Trigger | Priority Assets |
|---|---|---|
| Day 1 (Close) | External attack surface scan | Internet-facing systems, domains, IP ranges |
| Week 1 | Authentication testing | SSO, MFA, privileged access systems |
| Week 2 | Integration assessment | Inherited vendor connections, API endpoints |
| Week 3 | Cardholder Data mapping | Payment systems, transaction databases, logs |
| Month 2 | Network segmentation testing | Connections between inherited and existing environments |
| Month 3 | Continuous monitoring | Change detection on inherited attack surface |
Implementation: Continuous Testing for Growth
Annual penetration testing creates a 345-day gap. When you're acquiring institutions or launching integrations quarterly, that gap fills with untested exposure.
Change-triggered testing closes it. When attack surface monitoring detects new assets from an acquisition, testing initiates automatically against those specific systems. When a new vendor integration goes live, the authentication and authorization controls get tested before the connection has been exploited.
This isn't about testing more frequently on a calendar. It's about testing when your environment changes, which in a growing institution is constantly.
The institutions that wait until the annual test to discover what they inherited will keep learning about their attack surface from incident response reports instead of penetration test findings.
