The Full Cybersecurity Blueprint for a 10,000-Employee Enterprise Technology Company

At this size the identity problem isn't "turn on SSO" — it's federating identity across business units that likely each ran their own directory before being unified, including at least one acquired company with its own identity provider still partially in place. One cloud identity provider as the actual source of truth, with every business unit's applications federated into it via SAML/OIDC, phishing-resistant MFA enforced everywhere, and SCIM-driven provisioning tied to HR across every entity in the org chart, not just the original parent company.

Non-human identity (NHI) deserves its own line item here, not an afterthought folded into "identity" generally — service accounts, API keys, CI/CD pipeline credentials, cloud workload identities, Kubernetes service accounts, and now AI agent identities routinely outnumber human accounts 10-to-1 or more at this scale, and they're the identity category most likely to be invisible, long-lived and over-privileged because nobody owns the lifecycle the way HR drives it for people. Build an actual NHI inventory — what exists, what it can touch, when it was last used, who owns it — before trying to enforce anything, and feed anything privileged straight into the PAM program below rather than treating NHI governance as a separate initiative.

The unglamorous part of human identity is the migration itself: decommissioning legacy per-business-unit identity stores without breaking access mid-transition. Run it in parallel with a hard cutover date per business unit, not an indefinite dual-running state — dual identity stores are themselves a standing attack surface and an audit headache that tends to outlive its planned lifespan by years if left open-ended.

At 10,000 employees with multiple business units and inherited infrastructure, standing privileged access — a domain admin account that's always-on, a shared root credential on a legacy system nobody remembers the full blast radius of — is common enough to deserve a dedicated program distinct from standard identity. A credential vault for all privileged accounts and the privileged subset of NHI (service accounts and API keys with write or admin-level access, specifically), just-in-time elevation instead of standing admin rights, and session recording on anything touching production or sensitive data.

Prioritize by blast radius, not by how official the system looks: a legacy on-prem system inherited through acquisition with a shared local-admin password is often higher real risk than a well-governed production cloud account, precisely because nobody's looked at it carefully since the acquisition closed.

A single EDR/XDR platform across every business unit, replacing whatever fragmented per-BU tooling exists from before unification — fragmentation here means gaps in coverage nobody can see, not just an inconvenience. Enforce consistent device posture (patch level, disk encryption, screen lock) centrally regardless of which business unit a device belongs to or which identity provider it was originally issued from.

The consolidation project itself is usually the hard part, not the tooling — migrating tens of thousands of endpoints off legacy agents while a business unit is mid-integration takes real program management, and it's worth treating as its own workstream with its own timeline rather than an assumed side effect of "rolling out EDR."

Identity-aware Zero Trust access replacing legacy site-to-site VPNs and flat networks, almost certainly plural at this size — each acquired business unit likely brought its own network architecture, some of it flat by design because it was never meant to be exposed to the rest of the organization. Build access policy around identity and device posture, not network location, specifically because "which network segment is this on" stops being a reliable signal once multiple business units' infrastructure is bridged together.

Segment aggressively between business units during integration, even while working toward unified identity — a flat bridge between a newly-acquired company's network and the core corporate network, built for short-term convenience during integration, is one of the most common ways a breach in a smaller, less-mature acquired unit becomes a breach of the whole company.

A dedicated secure email gateway in front of mail flow, enforcing DMARC to reject across every domain the organization owns — including domains inherited from acquisitions that are easy to forget still receive mail and are still spoofable. Anti-phishing, anti-malware and attachment sandboxing tuned for BEC and invoice-fraud patterns, with link rewriting so a malicious URL is still caught days after delivery.

Audit the full domain and mailbox inventory at least annually — at this size, with this much M&A history, there are reliably more mail domains in active or semi-active use than the security team's working list accounts for, and each one is a potential impersonation target.

Multi-cloud is close to a given at this size — different business units, especially acquired ones, frequently standardized on different providers before unification. A CSPM/CWPP layer that works consistently across every cloud in use, not a tool that only covers whichever provider the original parent company happened to pick, with policy as code enforced at the CI/CD and infrastructure-as-code layer so drift gets caught before it reaches production.

Build one unified cloud account/subscription inventory across every business unit as the actual foundation here — at this scale it's common for the security team's inventory to lag the real account count by a meaningful margin, usually because a business unit spun up its own account outside central IT's visibility at some point and nobody reconciled it afterward.

Cloud identity entitlement management (CIEM) matters even more here, since permission sprawl compounds across every business unit's own history of who granted what to whom — review it as its own workstream, not a sub-task of general IAM. Centralize cloud audit logs from every provider and every business unit into the same unified SIEM used for everything else, rather than leaving each cloud console as its own island only that business unit's team ever checks. And apply the same segmentation discipline used in network security here too — a business unit's cloud environment shouldn't have an open path into another's just because both happen to be "in the cloud."

