When you build infrastructure for banks and credit unions, trust isn’t a feature you add later—it’s the foundation you build on from day one.

At Across, we help U.S. community banks and credit unions manage third-party fintech risk in a way that is regulator-defensible, operationally sound, and scalable. That means we don’t just advise on controls, we have to live by them ourselves.

That belief is what led us to pursue SOC 2 attestation early in our journey, even before full platform automation. This post shares why we did it, what it took, and what we learned along the way.

Why SOC 2 Mattered to Us (and Our Clients)

SOC 2 is often described as a “security attestation,” but in practice, it’s much more than that. It’s a structured way to demonstrate that an organization has designed, and operates controls to protect data, manage access, and ensure accountability.

For the banks and credit unions we serve, SOC 2 matters because:

• They are accountable to regulators for every third party they rely on
  
  
• Vendor risk assessments must be evidence-based, not trust-based
  
  
• Examiner questions increasingly focus on how controls operate, not just whether policies exist
  
  

If Across was going to be part of our clients’ risk management stack, we needed to be able to stand up to the same scrutiny they face.

What SOC 2 Really Means (From the Builder’s Side)

At a high level, SOC 2 evaluates controls against the AICPA Trust Services Criteria, such as Security, Availability, Processing Integrity, Confidentiality, and Privacy.

• Type I assesses whether controls are designed appropriately at a point in time
  
  
• Type II goes further and evaluates whether those controls operate effectively over a defined period
  
  

For us, SOC 2 was not about passing an audit, it was about building operational discipline that could scale as our platform, data volume, and client base grow.

Where We Started: Early-Stage Reality

Like many early-stage companies, we started lean.

We had:

• A small team
  
  
• Manual processes alongside early platform capabilities
  
  
• A fast-moving roadmap driven by real client demand
  
  

What we didn’t want was a gap between saying “we take security seriously” and being able to prove it.

The biggest realization early on was: good intentions don’t count without evidence.

That mindset shift shaped how we approached SOC 2, not as a documentation exercise, but as an operational one.

Making Scope Decisions (and Why They Matter)

One of the most important parts of the SOC 2 journey is scoping.

SOC 2 is risk-based by design. You don’t include controls because they’re popular, you include them because they’re relevant.

We made deliberate decisions about:

• Which Trust Services Criteria applied to our platform and operations
  
  
• Which systems, workflows, and data flows were in scope
  
  
• How to align scope with how our clients and regulators would evaluate us
  
  

This process mirrored how banks scope their own third-party risk reviews, and reinforced why SOC 2 is most valuable when treated as a governance exercise, not a checklist.

The Hard Part: Turning Controls Into Daily Behavior

Writing policies is relatively easy. Living them is not.

The hardest part of our journey was translating controls into day-to-day behavior, including:

• Enforcing least-privilege access while staying productive
  
  
• Building habits around documentation and evidence collection
  
  
• Training the team to think “auditor-ready” by default
  
  
• Ensuring consistency across people, processes, and tools
  
  

SOC 2 doesn’t reward heroics, it rewards repeatability. That lesson reshaped how we operate.

How SOC 2 Shaped Our Product Thinking

One unexpected benefit of this journey was how deeply it influenced our product and platform design.

As we build automation and AI-assisted workflows, SOC 2 principles pushed us to prioritize:

• Clear audit trails
  
  
• Human-in-the-loop accountability
  
  
• Evidence traceability from input to conclusion
  
  
• Role-based access and segregation of duties
  
  

These aren’t just compliance features, they’re core to building examiner-ready systems for regulated financial institutions.

What We Learned Along the Way

A few lessons we wish we had known earlier:

• Start earlier than you think you need to
  
  
• Evidence discipline matters more than perfect policies
  
  
• Security and compliance are cross-functional, not just “IT work”
  
  
• Auditors value consistency far more than complexity
  
  

Most importantly, SOC 2 works best when it reinforces how you already want to operate.

What This Means for Our Clients

For our bank and credit union partners, SOC 2 attestation means:

• Demonstration of our capability to form and follow policies and processes
  
  
• Greater confidence in how we protect sensitive data
  
  
• Fewer back-and-forth security questionnaires
  
  
• Clear, auditable evidence during vendor reviews
  
  
• A partner that understands regulatory expectations firsthand
  
  

It also means our controls will continue to operate,  not just exist on paper.

What’s Next

SOC 2 is not a one-time milestone. It’s an ongoing commitment.

We are focused on:

• Continuously operating and monitoring our controls
  
  
• Raising the bar as our platform becomes more automated
  
  
• Ensuring our security posture evolves alongside our clients’ needs
  
  

A Commitment, Not a Badge

We didn’t pursue SOC 2 to check a box or add a logo to our website.

We did it because trust, transparency, and accountability are non-negotiable when you build risk infrastructure for regulated institutions.

This attestation is one step in a longer journey and we’re committed to doing the work every day to earn that trust.

‍