How to prepare for an offensive audit and get real value from it

When a company hires us for an offensive audit, there is one reflex that comes up almost every time. In the days before, the IT team rushes to patch servers, close old access and review configurations against the clock so that everything looks spotless on the day of the test.

It is understandable and it is, almost always, a mistake.

An offensive audit is not an exam you have to pass. It is a snapshot of how you really are on an ordinary Tuesday, when no one has done a clean-up the weekend before. If you dress up the environment for the occasion, you will be paying to have a company audited that does not exist for the rest of the year. What actually deserves preparation is something else. Almost none of it has to do with patching holes ahead of time.

This is what is worth having ready.

Decide what you want to know

“Test everything” is not a scope, it is a way of not deciding. An audit has a budget and a timeframe. How they are spent depends on the question that keeps you up at night.

Wanting to know whether someone can get in from the internet without credentials is not the same as whether a disgruntled employee can escalate to control of the domain, or whether ransomware landing on a laptop spreads to the servers. Each of those questions leads to a different type of audit and a different starting point.

This is the part where the client adds the most value. You do not need to be technical to do it. It is enough to put on the table what would hurt you most if it went wrong. We translate that into a technical scope, but you set the priority.

Know what you have

You cannot scope what you do not know exists. Before starting it helps to have a list, even a rough one, of your domains, public IPs, important applications and who is responsible for each thing.

It does not have to be a perfect inventory. In fact, the moment of putting it together is often revealing, because that is when the server set up by someone who has since left, the subdomain from a campaign three years ago, or the admin panel no one remembered was still published all surface. What surfaces there is, very often, the first thing an attacker looks at.

Get the logistics ready

This is the boring part and it is the one that decides whether the team is productive from the first hour or spends the morning waiting for access.

Depending on the type of audit, that can mean credentials and test accounts at different privilege levels, VPN access, a network drop for the internal audit, or a machine inside the office. It is also worth agreeing the window in which the testing will happen and leaving a contact person who can unblock whatever is needed without having to open a ticket that takes two days.

Every hour the team spends waiting for a permission is an hour it does not spend looking for the flaw that actually matters to you.

Decide whom you tell and whom you do not

This is a strategic decision, not a formality. It is worth thinking through.

The underlying question is whether or not you tell your security team. If you tell them, the test runs without scares and no one triggers the protocol for a real incident by mistake, but you give up measuring something that goes unmeasured the rest of the year, which is the ability to detect and stop an attack while it is happening. If you do not tell them, that ability does get tested, at the cost of a few scares and the odd late-night call.

There is no right answer. It depends on whether what you want to measure is only the technology or also the people and the processes that have to react when something happens. What must be clear beforehand is the written authorisation from whoever has the power to give it and a couple of emergency contacts in case something goes wrong.

Do not dress up the environment the week before

We come back to the beginning, because it is the most expensive mistake and the easiest to make.

Do not mass-patch, do not change configurations, do not stand up new defences just for the occasion and do not clean the logs. Every last-minute change turns the audit into the portrait of a system you will not be running the following week.

If there is something you know is wrong and you are embarrassed by it, leave it. That is precisely what you want to see documented, with its impact and its priority, so you can justify internally the time and the budget to fix it.

Keep your backups current

An offensive audit is done carefully, but it works on real systems. Every now and then a fragile service or a legacy application does not take it well.

Before starting it helps to have recent and verified backups, to know who can restore them and to agree what happens if we find something critical midway. Defining that stop-and-notify threshold in advance avoids decisions improvised in the heat of the moment.

Prepare to act, not to file

This ties in with something we already covered when we wrote about why passing a compliance audit does not mean you are secure. An audit that ends up as a PDF in a drawer has not protected you from anything.

The most important preparation happens before you start and consists of deciding who will own fixing the findings, reserving team time for the following weeks and budgeting for the re-test that confirms what was fixed is genuinely closed. The audit is the cheap part. The value is realised in the fixing. That has to be planned from day zero.

The better you have these points sorted, the cheaper and the deeper the audit comes out, because the team’s time goes into finding real problems rather than waiting for a credential. Preparing for an offensive audit is not about dressing up for the photo, it is about making sure the photo is worth something.

---

If you are thinking about auditing the security of your organisation and want help defining the scope, write to [email protected].