Frequently Asked Questions – Data Management Procedures

This page is to be used in conjunction with REG 08.00.03 – Data Management Procedures and the following pages:


Table of Contents

  1. Can I store university data in G Suite?
  2. What should I do if I receive a credit card number in an email, other end-user messaging, or a shared file such as G Suite?
  3. What should I do if I need to scan a document containing a credit card number?
  4. What precautions do I need to take when scanning documents containing sensitive information?
  5. Can I store university data in DropBox?Can I put grades in DropBox?
  6. How do I protect my research data?
  7. Is encryption needed, and at what level(s)?
  8. What do I use for encryption?When do I need encryption?
  9. What happens if I don’t comply?
  10. Is there a training class?
  11. I have a data element that I think is sensitive. How do I have it added it to the DSF table?How should I protect the sensitive data?
  12. Why are Deans considered as Data Stewards?
  13. Why are distinctions made among Generic Cloud Service, Google Drive and Google Docs in assessing where sensitive data may be stored?

For further explanation of Sensitive Data Classification levels, review Data Sensitivity Levels.

1. Can I store university data in G Suite?

The following practices summarize the approach based on the Sensitive Data Classification of your data:

  • Never store purple-level data in G Suite. Purple-level data, also known as Ultra-Sensitive Data, includes:
  • If you have approval from your Data Steward AND you have encrypted your red-level data, also known as High Sensitivity Data, you may store it in G Suite.
  • If you have approval from your Data Steward, you may store yellow-level data, also known as Moderate Sensitivity Data, in G Suite.
  • You may store green-level data, also known as Standard Sensitivity Data, and white-level data, also known as Unclassified Data, in G Suite.

[Back to top]

2. What should I do if I receive a credit card number in an
email, other end-user messaging, or a shared file such as G Suite?

Unencrypted
 transmission 
of
 Ultra-Sensitive purple-level cardholder 
data
 is 
prohibited. Credit 
card 
numbers (PANs)
 and
 cardholder
 data 
are not allowed to
 be
 transmitted by end-user messaging (EUM) such as:

  • email,
  • SMS text messages,
  • voicemail,
  • instant
 messaging, 
or
  • chat.

Treat credit card numbers shared with you in G Suite the same as if you had received them via EUM. If you receive a credit card number via EUM, follow the procedure below:

  • Do not, under 
any circumstances, process 
credit
 card
 numbers 
received 
in
 EUM. Doing so—even once—could make the whole email or other messaging system subject to substantial penalty for non-compliance with PCI-DSS.
  • If you receive a credit 
card
 number via EUM, 
respond 
to 
the 
sender 
with 
a 
standard
 template 
message advising that 
the EUM 
transaction 
request cannot 
be
 processed. Either delete or redact the credit card number from the original message in your response (in other words, do not send the credit card number back to the sender).
  • In your response, refer the sender to one of the following:
    • a secure university payment processing Web page
    • other means for secure payment card processing.
  • Send an email to the Help Desk (help@ncsu.edu) and provide all of the following information. Be careful to delete or redact the credit card number from the original message when emailing the Help Desk.
    • sender’s email address
    • email address in the ‘To:’ field
    • date and time
    • subject of the email.
  • The information you provide to the Help Desk will allow OIT to redact the credit card 
information from all university logs.
  • Print the EUM containing the credit card information on a printer in a secure area and immediately retrieve it from the printer.
  • Store the hard copy in an area designated for the secure storage of documents containing credit card numbers.
  • Delete the message from your EUM message queue.

[Back to top]

3.  What should I do if I need to scan a document containing a credit card number?

Storage for scanned documents is typically not secure. If you scan a document, it may be stored in a variety of locations:

  • the scanning device itself
  • system components used to transmit the scan
  • PCs
  • files and databases using the scan.

Before scanning the document, you must redact the credit card data. Use the following techniques:

  • Physically cut out the part of the paper containing the credit card number. If you’re designing your own form, put the space for credit card information at the bottom of the form. Then when it comes time to scan, simply remove the bottom of the form before scanning.
  • Mark through the credit card number with a black marker or White-out.
  • Cover the credit card number with opaque tape.
  • After you scan, check to make sure the credit card number is still unreadable.

