Signing a Vendor Renewal Above Risk Appetite

You do not have the authority to accept this on the security team's behalf, and 'sign it and we will fix it later' is still an acceptance decision.

Frame the treatment options explicitly:

• Avoid - exit or replace: ruled out by the nine-month RFP, and an unplanned exit creates availability and data-portability risk of its own.
• Reduce - compensating controls plus a contractual remediation obligation: feasible inside 14 days.
• Transfer - cyber insurance and contractual liability: partial. The $250k cap sits far below any plausible loss, and insurers exclude known, documented gaps.
• Accept - legitimate only if residual risk is inside appetite. It is not: the appetite statement bars unmitigated high residual risk on customer PII, and this is high.

Recommendation: conditional renewal. Time-bound, with compensating controls documented, a dated remediation obligation (evidence of DR-region encryption within 60 days), and a 90-day re-review. That is a reduced risk accepted with conditions, which is a different decision from accepting the gap unchanged.

Decision owner: the business owner proposes, but acceptance above appetite belongs to the CRO, recorded in the risk register and minuted at the risk committee. Security advises, evidences and documents; security does not sign off residual risk it did not create and cannot remediate. The 14-day deadline is a commercial fact, not a reason to compress governance - a conditional renewal can be executed on time with the exception running in parallel.

The ALE is a placeholder wearing the costume of a number. A single scenario of 30% × $6M hides every assumption that matters:

• The likelihood is unanchored. Is 30% the chance of any breach, or the chance of the specific DR-bucket misconfiguration being exploited? Those need different controls and produce different numbers.
• The impact is a point estimate on a distribution. Notification, credit monitoring, legal defence, regulatory action, card-brand penalties and churn have very different tails. Verbal card data inside recordings widens the notification population and the card-brand exposure.
• It ignores the actual finding. The gap is encryption at rest in one region. The model should ask what must go wrong for that bucket to be exposed, what fraction of the 1.4 million records sits in that region, and what control interrupts the path. If 4% of records are there, the expected loss moves by an order of magnitude.
• It ignores concentration. No alternative vendor for nine months means any availability event is simultaneously a business-interruption event, which the model omits.

What to present: a loss-exceedance view - P10/P50/P90 for two scenarios (targeted exposure of the DR bucket; broad compromise of the SaaS tenant), each tied to the control that would change the estimate, plus the missing data and what you would pay to obtain it. State plainly which figures are evidence and which are assumption.

The committee is deciding whether to accept a distribution and its tail, not a scalar. Give them the tail, the conditions, and the trigger points at which you would revise the estimate.

Compensating controls are only real if someone verifies them.

• Evidence, not assertion: configuration export or vendor attestation for the DR region, re-verified quarterly, backed by a right to audit or to receive an independent report.
• Data minimisation: suppress or redact spoken card data at source - pause recording during payment capture, or mask on ingest. This removes the highest-value data rather than protecting it.
• Access control: SSO with MFA for every vendor administrative account, IP allowlisting for support sessions, no shared credentials, session logs exported to the bank.
• Detection you own: alert on anomalous bulk export from the tenant using the vendor's audit API, so you are not entirely dependent on their monitoring.

Contract changes: raise or carve out the liability cap for confidentiality breach; a security addendum naming the controls; breach notification within 72 hours or sooner where the bank's regulators demand it; deletion and certification on exit; subprocessor disclosure and change notice; a 30-day cure period; and a termination right for material remediation failure. A cap of $250k against a plausible multi-million loss is a commercial position, not a risk transfer, and the committee should see it stated that way.

Re-review triggers: the 60-day encryption deadline missed; any change of subprocessor or hosting region; any vendor incident touching the tenant; a repeat exception in the next SOC 2 report; and the next renewal date. Record each as a condition in the risk register with an owner and an expiry - an exception with no expiry has quietly become an acceptance.