Table of Contents
Updated by Jessica Powell
Convictional is committed to the security of our services.
If you have any questions, please email: email@example.com.
Updated: July 2020
In the event of a change to our security policy, you will only be notified if something here is removed or materially changed. If a minor change occurs involving our approach to security, or something is added, it will made added to this document but you will not be explicitly notified. Every time we change this document we will update the updated date above to reflect that changes have been made. If you have any questions, contact support.
HTTPS & Data Transit
Access to Convictional is encrypted in transit using SSL. This includes the app, database, requests and responses from our API, our support and API documentation, our website and our email communications. Many Convictional services are not exposed to the internet, only our API, documentation and app are exposed. When we connect with third-party services on your behalf, we always force encrypted connections with API endpoints. We have automated security checks in place that would alert us to the introduction of unsafe code, connecting to our own or third-party services using unencrypted HTTP requests. This means that all data transit to and from Convictional is encrypted while in transit, and will remain that way.
We attempt to follow security best practice with respect to sensitive credentials and system access provisioning. We provide the minimum usable access levels to staff accessing sensitive system data. Our database credentials and other sensitive access credentials are stored within a key management system (KMS). The KMS means that no one outside of two trusted security officers within the company are able to access sensitive credentials, including all other Convictional employees without security clearance. All our internal services use Google IAP to protect access to backend services not exposed to the internet. We require 2-factor authentication via security key or TOTP code to be used on user accounts. We require staff login to third-party web services using Google SSO which itself requires 2 factor authentication in order to access your account. This means that Convictional is protecting access to your data both from within Convictional and from any entity outside of Convictional.
We follow modern best practices for code change management. These best practices include, but are not necessarily limited to the following:
- Prior to each change being introduced into our code base, it runs through a series of automated tests
- Our automated tests assess the security, behavior and impact that the code we are introducing will have on the codebase
- We automatically check for security issues within our third-party dependencies as well as our own code
- At least one senior software engineer reviews each recommended change before it can be introduced into production
- We automatically check the structure and formatting of the code for bugs and prevent the introduction of new code that gets flagged
- We run automated tests both for individial functionality and across the bounds of our functionality in order to ensure we don't introduce unexpected behavior to the system as a result of a change
This allows us to both move quickly, and safely. For a full list of checks and balances that exist before code changes are made, reach out to support. This means that it would be difficult to introduce bugs, performance or other regressions into the code base, protecting our customers.
Logging & Monitoring
We log all state changes that occur both within and among the systems that Convictional integrates with, as well as user access and routine operations. This is an ongoing effort and requires continuously adapting as new services are built and deployed. As an integration service provider, understanding what is happening when many millions of records are in motion on a daily basis is core to our business. We use the full suite of logging, monitoring, profiling and other tools provided by Google Cloud in order to ensure availability and observability for our systems. We have 16/7 on call coverage, with the goal of moving to 24/7 in the next year. We are able to provide relevant details from logged interactions in the event of an issue. All Convictional support and engineering staff are trained to use logs in order to ensure we can quickly and effectively diagnose and resolve issues.
We provide a publicly visible status page that is updated on a regular basis in the event of an incident with our services. The most typical case is when a configuration change brings a service offline temporarily (such as a DNS disruption or other similar case). We will keep that page up to date with the nature of the issue, the impact on customer access and data (where relevant) and the timeline for resolution of the issue. Many of our competitors focus primarily on up-time as a proxy for service availability. We combine uptime with a more qualitative assessment of whether or not services are performing as expected. Because our business deals in data from third-parties, we can never gaurantee that uptime means constant state or expected behavior. We have extensive validation in place to ensure expected behavior. In the event that your data were to be impacted, you will be notified urgently using your account email. We have followed this process since the founding of our business, and intend to continue.
Convictional services are built on top of Google Cloud Platform. Here is a link to a microsite where you can learn more about the security of Google Cloud. We also connect with third-party payment gateways such as Stripe to store sensitive payment information and we retain only the ability to change your customers on your behalf but not their (or your) payment information. We connect to third-party commerce platforms like Shopify to do work on behalf of customers. All our backend services, with the exception of public facing APIs (by definition) are not exposed to the internet and protected behind strict access control. We do regular security scans when new code is submitted using automated tools that will flag potential security issues in dependencies. We have over a thousand automated test that run on any changes we make to prevent regressions.
Our database is backed up on a rolling basis four times a day with offsite redundant backups inside of Google Cloud. The database itself is encrypted at rest by our key management system (KMS), meaning that even if someone was able to breach our cloud services provider, the data would require authentication from the KMS in order to be decrypted. No production data is retained on development machines. We will never sell or allow third-parties access to your data. Every action we perform is logged and accessible. We store the following personally identifyable information:
- First name
- Last name
- Street address
- Postal or zip code
- Region, province or state
Our customers can choose to delete archived orders, which removes all PII listed above from our system. We do not store the following: consumer email address, phone number or any other consumer PII. We do not intend to, and would notify customers if this were to change. We are considering permanently expunging consumer PII after an order has been shipped, but have not yet implementing this change.
Support cannot access sensitive business documents in your system and your approval is required to connect to your commerce platform or manage documents in your account. This creates more friction for us when we provide you support but the trade off is that none of us know what is happening in your account unless you approve access to it directly by inviting us. Anyone with the ability to gain this access is trained for compliance with our security procedures, and have the same level of two-factor authentication applied to their user accounts they use in order to gain access.