Pylon Compliance Library
In plain language
Financial regulators do not write rules about technology. They write rules about outcomes — customer information stays protected, records stay retrievable, someone supervises the system — and then examiners ask you to show the technology that produces those outcomes. This library takes each of those rules and states what it actually asks you to configure, what you have to do on a schedule, and what evidence proves it.
Nine sections, each written the same way: a plain-language summary first, then the requirement in digestible pieces, cited to the SEC and FINRA primary sources rather than to a summary of a summary. Every section ends with two machine-readable blocks — the recurring work it implies, and the configuration it lands on — and those blocks aggregate into the two rollups below.
Who this library is for
It is written for the people who have to operate the program, not for the people who write the rules: chief compliance officers at registered investment advisers, operations and technology leads at broker-dealers, CFOs and COOs at hedge funds and private equity advisers, and the outsourced IT or managed security provider sitting between them.
If you can read a rule but not a firewall configuration, start with the plain-language summary at the top of each section. If you can read the firewall but not the rule, start with the configuration touchpoints at the bottom.
How to use it
- Scoping a new obligation. Read the section summary, then its scheduled actions. That pair tells you what changes and how often you will be doing it.
- Building a compliance calendar. Go straight to all scheduled actions, which lists every action in the library with its cadence, owner archetype, and source.
- Preparing for an annual review or an exam. Work through monitor and review. It is the checklist for demonstrating that the technology program is operating, not merely documented.
- Handing work to a provider. Every action and configuration rule has a stable identifier. Those identifiers are the vocabulary to use in a statement of work or a ticket queue.
What it deliberately does not do
This library does not interpret the law for your firm, does not tell you which rules you are subject to, and does not describe any specific client’s environment. Registration status, business model, and custody arrangements all change the answer. Where a requirement has a genuine ambiguity, the library says so rather than inventing a rule.
For how Pylon delivers this work as a service, see Regulatory Compliance, SEC & FINRA compliance, Regulation S-P, and RIA cybersecurity.
Sections
Regulation S-P: Safeguards, Incident Response, and the Notification Clocks
Regulation S-P says you have to protect customer information, know when it has been exposed, and tell people about it on a clock. The 2024 amendments turned the last part into a written program with deadlines: customers get notified within 30 days of you becoming aware, and your vendors have to tell you within 72 hours of becoming aware. Almost all of the work is knowing where customer information actually lives before anything goes wrong.
6 scheduled actions · 6 configuration touchpoints
Advisers Act Compliance and Cybersecurity: Rule 206(4)-7 and the Technology Program
Rule 206(4)-7 does not mention firewalls, encryption, or passwords. It says a registered adviser must have written policies and procedures reasonably designed to prevent violations, review them at least annually, and designate someone to run them. Cybersecurity enters through that door: if a technology failure could cause you to breach the Advisers Act or your duty to clients, then controlling it is part of your compliance program, and the annual review has to actually look at it.
6 scheduled actions · 4 configuration touchpoints
Books and Records: Electronic Retention Under Rule 17a-4 and Rule 204-2
Regulators do not just require you to keep records. They require you to keep them in a form that cannot be quietly changed, to produce them quickly when asked, and to capture business communications wherever they happen — including on the messaging app someone uses because it is convenient. Most firms fail this on the last point, not the first.
6 scheduled actions · 6 configuration touchpoints
FINRA Supervision and Cybersecurity: Rule 3110 and Broker-Dealer Technology Controls
FINRA requires a broker-dealer to supervise its business, and supervising a business that runs on technology means supervising the technology. That produces three concrete demands: written procedures describing who reviews what, a system that can actually surface the communications and activity being reviewed, and an annual test that checks whether the supervision happened.
6 scheduled actions · 5 configuration touchpoints
Regulation S-ID: Identity Theft Red Flags, at a High Level
Regulation S-P is about keeping customer information from getting out. Regulation S-ID is about noticing when someone uses that information to impersonate your client — a changed address followed by a withdrawal request, a login from somewhere improbable, a wire instruction that arrives by email. The rule asks for a written program that identifies those patterns, detects them, responds to them, and gets updated as the patterns change.
6 scheduled actions · 5 configuration touchpoints
Vendor and Service-Provider Oversight for Regulated Financial Firms
You can outsource the work but not the obligation. Regulators expect you to know which vendors can reach your client data, to have checked them before you let them in, to have written a breach-notification duty into their contract, and to look again periodically. Almost every firm has the first item partly wrong, because vendors arrive through subscriptions and integrations rather than through procurement.
7 scheduled actions · 6 configuration touchpoints
Access Control and MFA for RIAs, Broker-Dealers, and Funds
No SEC rule says the words multi-factor authentication. Examiners ask about it anyway, because it is the control that most reliably prevents the incident that triggers every other obligation in this library. The defensible position is MFA on everything that reaches client data — staff, vendors, and service accounts — with the exceptions written down, owned, and shrinking.
7 scheduled actions · 8 configuration touchpoints
Incident Response and Exam Evidence for Financial Firms
An incident response program has two jobs and firms usually only build the first. The first is handling the incident. The second is producing a record afterwards that shows the handling was competent — who decided what, when the clock started, why the notification population was that size. The second job is what an examiner sees, and it is almost entirely determined by decisions made before anything went wrong, especially how long you keep logs.
7 scheduled actions · 6 configuration touchpoints
Private Fund and PE Adviser Technology Notes
Private fund and private equity advisers face the same rules as any other registered adviser, but the operating conditions are different: a small team, highly sensitive deal information, institutional investors who audit your technology harder than any examiner, and — for PE — portfolio companies whose security problems can become the fund’s problem. The compliance obligation is ordinary. The pressure comes from the operating conditions.
7 scheduled actions · 7 configuration touchpoints
Rollups
Scheduled Actions: Every Recurring Compliance Technology Task in the Library
This is every recurring task the library implies, in one table, with how often it happens and who normally does it. If you are building a compliance calendar, start here rather than reading nine sections. Each row has a stable identifier so it can be tracked in a ticket queue or handed to a provider without ambiguity.
Monitor and Review: A Reasonable Basis That the Technology Program Is Operating
Regulators do not ask whether you have policies. They ask how you know the policies are working. This page is the checklist for answering that — every check from every library section in one list, each paired with the artifact that answers it, plus the configuration state someone should confirm in the live environment rather than in a document.
- Author
- Rachel Lannon and Byron Foley
- Reviewed by
- Tim Quinn
- Last updated
This is operational technology guidance for regulated firms, not legal advice. Confirm how each requirement applies to your firm with your compliance counsel.