Communicating Security and Privacy Risk to Stakeholders and Leadership Questions

Direct answer

I would not argue "security versus the freeze". I would show the CTO that the freeze and the patch protect the same thing: a stable production system. A release freeze (a period when only approved changes ship) exists to avoid unplanned outages. An exploited critical flaw is an unplanned outage with a data-breach bill attached. So I ask for a narrow emergency change, not an end to the freeze. If the patch truly cannot ship, I get a time-boxed, signed risk acceptance (a one-page written record, signed by the executive who owns the risk (here the CTO, with the CEO or executive risk owner co-signing when the flaw is internet-facing and known to be exploited), naming the flaw being tolerated, what could go wrong, the safeguards in place and the date it expires; signing makes them answerable for the outcome) plus compensating controls (interim safeguards that reduce the risk while the real fix waits).

Step 1: turn "critical" into likelihood

Publicly tracked flaws get a CVE identifier (Common Vulnerabilities and Exposures, the public ID for a flaw). Its CVSS score (Common Vulnerability Scoring System) rates severity, not the chance it hits us. I add three facts the CTO can weigh:

• Is it on CISA's KEV catalog (Known Exploited Vulnerabilities, a list of flaws confirmed exploited in the wild)?
• What is its EPSS (Exploit Prediction Scoring System) value? FIRST defines it as the probability a published CVE will be exploited in the wild in the next 30 days.
• Is the vulnerable component internet-facing in our environment?

Reading the numbers: an EPSS of 0.92 means about a 92% chance of exploitation in the wild within 30 days, so I treat it as urgent; 0.01 means about 1%, which supports waiting for a scheduled deploy. A CVSS 9.8 with EPSS 0.01 and no KEV listing is a different conversation from a CVSS 9.8 with EPSS 0.92 that is on KEV.

Step 2: what I say to the CTO (about 30 seconds)

"The patch touches one service, the payments API, was tested in staging on Tuesday, and has a one-click rollback. The flaw is internet-facing and is on CISA's KEV list, which means attackers are already using it. Waiting turns a short planned deploy into an unplanned incident during your freeze. I am asking for a single exception, with a rollback plan and a deploy window you choose."

Step 3: if it cannot go out

1. Record the decision. The CTO owns the business risk because the CTO controls the system, the budget and the freeze trade-off and answers for outages; security measures the risk and advises but does not own the product. Write a risk acceptance naming the flaw, the exposure, the compensating controls, an owner, and an expiry date no later than the end of the freeze.
2. Reduce exposure now. Apply a virtual patch (a rule in a web application firewall, or WAF, the filter in front of an application, that blocks the known exploit pattern), turn off the vulnerable feature with a feature flag (a configuration switch that disables a feature without a new release), or restrict network access to the affected service.
3. Detect. Add an alert for exploit indicators and review it daily during the exception.
4. Pre-stage. Keep the patch built and tested so it ships the hour the freeze lifts.
5. Pre-agree overrides. If the flaw is not yet on KEV and is later added, or exploitation is observed here, the exception ends and the emergency change proceeds automatically. In the scripted case above the flaw is already on KEV and internet-facing, so under my own rule it ships first; a risk acceptance there is a last resort that the CTO chooses against my recommendation, and I ask for the CEO or the executive risk owner to co-sign it before I treat it as accepted.

Product-manager framing (paragraph and one rule)

Paragraph: "Every feature we ship this sprint depends on customers trusting us with their data. This fix takes one engineer for a day. A breach would freeze the whole roadmap for weeks." Rule: anything critical that is internet-facing or known to be exploited ships first; everything else is ranked by customer value divided by effort.

Pitfalls

Do not threaten ("you will be blamed"). Do not demand the full patch cycle. Do not accept a WAF rule without testing that it blocks the exploit.

Direct answer. Use STAR (Situation, Task, Action, Result) and put most of the time on Action: how you changed the message for this audience. Sample shape below, to be replaced with your own story.

Situation. A routine review found that a storage bucket holding customer exports had been publicly readable for about two weeks. No evidence of access yet, but our logs only covered part of the period.

Task. Brief the CEO and General Counsel the same afternoon. They needed to decide whether to notify customers and whether to delay a partner launch that week.

Actions

• Led with the decision and the facts we knew. First line: "We found a data exposure. We have closed it. We do not yet know if anyone took data. I need two decisions from you today."
• Separated known, unknown and next check. Known: exposed for 14 days, now closed. Unknown: whether it was accessed. Next: log review done by 9am tomorrow.
• Kept jargon out and gave options. Wait for the log review before notifying, or prepare the notice now to send quickly if needed. I recommended preparing now. Legal would decide whether notification was legally required; I did not make that call.
• Stayed calm under pressure. I did not speculate, and I committed to a time for the next update.

Result. Leadership approved preparing the notice and holding the partner launch by one day. The log review found no sign of access in the part of the period the logs covered. Because that left a gap, I reported it as 'no evidence of access, not proof of none', and Legal decided that a notice was not required; so none went out, and the review of storage settings became a standing monthly check. A measurable outcome to cite is the decision time (same day) and the control added.

What I learned. Bad news lands better when it arrives with a recommendation and a time for the next update. The mistake to avoid is burying the headline in background.

Direct answer
Rank by risk reduced per unit of engineering effort, with an override for anything both severe and exposed. Deliver in stages: quick wins that cut exposure within the sprint, then permanent fixes scheduled into the roadmap. Present it to product leadership as a one-page choice between security, cost and time, with a recommendation.

Prioritisation rules

