Managed support teams hear the same assumptions about security incidents from customers again and again, usually in the first tense phone call. Some of them are harmless. Others cost days, evidence or money. This article tests six popular beliefs against the reference material in the Ops Atlas entry on ResponseOps, an informal label for running incident response as a standing capability. If you buy or deliver support services, these are the corrections worth making before the bad day arrives.

A quick note on wording, which becomes the sixth myth below. The Atlas page describing ResponseOps states that the word is not a standard term. Keep that in mind when you draft service descriptions.

Myth 1: “Wipe the server and reinstall; problem solved”

The reality. A rebuild feels decisive, and it does remove one compromised machine. What it does not remove is the person or group that got in, and it destroys the traces that would show how they did it. The Atlas puts it bluntly: reimaging deletes evidence and one foothold, not the actor.

What a support team should do instead. Take a memory capture and a disk copy first, record hashes at the moment of collection, log custody in UTC and keep originals untouched. Then widen the lens: which credentials were on that machine, and where else have they been used? Only when that picture is reasonably complete should rebuilding begin. The Atlas lists evicting before scoping as a classic route to re-entry, with the intruder simply returning through an access path nobody found.

Myth 2: “Contain everything immediately”

The reality. Speed sounds like a virtue, and in many cases it is. But dramatic, broad containment can alert an intruder, who may react by accelerating damage or by triggering destructive logic set up in advance. The Atlas mentions dead-man switches that activate when a host is isolated or switched off.

What a support team should do instead. Weigh the options explicitly. The Atlas cites the containment criteria from the 2012 US guidance: the scale of possible harm, the fate of evidence, service uptime, effort required, the step’s effectiveness and its staying power. The 2025 revision goes further by asking teams to balance quick recovery against the value of watching an attacker for a while. If you choose to delay, time-box the delay and name the person who approved it, so the pause is a decision and not a drift.

Myth 3: “We have backups, so this is a restore job”

The reality. Backups answer the question “can we get our systems back?” They say nothing about “what did the attacker take?” In double-extortion cases, data is copied out before systems are encrypted, so restoring does not undo the theft. And if the backup itself was compromised, restoring from it can lead straight to re-encryption.

What a support team should do instead. Treat restore as one workstream among several. Validate backups before use, keep notification and scoping going in parallel, and agree with the customer who speaks to regulators and clients. The Atlas adds that the US cyber agency considers eradication and recovery compatible with running at the same time, so there is no need to hold everything until a long investigation ends.

Myth 4: “Label the report privileged and it is safe”

The reality. Customers sometimes assume that having a lawyer engage the forensic firm, or stamping a document, guarantees confidentiality. The Atlas points to a 2020 US federal court ruling arising from a 2019 bank breach, where a consultant’s findings had to be handed over despite a lawyer’s involvement in the engagement. According to the entry, the court reasoned that a pre-breach statement of work would have yielded substantially the same report, so privilege failed.

What a support team should do instead. Do not give legal advice. Say, plainly, that the customer’s counsel should decide how engagements and reports are structured, and that routing alone is not a shield. This is an information point and varies by jurisdiction; it is not a conclusion about any particular matter.

Myth 5: “Attribution and incident counts tell us how we are doing”

The reality. Customers like to ask who did it, and managers like to chart how many incidents occurred. The Atlas notes that, in line with NIST’s view, trying to attribute an attack is often futile, and that incident counts measure workload rather than quality. A quiet quarter might mean either excellent prevention or poor detection.

What a support team should do instead. Report measures that expose behaviour: the intruder’s unnoticed stay, the lag until declaration, the lag until containment, growth of the known footprint, returns after eviction, deadline compliance for notices and the integrity of preserved evidence. The Atlas’s worked example shows an intruder active for 11 hours 17 minutes before the alert, a 45-minute declaration delay and containment after 5 hours 45 minutes. It then shows a quarter with one repeat entry out of four incidents, 80 percent on-time notices and 97.4 percent evidence integrity. Those are teaching figures, not targets, but the format is what you should copy.

Myth 6: “ResponseOps is an official standard, so put it in the contract”

The reality. It is not. The Atlas explains that no incident response standard uses the word, that an international standard family calls the practice “ICT incident response operations”, and that other organisations use similar words for unrelated things. In an agreement, ambiguity gets expensive.

What a support team should do instead. Write “incident response” and define the services precisely: who declares, who preserves evidence, who coordinates eviction, response times for the first call, and which tasks sit with the customer. For a reminder of how clear service principles reduce friction, see the piece on core principles for dependable software delivery.

Why these six keep resurfacing

Every myth listed here is a reflex posing as a plan, and a real plan asks who decides before anyone acts. Wipe, contain, restore, stamp, count, name: each feels like action. The remedy is boring and effective: assign ownership, rehearse, write down the clocks, and keep response conversations off systems the attacker may read. On that last point, the Atlas lists running incident chat on compromised email or messaging as an anti-pattern, so a support team should always have a phone bridge or a separate channel ready.

There is also a skills angle for support engineers. Many of the steps above reward habits that operations people already have, such as writing runbooks and automating repeatable work, which is the territory explored in how operations engineers grow into reliability roles. Add evidence handling and a working knowledge of notification clocks and you have a credible response-support offering.

A short conversation script

When a customer opens with one of these myths, a calm reply keeps the call productive. Try: “Before we rebuild, let us capture what we need so we can see how they got in.” Or: “We can contain quickly, but let us agree what we might lose if we move too fast.” Or: “The backup helps with recovery; it does not tell us what was copied.” Each response respects the customer’s urgency while steering toward the step that matters.