If you inadvertently scan a document containing a credit card number (or other Ultra-Sensitive, purple-level data):

  • Immediately inform your supervisor.
  • Open a case with Help Desk to redact the data and/or delete copies of the scan. The information provided to the Help Desk should include:
    • location of the scanner
    • computer application receiving and storing the scan
    • communications method used for transmitting the scan, if known; e.g., email, scan-to-PC, or File Transfer Protocol (FTP)
    • date and time you scanned the document
    • name, email address and phone number of the person who scanned, if known
    • name, email address and phone number of the person who discovered the incident and reported it to the Help Desk.

[Back to top]

4. What precautions do I need to take when scanning documents that contain sensitive information?

  • Many safeguards are documented in Controls for Securing University Data – Best Practices. See controls 2.2, 2.3, 2.7, 2.8, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 4.5, 4.6, 4.8, and 4.12.
  • Be aware that copiers, printers and scanners (referred to collectively as “scanners” below) may store copies of items on internal storage devices. If possible, learn how to remove or erase stored copies from your scanner. It may be possible to do this automatically after the scan is sent from the scanner. If you dispose of or transfer a scanner, make sure its internal storage is wiped clean before it leaves your department’s control.
  • Before scanning, redact sensitive information from the hard copy, if possible. Cut out the sensitive section(s) with scissors or a craft knife. You may also obscure sensitive data with a black magic marker, white-out fluid, or opaque tape. Check every scanned image to make sure the sensitive data is completely obscured.
  • Consider designing departmental forms so that sensitive data is grouped at the bottom of the form, separated with a dotted line from the rest of the form. This makes it easier to redact the sensitive data before scanning, just by cutting along the dotted line. This also means that the filed version of the cut document need not contain the sensitive data, and therefore may not need to be physically secured.
  • Before, during and after scanning, store all media containing sensitive information in secure physical conditions; e.g., behind locked doors or in a locked cabinet.
  • For scans containing sensitive data, investigate access control techniques for both the scanner device (locally stored images) and for on-line systems used to access the scans stored on IT systems. Access to the sensitive data should be limited to only those with a real need to know.
  • Consider procedures (where possible) for automatic deletion of the scanned images when they are no longer needed.