This domain doesn't exist in a smaller, single-business-unit plan, and it's one of the most consequential ones here: systems inherited through acquisition — on-prem data centers, legacy applications nobody wants to touch, infrastructure running software past end-of-life — carry real, underpriced risk precisely because they're unglamorous and easy to deprioritize against shinier cloud-native work.

Run a standing inventory and risk-tiering process for every inherited system: migrate to the unified cloud environment where it's cost-justified, apply compensating controls (network isolation, enhanced monitoring, PAM) where migration isn't imminent, and formally risk-accept — in writing, with an executive signature, not silence — anything that's staying as-is. Silence is the actual failure mode here, not any single technical gap.

Build a standard security due-diligence playbook for future acquisitions, run before the deal closes, not after: identity architecture, cloud footprint, known vulnerabilities, incident history. The findings won't block most deals, but they define exactly what joins the integration backlog on day one instead of being discovered eighteen months later during an audit.

A SaaS security posture management (SSPM) tool connected to identity-provider logs to build a real inventory of what's in use across every business unit — at this size and with this much organizational history, the gap between the official approved-SaaS list and what's actually logged into daily is usually large, and each acquired business unit adds its own set of tools nobody centrally reviewed.

Tier by data sensitivity and enforce centrally once discovered: anything touching customer or employee data gets brought under SSO and a real security review; low-risk internal tools get lighter-touch visibility. Don't try to review everything with the same rigor — at this scale that's a losing battle that burns the team's limited review capacity on low-risk tools.

Classification first, DLP enforcement second — at this size, with multiple business units generating and storing data under historically different standards, a DLP tool deployed before classification is consistent just generates noise nobody can prioritize. Encryption at rest and in transit enforced as a baseline across every business unit's data stores, including ones inherited through acquisition that may not have started from the same bar.

Focus DLP enforcement on the exfiltration paths that actually matter at this scale — cloud storage sharing settings, email attachments leaving the organization, and increasingly AI tool inputs — rather than trying to inspect everything everywhere, which mostly produces alert fatigue instead of risk reduction.

At multinational scale, data privacy stops being purely a legal/policy function and becomes an engineering problem: GDPR and other regional regimes require knowing where personal data physically lives, how it flows between regions, and being able to actually act on a deletion or access request across every system that holds it — including systems inherited from an acquired business unit in a different region with different data residency obligations.

Build a real data-flow map as the foundation, region by region and system by system, before promising any regulator or customer a specific residency or retention guarantee. Automate subject access and deletion requests wherever system volume makes manual handling unrealistic — at this scale, manual handling becomes the actual bottleneck and compliance risk, not the underlying legal requirement itself.

Immutable, offsite backups across every business unit's critical systems, including legacy on-prem infrastructure that's easy to deprioritize precisely because it feels like someone else's problem after an acquisition. At this scale, the blast radius of a ransomware event spanning multiple business units is a board-level, potentially material event, not just an operational incident.

Test actual restores at least quarterly for the systems that matter most, with a documented, rehearsed order of restoration — at this size, knowing what to bring back first, and in what sequence given real dependencies between systems from different business units, matters as much as the backups existing at all.

SCA, SAST and container scanning as CI/CD gates across every product line and business unit — at this size, that usually means standardizing security tooling across multiple previously-separate engineering organizations, each of which may have built its own pipeline conventions before unification, which is as much an engineering-culture project as a tooling one.

Embed AppSec engineers directly with the largest product lines rather than running security as a purely central, request-driven function — at this scale, a fully centralized team becomes the bottleneck, and embedded engineers build the trust and context needed to get security gates adopted rather than routinely overridden.

API discovery first, at this scale, before anything else — multiple product lines and business units almost always means more undocumented internal and partner-facing APIs than the official inventory accounts for, and broken object-level authorization between services from different business units is a realistic, underrated breach path once those services start talking to each other post-integration.

Prioritize discovery and authorization review on the integration points between business units specifically — that's where the newest, least-reviewed API surface area actually lives, more so than in any single product's long-stable API.

At this size, AI risk spans employee use of third-party AI tools, AI/agentic features shipped across multiple product lines, and — specifically here — AI tools or models inherited through acquisition that were never reviewed against the parent company's standards. One AI gateway and governance program across every business unit, not a per-BU patchwork, with a live inventory covering acquired AI usage as part of the standard M&A integration checklist.

The threat landscape is the OWASP LLM Top 10 — prompt injection, insecure output handling, training-data poisoning, model supply-chain risk, excessive agency and the rest — applied consistently across every product line shipping AI features, with a hard human-in-the-loop gate on any agent capable of high-impact action, logged in enough detail to reconstruct an incident afterward.