1. Override: severity 5 and exposure 5 (reachable from the internet) is fixed first, regardless of effort.
2. Otherwise: score = severity x exposure (each 1 to 5), divided by effort in engineer-weeks. Higher goes first.
3. Active exploitation moves an item up one position.
4. Dependency: a fix that unblocks others goes ahead of equal scores.

Scales, so a finding can be scored consistently. Severity: 5 = attacker gains full control or sensitive data for all customers; 4 = major impact on one product or a large customer group; 3 = limited data or a workaround exists; 2 = minor; 1 = negligible. Exposure: 5 = reachable from the internet with no login; 4 = internet-reachable behind a login; 3 = reachable from the internal network; 2 = reachable only by a small group of admins or service accounts; 1 = needs physical access.

Worked example (illustrative)

Order: A first by the override, then C, D, B. Capacity of 3 engineer-weeks per sprint: A and C (2 + 1 = 3) fit in sprint one.

Staging: quick wins vs permanent fixes

• Quick wins (sprint 1): A (put the panel behind sign-in with MFA) and C (rate limit). Both cut exposure fast.
• Permanent fixes: D (upgrade, 5 weeks) and B (move secrets to a vault, 8 weeks) scheduled over the next quarters. Until B is done, a compensating control (a stopgap that lowers risk while the permanent fix waits): restrict network access and rotate the credentials.

One-page brief
Headings: the ask, what we recommend, three options (all four now, quick wins plus scheduled fixes, quick wins only) each with cost, time and remaining risk, and a decision date. At an assumed $4,000 per engineer-week and 3 engineer-weeks of capacity per sprint, the options read:

Recommendation wording: "We recommend option 2: it removes the two internet-facing risks this sprint for $12,000 and schedules the rest. We need your decision by the planning date." State the tradeoff plainly: quick wins plus scheduled fixes leaves B open for months at lower exposure, which is accepted by a named owner with an expiry.

Direct answer

SQL injection (an attack where a hacker types database commands into a form or web address and the application runs them) lets an outsider read or change data the website holds. In business terms it is a way to walk out with the customer list through the front door of the website.

Analogy for the room

Imagine a clerk who reads out whatever instruction is written on a customer's order slip. A bad actor writes "also hand me every customer file". The clerk never checks. The flaw is the missing check.

What it enables (1)

An attacker with no account could read customer records, alter or delete data, and in some setups take over the server.

Business impact (2)

• Customers: personal or payment data exposed.
• Revenue: shutdown of ordering, plus lost trust.
• Reputation: public disclosure.
• Regulatory exposure: a breach of personal data can trigger legal notification duties. Counsel decides which apply.

Mitigation and timeline (3), illustrative

Immediately: add a protective filter in front of the app (a web application firewall, a gatekeeper that blocks requests that look like attacks; it is a stopgap, not a fix) and review the logs (the website's record of past requests) for signs someone already tried this. Within about a week: change the code so typed text can never be run as a command (parameterized queries: the program sends the database its fixed instruction first, such as "find the order for this customer name", and the customer's typed text separately, so text like "also hand me every file" is treated as an odd name that matches nothing), then retest. Ongoing: scan all code for the same pattern.

Executive summary, exact wording

"We found a flaw in [application] that would let an outsider read or change customer information without logging in. We have no evidence it has been used and are checking our records to confirm by [time]. If exploited, it could expose customer data, interrupt sales and create legal reporting obligations. Today we are adding a temporary protective block, and engineering will deliver the permanent fix and retest within about a week. We need your approval to prioritize this fix over planned work."

Email subject line

"Decision needed today: customer-data flaw in [application], fix plan attached."

Pitfalls

Do not use the word 'injection' without the clerk analogy. Do not state that no data was taken until the log review says so.

Direct answer

Residual risk is the risk left after your safeguards are in place. Inherent risk is the risk before any safeguards. An executive decides whether to accept the residual by comparing it with how much risk the company has said it will live with (its risk appetite), and by checking that the benefit of going ahead (for example, the revenue from keeping the application open for orders) is larger than the remaining loss. Acceptance is signed by the person who owns the business outcome, not by security.

One-paragraph version

"Residual risk is what could still go wrong after we have done what we can afford to do. For our customer web application, a break-in could cost about $450,000 a year in expected losses (the chance of it happening in a year multiplied by what it would cost if it did). With multi-factor sign-in and a web firewall we cut that by 70%, to about $135,000. The decision is whether we are comfortable carrying $135,000 a year, or want to pay to reduce it further."

Worked example (illustrative numbers)

• Inherent: 30% yearly chance times $1,500,000 cost = $450,000 expected yearly loss.
• Control reduces the chance by 70%. Residual: 30% times 30% remaining = 9%, and 9% times $1,500,000 = $135,000.
• Expected yearly loss is the average yearly cost to plan for: chance per year times cost per event.
• Business consequences if it happens: customer data exposed, ordering down for days, legal notifications.
• Appetite check: if leadership's stated limit for this application is $150,000 a year, $135,000 is inside it and can be accepted. If the limit were $100,000, it would need more treatment or an explicit exception.
• Benefit check: if keeping the application live is worth $2,000,000 a year in orders, carrying $135,000 of expected yearly loss is a trade the executive can reasonably make. If it were worth only $100,000, the same $135,000 would not be.

Documentation I would obtain

1. A risk acceptance record: description, inherent and residual scores, controls, assumptions.
2. Signature of the accountable business executive: the person whose budget or revenue absorbs the loss, for example the head of the business unit.
3. Review date, because assumptions age.
4. Conditions that would reopen it, such as a new exploit or a system change.

Counsel advises on legal duties and does not sign the acceptance. For exposures above the threshold the board has set, the board is informed.

Pitfalls

Do not call residual risk zero. Do not let the acceptance be signed by the person who built the system.