Communicating Security and Privacy Risk to Stakeholders and Leadership Questions

Direct answer. One incident, two messages, framed around what each person must decide. The product manager (PM) needs scope, fix effort and launch impact. The legal/compliance lead needs facts that start legal clocks, such as what data and whose, and when we became aware. Engineers prepare the facts; counsel decides what the law requires.

One paragraph. "We found a flaw that lets someone read other customers' records. For the PM: it affects the account page, a fix is about two engineer-days, and I need a decision today on whether to pause Friday's release; the number to weigh is the delay, which is two days if we fix first. For legal/compliance: it exposed names and email addresses of an estimated 4,200 customers (1,100 confirmed in the logs so far), we became aware at 09:40 on Wednesday 14 October, we have no evidence of misuse yet, and the date to weigh is Saturday 17 October at 09:40, 72 hours after we became aware." (Figures are illustrative.)

(a) Product manager: top three points

1. What customers see and which feature is affected.
2. Fix effort and the options (patch now, disable the feature, ship with a limit).
3. Launch impact and the decision needed today.
   Metric they care about most: days of delay to the release.

(b) Legal/compliance lead: top three points

1. What personal data, whose, and how many records (confirmed versus estimated).
2. Evidence of access: logs checked, results, and what we do not yet know.
3. The timeline: when we became aware, what we have contained, what we will confirm next.
   Concern they care about most: the notification deadline, the legal clock that starts when the company becomes aware of the problem. For example, under GDPR (the EU General Data Protection Regulation, the EU privacy law) Article 33, the controller (the organization that decides why and how personal data is used, here our company) must notify the supervisory authority (the government data-protection regulator) without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to put people at risk. The clock starts at awareness, not at the original flaw, and it runs through weekends: 09:40 on Wednesday 14 October plus 72 hours is 09:40 on Saturday 17 October. So I record the awareness time at once. Whether this event is a reportable breach (one the law requires us to report to the regulator or to customers) is counsel's call.

Pitfall. Telling legal "it is probably nothing" before the logs are reviewed, or telling the PM about legal exposure in terms they cannot act on.

Direct answer

I would not say no and I would not say yes. I would propose a way to ship on the date with a smaller exposed surface and temporary protections, and ask product leadership to sign for the remaining risk with a date to close it. The plan is a negotiation about risk ownership, not a veto.

Plan the conversation

1. Prepare: write the risk in one sentence they care about, such as "a logged-in customer could read another customer's order history by changing the number in the web address". Gather facts: what is exposed, to whom, what protects it.
2. Meet: open with the shared goal (the date), then show options.
3. Close: end with the specific decision and who owns it.

The words I would use

• Opening: "I want this to ship on the 15th, and I think we can do that. Here is the one risk I would like us to decide on together: as built, a logged-in customer could read another customer's order history by changing the number in the web address."
• Option pitch: "Option A: ship on the 15th to 5% of customers behind a feature flag, with rate limits and an alert my team owns. Option B: ship to everyone on the 15th as built, which means you accept the exposure. Option C: slip two weeks and fix it properly. I recommend A: you keep the date, and the exposure shrinks to a small group we can switch off in minutes."
• Sign-off request: "Can you confirm in writing that you accept the remaining exposure until 14 November, that the feature is switched off if the alert fires, and that Dana owns closing the gaps by then?"

What I would propose

• Reduce the surface: the attack surface is everything an attacker could reach or try. Shrink it by launching behind a feature flag (a switch that turns the feature on for chosen users and can turn it off without a new release) to a small group, or by leaving out the riskiest function.
• Temporary mitigations: rate limits (a cap on how many requests one user or address can make, which slows bulk data theft), a web firewall rule (a gatekeeper in front of the application that blocks requests matching known attack patterns), tight permissions, and extra monitoring with an alert owner.
• Required testing before go-live: a focused security review and retest of the top findings. Anything unfinished is listed.
• Rollback window: the fallback if the launch goes badly. For a fixed number of days we can disable the feature without a new release, and a named person has the authority to pull it. This is separate from the mitigations above: they lower the chance of harm, the rollback window limits how long any harm can continue.

