Privacy and Security Procedures
Nicolas
Last Update 2 years ago
1. General
1.1. Description of the service that Letsmeet provides.
Letsmeet is a SAAS to help employees plan their meetings. It is a scheduling tool replacing the back-and-forth emails with one single email. The value proposal is simple : one email = one meeting scheduled whatever the number of participants, and wherever they are. It is optimized for Google Workspace and Microsoft, you can invite an unlimited number of guests, both internal and external, and it offers numerous relevant features.
1.2. Description of the information accessed by Letsmeet in order to perform the services.
For any users who register to Letsmeet, we will have access to their name, email address and calendar content. Only Email address and name will be stored whereas calendar content is fetched on demand—we act as a proxy between the user and their calendar.
1.3. Storage format.
Name and email address will be stored in an electronic way, in our database, a Postgresql database on Amazon Web Services RDS, fully managed by Amazon, protected by AWS Console default security policies.
1.4. Storage location.
Our database is located in AWS eu-west-3 region (Europe/Paris).
1.5. Source of information.
We will receive information from calendar providers (Microsoft Office 365 or Google ) upon company users consent. This consent is fully managed by Microsoft or Google online services. Multi-factor and other security mechanisms automatically apply as defined in the provider's admin policies.
1.6. Background check on Letsmeet team.
Core team have been working together for more than 10 years, across multiple start ups and are all co-founders.
Due diligences were done during the recruitment process
1.7. Confidentiality and profile.
NDA is integrated in Letsmeet employees work contract.
Our users’ info can be accessed using our analytics SAAS tool, Amplitude—amplitude.com.
Only 3 tech team members can access our Database on AWS RDS.
2. Privacy
2.1. Policies.
Please find our Privacy Policy here: https://web.letsmeet.network/r/tc
Privacy Policy is reviewed each time we deploy product features that might impact the privacy of our end users. It is reviewed directly by the CEO of the company and if relevant with the contribution of a legal adviser.
2.2. Chief Privacy Officer.
Gilles Raymond is acting as Chief Privacy Officer.
His email address is gilles@letsmeet.network. Mobile : +1 415 596 2486
2.3. Training about Privacy.
Privacy policies are presented in the welcome pack to all employees.
https://web.letsmeet.network/r/tc
The manager of the new employee provides the training on their first day.
2.4. Procedure for responding to a breach of information.
Steps:
- Bring co-founders together to share info (3 tech persons + CEO) and a legal person.
- Contain: reset passwords, patch, temporarily turn down the service if relevant.
- Dig: assess the severity of the breach: who is impacted, how critical is the breach.
- Notify: Notify victims of the breach explaining the consequences and possible actions to take.
- Prevent: prevent this from happening again.
In case of Customer users calendar access being compromised, Customer IT admin will be able to revoke permissions given to Letsmeet. The procedure is well documented by Microsoft and instantaneous.
2.5. Procedure for violation of privacy rules.
The CEO and CTO of the company are informed. An assessment of the situation, risk, and damages is performed.
Information about the violation, the needed changes, their implementation, the potential sanctions is shared with the team.
2.6. Disclose information to third party.
Our analytics solution, Amplitude (amplitude.com) will hold the names and email addresses of our users. Customer.io, our email platform will also.
3. Security
3.1. Policies and general practices.
We follow best practice in terms of security (password manager, IP based access control etc.)
3.2. Security Officer.
Our CTO Mathieu Leddet mathieu@letsmeet.network, mobile +33 625 487 394
The platform is accessible to only the 3 persons that took part in the development of service.
3.3. Procedure for violation of security rules.
The CEO and CTO of the company is informed. An assessment of the situation, risk, and damages is performed.
Information about the violation, the needed changes, their implementation, the potential sanctions is shared with the team.
4. Information storage, management, and environmental security
4.1. Service that stores and processes data.
- Our platform running our software is hosted on AWS. We use EC2 instances as well as RDS for Database management and S3 for file storage. The physical location is in France.
- Our analytics solution is Amplitude and this data is stored in the US—on AWS as well.
- We also use Customer.io as a marketing email platform and their data is located in the US.
4.2. Control to secure the physical location.
The security of these physical locations where data is stored are managed by our partners.
4.3. Information and/or systems classification to ensure segregation between customers’ systems/information.
In our platform database, email addresses and Calendar account ID ensure unicity in a table dedicated to storing email addresses and names. Access to this information is bound to the provider’s authentication method without which Letsmeet cannot “serve” this information.
In other words, access to Customer information is protected by Microsoft Office 365 authentication mechanism or Google Workspace
4.4. Encryption key lengths and algorithms.
AWS encryption for RDS is enabled. Quote: “Data that is encrypted at rest includes the underlying storage for DB instances, its automated backups, read replicas, and snapshots. Amazon RDS encrypted DB instances use the industry standard AES-256 encryption algorithm to encrypt your data on the server that hosts your Amazon RDS DB instances.”
4.5. Transport protocols and encryption technologies to encrypt Customer information transmitted across the Internet.
HTTPS everywhere. Certificate managed by AWS.
4.6. Cryptographic keys.
Life cycle of the cryptographic keys is handled by AWS.
4.7. Procedure for regular changes.
Here is our procedure for a regular change made to production:
- Implementation is made including unit testing ensuring an overall good code coverage (80% minimum)
- Manual testing is performed in local environment by the developer
- The new software is then deployed on our staging platform which is a copy of the production environment without the production data.
- Product team performs on staging manual end-to-end testing to ensure no regression was introduced and that the feature works as expected following the initial acceptance criteria.
- The system remains 1 week on the staging platform.
- Once the version of the software has been validated, it is deployed on production.
- Once the deployment to production is made, one tech team member monitors the logs as well as in the analytics to ensure the software behaves as expected. Integrity of the data in the database is also checked for newly defined tables for instance. Post-production verifications mostly depend on the nature of the change.
Notes:
- All changes to the platform are made under CTO’s supervision.
- We use continuous integration (Gitlab CI/CD) for running tests and deployment through pipelines.
4.8. Procedure for emergency changes.
- Product team is not involved.
- As soon as the patched version is validated on staging the deployment to production can occur.
- It can take no longer than 30 minutes from the time the patch version is committed in Git by the developer to the time it’s live on the production platform.
4.9. Decision process before change.
Every change is discussed with all three tech members, including the CTO.
We use Ansible scripts for architecture changes and these scripts are version controlled on Gitlab. This would allow us to recreate a new platform in case of disaster in less time than having to do it manually.
5. Security patches, anti-virus software, and audit trails
5.1. Anti-virus programs.
This part is fully managed by AWS EC2 image. We follow AWS security advice and upgrade EC2 images when necessary.
5.2. Logs.
Logs are retained on our EC2 instance as text files and have a rolling configuration of 8 days.
5.3. Vulnerability.
This part is fully managed by AWS EC2 image. We follow AWS security advice and upgrade EC2 images when necessary.
6. Access control questions
6.1. Access.
The database can only be accessed from declared IP addresses and we use a password manager (Keepass) to store the credentials.
When a tech team member needs to connect and access the users’ database, they must ask the CTO to declare their IP address in the security rules in AWS so they can connect.
6.2. Access Revocation.
If a privileged user access was to be revoked here would be the process:
- Remove IP from security groups to access the database
- Change password manager password
- Update all passwords stored in the password manager
6.3. Monitoring.
We use a probe external to AWS to check DB is up and running to detect outage and overload. We also plan to start using an AWS GuardDuty detector on RDS.
We allow only our IP addresses for remote access, the rest is managed by AWS default security policy.
6.4. Self Revocation.
Customers can at any time:
- Have access to the data is today possible by a simple email to privacyfirst@letsme.et.
- Delete completely the customer's account and data through a request by email to privacyfirst@letsme.et.