The Reg S-P service-provider oversight file step by step
Author
Audrey
NobleCloak's AI Correspondent · AI-drafted, fact-checked against our sourced evidence before publishing.
Date Published
If you're a CCO at an RIA or small broker-dealer, you already know the amended Regulation S-P is live. The compliance date for larger entities was December 3, 2025; for all smaller entities it was June 3, 2026. The industry asked for an extension — SIFMA and the IAA petitioned — and the SEC denied it. And Reg S-P is a named SEC Division of Examinations priority for FY2026. So the question isn't whether this applies to you. It's whether, if an examiner asked today, you could hand over a service-provider oversight file that shows you're actually doing the thing the rule requires.
Most firms can't, not because they're negligent but because the rule's service-provider obligations are new in a specific way, and AI vendors are the hardest case. This playbook builds the file, section by section: what to write (policies), what to collect (evidence), and how to make it examiner-ready without a compliance department.
What the rule actually requires of you
Strip the amendments down to the service-provider core. The safeguards rule now — at 17 CFR 248.30(a)(5) — requires you to adopt written policies and procedures for oversight of service providers, including through due diligence and monitoring. That word monitoring is the shift: oversight is no longer a one-time onboarding check, it's an ongoing obligation. The incident-response half of the amendments layers on three concrete mechanics:
- Your written incident-response program must be designed to detect, respond to, and recover from unauthorized access to customer information.
- Service providers must be contractually required to notify you of a breach as soon as possible, but no later than 72 hours after becoming aware of it.
- You must notify affected customers as soon as practicable, but not later than 30 days after becoming aware that their information was, or was reasonably likely to have been, accessed.
Nothing in Reg S-P names "AI" or mandates AI-specific controls — no US regulator does today. But an AI vendor is a service provider that often holds customer information, so it falls squarely inside the oversight and incident-response obligations you already owe. The exposure is inherited through the rule you're already subject to, not bolted on by a new one. That's the honest framing, and it's the one that survives an exam.
Part 1 — What to write (the policies)
Three documents. Keep them short and real; a policy you don't follow is worse than none.
1. A service-provider oversight policy. State how you select, diligence, and monitor service providers, and say explicitly that the standard is risk-based and proportional — more scrutiny for providers touching more sensitive customer data. Name who owns the process (usually you), the cadence of re-review (annually at minimum; on any material change), and the trigger events that force an off-cycle review: a new AI feature, a sub-processor change, a reported breach, an M&A event at the vendor. Add one AI-specific line: new or newly-enabled AI functionality in a service-provider's product is a re-diligence trigger.
2. An incident-response program. Write the playbook for a breach: who's notified internally, how you assess scope, the 30-day customer-notice clock and who starts it, and your regulator/law-enforcement notification path. Cross-reference the vendor's 72-hour obligation so the two clocks connect on paper.
3. Vendor contract language. This isn't a standalone doc but a checklist you apply at every contract and renewal. The 72-hour breach-notice clause is now table stakes. For AI vendors, add representations on data use (is your customer data used to train the vendor's models?), retention, sub-processors, and the right to a security attestation. NYDFS, in its October 2024 AI guidance, recommended firms seek AI-specific reps and warranties from vendors even though it imposed no new requirements — that's a useful, sourced precedent to point to when a vendor pushes back.
Part 2 — What to collect (the evidence, per vendor)
Policies are the promise; evidence is the proof you kept it. For each service provider that touches customer information, your file should hold:
- A diligence record — dated — showing what you reviewed and concluded. A completed vendor questionnaire, a reviewed SOC 2 (or a documented note that none exists and how you compensated), and a risk rating.
- The contract, with the breach-notice clause and any AI-specific reps flagged.
- A data-flow note: what customer information this vendor touches, how it gets there, and where it's stored.
- A monitoring log — the ongoing half. Dated entries: the annual re-review, any feature changes you caught, any news that prompted a look. Two or three lines a year per vendor is enough; the point is a dated trail, because "ongoing monitoring" with no timestamps is indistinguishable from "we did it once and stopped."
Part 3 — The AI vendors, worked
Reg S-P files fall apart on AI vendors because the tool often got in without a contract at all. Take the canonical find:
> Otter.ai holds Calendar + Drive read access for 8 users since March; meeting recordings are retained; no SOC 2 on file.
Walk it through the file. Is Otter a service provider under Reg S-P? If those calendars or drives contain customer information — client meeting notes, account details, planning documents — then yes, and it's been one since March with no diligence, no contract, no breach-notice clause, and no attestation. That is exactly the gap an examiner is trained to find, and "we didn't know" is not a defense when the grant was visible in your own admin console the whole time (see Reading OAuth grants — the shadow-AI map in your Workspace and Entra).
The remediation is a decision, documented: diligence-and-formalize (get the questionnaire answered, put it under contract with the 72-hour clause, restrict the scope), or revoke (kill the grant, remove the exposure). Either way you write down what you found, what you decided, and when. A revoked risky grant with a dated note is a clean finding at exam — it shows the program works. To generate the diligence record itself, the twelve questions in The AI vendor due-diligence questions that actually matter are the ones that hold up.
The pre-exam checklist
Run this the quarter before your exam window:
If every box is checked, you don't have a Reg S-P problem. You have a file.
The honest part
This playbook makes you defensible on paper and in process — it does not make you breach-proof, and it can't. A written incident-response program is a requirement, not a guarantee your vendor won't be compromised. A SOC 2 is a snapshot of the vendor's controls on the days the auditor looked, not a live feed. And a diligence record is only as good as the vendor's honesty in answering — which is why the monitoring half matters, and why point-in-time evidence has to be re-run, not filed and forgotten. The file's job is narrower and real: to show that a reasonable, proportional oversight process exists, ran, and left a dated trail. That's what the rule asks for, and it's what an examiner can see.
Assembling this file for a handful of AI vendors — reading the grants, chasing the questionnaires, drafting the diligence records — is real hours a 1–2 person shop doesn't have spare. That's the labor a Discover scan is built to relieve: we produce the dated diligence records and the flagged shadow-AI findings in the shape this file needs, so you're populating sections, not starting from a blank page.
Get your Reg S-P AI vendor file — we run it with you. Next: What an examiner-ready AI evidence binder contains.