What I ask them to sign off on

A short risk acceptance: the remaining exposure in plain words, the mitigations in place, the testing not completed, an expiry (for example 30 days) and an owner who will close the gaps, plus the rollback trigger. The sign-off belongs to the business leader who owns the feature, with legal consulted if personal data is involved.

What would change my call

If the feature exposes regulated data with no authentication, or the flaw could be abused at scale, I would escalate to the executive who owns the risk and recommend a delay, since temporary mitigations would not bring the risk inside appetite (the amount of risk the company has said it is willing to carry).

Pitfalls

Do not present only problems. Do not accept an acceptance with no expiry, because temporary exceptions turn permanent.

Direct answer
Do not say "no". Say "yes, with conditions": acknowledge the client's business reason, make the risk concrete, offer a safer way to meet the same need, and agree a dated plan. Speak to the client in terms of business impact and to the compliance team in terms of control gaps and evidence.

To the client

• Restate their need (for example, 4,000 employees depend on this system for sign-in).
• State the risk plainly: it lacks modern controls such as multi-factor authentication or current patching, so one stolen password could expose customer data.
• Present two or three options with trade-offs: integrate as asked; integrate behind protections; or migrate first. Recommend the middle option.
• Words I would say: "We can connect it. The catch is that it cannot enforce multi-factor sign-in today, so one stolen password could expose customer records. I suggest we connect it behind a gateway that adds that check, keep it isolated, and agree together a plan to retire it within 270 days, so your 4,000 employees keep working throughout."

To compliance

• Identify which requirements the system fails and the compensating controls (alternative safeguards that reduce the same risk when the standard control cannot be applied).
• Record a formal risk acceptance (a signed decision by a named executive to knowingly live with a stated risk for a stated time): who accepts, what exactly, and an expiry date.
• Define the evidence you will provide: logs, test results, review dates.
• Words I would say: "This system fails the requirement for multi-factor authentication on remote access. We propose gateway MFA, extra logging on the legacy accounts and restricted admin access as compensating controls, signed off by the executive sponsor as a risk acceptance that expires on day 270. Evidence: monthly access logs, the day-90 MFA test report, and migration progress at each review date. Please tell us if any of these does not satisfy the requirement."

Mitigations

• Isolation: place the legacy system in its own network segment, reachable only through one authentication gateway.
• Compensating controls: MFA applied at the gateway, extra logging and alerting on the legacy accounts, restricted admin access.
• Phased migration: move users to a modern identity provider in stages, with the legacy system kept as a fallback until the last phase.

Acceptance criteria and timeline

• Day 30: isolation in place; the legacy host reachable from one gateway address only. From day 30 all users reach it only through the gateway, with the extra logging and restricted admin access already on. MFA is enforced first for a named pilot group to test it, and for everyone at day 90. Days 30 to 90 are the exposure window, covered by the signed risk acceptance.
• Day 90: all logins pass through MFA at the gateway; alerts tested.
• Day 180: majority of users migrated; legacy used by exceptions only.
• Day 270: legacy decommissioned or the risk acceptance renewed by an executive sponsor.
  Each milestone has a pass test, an owner and a review date, and missing one triggers an escalation to the sponsor.

What would change the call
If the system cannot be isolated, or handles regulated data that the rule forbids on unsupported software, recommend not integrating until the migration is done. Legal or the auditor decides whether a compensating control satisfies a specific requirement.

Direct answer
A one-page briefing with five sections: what changed, impacts, options with costs and time, a recommendation, and decisions needed. A one-line recommendation sits at the top of the page, and the sections that follow show the alternatives so leadership can see the choice was weighed. Legal or compliance owns the reading of the rule. The architect owns translating it into design impact.

1. What changed
Two sentences: the new requirement, its effective date, and which of our systems and data it touches. Mark clearly what is confirmed by Legal and what is still interpretation.

2. Impacts

