When an alumnus user registers the following fields are stored in Vuture whilst approval is pending: 

• Email Address 
• First Name 
• Last Name 

When the user is approved the following fields are synced from the CRM or Contacts Module to Vuture daily (this can be varied) so that the directory search does not have to query the CRM or Contacts Module each time. You can specify what these fields are, but the standards fields are:

• Email Address 
• First Name 
• Last Name 
• CRM Contact ID (if applicable)
• Years at Business 
• Current Staff or Alumni 
• Any other IA fields you choose to include in the directory search 

Any non-CRM fields you choose to create are also stored in Vuture. Only the photo is standard.

• Photo 
• Any Vuture-only fields that you create 

Data in Transit

• Web pages rendered from Vuture pull data from your CRM or the Vuture Contacts Module via your existing secure connection. This uses HTTPS calls (locked down by IP from your Vuture Server IP) to the CRM or Contacts Module web client using the Vuture system IA account. 
• These pages are served from your Vuture application server and are not cached. They are protected in transit by TLS and on the web server through an HTTPS browser connection. The connection from Vuture to your CRM or Contacts Module is secured by TLS and the passwords are encrypted.  

User Records

• If a user opts out of the Alumni program using the system, then their data is removed from Vuture 
• Currently if a user is removed from the CRM Alumni folder they also need to be deleted in Vuture for all their data to be removed. 

Data Encryption

• Data in the Vuture Cloud on Rackspace servers is encrypted. 
• 256 bit SSL security certificates are used to provide bank-level data security, encrypting all data between the internet and application servers 
• Authentication credentials are stored using salted SHA-512 - the salt is random and 36 characters in length 
• Sensitive data elements are encrypted in storage using strong cryptography with associated key-management processes and procedures. 

• Each client gets their own separate SQL Server database. We use a product called NetLib Encryptionizer to encrypt the data at rest with its own encryption key which is stored securely in a Key Vault. Anyone who got access to the SQL Server database file would only see unreadable encrypted data. 

• Cryptographic keys are distributed to the fewest number of custodians necessary 
• Cryptographic keys are stored securely and in the fewest possible locations and forms 
• Key management processes and procedures are documented and implemented including: 
  • The generation of strong keys, 
  • Secure key distribution and storage 
  • Periodic changing of keys 
  • Retirement or replacement of old or suspected compromised keys 
  • Split knowledge and establishment of dual control of cryptographic keys 

See the Information Security page for general information

Typical Network Configuration with Standalone or Contacts Module

Typical Network Configuration with a CRM