Reg S-P for Smaller Entities: A Minimum-Viable Incident-Response Program That Passes Exam

The smaller-entity deadline for the amended Regulation S-P passed on 3 June 2026. If your firm treated it as a paperwork exercise, the gap is now a finding waiting to happen — and the fix is smaller than most vendors want you to believe.

The SEC adopted the Regulation S-P amendments in May 2024. Larger entities had to comply by 3 December 2025; smaller entities by 3 June 2026. Both dates are now behind us, which means an SEC examination or a FINRA cycle can ask to see your incident-response programme today and is entitled to a straight answer. The trap for a small broker-dealer or a sub-billion adviser is not the enterprise problem everyone writes about. It is being sold a security operations centre you do not need while the four artefacts an examiner will actually ask for remain unwritten.

Where the smaller-entity line falls

The amendments split covered institutions into two tiers, and the split decides your deadline, not your obligations. A broker-dealer or transfer agent is a smaller entity if it qualifies as a small entity under the Securities Exchange Act. An investment company is smaller if, together with related funds, it holds net assets below $1 billion. A registered adviser is smaller if it reports less than $1.5 billion in assets under management. Everyone below those lines got the extra six months. Nobody below those lines got a lighter rule.

That distinction matters because proportionality in Reg S-P works the way it works in DORA: it reduces the depth of what you document, not the existence of the obligation. The rule expects the same written incident-response programme, the same customer-notification discipline and the same service-provider oversight from a fifteen-person adviser as from a national broker-dealer. The fifteen-person adviser simply gets to run it on one page instead of forty.

The minimum-viable written programme

The rule requires written policies and procedures for an incident-response programme reasonably designed to detect, respond to and recover from unauthorised access to or use of customer information. “Reasonably designed” and “written” are the operative words. An unwritten process that lives in the head of your one competent person fails on both counts, however well it actually works. A lean but genuine programme covers five things:

1. Detection and reporting. How an incident reaches the person who owns the response — the mailbox, the phone number, the fact that a vendor alert or a staff report is a trigger, not a nuisance. Name the owner by role.
2. Assessment of scope. How you determine what customer information was involved, which systems were touched and whether sensitive customer information is in play. This is the judgement that starts the notification clock, so it has to be written down before you need it.
3. Containment and recovery. The steps to stop the access and restore normal operation. For most smaller firms this is a short, honest description of who you call and what you switch off, not a runbook borrowed from a bank.
4. Customer notification. The decision procedure and the template, held ready, so the 30-day clock is a process rather than a scramble.
5. Service-provider handling. How an incident at a vendor becomes your incident, on your timeline.

That is the whole programme. It can be five pages. What it cannot be is absent, generic or copied from a template that names systems you do not run. An examiner reading a programme that references a SIEM you have never operated learns more about your compliance than a firm that admits, in writing, that detection depends on a shared mailbox and a named principal checking it.

The part you cannot delegate away

The service-provider requirement is where smaller firms are most exposed, because it is the part that depends on someone else. The amendments require written policies and procedures reasonably designed to oversee service providers through due diligence and monitoring, and to require, by contract, that a provider protects customer information and notifies you as soon as possible — and no later than 72 hours — after becoming aware of a breach affecting the systems that hold your customers’ data.

Read that timing against the 30-day notification clock and the design constraint becomes obvious. If your custodian, your CRM host or your outsourced IT provider takes a fortnight to tell you, you have already burned half your window before you knew there was a clock running. The 72-hour vendor obligation is what makes the 30-day customer obligation survivable. If it is not in the contract, it does not exist, and the gap is yours, not the vendor’s. The specifics of which clauses to insist on and what telemetry you should actually be able to see are worth reading in their own right, because this is the clause most standard vendor paper omits and the one an examiner can verify in minutes.

The 30-day clock and who starts it

The notification rule is precise: notify affected individuals as soon as practicable, and no later than 30 days, after becoming aware that unauthorised access to or use of sensitive customer information has occurred or is reasonably likely to have occurred. The clock starts at awareness, not at confirmation, and “reasonably likely” is a lower bar than certainty. That single design choice is why the assessment step in your programme matters more than the containment step. The firms that miss the window are rarely the ones that cannot fix the breach; they are the ones who never wrote down who decides that the clock has started.

So name that person by role, give them the template in advance, and record the awareness date the moment an incident is logged. The mechanics of running a defensible clock — logging the trigger, timestamping awareness, documenting the notification decision — are the same discipline that serious-incident reporting under other regimes demands, and a firm that builds it once can point the same machinery at more than one rulebook.

What proportionality does not excuse

Being small buys you brevity, not absence. You are not expected to run a 24-hour monitoring function, retain a forensic firm on standing retainer or maintain the documentation depth of a systemically important broker-dealer. You are expected to have a written programme, a named owner, contractual notification terms with the vendors that touch customer data, a ready customer-notification template and evidence that the programme has been reviewed rather than filed and forgotten. Five artefacts. None of them require a security operations centre. All of them require a decision to actually write the thing down.

The deadline has passed. The question an examiner will ask is not whether you have a SOC. It is whether, when a vendor emails you at 4pm on a Friday, anyone in your firm knows the clock just started and where the template lives.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK and Middle East, with on-site time where the engagement requires it.