TrueScheduler Security and Privacy
When connected to a 3rd party application (icloud, google cal, outlook, exchange) TrueScheduler only imports the calendar subject line, the date, time and duration in order to block the time in TrueScheduler to prevent double bookings. We do not import, store or keep any personal or identifiable information.
All 3rd party integrations are done via Oath authentication. This allows TrueScheduler to connect with 3rd party providers without seeing, collecting or storing your user names or passwords. TrueScheduler is connected via an authentication code that is provided as you connect via Oath.
TrueScheduler does not access any information within your connected calendar or email account including contacts, email address or emails. Email addresses can be used to authenticate account ownership within TrueScheduler, but we do not collect any information related to your personal data.
Data Hosting
| Azure | TrueScheduler is hosted on Azure. You can read about Azure and AWS’s thorough security provisions on their site. TrueScheduler leverages all of the platform’s built-in security, privacy and redundancy features. Azure continually monitors its data centers for risk and undergoes assessments to ensure compliance with industry standards. Azure’s data center operations have been accredited under: ISO 27001, SOC 1 and SOC 2/SSAE 16/ISAE 3402 (Previously SAS 70 Type II), PCI Level 1, FISMA Moderate and Sarbanes-Oxley (SOX). |
| AWS | TrueScheduler utilizes AWS CDN for images. TrueScheduler leverages all of the platform’s built-in security, privacy and redundancy features. AWS continually monitors its data centers for risk and undergoes assessments to ensure compliance with industry standards. AW’s data center operations have been accredited under: ISO 27001, SOC 1 and SOC 2/SSAE 16/ISAE 3402 (Previously SAS 70 Type II), PCI Level 1, FISMA Moderate and Sarbanes-Oxley (SOX). |
| Backups | TrueScheduler runs back up of all data and code base daily on redundant servers in 2 separate geographies. As well, code and data backups are hosted on Dropbox Cloud Storage. |
| Encryption | Data that passes through TrueScheduler is encrypted, both in transit and at rest. All connections from the browser to the TrueScheduler platform are encrypted in transit using TLS SHA-256 with RSA Encryption. TrueScheduler requires HTTPS for all services. For sensitive data where the original values are not needed, such as our own passwords, we hash the data using the BCrypt algorithm. Where the original values are needed, such as authentication details for accessing calendars, the values are encrypted using the AES-256-GCM algorithm using a unique, randomly generated salt for each set of sensitive data. |
| Secure transfer to servers | TrueScheduler has employed a data security service to authenticate data transfers between our development team and the virtual machines. All data is encrypted and secured. |
| Data Sharing and Third Party Access | TrueScheduler doesn’t sell customer data to anyone. We do not share data for cross channel marketing purposes. TrueScheduler does not grant access to any 3rd party provider unless through account connection via Oath authentication or API key. Both can be disconnected at anytime from within TrueScheduler or from within 3rd party application. Otherwise, there are no 3rd parties that are given data, sold data or have data shared for any reason. |
Personnel
| Background Checks | All TrueScheduler employees go through a thorough background check before hire. |
| Training | While we retain a minimal amount of customer data and limit internal access on a need-to-know basis, all employees are trained on security and data handling to ensure that they uphold our strict commitment to the privacy and security of your data. |
| Confidentiality | All employees have signed a non-disclosure agreement and confidentiality agreement before hiring. |
| Data Access On | Only authorized employees are granted access to our production infrastructure and the use of password managers to ensure strong passwords and two-factor authorization when available is mandated across the company |
Reliability
| Disaster | We have business continuity and disaster recovery plans in place that replicate our database and back up the data onto multiple cloud servers in different geographies and data centers to ensure high availability in the event of a disaster. |
| Reliability | TrueScheduler has uptime history of 99.3% |
Development Cycles
| New Features | TrueScheduler develops new features in 3 week sprints. Our deployments begin on a development server, then staging, then to live. Live server deployment occurs on Sunday morning PST. |
| QA and Testing | TrueScheduler runs automated testing along with manual testing before each deployment. |
| Dev and Staging Server QA | Before TrueScheduler is released on live servers, the code is deployed on staging and development servers during the QA process. Once the testing is complete, the code is added to a repository for live server deployment on the sprint cycle timeline. |
| Live Monitoring | Once the code is released to our production server, our QA team runs automated tests, manual test and utilizes external software to monitor our services. The external software is running 24/7 with alerts that are automatically sent to our development team with any issues. These alerts are monitored 24/7 and are sent via text message and email to our team. |
Vulnerability
| Firewall | TrueScheduler is hosted on Azure servers and is utilizing Azures Next Generation Firewall Service, which sits behind Azures Web Application Gateway service. This service includes protection against things, such as SQL Injections or malformed HTTP requests. |
| Malware and Virus Prevention | All of our employees are working from company owned machines that are running anti-malware and virus protection software. Our office server is protected by a firewall for external penetration protection. |
| Scanning | Our internal server, employee machines and data hosting continuously run vulnerability scanning software. |
Application Security
| Login credential protection | For our external applications that work with TrueScheduler, TrueScheduler does not store/collect passwords. All TrueScheduler authentication is using a secure Oath connection to grant access to TrueScheduler with a secure token used for each individual user’s account. Examples include: Zoom, Stripe, Authorize.net, Google calendar, Exchange, Office365, Outlook.com, Icloud, mailchimp and more. All 3rd part |
| Disconnecting | When an account is cancelled or downgraded to free, all Oath connections are automatically disconnected from TrueScheduler to your third party applications. |
| API Access | All access to data via TrueScheduler is explicitly approved through an OAuth authorization mechanism which grants access tokens that can be revoked at any time. |
Certifications
| GDPR | We have incorporated GDPR standards into data practices to make sure our all of our customers are supported and in compliance with GDPR. |
Security FAQ
Q. Have any significant security breaches or incidents occurred in the past 5 years?
A. No.
Q. Are privileged and generic account access tightly controlled and reviewed on a periodic basis, at least annually?
A. Yes.
Q. Are shared user accounts prohibited for employees? What about Clients?
A. Employees have their own dedicated accounts. Clients also have their own dedicated accounts, with access to their data only.
Q. Does your password construction require multiple strength requirements, i.e. strong passwords and utilizes a random sequence of alpha, numeric and special characters?
A. We require a minimum 6 characters in passwords on the basic password management level. OWASP and NIST SP 800-63-3 password policy options may be available in the coming year.
Q. Is the network boundary protected with a firewall with ingress and egress filtering?
A. Yes. All firewalls and load balancing facilities are provided by Azure and Amazon AWS.
Q. Are public facing servers in a well-defined De-Militarized Zone (DMZ)?
A. Yes, this is inherited from Azure’s default infrastructure zoning and TrueScheduler has regional servers spread throughout the world.
Q. Is internal network segmentation used to further isolate sensitive production resources such as PCI data?
A. PCI data is not stored as it is only framed by TrueScheduler from 3rd party providers such as Stripe and Authorize.net. TrueScheduler doesnt collect data or store data.
Q. Is network Intrusion Detection or Prevention implemented and monitored?
A. A broad spectrum of monitoring tools, supplemented by notifications and alerts provided by Azure remain constantly on. This includes intrusion detection and email confirmations of network access.
Q. Are all desktops protected using regularly updated virus, worm, spyware and malicious code software?
A. Yes.
Q. Are servers protected using industry hardening practices? Are the practices documented?
A. Security services are utilized regularly to provide system security audits.
Q. Is there active vendor patch management for all operating systems, network devices and applications?
A. Yes. This is provided by Azure automatically via their service.
Q. Are all production system errors and security events recorded and preserved?
A. Logs are preserved for a minimum of 1 month, with some remaining up to 6 months, depending on severity and action required.
Q. Are security events and log data regularly reviewed?
A. Yes. Logs are reviewed daily, weekly and monthly – depending upon the nature of the log events.
Q. Is there a documented privacy program in place with safeguards to ensure protection of client confidential information?
A. Yes.
Q. Is there a process in place to notify clients if any privacy breach occurs?
A. Yes.
Q. Do you store, process, transmit (i.e. “handle”) Personnally Idenfiable Information (PII)?
A. Yes.
Q. In what country or countries is PII stored?
A. Most of our PII data is stored in the US. However, we are able to store account data for our enterprise customers in a specific regional center. Example. Australian organization could elect to have their data stored in our Canberra Azure location. Or European countries can store in European data center.
Q. Are system logs protected from alteration and destruction?
A. This is provided by Azure and backed up on Dropbox Cloud Storage.
Q. Are boundary and VLAN points of entry protected by intrusion protection and detection devices that provide alerts when under attack?
A. Yes. These services are included in our Azure firewall which protects against intrusion and sends automated alerts to our development team.
Q. Are logs and events correlated with a tool providing warnings of an attack in progress?
A. Yes, our security service includes logging and alerts of attacks in real time.
Q. How is data segregated from other clients within the solution, including networking, front-ends, back-end storage and backups?
A. Every client account is logically separated from other clients, through the use of a required persistent tenant identifier on all database records.
Additionally all application code requires this tenant identifier for all operations – both read and write. An automated testing regime is also in place to protect code changes from regressions and possible cross-tenant data contamination.
The tenant identifier is “hard linked” to every user account and logically enforced through fixed “WHERE” clauses on database queries and equivalent measures for file access. A platform user is not able to change or otherwise unlink their session or account from this tenant identifier. Thus there is no logical possibility of a user having login authorization under a different tenant identifier. Even if they tried to access pages using a different tenant’s ID, the system would reject the request due to the user account not being registered to the requested tenant ID.
Q. Do you have an Incident Response Plan?
A. Yes, a “living document” is maintained which outlines disaster and incident response
checklists, contact details and key system facilities for understanding and responding to incidents.
Q. What level of network protection is implemented?
A. We utilize Azures Web Application gateway (load balancer) and Next Generation Firewall to protect our network of virtual machines running on Azure Cloud.
Q. Does the platform provide reports for Quality of Service (QOS) performance measurements (resource utilization, throughput, availability etc)?
A. Such metrics are not provided to clients, aside from availability and response timings as per our status page on status.pingdom.com
Q. Is the disaster recovery program tested at least annually?
A. Yes, recovery checks and performed and tested annually.
Q. What is the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) of the system?
A. The RTO is 4 hours, with RPO being 1 hour.
Q. Do you provide backup and restore plans for individual clients?
A. All aspects are multi-tenanted, so backups are taken across entire client base. Complete file backups are run every 24 hours and benefit from Azure database point in time backups taken every 5 minutes. Backups are stored on Dropbox Cloud as well as redundant Azure virtual machines.
Q. What is the maximum time that backups are retained?
A. Database point-in-time backups are retained for 30 days, with general file backups for 90 days minimum.
Q. What is the expected turnaround time for a data restore?
A. Any client restore in any non-disaster scenario must be requested and scheduled with us. Turnaround is between 1 and 2 business days.
Q. Can a single entity account be restored without impacting the entire platform?
A. If restoration of a specific record or artifact is required by a client, this can be performed online via a per request basis and is chargeable work. There is no impact on the platform or client account.
Q. Is High Availability provided – i. e. where one server instance becomes unavailable does another become available?
A. Multiple server instances are running at all system tiers through Azure’s virtual machine, with Web Application Gateway handling load balancing. Failure of a server instance within the data center is handled by Azure WAG, with the problem instance recycled and/or removed and replaced with a new instance.
Q. Is data stored and available in another location (data center) to meet disaster recovery requirements?
A. Yes. All data is replicated to a second data center which differs by geographic location as well as having backup data stored on Dropbox Cloud Storage. .
Q. Is the failover process an active/active, automated switchover process?
A. Failure of a server instance within the primary data center is handled by Azure WAG load balancers, with the problem instance recycle and/or removed and replaced with a new instance.
In the event that the entire data center were to have a critical failure, then switchover to the secondary center is a manual process, as we need to perform a full assessment of the issue first to ensure there is no simple workarounds to keep the existing primary center presence available. If it is determined that a move to the secondary center is required, then switchover will be initiated manually to meet the target recovery objectives.