Considerations for Data Implementation

Just like your hopelessly romantic friend who continues to jump into the deep end of the dating pool will tell you, asking compatibility questions and planning to prevent later problems is intimidating and boring. However, five days later, over a gallon of Rocky Road in a dark room, listening to Adele, they’ll also tell you that they should have listened to you and asked the right questions before diving in. That’s what TSLAC’s here for: the right questions, not the Rocky Road. Just like your friend who will find love one day, data is a sensitive and vulnerable companion who needs their heart/data protected before making any big moves. In this article, we’ll discuss some questions to consider and ask internally and externally before implementing any type of new software or electronic program.

Woman in a black dress, in a restaurant, and on a date with data. Data being a man with a circle full of data for his head. Data gave his date a red rose.

Find out if the database or software is…

Ask the vendor or determine through research…

  • How do they backup the data? 
  • Where is the data stored? 
  • If the contract ends, what happens to the data?

Check out TSLAC’s article “Electronic Records, Third-Party Systems, and Contracts” for further considerations related to contracts with vendors.

Among your entity, ask…

  • What is the business need for this database or software? Do you already have an approved database or software that suffices? 
  • Who will be the custodian? Who will be the backup custodian? Custodians are the designated persons responsible for ensuring the data, information, and records are properly maintained for the entire lifecycle. We recommend designating custodians by their position.
  • Which departments are using the database or software? We strongly recommend creating an inventory of software and other databases that host your entity’s data. Within that inventory, we recommend for:
    • Subject matter experts to explain the need for the software. 
    • IT to review and determine the overall purpose of the software.
    • The entity to come to one overall summarization of the tool. This will help staff know if there is similar software already approved for use among your entity. The fewer software products implemented, the easier they are to manage.
Oliver Twist, asking with an empty bowl for more. Caption is "Cyber security budget before a breach." Under that is a photo of a man laying on a pile of cash. Caption is "Cybersecurity budget after a breach."
  • What kind of data is being stored in the database or software?
    • Public, confidential, sensitive? Here is a guide to the different classifications of data. Are users aware of and trained on the different classifications and how the data should be managed based on the classification?
    • If any, which record series does the data fall in? The following resources will help determine if the data constitutes a record:
  • Is there anything that can affect getting access to the records for the duration of when you need these records? (In other words, will you have access to the records for their full retention period? If not, what will you do to ensure that you meet this requirement?)
  • Do you envision this data being exported out by staff? If so…
    • Will they be creating records? For help in determining this, see guidance above.
    • How will you ensure they are deleting any convenience copies?
Boromir saying, "One does not simply walk away and leave your computer unlocked..."
  • If the data is floating around in various documents, is that a problem?
  • If so, what training, policies, and procedures should be implemented or updated?
  • How are you going to maintain any related policies, procedures, or training (e.g., designate a position that should review each annually)?
  • When does the contract end?
  • When the contract ends, how will you export the data that you need? Does IT need to be involved?
  • In general, does IT need to be involved with the software or database? If so, how?
  • If IT does need to be involved at any point, do they have the necessary tools, procedures, and awareness to make this a breeze? If it won’t be a breeze, what are the complications you may foresee? Are there any strategies you can use to mitigate these complications?
  • How will you let future staff know this data exists and ensure they always have access?

Ask both the vendor and your entity…

  • Who has access to the data? Who should have access to the data? Do the two align?
    • If not, what needs to be updated (e.g., contracts, terms and conditions, training, policies, procedures, etc.)?
  • When your entity needs to destroy the data and/or record because it has met retention, how will you confirm it is actually destroyed? Should you document the destruction? If so, how will this look?
    • For state agencies and public universities, documenting destruction is required. How this look can be determined by your entity.
Forest Gump saying, "I may not be a very smart man, but I know what data integrity is..."

We hear and resonate with you. This keeping-your-heart-close-to-your-chest-and-asking-the-right-questions approach isn’t the most alluring, but trust us, it will mitigate the risk of your data falling into the wrong hands.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.