Our Commitment to Security

Our security whitepaper

Download it

Vanta trust report

View it

SOC reports

Request it

Terms and privacy policy

View them
compliance logos for GDPR and CCPA

Overview

At Abound, we help our customers onboard and improve the financial experience of 1099 workers through our full suite of embeddable APIs. As a result, we often work with sensitive information about our customers’ users, including financial transactions, government identifiers, and necessary personal information - i.e. name, address, and other related contact info.

In order to keep this information as safe as possible, we’ve designed our systems with a variety of security measures and implemented practices that help us consistently stay on top of security maintenance.

Built for banking

Privacy

We follow the law on privacy & protection of Personal Information, including California’s CCPA (as amended by the CPRA) and the GDPR. We’re happy to sign Data Protection Agreements (DPAs) with customers that outline how we protect personal information, and these agreements incorporate the EU’s Standard Contractual Clauses (SCCs) to ensure we’re legally on the hook for handling this information appropriately. We also monitor our compliance with other US states that have passed major privacy laws.

We’re happy to help our Clients satisfy end user rights to view, edit/correct, and delete their data, and we don’t sell Personal Information to others. We limit our use of Personal Data to necessary and permitted interactions that directly relate to our role as a service provider to Clients, and we only process Personal Information to fulfill our contractual obligations to our Clients. To learn more about our Privacy Practices, please see our detailed commitments in our Privacy Policy, Service Agreements, and DPA.

Encryption

Our corporate and cloud systems are designed to encrypt data at rest and in transit, using AES-256 and TLS 1.2. This includes production infrastructure, backups, files & documents, and company laptops & mobile devices.

We selectively hash sensitive information before storing it in databases, which gives us an extra layer of protection against accidental disclosure - including from staff maintaining the system.

Architecture

Our systems are hosted on AWS, which is a top tier cloud infrastructure provider. You can find out more about AWS security & compliance at aws.amazon.com/compliance/.  

Where it makes sense, we leverage AWS’s expertise in designing secure systems by using serverless computing and managed resources. This helps reduce the number of areas where we could make maintenance or configuration errors that would reduce our security posture.  

When we do maintain our own servers, we use hardened linux images from AWS and continuously monitor them for vulnerabilities. Vulnerability alerts are escalated to Security, DevOps, and Engineering staff for remediation, which is enforced by dedicated compliance management software and validated against internal SLAs. Aside from designated edge devices, internal servers are not directly addressable from the web, and staff are required to use VPNs to perform administration tasks for cloud resources.

Finally, we use compliance monitoring software to help ensure that we don’t make avoidable mistakes and stay on top of security maintenance - this software is integrated into our cloud provider and reports to independent auditors to keep us honest.

Software Development

We strive to make sure our platform operates consistently and minimize preventable security mistakes. As a result, we’ve baked the following practices into our development and release cycle:

  • Code changes are peer reviewed and must be approved for migration to production by two staff members.
  • Abound code is evaluated for security weaknesses using static code analysis software. Code that introduces new security weaknesses must be fixed prior to release.
  • We monitor 3rd party dependencies for security vulnerabilities and use tools to help automate the process of updating them.
  • Secrets and sensitive environment variables are kept out of the codebase, with tools configured to alert us if we make any mistakes.
  • Developers complete both general and developer-specific security training as part of their onboarding process.

Logging, Alerting, and Threat Detection

We use logging to monitor health, performance, and anomalies in our production infrastructure. Logs are continuously monitored by a threat/intrusion detection service to help us identify and respond to possible security issues. Alerts are escalated to appropriate staff, including Engineering, DevOps, and Security staff, and we maintain formal policies governing incident response. We’ve configured logging sources to minimize sensitive information that might otherwise appear in log data.

Resilience and Business Continuity

We regularly (annually or more often) conduct exercises designed to help us prepare for security incidents, cloud outages, physical disasters, and other types of anomalous events. Exercises may include technical recovery drills, tabletop testing, simulated events, and communications planning. This helps ensure that our systems have a high level of baseline resilience and support options for recovery in the event that failures cascade to a level that results in disruption of services. Much of our infrastructure is configured such that a malfunctioning server is automatically replaced with a healthy backup from an alternate availability zone, and we maintain continuous database backups in the event that primary, secondary, and any tertiary failovers fail to resolve the issue.

Additional practices

To round things out, we also perform the following:

  • Annual penetration testing, where security partners use ‘white hat’ hacking techniques to help us understand where our systems can be improved. Testers use the ASVS 4.0 security verification standard maintained by the OWASP foundation.
  • We take a serious look at vendor security practices before partnering with them, and review their security posture annually to make sure they remain a good fit.
  • We consider fraud risks as part of our risk modeling.
  • We minimize interactions with sensitive data where possible, and avoid working with PCI information.
  • We do annual security training, require staff to use MFA where available, enforce security baselines on corporate devices using MDM software, and otherwise align with security best practices that form a fundamental part of secure operations.

Compliance

To ensure complete accountability, we have outside auditors review our security on an annual basis under the SOC 2 (Type 2) framework, including Security, Availability, and Confidentiality criteria. We’re happy to provide our SOC 2 reports to customers and prospects under NDA - please contact security@withabound.com with support@withabound.com CC’ed to request a copy. Our SOC 2 report includes an assessment of our compliance with a standard set of security best practices & principles, a description of our security controls, network diagrams, descriptions of the platform architecture, as well as our auditor’s formal opinion as to the design, operation, and functioning of those controls over an extended period of time.

Questions

If you have questions about our security practices that aren’t covered above, or suggestions on how we can improve this page, please contact security@withabound.com with support@withabound.com CC’ed.

If you’d like to book a demo or speak with our Sales team, you can get in touch with them here: withabound.com/demo.

Version 1.0, last updated 6/24/22

Ready to build the future independent workers want to work in?

Get started
Book a demo