Last updated September 6, 2016
Your company's work day is valuable. Here's how Robin keeps it safe.
Need something to share? Download Whitepaper
The diagram below will give you the fastest overview of Robin's service architecture. Click the image to view a larger version.
Robin is a cloud service, and hosted by data centers with the highest level of certifications including ISO 27001 and SOC. For more compliance information, you can visit AWS Security and AWS Compliance.
All application servers are based in the US, but may be accessed internationally via the internet.
We constantly monitor our service performance and have automatic notifications to ensure rapid response for service interruptions. All code is audited and peer reviewed before deploying to production servers. We also monitor updates from the security community and immediately update our systems when vulnerabilities are discovered. When we do have issues reported, we keep an updated system status here.
New features, performance improvements, and bugfixes are deployed multiple times per week. While agile, our development cycle relies heavily on a strict system for code quality and security. All code is peer reviewed, and requires multiple levels of acceptance on test/staging environments prior to deployment on production. Key highlights for common questions:
We maintain automatic access and security logs in multiple locations. All employees are required to use two-factor authentication and strong passwords that are unique from other services. Customer data access is limited, and is allowed only to a small set of employees as required for support and maintenance. Access is further limited to a small whitelist of IP addresses, and require public key authentication.
Individual employee access follows a principle of least access, and access rights are reviewed quarterly.
Password authentication is available by default, and validated by entropy to restrict weak passwords. Robin also supports Single Sign-On through SAML 2.0, Google SSO, and ADFS (via SAML). Users registered through SSO use JIT provisioning. SCIM 2.0 support for automatic deprovisioning is in development and planned for late 2016.
Customer data is encrypted when in-transit and at rest. All connections with Robin's services are encrypted and served through SSL. You cannot access the service without using HTTPS. All certificates are verified on both sides with third party authorities. Data is encrypted every step of the way:
When at rest, customer data is encrypted using a key management system which logs all access automatically. Additionally, passwords are both hashed and salted using one-way encryption, which protect them even in the unlikely event of unauthorized database access. Application credentials are stored separate from the code base. Clients authenticate with Robin using a token system. Each token has specific access scopes, which can be individually revoked without impacting others on the platform.
Servers are patched regularly to maintain a top security rating. Vulnerabilities are tracked via a combination of automated mailing lists and proactive interal audits completed on production machines weekly.
Our engineering team actively contributes to security libraries, including an open source library of Microsoft's NTLM encryption used for secure Exchange authentication.
When you sign up for a paid subscription, we do not store your credit card information on our servers. We currently use Stripe, which is PCI-Compliant and dedicated to safely storing sensitive payment data. You can find a copy of their security practices here.
We do not store any data with regulatory requirements, such as HIPAA or PCI
Robin's public-facing web service uses the following IP addresses for calendar connection and webhooks. If you host your calendar server on-premise (e.g. Exchange), add these addresses to your firewall's incoming connection whitelist. This will make sure Robin is able to connect.
For additional verification, you can also match user agents containing RobinAPI, which will appear similar to RobinAPI/123456 in the request headers
For networks that whitelist ongoing connections, you can verify against our DNS (e.g. *.robinpowered.com) which is signed via DNSSEC. DNSSEC removes the need for specific IP address range since the DNS record itself is secured and can be validated with third party authorities similar to an SSL certificate. You can confirm using this tool from Verisign.
Once an external calendar account is connected to Robin, our cloud service will begin to synchronize data with the designated room calendars. In doing so, a subset of your calendar events and their details will be saved in Robin.
Robin will then keep this data in sync with your calendar system. Events booked through Robin will similarly synchronize the data back to your calendar service, so that Robin and connected calendars stay consistent. Synced event details include:
We do not store event attachments. You can learn more about our specific connection practices by service (e.g. Exchange) in our help center.
Application and customer data is stored redundantly at multiple availability zones within Amazon's data centers. Customer data and application source code are automatically backed up daily. Backups are retained for 30 days to recover in the event of a disaster.
In the event of a security breach, our team will promptly notify you of unauthorized access to your data. Service availability incidents are published to our status page with additional information. See an example incident report.
All employees are governed by documented strict security policies covering acceptable use, customer data, and encryption standards. If you would like to request a copy of these policies, please contact your account manager.
If you believe you've found a security vulnerability while using Robin, we'd also like to hear from you. Fixing problems quickly and responsibly is incredibly important to us.
Need something to share? Download Whitepaper
September 6, 2016: Expanded details on encryption and policy docs
April 12, 2016: DNSSEC and application development section
November 24, 2015: Service IP addresses for whitelists
November 8, 2015: Network architecture diagram
Oct 16, 2015: Additional information about data collection
May 13, 2015: Initial draft published
Join the thousands of company schedules powered by RobinStart your two week free trial