The Legacy TLS Exception the VP Wants Signed by Friday
Northwind Retail's PCI assessment closes in 45 days. The e-commerce team runs a legacy order-status API on TLS 1.0 with RSA-1024 certificates; 11 downstream partners still connect to it. The vendor upgrade is quoted at 6 months and $180k. The API handles no cardholder data directly, but it queries an order database that stores last-four digits and shipping addresses. The QSA logged it as an observation rather than a failure because the service sits outside the CDE, though it is reachable from CDE-adjacent networks. The VP of Digital wants a 12-month risk exception signed by the CISO so the assessment can close on time. The risk register currently rates the entry Likelihood 4 / Impact 3 on a 5x5 matrix, with no compensating controls documented.
1. Should the CISO sign a 12-month exception as requested? State what must be true before any signature, and who actually owns the risk.
Read the worked answer
The CISO should not be the signatory in the way the VP is asking. The VP of Digital owns the business process that depends on the API; risk acceptance belongs to the business owner, with the CISO in an oversight/advisory capacity and a documented record if security disagrees. A CISO signature alone converts a business decision into a security decision and leaves no accountable owner when it fails.
Before any signature, four things must be true:
- The scope claim is verified, not asserted. Someone must trace actual network paths and credentials from the CDE to this API. 'Outside the CDE' is a segmentation argument, not a fact. If the API reaches the order database with a shared service account that also serves CDE systems, the exception covers far more than the VP believes.
- Compensating controls are enumerated with owners and test evidence, not narrative. A prose paragraph saying 'monitoring is in place' is not a control.
- The duration is justified by the remediation plan. The vendor quote is 6 months, so 12 months has no basis. Grant 90 days with milestone evidence and a hard review date.
- Residual risk is re-scored honestly. If allowlisting and monitoring genuinely reduce likelihood from 4 to 2, say so and show why. If not, leave it at 4 and let the committee see the real number.
The QSA observation is also conditional: it holds only while scope stays fixed. Add a trigger that reopens the exception if a new integration or data flow appears.
2. Name the compensating controls you would require, and describe how each would be tested rather than merely documented.
Read the worked answer
The controls should be chosen for what they actually change, and each needs a test that could fail.
- Terminate the legacy protocol at a single hop. Put an API gateway or reverse proxy in front that accepts TLS 1.0 only from the 11 allowlisted partner source addresses and re-originates TLS 1.2+ with modern ciphers internally. This constrains the weak protocol to one network segment instead of letting it reach the database tier. Test by connecting from a non-allowlisted address and confirming a drop, and by capturing the internal hop to confirm the cipher suite.
- Per-partner authentication with creditable tokens. One shared credential means the exception covers 11 parties with the same blast radius. Test by replaying an expired token and confirming rejection.
- Least-privilege database access. Replace any shared account with a read-only identity limited to the specific views the API needs. Test by attempting a write and a schema read.
- Volume and pattern alerting per partner. Baseline request rate, alert on deviation. Test with a synthetic burst.
- Logging retained longer than the exception period. If you cannot reconstruct what happened six months ago, the control did not exist.
State explicitly which controls reduce likelihood (access restriction, authentication) and which only reduce impact or detection time (logging, alerting). Do not let detection controls be counted as prevention when re-scoring.
3. On day 40, a partner reports that its IP block has been reassigned to a shared hosting provider covering roughly 4,000 addresses. What do you do, and what does this reveal about the exception as written?
Read the worked answer
The allowlist has silently degraded from 11 known networks to one network covering thousands of unrelated tenants. That is the control failing, not an inconvenience.
Immediate actions:
- Suspend the exception or escalate it for re-approval today. The residual risk score assumed 11 named parties; it no longer describes reality.
- Require the partner to provide static egress addresses or, better, mutual TLS with a client certificate they control. IP allowlisting is a property of their infrastructure, which you do not control.
- Check the logs for the exposure window: who connected from that range, what order records were returned, and at what volume.
What it reveals: the exception treated compensating controls as permanent facts rather than as conditions that decay. Every control in an exception needs a monitoring mechanism that detects when its assumptions break. Here the assumption was 'this IP range belongs to one partner,' and nothing was watching for a change of ownership.
Add to the exception template a named monitoring owner and a review trigger per control. An exception that cannot detect its own control's failure is a false assurance that will be cited back to you in the post-incident review.