All user data stored is encrypted at rest in Amazon RDS, and we use industry standard AES-256 encryption algorithm to encrypt users data. More details at https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html
Memory uses Amazon S3 to store files like profile pictures, invoices and generated reports. The file paths are randomly generated SHA1 keys.
Data at rest in Memory that (can) contain confidential business or customer information is encrypted using industry standard AES-256 encryption algorithm.
Critical data like passwords and credit card details are never stored by Memory. We use third party tools like Stripe to store credit card details and one way hashing algorithm (Bcrypt) to store passwords.
All communication between the server and the client (browser, mobile and desktop) is encrypted by using SSL encryption (HTTPS). The SSL certificate is issued by Comodo. The web application itself is behind a firewall provided by Cloudflare with the highest security tier.
Encrypted format via AWS KMS and Ruby Lockbox:
Data stored is encrypted at rest in RDS. Only apps have credentials to read and write across the full database. Individual developers only get access to a subset of the tables for the data required to perform their tasks.
We also require a VPN account in order to remotely access our network.
We have extensive support of SAML for all of our services, including user login, provisioning and deprovisioning of users. We have complete technical documentation available upon request.
Memory will provide access privileges to authorized personnel based on the following principles:
We do not have any third-party having access to our networks. We have sub-processors who can require access to certain personal data, which is only granted when it is absolutely necessary.
We have audits enabled for all our critical services and record access logs.
Memory backs up data every day, and the backup is kept for a period of one week before it is destroyed.
The per second information that is collected via Memory app (which we call micro-entries) is backed up for a period of one week before it is destroyed.
All these micro-entries are processed instantly to generated timeline entries. Timeline entries are what users see on their timeline. These entries always have their separate backup which is permanently available until the user decides to deletes timeline entries or deletes the Timely account in entirety.
The user can be sure that the one week backup destruction applies only to the per second information that is collected via Memory app. Deletion of these micro-entries does not have any impact on timeline entries.
Timely uses AWS data centers in the EU west zone. The services and data are hosted in Amazon Web Services (AWS) facilities (eu-west-1) in the Europe (Ireland).
The SaaS application is hosted in a data center or cloud infrastructure that is Privacy Shield Certified ISO 27001 certified. Amazon Web Services ISO 27001 Compliance - Amazon Web Services (AWS)
Multi-tier web application is separated by logical layers: front-end, back-end and database. The front-end and mobile clients interact using JSON APIs with backend over SSL. The web application itself is behind a firewall provided by Cloudflare with the highest security tier. All communication between the web application and database happens over SSL with firewall configurations. Every feature or bug fix goes through a QA cycle before it is deployed for the end user, apart from the system level tests which happen in an automated way.
Our architecture is designed as per the industry standard features by using following:
We are running a multi-tenant environment and we are segmenting / separating customer data from other customers based on database table ids and querying.
We depend on McAfee Total Protection.
In Memory, we are using Snort in Network Intrusion Detection System Mode.
We have installed Snort on VPN EC2 instance to detect and prevent any malicious network activity. We are using PulledFork service to download latest rules created by Snort community. This will keep our security system up to date. We are using Logstash service to ship these logs to our Elastic Search instance. We can analyse these alerts, logs on our Kibana instance.
We follow the guidelines similar to OWASP for application development. We follow process of code review to check for any security vaulnerability fordevelopment as well deployment related code. Also we use different tools which reviews our application for any potentials risks or vulnerabilities.
In the event of a privacy/security incident, the goals of Memory AS’s Privacy/ Incident Response Team are to:
In an event of disaster our automated backups are available for 5 days.
We have monitoring and alarms set-up on AWS. In case of suspicious activity we get notified.
We will process personal data of customer's employees/representatives for our own purposes such as marketing communication, only for internal features and releases. These options can be opted out from user settings.
We will process any personal data on customer’s behalf limited to what is being asked to do.
We will use the Processed Data of the customers for:
In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.