External Party Data Transfer Policy
This document covers the transmission to external vendors, consortiums, companies or individuals of University of Richmond sensitive data. Sensitive data is FERPA protected data, Social Security numbers, personally identifiable information, human resource data, employment data, or any other University-maintained data whose disclosure would be seen as causing harm to the University.
This document is intended to cover cases where data transfer is being performed in a one-off basis. For data transfers that occur on an ongoing basis other and/or additional policies and procedures may be appropriate.
- The University will only transfer sensitive data to external parties if the owner of the data explicitly approves its transfer. For FERPA and most student-related data, the owner is the registrar. For other sensitive University data, the owner is the highest level figure that would have direct authority over and full responsibility for the data—not necessarily the internal users of that data.
- This data must be encrypted during transfer. A best practice approach is to use a standard of AES 256 bit encryption, although other levels may be appropriate. This can be achieved using encrypted ZIP files.
- The key to the encrypted data must be transferred out of bounds. That is it cannot be transferred using the same mechanism as the data. For instance, if the data is sent via e-mail, the key must be exchanged via phone or letter.
- The external party must acknowledge receipt of the data. One best practice approach is to create a CD with the encrypted data on it and then to use an overnight shipping company to send it, requesting a return receipt. E-mail acknowledgements are also acceptable although not preferred.
- The data must be verified as secure before the transfer occurs by a third internal party. The IS security officer or designates can provide this service.
- The data must be securely archived so that in event of an issue the University can verify the exact contents of the data at issue.
|1.0||July 12, 2007||Chris Faigle||Initial policy created.|
|1.1||May 18, 2010||Melody Kimball||Revision history added.|
|1.2||October 17, 2013||Anthony Head||Increased encryption strength|