How to Log a Security Policy Exception an Examiner Will Accept

What is a security policy exception?

A security policy exception is a documented, approved decision to let a specific system, person or process operate outside a written security policy for a defined period. In risk terms it is a formal risk acceptance. Without the document and the approval, the same situation is simply noncompliance with your own policy, and that is how an examiner will read it.

Every firm has them. A portfolio accounting server that cannot run current endpoint protection, a custodian portal that does not support single sign-on, a principal who travels to a country where the firm's MFA app is blocked. The policy says one thing, the operating reality says another, and the gap needs a paper trail.

Why do examiners care about policy exceptions?

Examiners care because the rules behind your security program require written policies that you actually follow. An undocumented exception is evidence that the written program and the real program have drifted apart.

For an SEC-registered adviser or broker-dealer, 17 CFR 248.30(a)(1) requires written policies and procedures addressing administrative, technical and physical safeguards for customer information. For advisers, Advisers Act Rule 206(4)-7 requires written policies reasonably designed to prevent violations and a review, at least annually, of their adequacy and the effectiveness of their implementation.

The SEC Division of Examinations made the stakes concrete in its September 14, 2026 risk alert on annual compliance reviews. Staff observed advisers that did not take corrective action after their reviews recommended changes, and instances of noncompliance that "were not addressed or recorded in the annual reviews." An exception that sits in an email thread, invisible to the annual review, fits that pattern exactly.

Do any rules spell out how an exception must be approved?

Yes, for firms under the FTC Safeguards Rule, and the language is a useful model for everyone else. 16 CFR 314.4(c)(5) requires multi-factor authentication for anyone accessing any information system "unless your Qualified Individual has approved in writing the use of reasonably equivalent or more secure access controls."

The same section treats encryption the same way. Under 314.4(c)(3), if encrypting customer information is infeasible, the firm may use "effective alternative compensating controls reviewed and approved by your Qualified Individual." The rule names an approver, requires the approval to exist, and ties the exception to a compensating control. The Safeguards Rule covers investment advisers that are not required to register with the SEC, along with other non-bank financial firms.

SEC-registered firms have no equivalent text in Reg S-P, but the pattern carries over. Name an approver, write down the approval and record what replaces the missing control.

Open exceptions also belong in front of leadership. Under the Safeguards Rule, the Qualified Individual's annual report to the board covers risk management and control decisions, and our guide to the Qualified Individual's board report shows where they fit.

What should a policy exception record include?

An examiner-ready exception record answers six questions on one page: what policy, what asset or person, why, what compensates, who approved, and when it ends.

• Policy and control reference. Quote the policy section being waived, for example "MFA on all remote access."
• Scope. The specific system, account or user. "The trading desk" is too broad. "The service account used by the order management system's nightly import" is right.
• Business reason. One or two sentences on why the control cannot be applied now, in plain language.
• Risk assessment. What could go wrong and how likely it is. The Safeguards Rule's written risk assessment must include "requirements describing how identified risks will be mitigated or accepted," and an exception is an accepted risk, so this field doubles as your risk acceptance form.
• Compensating controls. What the firm does instead, such as IP restrictions, a separate admin account or extra logging, and how you check it is working.
• Approval. Name, title and date of the approver. Under the Safeguards Rule that is the Qualified Individual. At an SEC-registered adviser it is usually the CCO who administers the 206(4)-7 program, often with the business owner of the system co-signing.
• Expiry and review date. A fixed end date and a trigger for early review, such as a vendor upgrade or a security incident.

The NIST Cybersecurity Framework 2.0 captures the same idea in subcategory ID.RA-07: "Changes and exceptions are managed, assessed for risk impact, recorded, and tracked." The CIS Controls use similar language for software, requiring that unauthorized software be removed or receive "a documented exception" (Safeguard 2.3).

Should exceptions live in the risk register?

Yes. Keep them in one register that the annual review reads, usually a dedicated tab of the firm's risk register. Tickets, inboxes and the IT provider's notes are where exceptions get lost. The register is the single list an examiner can sample from and the CCO can sign against.

A simple spreadsheet works if it is controlled: one owner, restricted edit rights and version history. Each row links to the supporting evidence, such as the screenshot of the conditional access rule that compensates for a missing control.

For advisers, retention follows the annual review. Rule 204-2(a)(17)(ii) requires records documenting the annual review of 206(4)-7 policies, and the rule's general retention period for books and records is five years. If your annual review relies on the exception register, keeping closed exceptions for the same period keeps the story complete. Broker-dealers should map the register to their own retention obligations with compliance counsel.

For the wider retention picture, see Reg S-P recordkeeping under Rule 204-2. If the firm has not settled who owns the security program, who signs your Reg S-P program is the place to start, because that person is usually the right exception approver.

What makes an exception look bad in an exam?

Four patterns draw findings: no expiry, no compensating control, an approver with no authority over the policy, and exceptions that never make it into the annual review.

Permanent exceptions are the most common. An MFA waiver granted for a client trip in 2023 that is still active in 2026 has become an unapproved change to the policy. Either renew it on its own merits with a new review, or close it.

The second pattern is a register that contradicts the technical record. If the register says an exception expired in June and the account is still excluded from the MFA policy in October, the register is a liability. Reconcile it against the actual configuration each quarter.

What should you do this quarter?

Start by finding the exceptions you already have, then put them on paper. Most firms discover more than they expect.

1. Pull every exclusion from your identity provider's MFA and conditional access policies, every device excluded from endpoint protection, and every unsupported system still in service.
2. For each one, either remove it or write an exception record with the fields above.
3. Get each record signed by the right approver: the Qualified Individual under the Safeguards Rule, or your CCO and the system owner at an SEC-registered firm.
4. Set an expiry no longer than 12 months, and put the review dates on the compliance calendar.
5. Add the register as a standing input to the 206(4)-7 annual review, and record in the review what was opened, closed and renewed.
6. Reconcile the register against live configurations each quarter.

How can s90 help?

s90 keeps a risk register for each client and reconciles it against the live configuration of identity, endpoint and email controls. Exceptions, compensating controls and expiry dates appear in the Technology Posture Report the CCO reviews, and s90's agreement commits to producing that evidence within 24 hours of an examiner request. If you would like a second set of eyes on your current exceptions, start with a short review call.