Of the four cybersecurity-adjacent rules that govern an SEC-registered investment adviser — Rule 206(4)-7, Regulation S-P, Rule 204-2, and Regulation S-ID — the one most firms understand least is Regulation S-ID. It is also the one most likely to be sitting in a binder, unchanged, since the day it was first drafted.
That is now a problem. The SEC has begun treating identity theft as a cyber-first risk, and a Red Flags program that does not reflect how identity theft actually happens today is, in the agency’s view, not a program at all.
What Regulation S-ID Actually Requires
Regulation S-ID — the Identity Theft Red Flags Rule — requires firms that maintain “covered accounts” to develop and implement a written Identity Theft Prevention Program designed to detect, prevent, and mitigate identity theft. The program must do four things: identify relevant red flags and incorporate them into the program, detect those red flags in the course of business, respond appropriately to red flags that are detected, and ensure the program is updated periodically to reflect changes in risk.
The first threshold question is whether the firm maintains covered accounts at all. A covered account is, broadly, an account that permits multiple payments or transactions, or any other account for which there is a reasonably foreseeable risk of identity theft. Many advisers conclude — sometimes correctly, often without documenting the analysis — that they do or do not have covered accounts. The rule expects that determination to be made deliberately, documented, and reassessed periodically. “We decided years ago we don’t have covered accounts” is not a periodic assessment.
Why Most Programs Are Dead on Arrival
When I review an Identity Theft Prevention Program during an assessment, the pattern is almost always the same. The document was created once, often pulled from a template, and never meaningfully revisited. It lists generic red flags that have nothing to do with how the firm operates — alerts from consumer reporting agencies, suspicious documents presented at account opening — and contains nothing about the threats that actually compromise advisory clients today.
That gap is exactly what the SEC called out in its November 2025 action against M Holdings. The firm maintained a written Identity Theft Prevention Program, but it had not been meaningfully updated for years, contained no cybersecurity-specific red flags despite repeated cyber incidents, lacked reasonable procedures for responding to cyber-related identity-theft risks, and did not include periodic assessments of whether the firm maintained covered accounts. The SEC’s position was implicit but unmistakable: a static document that does not evolve with risk does not qualify as an operational program.
The lesson is that a Red Flags program written in the language of 2010 — focused on forged signatures and mismatched addresses — does not describe the way client identities are actually stolen in practice. Today, identity theft against advisory clients runs through email.
What a Modern Red Flags Program Must Include
If identity theft now happens primarily through compromised credentials and manipulated communications, the red flags have to reflect that. A current program should incorporate, at minimum:
- Phishing-driven credential theft. An employee or client credential harvested through a fraudulent login page is the opening move in most modern identity-theft events.
- Email account compromise indicators. Unusual mailbox rules (auto-forwarding, auto-delete), logins from unexpected locations, and password resets the user did not initiate.
- Wire-fraud patterns. Last-minute changes to wire instructions, urgency or secrecy in payment requests, and requests that deviate from a client’s established pattern.
- Malicious mailbox rules. Rules created to hide an attacker’s activity from the legitimate account owner — a hallmark of business email compromise.
- Instruction spoofing. A spoofed client instruction, a fake custodian email, or a fraudulent password-reset request is an identity-theft event, not just an IT nuisance.
Each of these is both a cybersecurity event and a Regulation S-ID red flag. The two rules are not separate problems handled by separate people — they describe the same incident from two regulatory angles, and the program should say so.
Detection, Response, and the Link to Reg S-P
A red flag the firm cannot detect is not in the program in any meaningful sense. Detection ties directly to the technical controls discussed elsewhere in this library: email authentication and anti-impersonation protection, audit logging that captures mailbox access and rule changes, and monitoring that surfaces anomalous sign-ins. If the firm’s written program says it watches for malicious mailbox rules but the tenant produces no logs that would show one, the control exists only on paper.
Response procedures must be equally concrete. When a red flag is detected, who is notified, what is the containment step, when is the client contacted, and how is the event documented? This is where Regulation S-ID overlaps with the amended Regulation S-P incident response and 30-day notification requirements. A single compromised client email can simultaneously trigger an S-ID red flag, a Reg S-P sensitive-customer-information assessment, and a books-and-records preservation obligation under Rule 204-2. The programs should be built to recognize that overlap rather than treat each rule as a separate fire drill.
The Periodic Update Is the Part Everyone Skips
The rule requires the program to be updated periodically to reflect changes in risk, and it requires appropriate oversight — including approval of the initial program and involvement in its administration and material changes. In practice, this means the program should be reviewed on a defined cadence, the review should be documented, and material updates should be approved at the appropriate level of the firm. Folding the S-ID review into the annual Rule 206(4)-7 compliance review is the cleanest way to ensure it actually happens and that there is evidence it happened.
The Bottom Line
Regulation S-ID is not a paperwork formality, and it is no longer satisfied by a generic template that lists red flags borrowed from retail banking. The SEC now expects an Identity Theft Prevention Program that names cyber-era threats, can actually detect them through real controls, defines a concrete response, and is reviewed and updated on a documented cadence. If your program has not been opened since it was created, assume it is deficient — and assume an examiner who has read the M Holdings order will know exactly what to look for.
If you are not sure whether your Red Flags program reflects current risk — or whether you have correctly assessed your covered accounts — that review is part of the compliance work we do.