Transport Security Clause Samples
The Transport Security clause establishes requirements for safeguarding goods, data, or personnel during transit. It typically outlines the security measures that must be implemented, such as secure packaging, use of vetted carriers, or encryption of data transmitted over networks. By setting these standards, the clause aims to prevent loss, theft, or unauthorized access during transportation, thereby reducing risk and ensuring the integrity and confidentiality of the items or information being transported.
Transport Security. Each Participant’s security policy shall include written policies and procedures to ensure a secure channel for communications between Participants and QHINs and between Participants and Participant Members.
Transport Security. Entry control
Transport Security. Each QHIN’s security policy shall include written policies and procedures consistent with the technical requirements specified in the QHIN Technical Framework to ensure a secure channel for communications between QHINs and between QHINs and Participants.
Transport Security. Famly utilizes end-to-end SSL encryption from end-user devices all the way to the database in the Data Centres as well as between internal services on the servers in the Data Centres. Full documentation of data management and maintenance must be maintained. Measures for subsequent checking whether data have been entered, changed or removed (deleted), and by whom: ● Any access to Personal Data related to the use of the Famly Platform is automatically logged in the Application Log. By logging the time, username, type of application and the person that the data is concerning, or the used search criteria is registered. The log is kept for a minimum of six months and is deleted after a maximum of seven months. ● The Customer can gain access to specific information from the Application Log by special request to Famly. ● Provided that access to the Famly Platform is made in connection with technical issues e.g. support, error correction or other technical causes, such access will be logged in the Application Log.
Transport Security. ☐ none ☐ Basic128 ☐ Basic256 ☐ Basic256SHA256 ☐ Selfsigned ☐ Chained CAs
Transport Security. Biohazardous materials must be secured during transport from unauthorized access or theft and not left unattended in unlocked vehicles. A chain-of-custody should be established when shipping biohazardous materials, for example, using a courier service.
Transport Security. (i) Data carriers are removed from the data centre only if they cease to be functional;
(ii) Otherwise, data carriers for transport purposes are always carried on the respective person and are demagnetised and disposed of immediately.
Transport Security. The <TransportSecurity> tag provides the security specifications for the transport layer of the TPA. It may be omitted if transport security will not be used for this TPA. Unless otherwise specified below, transport security applies to messages in both directions. For each party which is represented by a role parameter in a prototype TPA, the corresponding tags under <Party> and <LogonParty> must be given values when the role parameter is replaced by an actual name. Transport security may be either encryption or authentication. Both encryption and authentication may be used in the same TPA, especially if authentication is by userid and password. Authentication verifies the sender of the message. Encryption prevents the message from being read by unauthorized parties but by itself performs no authentication or nonrepudiation For encryption, the protocol and protocol version (optional) must be supplied by the appropriate tags. Examples of encryption protocols are RC2, RC5, and RC6. Only certificate-based encryption is defined. For authentication, the authentication type must be specified with the <PasswordAuthen> or <CertificateAuthen> tag. The protocol (e.g. SSL), protocol version (optional), and certificate parameters or optional starting userid and password must be specified. A public key certificate must be supplied for each party (except as specified below). Authentication is bi-directional if each party has to authenticate to the other during a given message exchange. The alternative is that the client authenticates to the server but not vice- versa. In most cases, the choice is determined by other factors. If SSL Ver. 3 is specified for encryption, authentication is always bi-directional. If the authentication type is PASSWORD, the client authenticates to the server. If the authentication type is CERTIFICATE, the authentication could be bi-directional or not. For the purpose of this TPA, it is defined as bi-directional unless otherwise specified below. It should be understood that in a TPA in which each party can act as either a server or a client for different actions, the security definitions must enable each party to authenticate to the other, though not necessarily in the same message exchange. The <Certificate> tag provides the parameters needed to define the certificates. The <CertType> tag identifies the type of certificate. Examples are X.509V1, X.509V2, and X.509V3. The <KeyLength> tag gives the key length in bits (e.g. 512). All parties must...