Luck Is Not a Control: A 90-Day Sequence for Converting Near-Misses Into Program Change

The incident that never got a number

A help-desk technician notices that a contractor's account has been querying an unusual reporting table for three days. She escalates. The account is disabled, the contractor is contacted, and the explanation turns out to be a misconfigured export job. Everyone exhales. Nothing is written down.

Six months later, the same table appears in an extortion negotiation.

Near-misses are the most underused input in enterprise security, and the reason is structural rather than cultural. An incident opens a ticket, starts a clock, assigns an owner, and generates a post-incident review because a process exists to catch it. A near-miss does none of those things. It is resolved conversationally, often by the person who noticed it, and then it evaporates.

The window in which a near-miss is useful is short. Attention and budget align briefly, executives are willing to hear uncomfortable things, and the people closest to the event still remember what they assumed at the time. The 90 days that follow are the whole opportunity.

Days 0 through 14: freeze the record

The instinct to fix something immediately is strong and usually wrong. Fixing first destroys state and, worse, rewrites the story before anyone has captured it.

• Open a record. Give the near-miss an identifier in the same system that tracks incidents, even if it is classified as an observation. If it has no number, no one owns it.
• Document the detection path. How was it noticed? In most near-misses the answer is accidental — a help-desk call, a vendor notification, a colleague glancing at the wrong dashboard. The detection path is a finding in its own right and should be written down before anyone is tempted to describe it as monitoring.
• Build a timeline. Reconstruct to the minute where logs permit and to the hour where they do not. Note what was not logged, and why.
• Extend retention. Place a targeted hold on the relevant log sources so that normal rotation does not erase the evidence before the review concludes.
• Interview separately. Speak with each person who noticed or responded, individually and early. Ask what they believed was happening, what they decided, and what they chose not to escalate. Memory consolidates into a tidy narrative within about two weeks.

Days 15 through 45: a review that ends in decisions

The failure mode here is the classic root-cause workshop that produces a fishbone diagram and a list of forty action items, none of which are funded. Substitute a decision-focused review.

Convene a small group — no more than six — and include the person who noticed the event. Run two or three sessions of ninety minutes rather than a standing committee. The central question is not which control failed but what decision was made at each junction, by whom, on what information, and with what authority.

Produce three outputs:

1. A decision map. Each junction in the timeline, the decision taken there, and the information available at that moment. Most near-misses reveal that reasonable people made reasonable decisions against bad information.
2. Candidate systemic fixes. Three to five, described as classes of problem rather than instances. Add a rule to this detection is an instance. Reduce the time between anomalous query volume and human review is a class.
3. An explicit not-doing list. What the organization is choosing not to fix, with the reasoning. This is the most valuable page in the document, because it prevents the same conversation from recurring unfunded next quarter.

Days 46 through 75: choose few, fund them, name an owner

Select no more than three fixes. The selection criteria should be stated in the document:

• Does it address a class of failure rather than a single instance?
• Does it reduce detection latency, or only add another alert to an unread queue?
• Does it have a named owner and a date, or an aspiration and a steering committee?
• Will it survive the next reorganization?

A fourth criterion is worth adding quietly: does it cost less than the meeting series that will otherwise be convened about it?

Buying a tool is not a fix. If a purchase is part of the plan, define the outcome the tool must produce and the date by which the outcome will be verified. Otherwise the near-miss converts into a procurement process and the underlying condition persists behind a new console.

Days 76 through 90: communicate without overclaiming

The temptation at this stage is to announce that defenses have been hardened. Resist it. Overclaiming after a near-miss is how programs lose credibility the second time.

Sequence the communication deliberately. Speak to the team that noticed the event first, by name if they consent, because they did the organization a favor and should be told so publicly. Then the risk committee. Then the board or audit committee, if the event touched a material system.

The framing should follow a consistent shape: this was found because of X; here is what changed; here is what we still cannot see. That third clause is what separates a mature program from a press release. Executives who are told what remains invisible tend to fund the next increment; executives who are told everything is fixed tend to stop asking.

Four ways this sequence fails

• It becomes a blame exercise. The moment the review is framed as fault-finding, the people who notice the next near-miss will stop reporting it.
• The action list grows past three. Scope creep at day 50 is the most common cause of nothing changing by day 365.
• The fix is declared complete on delivery. A control that was installed but never tested under load has been purchased, not implemented.
• The detection backlog is not updated. Every near-miss should generate at least one detection engineering ticket, even if it is only to instrument the accidental path that worked.

The point is not the document

The output of this sequence is not a report. It is three funded changes, a written record of what the organization chose not to do, and a team that now believes reporting an almost-incident is worth the effort. Luck got the organization through the first event. The 90 days are how it stops depending on luck for the next one.