Communicating with the people who own the fix

Why this matters

Security teams almost never fix anything themselves. The patch is applied by infrastructure, the code is changed by developers, the configuration is altered by the cloud team, and the risk is accepted by a business owner.

Which means an analyst's effectiveness is largely a function of how well they work with people who do not report to them, have their own priorities, and did not ask for the finding. This lesson is the mechanics of that — and it is genuinely examinable material, not soft-skills filler, because the wrong move has a predictable consequence every time.

The lesson

Naming the owner of a finding

A finding with no owner does not get fixed. This is not a communication problem yet; it is a data problem, and it is the most common reason a remediation programme stalls.

Ownership has parts that are frequently confused:

• The system owner — accountable for the asset, usually a business or service owner.
• The technical owner — the team that operates it and can change it.
• The remediation owner — who will actually do this piece of work, which may be neither of the above (a database flaw on a server owned by infrastructure may belong to the application team).
• The risk owner — who can accept it if it will not be fixed. Never the security team, per lesson 1.

Getting to a real owner:

• Attach ownership to the asset record, per lesson 18, so it arrives with the finding rather than being rediscovered each time.
• Derive it from what already exists: the CMDB, the cloud account and tag, the deployment pipeline, the change history, the certificate contact, the repository's code owners.
• When it is genuinely unknown, escalate the ownership gap as its own finding. An asset nobody owns is a risk in itself and usually should not exist. Do not let an unowned finding sit in a queue being re-triaged monthly; that is a way of not deciding.
• Confirm rather than assume. Sending forty tickets to a team that does not own the systems costs you their cooperation, and they remember.

And name a person, not a group. Work assigned to a distribution list is work nobody has agreed to do.

Escalation that is proportionate

Escalation is a tool with a cost. Used early it is aggressive and damages a relationship you need next month. Used late, or never, it lets a serious risk sit indefinitely.

A proportionate ladder:

1. Direct contact with the owner. Most things end here, and a conversation often reveals a constraint the ticket did not mention.
2. A reminder with the deadline and the consequence, still direct.
3. Their manager, informed rather than complained to: "this is overdue and I want to check it has visibility."
4. The formal exception process. If it will not be fixed in the window, it should be recorded as accepted by someone with the authority to accept it. This is not a threat; it is the correct route, and it converts an argument about effort into a decision with a name on it.
5. The risk forum or steering group, where accumulated overdue risk is reported.
6. Executive escalation, reserved for genuinely serious and genuinely stuck items.

What makes escalation work rather than backfire:

• Escalate the risk, not the person. "This system has an actively exploited vulnerability and is internet-facing" invites help. "The platform team has not responded" invites defence.
• Warn first. Going over someone's head without telling them is remembered for a very long time, and costs you every future informal fix.
• Be consistent. Escalating only when you are annoyed teaches people the trigger is your mood.
• Match the severity. Escalating a medium to an executive spends credibility you will need for a critical, and the next escalation is discounted.
• Let it end. Once the risk is formally accepted by the right person, the matter is closed. Continuing to push against a documented decision is how a security team becomes something to be routed around.

Negotiating remediation timelines

Most remediation conversations are negotiations, and going in with only a deadline produces a worse outcome than going in with a trade.

What the other side is usually weighing, and it is rarely unreasonable:

• A change freeze, a release, a regulatory period, a seasonal peak.
• A patch that breaks a dependency, or needs downtime nobody will approve.
• A vendor who has not shipped a fix.
• Capacity already committed to work someone else considers urgent.
• A fix that is genuinely large — a framework upgrade, not a patch.

Approaches that work:

• Ask what is actually blocking it before proposing anything. The answer is frequently not "we don't want to", and the real blocker may be one you can remove.
• Bring the interim option. Virtual patching, disabling the feature, removing exposure, tightening access — lesson 24's toolkit. "Can we take it off the internet this week and patch in the release" is a far better conversation than a date demand, and it reduces risk now.
• Trade scope for speed. The twelve internet-facing instances this week, the other two hundred next quarter.
• Be explicit about what happens if it slips, without drama: the exception record, the named accepter, the report.
• Agree a date the owner believes in. A date imposed and missed teaches everyone the dates are fictional, which then applies to the one that mattered.
• Write it down, and follow up on the day. A negotiated date with no follow-up is a deferral with extra steps.

And when it genuinely cannot move: document, accept, expire, review. That is a legitimate outcome, not a defeat, and treating it as a defeat is what pushes teams into hiding findings.

Writing for someone who will never read the appendix

Most of your audience reads the first paragraph and the subject line. Write accordingly — this is a skill, and the exam treats it as one.

The structure that survives contact:

• Lead with the conclusion and the ask. Not the methodology, not the background. The reader should know within one sentence what you found and what you want.
• The second paragraph carries the consequence, in terms the reader cares about: the business impact, the deadline, the exposure.
• Detail below, in descending order of importance, so a reader can stop at any point and have the most important part.
• Appendices for evidence, present because someone will eventually need it, not because it must be read.

Specific habits:

• A subject line that says the thing. "Critical: internet-facing payment gateway, actively exploited, needs action today" beats "Vulnerability scan results — week 38".
• One ask per message. Two requests reliably get one response.
• Numbers with meaning attached. "CVSS 9.8" means little to most readers; "allows anyone on the internet to run commands on this server without logging in" means everything.
• Plain words. Not because the reader is unintelligent, but because jargon makes them skim, and a skimming reader misses the ask.
• Short. Every additional paragraph reduces the probability the ask is read.

The test: if the reader only read the subject and the first sentence, would they do the right thing? If not, the message is arranged wrongly, however complete it is.

Saying what you do not know

The habit that determines whether anyone believes the rest of it, and the one this whole course has been building toward.

Analysts are under real pressure to be definitive. Executives ask closed questions — was data taken, are we safe now, how did they get in — often before the evidence exists. The temptation is to answer with the most likely thing, stated plainly, because uncertainty sounds like incompetence.

It is the wrong trade, for a reason beyond honesty: a confident answer that changes later costs you every subsequent answer. The organisation stops being able to use anything you say, precisely when it most needs to.

How to be useful without overstating:

• Separate observation from inference explicitly. "We observed 40GB transferred to an external host" is an observation. "Data was stolen" is an inference. Both belong in the report, labelled.
• Attach confidence, and say why. "Likely, based on the connection volume and the archive we found staged" tells the reader how much weight to put on it.
• Say what would settle it and how long that takes. "We can confirm what was in that archive from the file server logs; about four hours." This turns an unsatisfying answer into a plan, which is what the person asking actually wants.
• Distinguish "no evidence of X" from "X did not happen" — every time, and especially under pressure. They are different statements and only one of them is usually supportable.
• State the limits of your visibility. "Our logs for that system go back 14 days; the activity may predate that" is essential context, and omitting it turns a bounded search into an unbounded claim.
• Correct early and plainly when something changes. A correction issued immediately is a functioning process. One that emerges later is a credibility event.

This is the same discipline the technical domains have asked for throughout, applied to speech: a scan that could not authenticate is not a clean result, an untested rule is not a detection, a control nobody verified is not a control — and "we have not seen it" is not "it did not happen." Saying so out loud, to an executive who wants a cleaner answer, is the hardest and most valuable version of it.

Topics this lesson owns

• [x] Naming the owner of a finding
• [x] Escalation that is proportionate
• [x] Negotiating remediation timelines
• [x] Writing for someone who will never read the appendix
• [x] Saying what you do not know