You Just Acquired a Company

The deal closed and you now own about nine hundred endpoints that nobody on your team has ever logged into. There is no reliable inventory. Their previous security tooling may or may not still be licensed. Somebody senior has asked, reasonably, whether anything is already inside that fleet, and your honest answer this morning is that you have no way to know.

The hard part of this job is not the deployment. It is that you have no baseline. On your own fleet you can tell an anomaly from an anomaly because you know what ordinary looks like there. On theirs, everything is unfamiliar, so everything looks suspicious and nothing does, which amounts to the same uselessness.

This page is the order that gets you from no visibility to a real baseline, and it is deliberately front-loaded with the boring steps, because a sweep run against 60 percent coverage produces a number somebody will quote and nobody should trust.

What will I know by the end?

Which of their machines are reporting and which are not, what the platform already flags across the acquired fleet, what their normal software estate actually consists of, and a set of recorded judgments that make the second week's sweep sharper than the first week's.

Why this works

Three ideas carry this one, and they are the reason the boring steps come first.

Rarity is measured against a population, so the population has to be right. Prevalence, opinions and report subscriptions all scope to an environment. Give the acquired fleet its own and "rare" means rare on their machines, which is the question you are asking. Merge it into yours and their entire software estate reads as nine hundred machines of unfamiliar software.

Coverage is a precondition, not a metric. A sweep against 60 percent of a fleet produces a number somebody will quote and nobody should trust. Establishing who is reporting is not preparation for the work; it is the first finding, and it bounds every claim that follows.

Backscan is what makes day one useful. A forwarder installed this morning collects what is already on disk, not only what arrives next, so the fleet's existing files become answerable without waiting for anything to happen. That is why you can ask about the time before you arrived at all.

There is no seed to hand Backstory here, which is worth saying plainly. Its starting points are a hash, a hostname, or an IPv4 address, and this playbook begins with a fleet rather than an indicator. Once a sweep produces a specific bad file, that hash is a seed, and An EDR Alert Just Fired is the page that takes it from there.

Step 1: Where does their data go?

Give the acquired fleet its own environment. Decide this before you install anything, because moving it afterwards is work.

An environment partitions both data and access, and every reason to separate them is live in an acquisition:

Their baseline is not your baseline. Prevalence, opinions, and threat report subscriptions all scope to an environment. Kept separate, "rare here" means rare on their fleet, which is the question you are actually asking. Merged into yours, their entire software estate reads as nine hundred machines of unfamiliar software and drowns your own signal for a quarter.
The judgments you are about to make are theirs. You will mark a great deal of their software Trusted over the next fortnight. Those calls belong to their fleet, not to yours.
Access is not settled yet. Their IT staff may need to read it, your team certainly does, and legal may have views for a while. Environment boundaries are how you express that without copying data around.
The deal may unwind, or the fleet may be folded in. Either is easier from a separate environment than from a merge you have to unpick.

Step 2: What do I check before I deploy anything?

Their network, once per network path. Run the pre-deployment check on one machine in each site, subnet, or cloud region you are about to deploy into.

This is the step people skip on an acquisition, and it is the step that most often costs a week. You have no idea what is between their endpoints and the internet. A TLS-intercepting proxy is the common finding, and it fails in the worst possible way: the install succeeds, the service starts, nothing errors loudly, and no file data arrives. Discover that on one machine and it is an afternoon. Discover it after nine hundred installs and you are debugging a fleet while somebody waits for your exposure answer.

Their egress rules, their proxy, their existing endpoint agents. Run the compatibility check too, on a representative machine, so you know what else on those hosts watches file activity before the two products meet.

Step 3: How do I know coverage is real before I read any result?

Open Assets and compare what reported against what you expected. See Assets.

You need two numbers to run this playbook honestly: how many machines the acquisition includes, and how many are checking in. The first number is usually softer than anyone admits, which is itself a finding worth writing down. Reconcile against their asset register, their identity provider, their hypervisor, whatever exists. The gap between the register and the check-ins is the part of the fleet your answer does not cover, and it belongs in the answer.

Then set a group policy for the fleet rather than leaving nine hundred machines on defaults. Asset Configuration covers what a policy controls, and two settings matter disproportionately here. Collection is aimed at executables, scripts, and related artifacts, roughly 65 formats by default and tunable, so decide whether their estate needs anything added. And an unfamiliar fleet is exactly where a backscan earns its keep, since a one-time backscan can be run against a whole asset group from the Groups tab and it is how you find out what is sitting on disk rather than waiting for it to be touched.

Step 4: What can Stairwell tell me about the time before I arrived?

This is the honest limit of the whole exercise, and getting it straight now keeps you from overstating the sweep later.

A forwarder starts observing when you install it. So first-seen in their environment begins at deployment, and the initial backscan tells you what is on those disks now, not when it got there. If a loader landed on one of their servers last March, you will find the file, and their environment's first-seen date will read as the day you deployed.