• Technical: affected components, data flows, new controls or evidence needed.
• Business: launch timing, customers or regions affected, penalties or lost-market risk for non-compliance.

3. Options (illustrative figures)
Assume the requirement takes effect in 20 weeks.

Twelve-month total is upfront cost plus 12 months of running cost. Slack before the deadline: A 14 weeks, B 10 weeks, C 4 weeks.

4. Recommendation
Option B. It has the lowest 12-month total, fits the deadline with 10 weeks of slack, and fixes the cause so the next rule change costs less. A is cheapest to start but costs the most per month because evidence stays manual. C leaves only 4 weeks of slack, which any slip would consume.

5. Decisions needed
Approve $300k and a team for 10 weeks; confirm scope with Legal within 2 weeks; accept a stated interim risk until week 10.

What would change the call
If Legal narrows the scope to one system, A becomes the best choice. If the deadline moves to 8 weeks, only A fits.

Direct answer

I would not present hardening as "security versus performance". I would put both on the same basis, expected annual dollar value per engineering cost, and show hardening wins by a margin that survives halving my own risk estimates. Then I would propose a sequence the board can accept: the hardening items that beat the sprint even at halved estimates go first, then the sprint.

Step 1: evidence to gather

• Open critical and high findings, with whether each is internet-facing.
• Which are on the KEV catalog (CISA's list of vulnerabilities known to be exploited in the wild).
• Customer contract or audit commitments that depend on the fixes.
• Performance side: the revenue effect the sprint expects, from analytics, not from belief.

Step 2: quantify hardening (illustrative inputs)

Annual expected loss (ALE = annual probability x loss if it happens), and how much a fix removes:

Total reduction $482,000 (270,000 + 112,000 + 100,000) for 24 engineer-weeks (8 + 6 + 10). At an assumed $4,000 per engineer-week, cost is $96,000. Ratio = 482,000 / 96,000 = about 5.0 dollars of expected loss avoided per dollar of engineering cost per year. Here the loss avoided is a cost the company no longer risks, which is already a profit-side number.

Step 3: the performance sprint on the same basis

20 engineer-weeks = $80,000. Expected gain: the sprint is expected (an assumed input to be taken from the team's analytics) to lift recurring revenue by 1%: 1% x $20M = $200,000 revenue. Revenue is not profit, so I keep only the gross margin (the share of each revenue dollar left after the direct cost of delivering the product), assumed 75%: $200,000 x 0.75 = $150,000. Ratio = 150,000 / 80,000 = 1.875, about 1.9. Converting revenue to margin is what puts the sprint on the same footing as the ALE figures above. Both ratios are annual dollars per dollar of engineering cost.

Step 4: make it defensible

• Sensitivity (testing how much the answer moves when an input changes): halve every probability, reduction is $241,000, ratio 241,000 / 96,000 = about 2.5, still above 1.9.
• Break-even (the input value at which the two options tie): hardening only ties the sprint when its ratio falls to 1.875, which needs 1.875 x $96,000 = $180,000 of reduction. That is 180,000 / 482,000 = about 37% of my estimates, so hardening only loses if my probabilities are below about 37% of what I assumed.
• Per week, the auth bypass returns $33,750, admin access $18,667, tenant tests $10,000, so I order them that way.
• Have someone outside the security team (finance or an engineering lead) challenge the inputs.

Recommendation to the board

Per item, at full estimates, authentication is 270,000 / 32,000 = 8.4 per dollar, admin access 112,000 / 24,000 = 4.7 and tenant tests 100,000 / 40,000 = 2.5; at halved probabilities they are 4.2, 2.3 and 1.25, against the sprint's 1.9. So: do the 8-week authentication fix and the 6-week admin access fix first (14 engineer-weeks), run the sprint after, and review tenant isolation tests at the next planning cycle, because it is the only item that falls below the sprint when my estimates are halved. If the board chooses otherwise, that is a recorded risk acceptance with an owner and review date.

Pitfalls

Comparing a probabilistic loss with a certain revenue gain as if they share a basis, and presenting illustrative probabilities as facts.