Implemenation Details...

Totally apart from the issue of whether screening is a good idea or not, I want to start a discussion of how to implement this thing.

I have a few thoughts that I want to get out there.

How are teams implementing the data retention policy?

From the document FRCFAQ.pdf:


  1. Store completed consent forms in a secure location.
  2. Print and store the web page with the “Completed” findings for each screening.
  3. Maintain each year’s file for 3 years for each team.

Our team is not unlike any team in that we are a pretty transient group of people. By this I mean that folks who are 1000% behind the program one year, may be an hour here and there the next (for a million reasons, work, family, burnout, or whatever).

As I understand FIRST’s policy, teams are suppose to keep the personal information from the team members they checked for 3 years. But how do we keep them secure? Where do we store them? How do we make sure that the records do not get lost or tossed when perhaps the team member designated as the keeper of the records this year goes dormant next year? How do we get rid of the data safely and securely after 3 years?

Many many questions.

My own initial thinking on this subject is that “interpret” the rules above to not mean literally “print and store” but to mean “be able to print such things if requested to do so by FIRST or other proper authority.” Once this slight of hand is accomplished, I would propose that teams get some “strong encryption” software. We could compile all the data requested into one zip file (via scanning or copying and pasting screen dumps for example). Then we could encrypt this file with a secret password that only one or perhaps 2 folks would know. Once encrypted, we could store the file in a password protected part of our website (this is just to keep most prying eyes from even getting the chance to break the encryption scheme).

The only part I don’t have is how to make the data unavailable after 3 years. Backup copies of websites, etc. make this harder to do than you might think.

Does anyone know of a foolproof way to make an encrypted file not decodeable after a fixed date?

Anyway, I would like folks to comment/share ideas on how to safely and conveniently implement the rules on data retention.

Joe J.

  1. Well, you could encrypt it using a method that needed a keyphrase (something like RSA or blowfish, I think…or something like PGP). Use a really long phrase of random characters, then store the characters in a file. Each year, get a new keyphrase and dump the 4th one. It wouldn’t be the best way to do it, I’m sure (you could write it down then save it) but it would keep most people out.

  2. Also, you could store files on one computer in a directory labelled for the year…then 3 years later, just shred that DIR… you’d need to password protect that and make it read-only for the owner. You could store passwords in a file in a school office or some place that won’t change. You could also have the user-account expire on the owner of those files after three years…

Both those ideas are moderatly easy to do… the second being the easiest.

<edit>numbered ideas</edit>

This is, perhaps, my largest concern.

FIRST’s policy makes no provision for anyone but the team leader to have any access whatsoever to this data and, as such, designating a team member to control this information is an improper implementation of the policy. What are the consequences for such an improper implementation? Well, there are none, it seems, and that’s a little bit scary.

In the interest of preserving privacy, the team leader should be the only person with access to these records, and past experience shows me that even that isn’t enough to protect you from defamatory statements and discriminatory actions. I can’t imagine what might happen if arbitrary team members were allowed access to such private information.