The shadow register: the security exceptions every company has and nobody tracks

Ask a security lead whether the company follows its MFA policy and you'll hear yes. Ask whether there are any exceptions and you'll get a pause, then a list, then "I should probably write these down."

Undocumented exceptions are one of the most common real risks in small and mid sized companies, and the fix is cheap. An exception with an owner and an end date is risk management. An exception without either is a vulnerability with a Slack thread attached.

I've run access and risk programs inside fintech companies, and the exceptions I found during reviews were rarely reckless. They were reasonable decisions made on a busy day that nobody ever went back to.

Where exceptions come from

A SaaS tool that only supports a shared login. A legacy system that can't enforce password rules. A contractor who needs elevated access for a migration. An executive who finds a control inconvenient. A customer contract that forces a non standard configuration.

Each one is defensible on the day. The trouble is the day after, and the year after.

Somewhere in your Slack history is a message that says "fine for now, let's revisit". That message is an entry in a register that doesn't exist.

What the standards expect

ISO 27001 doesn't use the word exception, but it doesn't need to. Clause 6.1.3 requires you to decide how each risk is treated and to get risk owners to approve the treatment plan and accept the residual risk. An exception is a risk treatment decision. If nobody approved it, nobody owns it.

SOC 2 auditors test controls as they're described. If your description says MFA is enforced for all users and they find an account without it, that is an exception in the report unless you can show it was approved, mitigated and time limited.

PCI DSS formalises this as compensating controls, documented in a worksheet that explains the constraint, the objective of the original control, the alternative and how it was validated. It's a good model even if you never touch card data.

A register that works

Keep it short. One row per exception, with the rule being broken, the reason, the compensating control, the risk owner who accepted it, the date approved and the expiry date.

Make expiry mandatory. Thirty, sixty or ninety days, then renew with a fresh decision or close it. An exception that renews itself forever is a policy change nobody admitted to.

Make the request easy. If raising an exception means a form with eleven fields, people will go back to Slack.

Review the register in your monthly or quarterly security meeting, and bring the oldest open items to management review.

In Steppe an exception is a record attached to the control it bends, so it shows up wherever that control does, including in front of the auditor. A spreadsheet works too, as long as someone opens it.

"Temporary" is the longest lasting control in information security, so give every exception an end date before you approve it.