The Exception That Outlives Its Deadline

Security does not own this decision, but it should own the framing. Risk acceptance belongs to the accountable business executive - here the CFO or the sponsor of the acquired entity - because the loss lands on the business, not on security. My job is to make the residual risk explicit and to refuse to record an acceptance above the approver's authority.

The exception record must contain: the asset and data flow (payment files, bank details, roughly €2.1M per quarter), the control gap and its root cause (vendor product limitation plus a shared, unrotated credential), the realistic threat and impact (business email compromise and payment redirection leading to direct fraud loss, plus contractual and regulatory exposure), the compensating controls with named owners, the residual rating after those controls, a hard expiry of 90 days rather than 12 months, a re-review trigger, and the signature of an approver whose authority matches the residual rating.

The appetite statement is the test. A design that permits silent redirection of supplier payments with no independent verification plausibly exceeds a $500,000 annual loss tolerance, and 'the vendor says Q3' is not a control. I would decline to renew as-is, offer a 90-day conditional exception built around payment callbacks and source-IP allowlisting, and put the residual in front of the CIO as a recommendation, not a veto.

Controls that move the needle:

• Outbound payment verification independent of the file channel: callbacks to a number on file for any new or changed bank account. This defeats the actual fraud, not the protocol version.
• Network segmentation: SFTP host in a DMZ, allowlisted vendor source IPs, no route to the corporate VLAN, no domain membership.
• Replace the shared account with per-user keys, or at minimum a vaulted credential rotated before every transfer, with session logging and file-integrity hashes.
• File-level encryption of the payment payload with a key exchanged out of band, so TLS stops being the whole story.
• Alerting on transfer volume, off-schedule transfers, and ACL or policy changes on the host.

Looks reassuring but is not:

• 'The vendor is contractually required to be secure.' Unverifiable at time of loss, and a contract does not stop a fraudulent payment instruction.
• Antivirus on the SFTP host, or annual awareness training. Neither addresses credential misuse or payment redirection.

A policy paragraph prohibiting TLS 1.0 while an exception lives beneath it is a third form of theatre. Note also that PCI DSS forbids TLS 1.0 for cardholder traffic; if any card data crosses this link, the exception is not grantable regardless of appetite.

Escalate when residual risk after compensating controls still exceeds the board's stated appetite; when the exception depends on a control that nobody will own; when the same gap has been renewed twice with no remediation progress; or when a regulator or contract (PCI DSS, a bank's supplier terms) makes the practice non-compliant rather than merely risky. Those are not judgments a CIO should absorb alone - they belong to the risk or audit committee, with security's assessment attached.

An initial approval asks 'is this risk acceptable to take on?' A renewal asks two different questions: did the promised remediation actually happen, and is the reason for the exception still true? That distinction matters. Renewal should require evidence - a vendor ticket, a test result, a dated commitment - and the absence of progress is itself a finding. I would also shorten the term each cycle rather than reissuing the same 12 months, and require the business to present a funded plan.

If the honest answer is that the vendor will never support TLS 1.2, the decision changes from 'wait' to 'replace the integration'. That is a capital decision with a budget and a project date, and the board should see it framed that way rather than as an annual security argument.