Security at Timely

All users data

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 Encryption

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.

Sensitive data that we collect

Names and emails (to authenticate the user, enable features, prevent fraud and other app functionality)
Location data (geographic position without identifying where an individual lives, works, and sleeps)
Online identifiers (IP addresses, cookie strings)

SSL encryption (in transit and when leaving our network)

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.

App tokens

Encrypted format via AWS KMS and Ruby Lockbox:

https://aws.amazon.com/rds/features/security

https://aws.amazon.com/kms

Data at rest

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.

SAML

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.

Level of access to IT systems

Memory will provide access privileges to authorized personnel based on the following principles:

Need to know – personnel or resources will be granted access to systems that are necessary to fulfill their roles and responsibilities.
Least privilege – personnel or resources will be provided with the minimum privileges necessary to fulfill their roles and responsibilities.
Requests for personnel access privileges must be formally documented and appropriately approved by Chief Data Protection Officer.
Memory systems must only be used by authorized personnel requiring authentication; access to the passwords must be restricted to authorized administrators or application developers only.
Where possible, Memory will set user accounts to automatically expire at a pre-set date.
Access rights will be immediately disabled or removed when the user is terminated or ceases to have a legitimate reason to access Memory systems.

Third-party access

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.

Detecting and managing inappropriate or unauthorised IT activity / access attempts

We have audits enabled for all our critical services and record access logs.

Backups

Memory backs up data every day, and the backup is kept for a period of one week before it is destroyed.

Clarification:

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.

Deployment Location

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)

https://aws.amazon.com/compliance/iso-27001-faqs/

Application Architecture and Security

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:

Cryptography and encryption
Certificate creation and management
Policy management
Authentication and non-repudiation

Multi-tenancy

We are running a multi-tenant environment and we are segmenting / separating customer data from other customers based on database table ids and querying.

Anti-malware solution

We depend on McAfee Total Protection.

IDS/IPS

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.

OWASP guidelines for application development

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.

Security Incidents

In the event of a privacy/security incident, the goals of Memory AS’s Privacy/ Incident Response Team are to:

Investigate the incident internally
Mitigate potential harm to affected customers
Minimize adverse impact to Memory AS in an ethically and legally appropriate manner, to include minimizing reduction in operations, reputational harm, and/or financial harm;
Appropriately communicate the incident or loss:
To affected parties in a timely manner (as appropriate or as otherwise may be required by law);
To regulatory agencies, news media, or other entities (as appropriate or required)
To employees (as appropriate or required, especially to leadership);
Provide guidance or assistance in the development of specific corrective actions (including disciplinary actions when appropriate); and
Conduct post-incident reviews, training and education, and provide internal communications in order to minimize potential future incidents

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.

Data processing

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:

Providing the Service,
Improving or otherwise modifying the Service and notifying Data Subjects thereof,
Customizing the content and/or layout of the Service for the particular Data Subject,
Replying to the Data Subjects' communications and contacting them,
Performing Supplier's obligations towards the Data Subject,
Exercising and enforcing Supplier's rights according to the Terms of Service

Personal Data Breach

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.