What you do get for those files is everything the corpus already knows about them: the automated verdict, how common the file is across the environments Stairwell observes, whether it is linked to any threat report, and what it resembles. Global first-seen is a real date and often a useful one, because a file the world first saw four years ago is a different proposition from one the world first saw last week.

So the sentence you write is "this file is present on these machines as of this date", not "this file arrived on this date". State which one you have. Presence is what Stairwell can prove here, and presence with the corpus's own history attached is a great deal more than their previous tooling was going to give you.

Step 5: What is the first sweep?

Three passes, in this order, all of them scoped to the new environment and all of them sorted rarity-first. Use oe: to scope, and see StairQL or CEL Query Language for the syntax.

Pass one: what the platform already flags. The cheapest possible question, and on an unmanaged fleet it is rarely empty.

oe:"Acquired Co" p:true

Pass two: what your existing intelligence already knows. Subscribe the new environment to the threat reports you already run, then read the matches. This pays off immediately rather than eventually, because a report's indicators are matched against what you have already collected as well as everything that arrives next, so the reports you have been carrying for two years get applied to nine hundred new machines the moment collection starts. Read the linking indicator on each match, not the count: a hash link is a strong statement and an address link on shared hosting usually is not.

Pass three: the rare and the unsigned. This is the pass that finds what nobody wrote a report about.

oe:"Acquired Co" magic:EXE !signed:VALID !wk

Executables on their fleet that are not validly signed and not well-known. Add the Assets column, sort by it, and read from the rare end. Expect this list to be longer than it would be on a managed fleet, because unmanaged fleets accumulate one-off installers and somebody's compiled utility, and expect to spend the first hour learning which of those are ordinary here.

Anything from any pass that survives a look goes into the ordinary loop: the object panel, AI Triage for what the file is, variants for what else resembles it, and Run-to-Ground for what landed alongside it. An EDR Alert Just Fired is that loop written out step by step.

Step 6: How do I learn what normal looks like on a fleet I did not build?

Read the other end of the list. Deliberately, with a coffee, going down from the most common file in their environment.

This is the step that separates a useful onboarding from a sweep somebody ran once. High local prevalence is their IT estate declaring itself: their endpoint agent, their VPN client, their remote monitoring tool, their imaging tooling, their line-of-business application, the utility their sysadmin compiled in 2019 and put on every server. Twenty minutes at the top of that list teaches you more about their operation than the asset register will.

Two payoffs, and the second one is the reason to do it now rather than later.

You have built the inventory nobody handed you. What software is on that fleet, in what versions, on how many machines, is a question you can now answer, and it was one of the open questions in the integration plan.
Every confirmation you record makes the next sweep cleaner. Mark their confirmed estate Trusted, with a comment naming what it is and who owns it. Safe opinions take those files out of threat report match counts and stop the notifications they generate, and rarity filtering means Run-to-Ground results get shorter too. Week two is a materially better sweep than week one, and the difference is entirely this step.

One pattern to look at hardest, because it is the one that pays: common on their fleet and rare everywhere else. That combination is the fingerprint of software built for them. Some of it is their own in-house application, which is exactly what you would expect. Some of it is an intrusion that has already spread, which is exactly what you are looking for, and neither reading is available to a tool that only knows what it has seen inside one organization.

You will hit remote monitoring tools, remote-access utilities, and password managers repeatedly in this step, and every one of them will match threat intelligence. That decision has its own page: The Alert Is a Legitimate IT Tool. Make it properly the first time, because you are about to make it thirty times.

Step 7: How do I hand this over?

The deliverable is not the sweep. It is the state you leave behind, so that the acquired fleet is something your team can operate rather than a project somebody ran.

Coverage, stated as a number. Machines reporting against machines expected, with the gap named. Everything else you say is conditional on this.
Findings, with assets and dates. What you found, on which machines, present as of when. Presence, not execution.
Recorded judgments. Opinions with comments across their estate, in their environment. This is the asset that compounds.
Standing coverage. Their environment subscribed to your reports, and a trigger configured so a match on the fleet nobody knows well reaches a person by email or webhook rather than waiting to be noticed.
Your own report for anything you established. Indicators you confirmed, written up so they keep matching after the integration project closes. See Write It Up.

What are the limits of this answer?

Coverage follows the fleet. Machines with no forwarder contribute nothing, and on an acquisition that set is larger than usual and less well known.
No history before deployment. See Step 4. Presence with dates is what you have.
Only what is collected. Roughly 65 executable and script formats by default, tunable. A document or a configuration file is outside the default set.
Stairwell is not inline. It is not a network enforcement point and it did not stop anything on that fleet before you arrived. What it gives you is the file history from the day you start, plus everything the corpus already knows about the files that were already there.

What should I read next?

Pre-Deployment Check, which is Step 2 in full, including what a TLS-intercepting proxy does to a rollout.
Environments, for what a boundary actually separates and how access follows it.
The Alert Is a Legitimate IT Tool, for the decision you will make constantly in Step 6.
Prevalence, for reading local against global, which is the whole of Step 6.