Authsignal is committed to the security of our services.
If you have any questions, please email: firstname.lastname@example.org.
In the event of a change to our security policy, you will only be notified by email if something here is removed or materially changed. If a minor change occurs involving our approach to security, or something is added, it will be added to this document but you will not be explicitly notified. Each time we change this document, we will update the date above to reflect that changes have been made. If you have any questions, contact our support team at email@example.com.
HTTPS & Data Transit
Access to Authsignal is encrypted in transit using SSL. This includes the mobile SDK, database, requests, and responses from our API, our API documentation, our website, and our email communications. Many Authsignal services are not exposed to the internet; only our website, API, documentation and app are exposed. When we connect with third-party services on your behalf, we always force encrypted connections with API endpoints.
In order to access Authsignal, you will need to use a browser, server and mobile operating system that supports TLS encryption version 1.2 or newer. We no longer support TLS version 1.0 or 1.1 due to known flaws in the protocol that can lead to exploits. Likewise, we use a restricted set of ciphers will may block support from legacy versions of Internet Explorer and Safari. Authsignal supports current versions of Chrome, Safari, IE, Edge and FireFox that support strong ciphers.
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 Authsignal 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 one trusted security officer within the company is able to access sensitive credentials, including all other Authsignal employees without security clearance. All our internal services use zero trust networking through secure tunnels to protect access to backend services not exposed to the internet. We require 2-factor authentication via the Authsignal App to be used on all user accounts. We require staff login to all third-party web services using 2 factor authentication. This means that Authsignal is protecting access to your data both from within Authsignal and from any entity outside of Authsignal.
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 individual functionality and across the bounds of our functionality in order to ensure we donct 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 Authsignal 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. We use the full suite of logging, monitoring, profiling and other tools provided by Amazon Web Services in order to ensure availability and observability for our systems. We have 24/7 on-call coverage. We are able to provide relevant details from logged interactions in the event of an issue. All Authsignal 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. 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.
Authsignal services are built on top of Amazon Web Services. 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 subscription tier on your behalf and modulate usage-based pricing. All of 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.
Our database is backed up on a rolling basis four times a day with offsite redundant backups inside of Amazon Web Services. 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 identifiable information:
- First name
- Last name
- Email address
- Company name(s)
Our customers can choose to delete archived orders, which removes all PII listed above from our system.
SOC2 Type I
Authsignal has certified its systems to SOC 2 Type I through an AICPA-accredited independent auditor who has assessed the operational and security processes of our service and our company. To receive additional information on our SOC 2 Type I compliance or to receive a copy of the report, please reach out to us at firstname.lastname@example.org with the subject header: Authsignal SOC 2 Type I Compliance
Authsignal is currently under audit observation for SOC 2 Type II.
Support cannot access sensitive business documents in your system and your approval is required to connect to your platform or manage configurations in your platform. This creates more friction for us when we provide you support, but the tradeoff is that none of us know what is happening in your platform 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.
To be updated as security issues are discovered email email@example.com and request security updates.