SEC 17a-4 website archiving requirements: what FINRA 2210 makes you keep, and for how long

If your firm is registered with the SEC or FINRA, your public website is a communication with the public, and the recordkeeping rules that cover email cover it too. That surprises people, because nothing in the rule text says the word "website." The obligation arrives by reference: FINRA Rule 2210 sweeps retail communications in, then hands the retention period and the storage format straight to SEA Rule 17a-4. Here is exactly what those two rules say, what they require you to keep and for how long, what changed in 2022, and where firms usually fail an exam on this.

The short version

Retail communications, which includes your public website, must be retained for at least three years, the first two in an easily accessible place, in a format that complies with SEA Rule 17a-4. Since the 2022 amendments there are two acceptable storage designs, not one: a complete time-stamped audit trail of every modification and deletion, or the older write-once, read-many format. Every material version of the page counts, not just the current one, so a live site with no capture history is a gap regardless of how good your CMS backups are.

Does SEC Rule 17a-4 apply to websites?

Indirectly, and that indirection is why it gets missed. The rule that names your website is FINRA Rule 2210, which governs communications with the public and classifies content available to retail investors as a retail communication. Paragraph (b)(4)(A) then says members must maintain all retail communications and institutional communications "for the retention period required by SEA Rule 17a-4(b) and in a format and media that comply with SEA Rule 17a-4."

So there is no separate website archiving rule to look up. FINRA decides that the page is in scope; the SEC rule decides how long you keep it and in what form. A compliance calendar that tracks 2210 but never opens 17a-4 will produce a policy with no retention number in it, which is the single most common gap we see described in vendor-neutral guidance on this topic.

Worth knowing: FINRA has long treated third-party content a firm links to or shares as adopted content in many circumstances, which brings it inside the same obligation. That is a large part of why dedicated compliance platforms crawl outward from your site rather than snapshotting a fixed list of pages.

How long must you keep website records?

Three years, with the first two years in an easily accessible place. That comes from SEA Rule 17a-4(b)(4), which requires preservation of originals of communications received and copies of communications sent relating to the business, for a period of not less than three years, the first two in an easily accessible place.

Two implications people miss. First, the clock is per record, not per site: a promotional page that ran for six weeks in 2024 has its own three-year life, so a retention policy expressed as "we keep the current site plus three years of backups" does not actually satisfy the rule. Second, "easily accessible" is doing real work in that sentence. A capture sitting in cold storage that takes your vendor two weeks to restore is not easily accessible in year one, and examiners have historically pressed on production time, not just existence.

Is WORM storage still required?

No. This is the part of the rule most likely to be out of date in an internal policy written before 2023, and it changes which vendors are viable.

Rule 17a-4(f)(2) now permits two alternatives. Under the first, a firm may preserve a record for its retention period "in a manner that maintains a complete time-stamped audit trail" that includes all modifications to and deletions of the record, the date and time of actions that create, modify or delete it, the identity of the person taking the action where applicable, and any other information needed to maintain the audit trail. Under the second, a firm may preserve records "exclusively in a non-rewriteable, non-erasable format," which is the traditional WORM approach.

Both are compliant. Practically, that means a system that logs immutably and can prove nothing was quietly altered is now an acceptable design, and you no longer have to buy a specific storage medium to satisfy the format requirement. It does not mean the bar dropped. An audit trail only helps if it is complete, tamper-evident and producible, and a homegrown log table that an admin can update is not an audit trail in the sense the rule means.

What actually has to be captured

The obligation is about versions, not pages. Every material change to public-facing content creates a new record. In practice that means four things need to be in your capture scope, and the last two are where teams get caught out.

The full public site, including pages nobody links to anymore but that remain reachable. Every material revision, including a fee schedule edited three times in a quarter and a disclosure that was live for one afternoon before someone pulled it. Dynamic and personalized content, because a page that renders differently for a logged-in visitor or by geography has more than one version to preserve, and a capture tool that fetches raw HTML without executing JavaScript will archive an empty shell of a modern application. Content you adopted, such as third-party material you linked or shared in a way that endorses it.

A CMS revision history is not a substitute for any of this. It records what an author typed, not what a visitor saw, and it usually cannot reproduce the rendered page with its templates, styles, disclosures and dynamic figures as they existed on a given date. That gap between "what was in the database" and "what was on the screen" is precisely what a capture is for.

What examiners ask for, and what usually fails

Requests in this area tend to be narrow and specific: show us this page as it appeared on this date, show us every version of this disclosure over the last two years, show us when this claim was added and when it was removed. Firms that fail do so in one of four ways.

No capture at all for the period in question, usually because archiving started after a redesign and nobody backfilled. Captures that exist but cannot be produced quickly, which runs into the easily accessible standard. Captures with no defensible timestamp, such as PNG files in a shared drive whose file dates were reset by a migration. Coverage gaps on the pages that matter most, typically campaign landing pages and microsites that marketing launched outside the main CMS and never told compliance about.

The fix for the last one is organizational rather than technical: whoever can publish a public page has to be inside the process that registers it for capture. When a request finally lands, the work is retrieval, and the practical bottleneck is usually that the evidence is scattered across an archive, a ticketing system, an email thread and a marketing tool, so being able to search across every system at once matters as much as having captured the page in the first place.

Choosing a tool against the rule instead of the brochure

Once you read the two rules, the shopping list gets short and unglamorous. You need capture that runs in a real browser engine so dynamic pages are preserved as rendered. You need a trustworthy timestamp tied to the source URL. You need either an immutable store or a genuine audit trail, per 17a-4(f)(2). You need retention you can set to three years or more and, just as importantly, deletion you control when the period ends. And you need retrieval fast enough to satisfy the easily accessible standard in the first two years.

Notice what is not on that list: replay fidelity, social media capture, e-discovery review seats. Those are genuinely valuable and several vendors do them well, but they are above the line the rule draws, and they are where quoted prices climb. We wrote up the whole vendor landscape, with the pricing each one actually publishes, on the website archiving software comparison, and the compliance archiving guide covers what makes a single snapshot defensible.

For firms whose scope is a known set of pages rather than a sprawling site, capture can be a scheduled call rather than a platform. Rendering the page in managed Chromium and keeping the dated snapshot alongside the PDF gives you the timestamp, the source URL and the retrieval path in one request:

curl https://api.sitepdf.com/v1/render \
  -H "Authorization: Bearer $SITEPDF_KEY" \
  -F url=https://www.example.com/fees-and-disclosures \
  -F archive=true

{
  "pdf_url": "https://api.sitepdf.com/v1/documents/doc_5t1nb.pdf",
  "archive": {
    "id": "arc_9k4rz",
    "source_url": "https://www.example.com/fees-and-disclosures",
    "captured_at": "2026-07-31T09:14:02Z",
    "retrieve_url": "https://api.sitepdf.com/v1/archives/arc_9k4rz"
  }
}

Run it from cron for scheduled coverage, or fire it from your publishing pipeline so a capture happens the moment content changes, which is the version of this that never has gaps. The website archiving page covers how the snapshot store works, and saving a web page as PDF covers the single-page version.

One honest caveat

This is a plain-language reading of two rules, not legal advice, and we are a software company rather than a compliance consultancy. Whether a specific page is a retail communication, whether particular third-party content counts as adopted, and how your retention policy should be written are questions for your compliance counsel. What we can tell you accurately is what the rule text says, which is the part that vendor marketing tends to paraphrase loosely: three years with the first two easily accessible, and since 2022, an audit trail or WORM, your choice.