The Vendor Exception Nobody Wants to Sign

Do not frame it as security approving. Security does not own the claims process, does not bear the loss if the credential is abused, and cannot accept risk on the business's behalf. The recommendation should be: an exception is permissible, but approval is a business decision taken with security advice, recorded in the risk register, and time-bound.

Reasoning to put in the paper:

1. Separate the control objective from the control text. AC-04 exists to give individual accountability for file transfers, keep the credential confidential, and limit blast radius if it leaks. A shared static password in a config file fails all three. The exception must be assessed against those objectives, not against the wording of the clause.
2. State the actual exposure in business terms. Two servers hold a plaintext credential to a channel that moves claims data; anyone with read access to either server, or to the repo or image that carries the config, has standing access. The exposure quantity is not '4,000 claims/day' - that is the cost of interruption, not of compromise.
3. Put the treatment options side by side. Mitigate now with compensating controls; avoid by moving to the vendor's newer API or a managed file transfer service; transfer part of the risk via contract (breach notification obligation, security schedule, right to audit, indemnity); accept only for a defined window.
4. Name the accountable owner. The exception request should be signed by the business owner of the claims process (e.g. VP Claims Operations), endorsed by the CISO with a documented residual-risk rating, and minuted by the risk committee. The register entry carries an expiry date, not 'until further notice'.
5. Set the expiry before the contract end, e.g. nine months, with two mandatory re-reviews. An exception that outlives the contract it was written for is evidence of an unmanaged process.

The weakest answer is 'deny, the standard says no'. The second weakest is 'approve, the business needs it'. The defensible answer is a bounded, owned, monitored acceptance with alternatives documented.

Compensating controls must map to the three objectives (accountability, confidentiality, blast radius), not merely be 'extra security'.

Accountability / attribution

• Move the credential into a secrets manager and issue short-lived credentials to a single managed file transfer (MFT) node so every transfer is attributable to a logged job, not to a person sharing a password.
• Restrict the VPN tunnel to named source IPs and the MFT node only; no interactive logins on that path.

Confidentiality

• Remove the password from config files and Git history; rotate immediately, then on a 30-day cycle (the standard's 'annual' is a ceiling for compliant accounts, not a target for a compromised one).
• Require MFA or certificate-based VPN auth for the tunnel endpoints.
• Weekly automated check that the credential is absent from repos and images.

Blast radius / detection

• Vendor account confined to a single directory with no read access outside its inbound/outbound folders; no shell.
• Alerts on file volume, off-hours transfers, new filename patterns, and repeated auth failures; a human reviews the alert queue.
• Contractual security schedule with breach notification within 24 hours and a right to audit.

Monthly evidence pack

1. Rotation log/tickets with timestamps (all cycles completed).
2. Secrets-manager access logs showing only the MFT node retrieved the credential.
3. Alert review sign-off by a named analyst, with counts of alerts raised and closed.
4. Source-IP allowlist and firewall rule export.
5. Vendor attestation of progress against the Q3 date, with the committed release ID.

If the monthly pack is not produced twice in a row, the exception should lapse automatically - write that into the approval.

Defensibility rests on five artefacts, all of which an auditor will ask for and none of which are the security team's opinion:

• A written request from the business owner stating the business impact and the alternatives considered (including cost and lead time of each).
• Security's assessment of residual risk in a consistent rating scale, with the accepted rating stated explicitly.
• Signature of an accountable executive whose authority matches the risk, plus risk committee minutes recording the decision and date.
• A defined expiry, re-review dates, and named owner of the compensating controls.
• Evidence the controls actually operated - the monthly pack above, filed against the register entry.

Auditors fail exceptions for process, not for risk appetite: no owner, no expiry, no evidence of operation, or an entry that was never revisited.

Automatic revocation triggers (put these in the approval as 'shall', not 'may'):

1. Any indicator of credential misuse - anomalous transfer volume, auth from an unexpected IP, failed-login bursts.
2. A missed rotation cycle or an unrotated credential found in a repo or image.
3. The vendor slipping its committed Q3 release without a re-planned date accepted by security.
4. Contract end or termination for any reason.
5. A new regulatory or contractual obligation that prohibits shared credentials on this data class.
6. Loss of a compensating control that has no replacement (e.g. MFT node decommissioned).

The paper should also say who flips the switch: revocation must not depend on the risk committee reconvening. Delegate it to the CISO with notification to the business owner, not the reverse.