The National Bioscience Database Center (NBDC) of the Japan Science and Technology Agency (JST) develops and operates the NBDC Human Database in accordance with the NBDC Guidelines for Human Data Sharing (hereinafter, the Data Sharing Guidelines). The “NBDC Security Guidelines for Human Data (for Data Users)” (hereinafter, the User Security Guidelines) describes the minimum requirements that should be followed in order to safely utilize controlled-access data (defined in the Data Sharing Guidelines) for the purpose of research activities, without data being leaked to outside parties.
The controlled-access data do not include identifiable personal information, but may contain data that could be used to identify individuals in combination with other information. Therefore, for each data set, the user must take the measures required for the security level (standard-level Type I or high-level Type II) set by the data submitter.
The information technology (IT) environments surrounding data users are different from one user to the next and change day by day. For this reason, just complying with the User Security Guidelines will not necessarily guarantee data security. Data users need to take additional security measures as deemed necessary while understanding their IT environments and referring to the security rules of their affiliated institution and other guidelines.  The User Security Guidelines will be reviewed appropriately in response to IT advances.
- Controlled-access data obtained from the NBDC Human Database.
- Principal investigator (PI)
- The investigator registered as the PI at the time of application for data use.
- Data user
- Organizational LAN (see Figure 1)
- The local area network (LAN) of the data user's affiliated institution. A high level of security is maintained, with external access limited to a minimum essential level (e.g., through restrictions on IP addresses and/or port numbers for communication) by a firewall managed by the network administrator.
- Controlled-access-data server (see Figure 1)
- A computer server installed at a fixed location and used for data storage and computation. When the server is connected to an organizational LAN, communication with other devices on the LAN is properly managed using firewall functions.
- Terminal (see Figure 1)
- A device that is capable of accessing data stored in the controlled-access-data server and that does not permanently save the data locally.
Figure 1: Organizational LAN, controlled-access-data server, terminals.
2.1 Basic Rules for Data Use
The controlled-access data provided by the NBDC must be used based on the following basic rules.
- Data must be saved in the controlled-access-data server connected to the organizational LAN (the server’s communication with other devices on the LAN must be properly managed using firewall functions) or in the controlled-access-data server not connected to any network. Data must not be moved outside of the controlled-access-data server.
- In cases where it is unavoidable to temporarily move data outside of the controlled-access-data server but within an organizational LAN, the data must be promptly deleted after use.
- Data must not be duplicated except for the following cases.
- Creation of a data backup
- Temporary duplication at the time of data transfer
- Temporary duplication performed by software
- Data access is limited to the data user and must be conducted solely from the terminal.
- The IT environments surrounding data users are different from one user to the next and change day by day. For this reason, just complying with the User Security Guidelines will not necessarily guarantee data security. Data users must take additional security measures as deemed necessary while understanding their IT environments and referring to the security rules of their affiliated institution and other guidelines. 
2.2 What the Principal Investigator Must Do
Data use in general
- Ensure that data users are familiar and comply with the User Security Guidelines.
- Keep a record of information regarding data users and the controlled-access-data server (including information on where relevant data are stored in the file system) in an electronic file accessible to only data users and update the record every time a change occurs. Record the update history for review.
- The data user must accept an audit conducted by the NBDC Human Data Review Board or a third party commissioned by the NBDC with regard to the state of implementation of security measures.
- Submit Form 5 (Checklist for the NBDC Security Guidelines for Human Data) to the NBDC Human Data Review Board Office at the time of application for data use and, in principle, each year in August. However, if the end of August falls within a six-month period beginning on the starting date of the data use, the submission of the form is unnecessary in that year and the form may be submitted the following August
- Use a server (including a virtual server) and file system that are dedicated to the type of data use described on the Application Form for Data Use. If the data user has no choice but to use a non-dedicated server shared with others, access to the folders containing the controlled-access data must be limited to the data user group.
- If connected to a network, the server must be connected to the organizational LAN and the following requirements must be met.
- Apply the latest security patches insofar as possible.
- Turn on at least the firewall functions provided by the operating system (OS) (e.g., iptables in Linux) and ensure that the administrator properly put restrictions on communication from the organizational LAN.
- Do not share the user ID and password for the controlled-access-data server, even among data users; create a sufficiently strong password that cannot be guessed by others.
- Do not install unnecessary software. Particularly, do not install file sharing software (also called file exchange or P2P software; e.g., Winny, BitTorrent).
- Terminate as many unnecessary processes as possible (which are launched automatically when the OS boots up).
- If data are copied to multiple servers for distributed processing or other purposes, the above five requirements must be met for these servers, too.
Also, it is desirable to use the configuration shown in the Configuration Guide (by OS) in Appendix A of dbGaP Best Practices Requirements  (Best Practice Security Requirements for dbGaP Data Recipients).
2.3 What the Data User Must Do
- When logging in to the controlled-access-data server, encrypt the communication using a sufficiently strong encryption method.
- When leaving the terminal, log out from the controlled-access-data server or lock the terminal. Configure the terminal so that the screen is locked after a certain period of inactivity (around 15 minutes).
- Do not copy data displayed on the terminal screen and save them to the local hard disk. It is preferred to use a terminal application that does not permit copying of data displayed on the terminal screen to a local disk.
- Turn off the cache function (which enables automatic saving of data on the terminal) if the function exists.
- Do not access data from a terminal application on a device that can be used by many unknown users (e.g., a PC in an Internet cafe).
- Apply the latest security patches to the terminal
- If a backup is made, one of the following requirements must be met.
- If the backup is saved in a fixed device such as a server, meet the requirements listed in the second subsection of Section 2.2 (What the Principal Investigator Must Do; Controlled-access-data server).
- If the backup is saved in a mobile device (e.g., a tape, USB drive, CD-ROM, notebook PC), encrypt the data and delete them after use. Keep a record of information regarding mobile devices in an electronic file accessible to only the data user in order to minimize the possibility of theft or loss and to enable early detection in such a security incident.
- If it is necessary to use a mobile device for temporary data transfer, handle the data in the same way as backup data.
- If it is necessary to print out data, keep the printed data out of the sight of people who are not data users. Shred the printout after use.
- After finishing data use, delete all data from all devices. Also, it is desirable to delete each temporary file that was generated during computations.
In addition to the measures listed in the previous section (Measures to Be Taken under Standard-Level (Type I) Security), the following measures must be taken with regard to the controlled-access-data server.
The controlled-access-data server must be placed in a server room that meets all of the following requirements.
- Limit access to the room, using multi-factor authentication with two of the following three authentication methods (see Special Notes on Revisions in Ver. 2.0).
- Biometric authentication (e.g., vein, fingerprint, iris, and face recognition).
- Property-based authentication (e.g., IC card, one-time password, and USB token).
- Knowledge-based authentication (e.g., password).
- Access to the room must be automatically recorded and must be available for later auditing.
- The server room must be dedicated to the type of data use described on the Application Form for Data Use. If a dedicated server room cannot be set up, the controlled-access-data server must be kept in a locked dedicated server rack.
4. Contact Information for Inquiries about the User Security Guidelines
NBDC Data Sharing Subcommittee Office
. NCBI. dbGaP Best Practices Requirements SECURITY BEST PRACTICE - Level 2b. November 8, 2008.
. Wellcome Trust Sanger Institute. HUMAN GENETICS DATA SECURITY POLICY. February 2011.
. Ministry of Health, Labour, and Welfare Iryojoho shisutemu no anzenkanri ni kansuru gaidorain (Guidelines for Security Management for Medical Information Systems) [in Japanese]. February 2010.
Special Notes on Revisions in Ver. 2.0
In Ver. 1.0, Type II security required only biometric authentication; in Ver. 2.0, either property-based or knowledge-based authentication is additionally required even when biometric authentication is performed. If a room access control system has already been installed based on Ver. 1.0, compliance with Ver. 2.0 will be required at an appropriate time (e.g., at the time of authentication device upgrade).