Special Considerations for Ultra Sensitive (purple-level) Data

  • Ultra Sensitive (purple-level) data (e.g., Social Security Number or credit card number) is not allowed in scanned documents (see also Question #3 above).
  • Do not scan documents without redacting the Ultra Sensitive (purple-level) data.

Special Considerations for Highly Sensitive (red-level) Data

  • You are required to encrypt scanned images that contain Highly Sensitive (red-level) data, during both transmission and storage.
  • Email attachments that contain Highly Sensitive (red-level) data must be encrypted.

Special Considerations for Moderately Sensitive (yellow-level) Data

  • You are required to encrypt scanned images that contain Moderately Sensitive (yellow-level) data; e.g., FERPA data, during transmission (e.g., via SSL or Secure FTP).
  • Encryption of stored Moderately Sensitive (yellow-level) data is optional.

Scan to Folder

  • Can send scanned image(s) to one or more of the following:
    • scanner’s hard disk
    • USB memory device on the scanner
    • network folder.
  • If the scanner is capable of encrypting images, then encrypt scans containing sensitive data before saving them to the desired folder. For example, some Minolta bizhubs have the capability to Scan to an Encrypted PDF file. The Minolta bizhub Connector for Google includes PDF encryption and can store encrypted PDFs in Google Drive folders.
  • Store images containing any sensitive data on a USB device only if the images themselves are encrypted.
  • If you’re scanning to a network folder, use secure transmission (e.g., SSL) if possible, whether the image itself is encrypted or not.

Scan to Email

  • Although some scanners can encrypt email, the university email system does not support encrypted email directly. For example, Minolta bizhubs can encrypt the email messages they send in a format known as Secure/MIME (S/MIME), but the university email system does not support S/MIME.
  • Investigate your scanner’s options for encrypting scans before they’re transmitted. If you absolutely must transmit scanned image(s) that contain sensitive data via email, first encrypt the image(s), and then attach the encrypted image(s) to an email message. For example, you might choose the option Scan to Encrypted PDF on a Minolta bizhub.
  • You may also store sensitive scans securely on a website using Scan to Folder with authenticated access. A secure link is then included in an email message. The image from the Web site  must be displayed to the reader with encrypted transmission (e.g. SSL).

[Back to top]

5. Can I store university data in DropBox?
Can I put grades in DropBox?

Do not use DropBox to store sensitive information. Student grades are educational records protected by FERPA and are therefore Moderately Sensitive (yellow-level) data. They should not be stored or synchronized using Dropbox.

Use DropBox to store only information that is not sensitive — Normal (green-level) or Unclassified (white-level) data. For additional details about appropriate use of DropBox, review IT Security under the heading Cloud Data Storage Solutions. For further explanation of data sensitivity levels, review Data Sensitivity Levels.

[Back to top]

6. How do I protect my research data?

Review specific guidelines for data management planning from the funding agency with which you are working. Several research funding agencies require or encourage the development of data management plans for research. Consider data management planning a best practice for any research project, whether or not the particular agency requires a plan. Because some funding agencies do not provide specific data management guidelines, the university provides Elements of a Data Management Plan for guidance. You may also refer to the DMP Tool as you develop your Data Management Plan.

Where and how you store and/or share research data depends on the sensitivity level of the particular data. The Data Steward and Data Custodian associated with your research project will decide where and how you may store your research data. Nominate the Data Steward and Data Custodian for the research project before submitting a grant application.

  • The Data Steward for Contracts and Grants data is the Director, Contracts and Grants in the Finance and Resource Management Division.
  • The Data Steward for college data is the Dean of the appropriate college.
  • The Data Custodian for a research project will typically be the Principal Investigator, but may be someone else, depending on where and how the data is stored.

The Data Steward and Data Custodian will construct a list of data elements being used by the particular research effort, together with their sensitivity levels and expected protection controls from the Data Sensitivity Framework.

You may not be able to share some kinds of special research data because of the nature of the records themselves or because of ethical and privacy concerns. You must treat these special research data with great care and protect them as you would red- or purple- level data.  As defined by the OMB, this special research data includes:

  • preliminary analyses
  • drafts of scientific papers
  • plans for future research
  • peer reviews
  • communications with colleagues.

The following data are associated research data but are not included in the data management plan because of more stringent compliance requirements. Research teams should consider these data to have at least red- or purple-level sensitivity. They should protect them appropriately, even though they do not appear within the purview of the sharable data in the Data Management Plan. These associated research data include:

  • trade secrets, commercial information, materials necessary to be held confidential by a researcher until they are published, or similar information which is protected under law, and
  • personnel and medical information and similar information the disclosure of which would constitute a clearly unwarranted invasion of personal privacy, such as information that could be used to identify a particular person in a research study.

[Back to top]

7. Is encryption needed and at what level(s)?

During Transmission

  • It is mandatory to use secure protocols for any transmission of Ultra Sensitive (purple-level) data (e.g., credit card numbers, Social Security numbers) or Highly Sensitive (red-level) data over open public networks such as the Internet.
  • Encryption of Moderately Sensitive (yellow-level) data during transmission is recommended.

Full-disk encryption

  • If you are storing Ultra Sensitive (purple-level) data (e.g., credit card numbers, Social Security numbers) or Highly Sensitive (red-level) data on the disk, then full disk encryption is mandatory.
  • If you’re storing Moderately Sensitive (yellow-level) data on the disk, full disk encryption is recommended.
  • NOTE: Full-disk encryption tools encrypt only at the system and drive-level, not at the file level. So full-disk encryption protects your data only in the event that the drive itself in your laptop, mobile device, or USB drive is lost or stolen. Once the disk or drive has been mounted normally on your computer system with authorized permission (e.g., password, valid digital certificate), further access to the data on the drive by applications on your computer is not encrypted.

Data File Encryption

  • If there are Ultra Sensitive (purple-level) data (e.g., credit card numbers, Social Security numbers) in the file, encryption is mandatory.
  • If there are Highly Sensitive (red-level) data in the file, encryption is recommended.
  • If there are Moderately Sensitive (yellow-level) data in the file, encryption is optional.
    • If you need to encrypt one or more files of any file type, you may group them together in a file folder before encrypting and compressing them using the 7Zip tool.
    • Tools such as Microsoft Office products (e.g., Word, Excel) and Adobe Acrobat provide the ability to encrypt individual files as you are saving them.
    • These tools (and other encryption tools you use) must provide for AES encryption at the 128-bit or 256-bit level.

Database encryption

  • If database fields are classified at the Ultra Sensitive (purple) level, encryption is mandatory.
  • If database fields are classified at the Highly Sensitive (red) level, encryption is recommended.
  • If database fields are classified at the Moderately Sensitive (yellow) levels, encryption is optional.

Email

NOTE: The university does not have the capability to encrypt data in the email body.

  • Do not send Ultra Sensitive (purple-level) data in the body or attachment of an email message.
  • Do not send Highly Sensitive (red-level) data in the body of an email message.
  • If you first manually encrypt a file containing Highly sensitive (red)-level data, and you have received approval from a Data Steward for this specific application transmission use, then you may attach that file to an email message and send the encrypted attachment via email.
    • Use the 7Zip tool to encrypt one or more files of any file type and group them together into a single compressed file before attaching the compressed file to an email message.
    • Tools such as Microsoft Office products (e.g., Word, Excel) and Adobe Acrobat provide the ability to encrypt files in formats they support as you are saving them.
    • These tools use AES encryption at the 256-bit level. Other tools that encrypt to this level are also satisfactory.
  • Encrypting Moderately Sensitive (yellow-level) data sent by email is optional.

Backup Copies

  • If there are any Ultra Sensitive (purple-level) data (e.g., credit card numbers, Social Security numbers) in the backup copy, encryption is mandatory.
  • If there are any Highly Sensitive (red-level) data in the backup copy, encryption is recommended.
  • If there are any Moderately Sensitive (yellow-level) data in the backup copy, encryption is optional.

Network Drives

  • If you are storing any Ultra Sensitive (purple-level) data (e.g., credit card numbers, Social Security numbers) on a network drive, encryption is mandatory.
  • If you’re storing any Highly Sensitive (red-level) or Moderately Sensitive (yellow-level) data on a network drive, encryption is optional.

[Back to top]

8. What do I use for encryption?
When do I need encryption?

As of the publication date of the Data Sensitivity Framework, the controls requiring encryption in the Data Sensitivity Framework should be considered as best practices for the university rather than compliance standards. They will become university compliance standards effective June 30th, 2014. In the meantime we will publish additional how-to and when-to documentation and provide education courses to assist you in getting your most sensitive data encrypted.

[Back to top]

9. What happens if I don’t comply?

  • There are serious consequences for university community members who violate REG 08.00.03 – Data Management Procedures:
    • For students, violations constitute “misconduct” under POL 11.35.01 – Code of Student Conduct.
    • For EPA or EPA non-faculty personnel, violations are subject to disciplinary action according to EHRA Discipline, up to and including dismissal.
    • For SPA personnel, violations are considered “unacceptable personal conduct” and subject to disciplinary action according to SHRA Discipline, up to and including dismissal.
  • If you violate state or federal law or the terms of a contract, you may also face criminal or civil prosecution.

[Back to top]

10. Is there a training class?

OIT-OCC will develop awareness training to coincide with publication of the Data Sensitivity Framework.

[Back to top]

11. I have a data element that I think is sensitive. How do I have it added it to the DSF table?
How should I protect the sensitive data?

Consult the table titled Table of data categories, trustees, stewards, and custodians to identify the Data Steward  in your area of responsibility. Ask the Data Steward what level of protection the data element in question requires. Discuss with the Data Steward what controls you need to apply to the data element. OIT Security and Compliance personnel can provide assistance and guidance. Your Data Steward may need to discuss the sensitivity level with other Data Stewards whose data categories also contain that element before establishing the permanent Data Classification Level (purple, red, yellow, green, or white) for the requested data element.

[Back to top]

12. Why are Deans considered as Data Stewards?

The provost, as the Data Trustee, is ultimately responsible for college and department data. Authority for university data next flows to the deans, as Data Stewards, who are responsible for the authorized use of university data in their colleges and departments. The scope of a Data Steward’s responsibility at the college level includes all of the following:

  • copies of OIT administrative data made specifically for use by internal college/department applications by the relevant university-wide administrative Data Stewards
  • data collected and/or stored and/or used within internal college/department applications
  • data collected, and/or stored, and/or used for research purposes by colleges and departments.

Deans may delegate data stewardship to designee(s) who have both business responsibility for any risk to the data and conceptual understanding of the need for IT protection. Deans (or designees) should identify all Data Custodians–typically college IT directors–for all college- or department-specific sensitive data. For data stored on individual laptops, workstations and servers, the Data Custodian is the individual maintaining these devices; e.g., the principal investigator for certain research data.

NOTE: It is critical that Data Custodians coordinate sensitive data protection with both college/department IT staff and OIT Security & Compliance staff. If OIT makes copies of administrative data specifically for use by internal college/department applications, the copies must not be used outside the scope of use approved by the overall university admistriative Data Steward.

[Back to top]

13. Why are distinctions made among Generic Cloud Service, Google Drive and Google Docs in assessing where sensitive data may be stored?

The document Storage Locations for University Data distinguishes among three storage locations that may appear at first to be subsets or overlapping each other. The following information is provided to clarify the distinctions among these categories and explain why they have differing assessments.

generic cloud service may be any one of a variety of Internet applications. A few examples are:

  • file storage service such as Google Drive or DropBox
  • photo-sharing service such as Flickr
  • social networking services such as Facebook or LinkedIn
  • generic Internet application used by the university such as Maxient’s Student Conduct implementation.

The scope of Cloud Services includes:

  • Platform as a Service (PaaS),
  • Infrastructure as a Service (IaaS) and
  • Software as a Service (SaaS).

If you wish to use a generic cloud service for any university purpose, then you must take due care to protect sensitive university data stored in such a service. Purchasing and the Office of General Counsel (OGC) will need to review and negotiate the contract provisions with the relevant cloud service provider. In addition, OIT Security and Compliance must perform a security assessment of the application., which allows for “due diligence” investigation of the security controls appropriate for the sensitivity level of the university data to be stored there. Thus, the table entries in Storage Locations for University Data indicate that sensitive university data (purple, red or yellow) should not be stored within generic cloud services unless:

  • The Data Steward approves, and
  • OGC and OIT Security & Compliance have evaluated and approved.

Purple data, in particular, should generally not be stored within a generic cloud service at all. If it is paramount that purple data be stored within such a service, then the data must be encrypted during transmission and before it is stored within the service. Additional very stringent controls will be needed for the storage of any purple data within a generic cloud service, and cloud services are not generally recommended for transmission, processing or storage of any purple data, either encrypted or in clear-text.

Google Drive is a specific cloud storage (IaaS) service. The NC State Google Drive implementation provides university file storage space on virtual drives at Google.

  • Yellow data on Google Drive
    If, for example, sensitive FERPA (yellow) data will be stored on Google Drive, then the university’s contract allows Google to act as the university’s agent in processing and storing that data. This approach is contractually sound and compliant with FERPA. Thus, you may store yellow FERPA data on Google Drive, unless both your Data Steward and OIT Security & Compliance believe there should be stronger controls on that particular yellow data when it is uploaded to or stored within Google Drive. Generally, for FERPA compliance reasons, the relevant user (faculty or staff) of the specific FERPA data elements should obtain individual student approval in writing before storing any of the student’s specific FERPA data on Google Drive.
  • Red data on Google Drive
    Because data stored within Google Drive is encrypted by Google, the university allows red data to be stored on Google Drive.
  • Purple data on Google Drive
    However, the controls and risks associated with storing purple data in files on Google Drive meet neither the compliance requirements of PCI-DSS credit card security nor, for example, US Government Export Control provisions.  With very few, highly-controlled, suitably-approved exceptions (e.g., password synchronization), purple data must not be stored on any Google facility.

Google Docs is a set of SaaS applications using Google native file formats. Google Docs is unsuitable, therefore unapproved, for purple data. However, other data classification up to red is allowed to be processed and stored within Google Docs on Google Drive (see above). 

[Back to top]