.svg)
Chris Sides
November 20, 2023
We are incredibly excited to share that Ansa has achieved SOC 2 Type 2 compliance! This is a huge achievement and speaks to the security, reliability, and integrity of Ansa’s stored value payments platform and entire team. SOC 2 is one of the first major milestones in Ansa’s ongoing compliance journey to reaffirm and attest our commitment to establishing a secure online payments experience.
Here at Ansa, we’re firmly committed to building for scale with deliberate and high leverage practices. For us, compliance isn’t and can’t be an afterthought; compliance is a core component of creating a robust platform. To build the future-ready digital payments platform, security must be part of every aspect of our operations, underlining our belief that a safer tomorrow is a collective responsibility, not confined to a single individual or team.
Chris Sides, a founding engineer at Ansa, shares learnings on why SOC 2 matters and why we decided to invest the time and resources as a small team.
Welcome to acronym land! Let’s dive into what SOC 2 means and why compliance is crucial to Ansa’s mission.
SOC 2 stands for Systems and Organization Controls 2; SOC 2 is a security framework developed by The American Institute of Certified Public Accountants (AICPA) centered around five principles: Security, Availability, Processing Integrity, Confidentiality, and Privacy. There are two common forms of a SOC 2 audit:
At Ansa we decided to directly work towards a Type 2 report, which we believe conveys a much stronger and more accurate signal on the holistic security of an organization than a Type 1 report alone. While SOC 2 is voluntary, there is no legal or industry requirement, the compliance standard serves as an effective benchmark to publicly testify the technical and organizational controls that we have in place at Ansa. Security and reliability are crucial prerequisites to establishing trust in a digital-first age, and we feel SOC 2 is an efficient and well understood framework to cover a wide swathe of technical controls, organizational policies, and all aspects of business operations.
A question our team has gotten, especially from engineers and employees at other early stage companies, is: why did you pursue compliance so early?
Ansa is an early-stage startup, founded in early 2022. Actively pursuing compliance this soon is atypical and potentially even surprising. With a team of only 4 when we started pursuing SOC 2 and 10 today (🔌 and still hiring! check out our open job postings), was this compliance initiative worth the opportunity cost given very finite bandwidth?
We wholeheartedly believe so; investing in security from day one and demonstrating digital stewardship is core to our ethos of who we are, how we build, and the quality of the products we deliver. An emphasis on data protection from our inception is crucial in forming a positive culture around compliance.
Another factor is the product domain; move fast and break things doesn’t cut it in financial services. Each accounting error results in merchant losses, potentially millions of dollars, and each application error significantly undermines the user experience. Accuracy is also paramount to comply with reporting and regulatory frameworks.
With this in mind, we found it non-negotiable to allocate resources towards a broad spectrum of technical safeguards at an earlier stage than many companies. As an additional benefit, building on top of a solid, well vetted foundation is magnitudes easier than trying to wrangle ingrained practices, both technical and operational, into a manageable place. This philosophy applies to all engineering, but is especially pertinent within compliance and security. As we continue to expand our platform we will inevitably grow into territory that requires additional financial regulation; allocating resources towards establishing a robust and secure groundwork today will pay dividends in the future.
It is our duty and privilege to develop the safe financial infrastructure today that will power the transactional flows and payment systems of tomorrow.
A core tenet of our approach to security is an emphasis on leveraging compliance frameworks and requirements to motivate quality engineering. This approach takes many forms depending on which controls or what part of the stack is in question. At a basic level, it involves prioritizing security through measures such as encryption, instance hardening, and the principle of least privilege. Where these base requirements get exciting is in designing a system to ensure these controls are applied consistently across Ansa’s entire infrastructure surface area, while also simplifying and streamlining day to day operations; we shouldn’t be revisiting wheel design for each new instance we launch.
A significant component of this is Infrastructure-as-Code, often abbreviated as IaC; the basic premise is to define your cloud infrastructure in reusable, modular code blocks which can then be used to provision specific environments. Infrastructure-as-Code not only streamlines the deployment and management of infrastructure but also significantly enhances security by providing consistency, traceability, automation, and the ability to enforce and audit security practices throughout the entire infrastructure lifecycle. Early adoption of IaC has already empowered us to scale effectively in two significant ways. Creating a completely new environment now requires mere minutes, as opposed to the previously time-consuming hours or days, and our entire team can effortlessly and securely participate in defining these environments. Additionally, IaC has also minimized our reliance on the dreaded and error prone ‘click-ops’ — minutes or hours spent in your favorite Cloud Infra dashboard clicking through various configuration screens.
One intriguing but frequently neglected aspect of numerous frameworks is the Disaster Recovery exercise. A common approach to meet the Disaster Recovery requirement is to conduct a table top simulation — an informal classroom like setting where individuals discuss their roles in an emergency and proposed response steps. Ansa chose to conduct a mock code-red disaster exercise: how quickly can we recover from a complete regional outage? We took inspiration from the Emergency Response episode of Parks & Recreation (costumes were optional)!
In practice, what this means is booking the majority of a day to gather the whole team in the ‘situation room’ and actually provision a recovery environment from the latest production backups. The exercise is not complete until the recovery environment is at functional parity with the production environment. We strongly feel that a ‘live disaster recovery’ is the best way to evaluate both the Disaster Recovery Plan and the team’s preparedness to execute the plan, because the live exercise is far more representative of a real emergency than a tabletop exercise. A live exercise puts evidence behind Recovery Time Objective and Recovery Point Objective (RTO and RPO) claims, and can help motivate investments by highlighting the business impact. I hope it goes without saying, but we did not actually disable or impact production access or services at all for the exercise.
The above examples represent just a subset of our defense-in-depth strategy and some insights we took away from our first SOC 2 audit. We look forward to delving further into related topics in future blog posts.
Want to be in the loop? Contact us at hello@getansa.com
.webp)
.png)
