Many enterprises want to understand and validate security practices of companies that provide services. We have deep expertise and experience with information security practices and various regulatory controls from PCI to HITRUST. The first question we are asked is “Do you have a SOC-2?” which is an audit conducted by a trusted 3rd party to verify policies and adherence to policies.
The short answer is: NO. We have not conducted an audit because it is costly and we rather keep our prices low (See why we built Goto Tools!)
Many times, companies then instead ask their vendors such as Goto Tools to complete a security questionnaire. These have up to 500 questions such as "Do you have a password policy that requires at least 8 characters?" etc. etc..
We are happy to answer these questions, please contact us! However, we have found the vast majority of Information Security teams are content when they understand how we run our company and how we built and run our services.
We follow strong security practices and leverage managed services for anything considered sensitive. We are 100% cloud based. We use Google Workspace for all internal communications and management and Google Cloud for all our hosting. We only use Mac computers and Android or iOS mobile devices. We treat all our employees laptops as “thin” clients with nearly 100% of work conducted via a web browser. We leverage Google device management to ensure proper device settings, including encryption and remote wipe just in case something is downloaded onto a device. We also force multi-factor authorization.
Our source code and hosting: We use GitHub Enterprise for our codebase. We have fully automated CI and CD processes that include linting, error checking and continuous dependency vulnerability management.
Services are hosted on Cloud Run and App Engine and we use Cloud Datastore and CockroachDB for storage. All data is encrypted at rest and transit.
We use Google Cloud Load Balancer and Cloud Armor for policy enforcement and SSL termination. We also use SSL between GCLB and the services hosted on Cloud Run and App Engine.
Authentication: We leverage Google Cloud Identity Platform for all authentication and SSO operations. Google’s Identity Platform passes in a signed header that we validate and map to our profile database to verify entitlements.
Payments: Stripe handles all payment processing. All we do is pass usage data along with customer ID. When a new customer changes plans, they send a signed webhook request with the customer ID and the updated entitlements. We use this to update our database records. We process offline contracts via Quote and purchasing inside of HubSpot, which in turn uses Stripe for processing and settlement.
Customer data: In addition to storing customer data inside of Google cloud, we send some events that may contain customer data such as IP, geotagged location (at the city level), and email address to PostHog and Google Analytics. Some of this data will be populated in Hubspot for lead tracking and support case management. Company information is also synchronized with Stripe to enable billing matching based on our customer ID.
Shared responsibility: We have purposely kept this service streamlined as a productivity tool. We missed “go links” that we had at Google and didn’t want to pay crazy fees that other commercial offerings require. We capture minimal information and only allow users to enter the short link which is used for people to share, and the destination URL, along with the email addresses in your organization that can edit the link in the future. We do our part to secure and protect these pieces of data. However, we cannot ensure your teams do not put sensitive data into one of these fields.
If you enable public link resolution, the system will redirect users without first requiring authentication. In this case it is possible for an outside user to identify the existence of internal URLs. For example, if you make “go/crm” public and use salesforce, somebody may be able to infer you use salesforce by entering company.goto.tools/crm and notice that it issues a HTTP redirect to Salesforce. Most companies we work with have no concerns with this, but we feel it is important to at least mention this possibility.
If you have any other questions related to our security practices, please contact us.