1. Imaginate takes utmost care to protect a user's information through various measures. These have been explained below:
   1. Personally-identifiable information:
      1. User Account:
         1. When a user logs in via SSO/AD, only his email ID is stored by Imaginate. An API which connects to the client authenticates this user.
         2. If a user account is created directly from the Imaginate web dashboard, a user email ID + first name + last name are needed. Since these are manually filled in by a user at the time of user/account creation, information that may not necessarily be classified under PII can be used.
         3. Manual password creation - If a user manually creates an account, he must also manually set his password. For this, we have a stringent password-setting process at the time of the first login on the dashboard:
            1. Password must be at least 8 characters long
            2. Password must have at least one capital letter
            3. Password must have at least one special character
            4. Password must have at least one number
            5. Password cannot have a 'space'
            6. There are checks to validate the strength (low, medium, strong) of a user-set password
      2. Other Non-Public Data
         1. At the time of collecting information related to analytics for training modules, the device that a user joins from, his IP address and his latitude and longitude is (currently) captured. But this is OPTIONAL. If we choose NOT to capture this information, it will not be saved/captured.
         2. Data related to 3D objects, environments, images/videos are stored in Azure (cloud service using either Imaginate's credentials or the client's Azure information - in both cases, complete data security is maintained when accessing Azure through a 'secret key')
   2. Masking of Data
      1. Since user account creation takes in only bare minimum fields, it is not masked.
      2. In the case where SSO is used, the API call to the client system entails use of an access token which is secure and unique only to this client.
      3. We use PBKDF2 technique as described above for where ever this occurs in our code base.
   3. Third party data connectors used:
      1. Wolf 3D - this is used for realtime generation of avatars and uses ONLY a passport photograph of the user. Using Wolf 3D avatars is not mandatory and a user can choose to use a 'generic' avatar on our Atom app, if he DOES NOT wish to share a photograph.
      2. Avatar SDK - this is used for realtime generation of avatars and uses ONLY a passport photograph of the user. Using Avatar SDK for avatars is not mandatory and a user can choose to use a 'generic' avatar on our Atom app, if he DOES NOT wish to share a photograph.
      3. Clevertap
         1. this takes the email ID of a user (as mentioned above)
         2. this also consumes device information (such as IP, device type, latitude and longitude) and can be OMITTED from being captured.
         3. Since the connection to CleverTap is managed through an access code, it is highly secure
      4. CAD model upload capabilities - does not use any PII
2. Encryption Standards - all password fields or fields requiring an additional level of security are stored using MD5 hashing algorithm and we are currently in the process of upgrading to SHA256.