ISO/IEC 42001 is worth treating as a near-term target, not a someday item, at this scale — enterprise customers and regulators are increasingly asking, and the model inventory, risk-assessment process and human-oversight controls described above are most of what a 42001 program actually requires. AI is also increasingly a tool for the unified SOC itself: AI-assisted triage and natural-language querying across a now-much-larger volume of log data is real leverage once detection is unified, with the same augmentation-not-delegation principle applied to who stays the decision-maker.

Continuous external and internal vulnerability scanning across every business unit's attack surface, prioritized by actual exploitability and exposure rather than CVSS score alone — at this scale, the volume of findings makes blanket severity-based triage unworkable, and risk-based prioritization becomes the only approach that scales.

Specifically include legacy and acquired-company infrastructure in scope from day one of scanning, not as a later phase — that's reliably where the oldest, least-patched, highest-real-risk findings concentrate, even though it's often the infrastructure furthest from the central security team's regular attention.

At this size, a largely in-house SOC becomes realistic and usually the right call — enough log volume and enough institutional risk to justify dedicated detection engineering, with MDR or an external partner retained for surge capacity and off-hours depth rather than as the primary tier-one function. One unified SIEM correlating identity, endpoint, cloud and application logs across every business unit, replacing any fragmented per-BU detection tooling inherited from before consolidation.

Detection content has to be tuned per business unit's actual environment and baseline behavior, not just applied uniformly — a correlation rule tuned against the parent company's normal traffic patterns will generate different false-positive rates against a newly-integrated business unit's very different baseline, and that gap needs active tuning, not just time.

Frequent, short phishing simulations and micro-training, with content and cadence that can be tailored per business unit and per risk tier — a newly-acquired business unit, mid-integration and unfamiliar with the parent company's internal communication patterns, is a measurably softer social-engineering target during the transition period and deserves more frequent simulation during that window specifically.

Track participation and repeat-clicker rates by business unit, not just company-wide — an aggregate number that looks fine can hide one business unit with a real, concentrated problem.

A formal risk-tiering program for vendors across every business unit, consolidated into one process rather than several parallel ones inherited from pre-unification days — and, specifically at this size, a standing M&A security due-diligence function that runs before a deal closes, not after, feeding directly into the Legacy & On-Prem/M&A Integration Security backlog described above.

Prioritize review depth by data sensitivity and system criticality, same principle as everywhere else in this plan — a vendor touching customer data or production infrastructure gets a real review; a low-risk internal tool doesn't need the same bar, and trying to apply one uniformly just slows down the reviews that actually matter.

Multiple overlapping frameworks are realistic at this size — SOC 2 Type II and ISO 27001 as the baseline enterprise customers expect, GDPR and other regional privacy regimes as a legal requirement rather than a sales enabler, and ISO/IEC 42001 as the near-term AI-governance target. Automated, continuous evidence collection matters even more here than at a smaller org, because the alternative — a purely manual audit process across multiple business units — doesn't scale.

AI is increasingly part of how this team actually works, not just something it governs: AI-assisted drafting for policy language and audit responses, automated summarization of evidence collected from the continuous-monitoring tooling above, and copilot-style help flagging where a control appears to have drifted out of compliance between formal review cycles. Same principle as everywhere else AI shows up in this plan — it speeds up the analyst's first pass, it doesn't replace the analyst's judgment on what actually gets reported to an auditor or the board.

Each acquired business unit needs its own compliance gap assessment against the unified framework set as part of integration, with a clear, time-bound plan to close gaps rather than an indefinite carve-out. An indefinite carve-out for "the acquired business unit's systems" is exactly the kind of finding that turns into a real audit failure once an auditor or regulator actually looks.

A formal, documented incident response plan and CSIRT function covering every business unit under one unified process, with scenario-specific runbooks and clear authority — who can take a production system offline, who talks to customers, who talks to regulators in which jurisdiction — spelled out in advance rather than improvised during a live incident across business units that may not have worked together before.

Tabletop exercises need to specifically include cross-business-unit and acquisition-related scenarios — a ransomware event starting in a newly-integrated business unit's still-partially-legacy environment and spreading toward the core network is a realistic scenario at this size, and it's exactly the kind of scenario a generic, single-environment tabletop never surfaces.

At this size, insider risk concentrates around departures and role changes, same as at a smaller organization, but the base rate is naturally higher given sheer headcount — and specifically around acquisition-driven transitions, where departing employees from a newly-integrated business unit may have broad access to both their former systems and newly-granted access to the parent company's systems during the transition window.

Correlate HR employment-status signals with access-pattern anomalies — large data exports, unusual repo activity, access outside normal patterns — concentrated in the run-up to departures and during integration windows specifically, built on telemetry the unified SIEM and DLP program already produce rather than a separate monitoring buildout.