Stakeholder Management and Cross-Functional Alignment Questions

Direct answer

Turn "security versus product" into a decision between concrete options with a named risk owner, then record and announce it. Ask security to state the risk concretely (what data, exposed to whom, how easily, how bad), ask engineering what each fix costs, and put three options on one page: ship on the date as-is, ship on the date with a reduced scope or a temporary compensating control (a lesser safeguard that reduces risk until the full fix), or delay for the full control. If the exposure is high (other customers' personal data readable), the fix is a gate and not negotiable; if lower, product can accept risk formally, in writing, with an expiry date.

Steps

1. Make the risk specific. "Data exposure" is vague. Get: which fields, who could see them, what it takes to exploit, and how many people are affected.
2. Ask security for the minimum acceptable control, not the ideal one. This turns a veto into a spec.
3. Get costs from engineering for each option, in days.
4. Decide who decides. The business owner of the risk accepts it, with security's written recommendation attached. Security advises; it does not silently own the ship date, and product cannot waive a high-severity issue alone.
5. Record the decision (risk acceptance with an owner and expiry) and follow up when the expiry hits.

Communication

Tell product, engineering, security, and (if customer data or contracts are involved) legal or privacy the same message: what ships when, which control is included, what is deferred and until when, and who signed off. Customer-facing teams get only what they may say.

Worked example (illustrative)

Feature: "export contacts to a file." Security finds the export endpoint accepts any contact ID without checking which customer account owns it, so one customer could read another's contacts.

Recommendation: B, gated on security's retest passing before release. A retest means security re-runs the same failing request against the fixed build (asking for another customer's contact ID) and records the result on the ticket: pass means the server now answers "denied", and release stays blocked until that pass is written down. If the check takes longer than the slack in the schedule, ship the rest of the feature and hold only the export behind a feature flag (an on/off switch in code) until the fix lands.

What a written risk acceptance looks like (illustrative)

Suppose the full audit report for exports is deferred while the ownership check ships:

Risk acceptance (example)
Risk: export activity is logged but has no dashboard or alerting yet
Severity: low (a customer can only export their own contacts)
Compensating control: security reviews the export logs weekly
Accepted by: Director of Product (business owner of the risk)
Security recommendation: attached, dated, "acceptable for 90 days"
Expires: 90 days after approval; close it or re-approve it then

Trade-offs and pitfalls

• Treating security as a vote instead of a control function leads to shipping known holes.
• Verbal risk acceptance disappears; a written one with an expiry does not.
• Do not make product argue security's case or the reverse. The facilitator's job is to present options neutrally.
• What flips the call: severity. If the data is regulated or customers' data crosses accounts, shipping as-is (option A) is off the table and the fix becomes a hard gate: option B is acceptable only because it includes the ownership check and passes retest before release, and if the fix cannot be verified in time, the affected feature (here the export) slips or stays behind its flag. Delay of that feature wins over shipping the exposure; a delay of the whole launch is needed only when the fix cannot be isolated behind a flag.