After a user gives Topicflow permission to access their Google or Microsoft calendar, we will periodically fetch event data from the calendar. We store information such as the title and time of an event in our database, so that we can present that information in the Topicflow user interface.
We only fetch events 60 days into the future, and if an event is not used in Topicflow (if no topics are added to the meeting agenda), we delete all information about the event from our database after 30 days.
A user may request that their information or events are deleted from our database at any time. Before doing so, they are able to export their data in order to retain it themselves.
Topicflow does not store any usernames or passwords, as we only support SSO-based authentication with Google or Microsoft. Users may choose to use multi-factor authentication with their Google/Microsoft account for added security.
Topicflow sessions are limited to a reasonable length of time, so that users must periodically re-authenticate.
Topicflow has a data permission system in which user data is strictly segregated according to a set of rules. This ensures that user data remains private and is seen only by the minimum set of users that is necessary.
Our databases are backed up daily, and backups are retained for 30 days. We practice the database recovery process at least once a year, to ensure that our disaster recovery procedures are working.
Topicflow servers are all hosted with AWS, currently in US-based datacenters. AWS has multiple security certifications in place, such as SOC2. Our AWS-hosted servers are contained within virtual private networks, and all administrative access to the servers themselves requires a secure VPN connection. Access to AWS requires multi-factor authentication. We capture audit logs from AWS to an external logging system. Our infrastructure is defined using an IaC (Infrastructure as Code) tool, to ensure that all changes are logged and that the infrastructure can be reproduced as needed.
All communication between our internal services and between users and our services is encrypted using TLS. All data at rest is encrypted using AES-256 encryption.
Topicflow has disaster recovery plans in place for a variety of scenarios. We practice our responses to these scenarios regularly. We also have an incident response plan to help us respond to incidents in a timely and organized manner.
Our AWS services are hosted across multiple availability zones, to minimize the chance of downtime if AWS experiences issues. Although our services are currently hosted in a single AWS region, our provisioning is highly automated and we are able to restart the service in a different region quickly.
Our development team follows secure software development best practices such as code reviews and an automated test suite that is run before every change to our production servers.
We run third party penetration tests at least yearly, and quickly remediate any vulnerabilities that are found.
We utilize services (primarily Github Dependabot) that continously monitor for vulnerabilities in the software libraries and dependencies that we use, and upgrade libraries as necessary. Our policy is to only use dependencies that are actively maintained and well trusted.
We also utilize static code scanning tools to continously monitor our application code for potential vulnerabilities.
Our servers are fully managed by AWS, who ensure that they remain up to date with all patches, etc..
All Topicflow employees and contractors sign a confidentiality agreement. Employees are trained on data access procedures, and will only access customer information when requested by the customer. Access to customer information is logged and monitored.
All new Topicflow employees undergo criminal background checks and reference checks before beginning their employment.