The 14-Day Launch Exception
Northbridge Pay is a 430-employee payments processor serving 1,100 merchants. Its board-approved risk appetite says no new product may launch with an open critical vulnerability, but the security exceptions committee can approve time-bound exceptions with compensating controls. A product team wants to launch 'Instant Refund Links' in 14 days. The design accepts a URL parameter and fetches it server-side; a contractor found that internal metadata endpoints are reachable, and the fix requires re-architecting the fetch service, estimated at six weeks. The product VP has verbally told the team to ship, citing a signed customer contract with a 30-day termination clause. The exception register is empty this quarter, and the CISO is on leave. The security architect can add an egress-deny rule and a URL allowlist, but the allowlist would block two merchant domains until DNS changes are tested. Customer support says refunds are the top complaint.
1. Should the exception be approved, approved with conditions, or denied? Explain the decision path, who must decide, and what evidence you would require.
Read the worked answer
Decision: approve a time-bound exception with conditions, not a clean approval and not a blanket denial. Reasoning: the board appetite prohibits launch with an open critical vulnerability, but it explicitly permits the exceptions committee to accept residual risk with compensating controls. The egress-deny rule removes the metadata path; the allowlist reduces reachable destinations, but its partial merchant coverage creates a business gap. Conditions should include: egress deny enforced at the network layer and tested from the production subnet; allowlist owned by security with a 30-minute change window; per-request logging and alerting on non-allowlisted fetches; a named business acceptor, not the VP alone, plus committee sign-off; expiry at six weeks or at fix completion; daily review of blocked attempts. The VP's verbal instruction is not risk acceptance. Contract pressure is a business input, not a control. Require the product team to document the two blocked merchant domains and a manual refund fallback. If the committee cannot meet before launch, the default is delay, because silence is not acceptance.
2. The product VP says the customer contract makes delay unacceptable. How should security respond without becoming a blocker?
Read the worked answer
Security should convert the contract claim into a quantified business risk and options, not a yes-or-no veto. First, ask for the contract clause and launch commitments; a 30-day termination clause is not the same as a customer requiring launch in 14 days. Second, present three options: launch only to merchants whose domains are on the allowlist, with manual refunds for the rest; delay 14 days to finish egress controls and test DNS for the two blocked domains; or launch in a mode where server-side fetching is disabled. Third, state residual risk in business terms: likelihood of SSRF, potential access to cloud metadata credentials, blast radius, and detection coverage. Fourth, route the decision to the risk committee or accountable executive with security's recommendation. This preserves security's role as adviser, not blocker, and creates a record. If the VP still overrides, document the override, the acceptor, and the expiry; do not silently absorb the risk.
3. What metrics and review cadence would show whether the compensating controls work?
Read the worked answer
Track leading and lagging indicators. Leading: percentage of production egress paths covered by deny rules, allowlist test pass rate, number of non-allowlisted fetch attempts, time to update the allowlist, and percentage of refund requests handled manually. Lagging: confirmed SSRF attempts, credential exposure near-misses, and open critical findings. Also track exception age against the six-week expiry and days active without committee review. Review weekly with the product owner, security operations, and the risk owner; require closure evidence, such as the architecture change, a penetration test, and an egress-rule regression test, before expiry. If any non-allowlisted fetch succeeds, or if blocked merchant volume exceeds an agreed threshold, trigger escalation. Report monthly to the exceptions committee and quarterly to the board risk committee, because a single exception is also a signal about the health of the exception process.