Q:

Maintaining Old Drupal Versions

Is there a list of best practices (or anything on drupal.org) for maintaining Drupal versions after end-of-life, specifically, when upgrading isn't an option? The best solution, of course, is to upgrade, but some organizations do not have the resources to make that happen.
I'd like to know some good practices here, especially when it deals with financial or private data. 
The Drupal LTS project looks to be dead. I do my best to monitor info problems through things like CVE, but those sources seem to only mention exploits on the currently maintained branches.

A:

I assume you're aware that Drupal 6 has been announced to be end of life as of Feb 24, 2016, as detailed in Drupal 6 end-of-life announcement. That mean that D6 will soon be considered as "old" also, right?
So looking at your question in this D6-context , I think "a" practise that may fit for D6 ("when upgrading isn't an option", as in your question) is to Buy Drupal 6 Long-Term Support (LTS) from one of the “official” vendors (up to you to decide if it is a 'good' or 'best' practise of course).
Moreover, as a variation of that "Drupal LTS project" that you mentioned, there now seems to be the D6LTS project.
For more details, refer to "What to do about Drupal 6 End of Life?". Some more details (from this link):

What, specifically, will happen after February 24th?

All D6 modules will be marked as “unsupported” on Drupal.org - which will mean the ‘update’ module will start telling you that ALL your modules are out-of-date.
Also, the status information that the ‘update’ module uses could go away at any time - so, you’ll no longer be able to rely on that in general.
The Drupal security team will no longer be making Security Advisories (or coordinating security releases)
In general, most module maintainers will no longer pay attention to Drupal 6 issues and will stop making new releases.

What should people with Drupal 6 sites do?

Archive the site, or
Plan upgrade.
Buy Drupal 6 Long-Term Support (LTS) from one of the “official” vendors.

What makes the “official” vendors special (vs. any other vendor)?

Get confidential information from Drupal security team.
Agree to follow security team processes and release all security patches publicly.
Vetted by the Drupal security team.

How will the Drupal 6 LTS work?

Same process as security team - but work done by vendors rather than security team.
Will publish patches on the D6LTS project.
Likely, but not 100% decided:

Announce new patches on the D6LTS issue queue.
Make new Pressflow 6 releases with the Drupal core patches.

Can the community get this without working with a vendor?

Yes!
But each vendor only supporting those modules their customers depend on
Question: And what about security issues that hackers find first?

