How ISO 27001 Changes the First 72 Hours of a Breach

A breach, whether it starts with a stolen login or a supplier being compromised, is something most founders assume won’t happen to them. ISO 27001 won’t change the odds as much as people hope, and anyone telling you a certificate stops you being attacked is overselling it. What it changes is what happens next. The first few days after a breach usually decide whether it stays a contained problem or becomes the thing your customers remember.

The First Morning

Picture the morning it happens without any of this in place. Nobody is sure who’s in charge. There’s an argument about whether to take systems offline and who has the authority to decide. Someone asks how far back the logs go and the answer is a shrug. Meanwhile a customer has noticed something is wrong and is already emailing, and there’s a legal deadline running that nobody has started counting. Every decision is being made badly, under pressure, for the first time.

Now the same morning with ISO 27001 behind you. There’s a plan. People know their roles and who makes the call on containment. The logs are there and go back far enough to show what happened. Someone owns the customer and regulator communication, and the clock was started the moment the incident was confirmed. The breach is still bad, but it’s being handled rather than survived.

What the Standard Actually Gives You

ISO 27001 requires an incident response process, so there’s a written plan with defined roles and escalation before anything goes wrong. It requires logging and monitoring, so you detect an intrusion yourself in days rather than hearing about it from the attacker months later, and so you have the evidence to work out what actually happened. It expects that plan to have been tested, so the first time you run it isn’t during a real incident. And it requires a review afterwards that feeds back into the system, so the hole that let the attacker in gets closed rather than forgotten.

The Clock You’re Working To

When personal data is caught up in a breach, GDPR gives you 72 hours to notify the supervisory authority. If you fall under NIS2 or DORA, the windows are tighter still, as we covered in the piece on EU regulation. Hitting those deadlines is close to impossible if you’re also trying to establish what happened from scratch.

This is where the wider set of standards earns its place. ISO 27701 extends the management system to privacy, which is exactly the ground a personal-data breach lands on. ISO 22301 is the recovery side, getting the business running again rather than only closing the incident.

Why Buyers Ask About This

Enterprise security questionnaires now ask directly about your incident response process. They want to see that you have one, that roles are defined, and that it’s been tested. So a real incident response capability isn’t only about surviving the bad day. It’s increasingly something you have to evidence to win the contract in the first place.

How Stenward Approaches It

We build the incident response process as part of the management system, not as a document that gets written once and never opened again. That means making sure the logging is genuinely in place, the roles are clear, the notification obligations are understood before you need them, and the plan has been run through at least once so it works under real pressure. The aim is that if the bad morning comes, you’re handling it rather than inventing the response as you go.

Last reviewed: November 2026. This article is general information, not legal advice. Breach notification obligations depend on your circumstances and the regulations that apply to you.