'Show Me Your SOC 2': How Small Firms Can Document Security Without Expensive Audits

tax_tina · March 22, 2026, 11:22am

Last month, I almost lost a great client because of four words: “Show me your SOC 2.”

I run a small CPA practice in Chicago—just me and two part-time bookkeepers—and we had a promising lead: a Series A startup needing monthly accounting and tax planning. Perfect fit for our practice. Then their CFO sent over a 12-page security questionnaire.

The questions weren’t unreasonable:

How do you encrypt data at rest and in transit?
What access controls and authentication do you use?
What’s your incident response procedure?
How do you handle data backup and disaster recovery?
Do you perform vendor security assessments?

But the implicit question behind all of this was: “Do you have a SOC 2 report?”

The Small Firm Security Dilemma

Here’s the problem: SOC 2 audits cost $15,000-30,000 for initial certification, plus ongoing annual audits. For a small practice billing $250k/year, that’s 6-12% of gross revenue just to prove we’re taking security seriously.

But in 2026, enterprise clients—even small startups—won’t work with firms that can’t document their security posture. They’ve been burned by vendor breaches, they’re under pressure from their own investors and compliance teams, and they’re not taking chances with their financial data.

So what do small firms do? Give up on enterprise clients? Pay for expensive audits we can’t afford?

The Beancount Security Documentation Approach

I decided to document our actual security controls instead of pursuing formal SOC 2 certification. Since we use Beancount for client work, I created a “Data Security Controls” document specifically addressing plain-text accounting security:

Encryption at Rest:

All Beancount files stored in Git repositories with GPG encryption enabled
Client data encrypted at file system level using full-disk encryption (FileVault on Mac, BitLocker on Windows)
Backup repositories use AWS S3 with server-side encryption (AES-256)

Access Controls:

SSH keys required for Git repository access (no password authentication)
Mandatory two-factor authentication (2FA) on all systems: GitHub, AWS, email, tax software
Separate Git repositories per client—no co-mingling of client data
Team members have access only to their assigned client repositories (principle of least privilege)

Incident Response:

Documented incident response playbook: detection → containment → notification → remediation → post-mortem
Client notification protocol: within 24 hours of confirmed breach involving their data
Git commit log provides audit trail for forensic investigation if needed

Backup & Disaster Recovery:

Automated daily backups to encrypted AWS S3 buckets
Git version history provides point-in-time recovery capability
Backup verification tested quarterly
RTO (Recovery Time Objective): 4 hours; RPO (Recovery Point Objective): 24 hours

Vendor Security:

All vendors reviewed for security practices (GitHub, AWS, domain registrar)
No third-party access to client data without written approval
Documented list of all systems with access to client information

The Outcome

I sent this documentation to the CFO along with a one-page “Plain-Text Accounting Security Advantages” explanation:

"Your data is stored as plain-text files in encrypted Git repositories. This means:

Transparency: You can audit exactly what’s stored (no proprietary formats, no hidden fields)
Immutability: Every change is cryptographically signed and logged in Git history (tamper-evident audit trail)
Portability: Your data isn’t locked in a vendor’s system—you have complete copies at all times
Control: Your financial data lives in repositories YOU own, not on shared SaaS servers with hundreds of other companies"

They approved the engagement. Turns out, explaining why plain-text + Git is secure—and documenting the specific controls we’ve implemented—was more convincing than a checkbox SOC 2 certification from a firm they’d never heard of.

Questions for the Community

I’m curious how others are handling this:

Are you seeing enterprise clients demand security documentation? Is this becoming more common in 2026?
What security controls do you document for clients? What’s the right balance between “enough to demonstrate competence” and “overkill for a 3-person firm”?
Has anyone pursued actual SOC 2 certification? Was it worth the cost? Did it actually help win clients?
How do you explain Beancount security to non-technical clients? What language resonates with CFOs who’ve only used QuickBooks?

The security landscape is shifting, and I think small firms using Beancount actually have some unique advantages—but we need to learn how to articulate them to clients who are asking harder questions about data protection.

Would love to hear your experiences and approaches to documenting security controls without breaking the bank on expensive compliance audits.

accountant_alice · March 22, 2026, 11:23am

This is such an important discussion. As an IRS Enrolled Agent, I want to emphasize something that many small firms don’t realize: you’re probably already legally required to document these security controls anyway.

The Regulatory Reality

The FTC Safeguards Rule isn’t optional for firms handling consumer financial data—and the penalties are severe: up to $100,000 per incident plus $43,792 per day for ongoing violations. IRS Publication 4557 requires all tax preparers to secure taxpayer information with:

Written security plans (WISP - Written Information Security Plan)
Access restrictions
Encryption protocols
Incident response procedures

So when a client asks “Show me your security documentation,” they’re actually asking for something you should have already created for regulatory compliance purposes. The good news? That WISP you’re required to maintain can also serve as your client-facing security documentation.

My Approach: WISP as Client Proof

I created my WISP two years ago to comply with FTC/IRS requirements, but I quickly realized it could double as proof for clients:

What I include in my WISP:

IRS Security Six implementation status (antivirus, firewalls, MFA, backup, drive encryption, VPN)
Data classification procedures (how we identify and handle sensitive tax data)
Access control matrix (who has access to what systems and data)
Encryption standards (GPG for Beancount files, TLS for transmission, full-disk encryption)
Incident response workflows (detection → containment → client notification within 24 hours → remediation)
Employee security training (even with just 2 team members, documented annual training)
Vendor security assessments (GitHub, AWS, tax software - all reviewed annually)

When a prospective client asks about security, I send them a redacted version of my WISP. It shows them we’re not just saying we take security seriously—we’re legally required to, and here’s the documented proof.

Plain-Text Accounting Advantages for Audit Trail

One thing I’ve learned from former IRS auditor experience: audit trail matters more than you think. Git commit logs provide something most accounting software can’t: an immutable, cryptographically-signed record of every change made to client books.

If there’s ever an incident—unauthorized access, suspected tampering, whatever—you can use Git history to prove:

Exactly what files were accessed/modified
When changes occurred
Who made the changes
What the data looked like at any point in time

That tamper-evident audit trail is actually better than what you get from proprietary accounting software, where the vendor controls the logs and you just have to trust their security.

Don’t Wait Until Client Negotiation

Here’s my biggest advice: Create your security documentation NOW, not when a client asks for it.

I’ve seen too many firms scramble to document security controls during a new client negotiation. It looks reactive—like you’re only thinking about security because the client demanded it. If you can hand them a 6-month-old WISP that’s been reviewed quarterly, it demonstrates ongoing commitment to data protection, not just checkbox compliance.

Suggested Starting Point

If you haven’t created a WISP yet, the IRS has templates and guidance in Publication 5293 (“Data Security Resource Guide for Tax Professionals”). It’s designed for tax preparers, but 90% of it applies to any small accounting firm handling sensitive financial data.

Start with that template, customize it for your Beancount + Git workflow, and you’ll have both regulatory compliance and client-ready security documentation.

The security documentation you’re building for clients? You needed it anyway for compliance. Might as well kill two birds with one stone.

bookkeeper_bob · March 22, 2026, 11:23am

I lost two potential clients last year to this exact issue—they wanted “enterprise-level security” and I couldn’t articulate what we were doing beyond “we use secure systems.” That was a wake-up call.

The Pragmatic Small Firm Approach

Here’s what I’ve learned: clients don’t want to read a 12-page WISP. They want simple, visual proof that you’re protecting their data.

I created a one-page “Data Protection Overview” that I customize for each client (takes about 30 minutes). It includes:

Visual Proof:

Screenshot of my GitHub 2FA settings (shows MFA is enabled)
Screenshot of AWS S3 bucket encryption settings (proves backup encryption)
Screenshot of a sample Git commit log (demonstrates version control and audit trail)
Diagram showing: Client Data → Encrypted Git Repo → Encrypted Backup → Encrypted Laptop

Plain Language Explanations:

“Your financial data is encrypted using the same technology banks use (AES-256)”
“Every change to your books is logged and timestamped—we can show you exactly what changed and when”
“Your data is stored in separate, isolated repositories—we don’t commingle client information”
“We perform daily encrypted backups with 90-day version history”

Security Commitments:

We’ll notify you within 24 hours if there’s any security incident involving your data
We review and test our security controls quarterly
Only authorized team members have access to your specific financial information

The Plain-Text Advantage I Emphasize

When clients ask “is plain-text safe?”, I flip the script:

"Plain-text + encryption is actually MORE secure than proprietary accounting software because:

You can verify what’s stored - Open any Beancount file in a text editor and see exactly what data we’re keeping. No hidden fields, no proprietary formats, no mystery data.
You own complete copies - Unlike QuickBooks Online where your data lives on Intuit’s servers, you have the complete Git repository. If our office burned down, your data is still safe.
Changes are permanent and auditable - Git commits are cryptographically signed. Nobody can secretly modify your historical data without leaving evidence.
No vendor security risks - Your data isn’t on shared SaaS servers with hundreds of other companies. It’s in isolated, encrypted repositories."

This explanation resonates with clients who’ve seen news about QuickBooks breaches or Xero security incidents. They like the idea that their data isn’t “in the cloud somewhere” with a vendor they have to trust.

The Checklist That Saved Me Time

I created a simple security controls checklist that I complete for every new client:

☑ Separate encrypted Git repository created for client
☑ SSH keys configured (no password authentication)
☑ 2FA enabled on all systems accessing client data
☑ Automated encrypted backups configured to AWS S3
☑ Client data segregation verified (no shared directories)
☑ Access restricted to assigned team member only
☑ Incident response playbook reviewed with team
☑ Client notification protocol documented

Takes 5 minutes to verify, and I attach it to the engagement letter. Clients love seeing a checklist—it’s concrete proof that we’re thinking systematically about their data security.

Question: How Technical Should This Be?

I’m still figuring out the right balance. Some clients understand what “GPG encryption” and “SSH keys” mean. Others glaze over at technical terms.

My current approach: Start with business language, offer technical details if they ask.

Business language: “We use bank-grade encryption to protect your data”
Technical details (if asked): “Specifically, we use GPG with 4096-bit RSA keys for file encryption, and AES-256 for backup storage encryption”

Has anyone found a better way to explain this to non-technical clients? What language resonates with business owners who just want reassurance their books are safe?

Bottom Line

You don’t need a SOC 2 audit to prove you’re serious about security. You need:

Clear documentation of your actual security controls
Visual proof (screenshots, diagrams) that clients can understand
Plain-language explanations of how you protect their data
A systematic checklist showing you’ve thought through their specific data protection

Small firms using Beancount actually have a security story to tell—we just need to learn how to tell it effectively to clients who are asking harder questions in 2026.

helpful_veteran · March 22, 2026, 11:24am

This is a fascinating discussion, and it highlights something I’ve been thinking about for a while: plain-text accounting actually has inherent security advantages that we should be talking about more.

The Security Paradox

There’s this perception that “plain-text” = “insecure” because, well, it’s plain text. Anyone can read it, right?

But that’s exactly the point—and it’s a feature, not a bug. Here’s the security paradox:

Proprietary accounting software obscurity ≠ security.

Just because you can’t easily read QuickBooks’ database format doesn’t mean it’s secure. You’re trusting:

The vendor’s encryption implementation (which you can’t inspect)
The vendor’s access controls (which you can’t verify)
The vendor’s security practices (which you learn about in breach announcements)
The vendor’s cloud infrastructure (which stores your data alongside thousands of other companies)

With plain-text + encryption, you get:

Transparency: Open any Beancount file and see exactly what’s stored. No hidden metadata, no mystery fields.
Verifiable encryption: GPG encryption is open-source, battle-tested, auditable. You know how your data is encrypted.
Immutable audit trail: Git commits are cryptographically signed. Tampering leaves evidence.
No shared infrastructure: Your data lives in isolated repositories you control, not in multi-tenant SaaS databases.

My QuickBooks Migration Story

I switched from QuickBooks Online to Beancount three years ago, partly because of security concerns. Here’s what prompted the change:

2023: News broke about yet another accounting software breach (I won’t name names, but you probably remember it). Thousands of small businesses had financial data exposed. The vendor’s response? “We’ve implemented additional security measures.”

I asked myself: How do I explain to clients that their data is safe when I don’t control the security?

With QuickBooks, I was outsourcing security to Intuit. If they got breached, my clients’ data was exposed, and all I could do was apologize and offer credit monitoring.

With Beancount + Git + GPG encryption, I control the security. If someone wants to access client data, they need:

Physical access to my encrypted laptop (which is also full-disk encrypted)
My SSH private key (which is password-protected)
My GPG private key passphrase
2FA codes for GitHub/AWS

That’s four layers of security I directly control. No vendor that can get breached by a phishing attack on their support team.

The Security Message That Resonates

When I explain Beancount security to clients, I use this framing:

“Think of it like this: Would you rather store your financial records in a bank vault YOU control, or in a shared storage facility where thousands of other people keep their valuables, managed by a company you have to trust won’t get robbed?”

Clients immediately get it. They like the idea of isolation—their data in a separate repository, not commingled with other companies’ data on shared servers.

I also emphasize: “If you ever want to fire me, you have complete copies of your financial data. You can hand it to any other accountant who knows Beancount, or even read it yourself in a text editor. You’re never locked in to a vendor or dependent on my continued existence.”

That portability and transparency builds trust in a way that “we use secure cloud software” never could.

Explaining Git as a Security Feature

One thing I’ve found helpful: explaining Git not as a version control tool, but as a tamper-evident security ledger.

“Every change to your books is recorded in Git commit history. Each commit is cryptographically signed and timestamped. If anyone—me, a hacker, whoever—tries to modify your historical financial data, it breaks the cryptographic chain. You’d know immediately.”

Compare that to proprietary accounting software where:

Edit history might exist, but you can’t verify it
Audit logs are controlled by the vendor
Historical changes can potentially be modified by privileged users
You’re trusting the vendor’s internal controls

Git gives clients something most accounting software can’t: mathematically provable data integrity.

The Documentation Opportunity

Bob’s checklist approach is brilliant, and I want to add one more thing: document what you DON’T do.

Clients worry about:

Data being sold to third parties
Data being used for vendor marketing
Data being shared with other tenants
Data being retained after contract ends

Add a “Data Privacy Commitments” section:

We do NOT sell or share your data with third parties
We do NOT use your financial data for marketing or analytics
We do NOT store your data on shared infrastructure with other clients
When our engagement ends, we securely delete all copies (or transfer them to you)

This addresses client fears in a way that SaaS vendor terms-of-service never do. You can make these commitments because you directly control the data—no vendor with their own business interests in the middle.

Tools vs. Practices

One last thought: Security isn’t about having the fanciest tools. It’s about having good practices and being able to prove them.

SOC 2 audits are expensive because they verify practices, not tools. The auditor doesn’t care whether you use Beancount or QuickBooks—they care whether you:

Documented your security controls
Implemented them consistently
Can prove they’re working
Review and update them regularly

Small firms using Beancount can do all of that without expensive consultants. Document your controls, implement them systematically (Bob’s checklist!), collect evidence (screenshots, Git logs), and review quarterly.

You don’t need a $30k SOC 2 audit. You need a $30 notebook to document what you’re already doing.

The security conversation is shifting from “what vendor do you use?” to “how do you protect my data?” Plain-text accounting firms have a compelling answer—we just need to articulate it clearly to clients who are asking the right questions.

finance_fred · March 22, 2026, 11:25am

Coming from the client side (I’m a CFO who insisted our accounting firm document their security controls), I want to share what made me comfortable with plain-text accounting after initial skepticism.

Why CFOs Are Asking Harder Questions in 2026

The security questionnaire isn’t just paranoia—it’s driven by real business pressures:

Board/investor requirements: Our board wants proof that all vendors handling sensitive data have documented security controls. After seeing portfolio companies suffer breaches, they’re not taking “trust us” as an answer.
Insurance requirements: Our cyber insurance carrier required us to verify that all financial data processors meet minimum security standards. No documentation = no coverage if they’re the breach point.
SOC 2 Type II for ourselves: We’re pursuing our own SOC 2 certification to win enterprise clients. Part of the audit includes vendor security due diligence. We need proof our accounting firm isn’t a weak link.
Regulatory compliance: Depending on your industry, you might have HIPAA, PCI-DSS, GDPR, or other compliance requirements that cascade to vendors.

It’s not that we don’t trust our accounting firm—it’s that we need documented evidence to show auditors, insurance companies, and board members.

What Made Me Comfortable With Beancount

My accounting firm uses Beancount, and honestly, I was skeptical at first. “Plain-text files? That sounds… primitive?”

But after they walked me through their security model, I realized plain-text + encryption is actually more secure than the alternatives:

What convinced me:

Isolated data storage: My company’s financial data lives in a separate Git repository. It’s not commingled with 50 other companies in a shared database. If another client gets breached, my data isn’t exposed.
Tamper-evident audit trail: Every change is logged in Git with cryptographic signatures. If someone modifies our books, we’d know. That’s better than QuickBooks where I have to trust Intuit’s internal audit logs.
No vendor lock-in: I own complete copies of my financial data. If my accounting firm goes out of business tomorrow, I’m not scrambling to export data from a proprietary system. I just hand the Git repository to a new accountant.
Transparent encryption: My firm showed me exactly how data is encrypted (GPG), where backups are stored (AWS S3 with encryption), and who has access (SSH keys + 2FA). I can’t get that visibility with SaaS accounting software.

The Documentation That Satisfied Our Auditors

When our SOC 2 auditor asked about accounting firm security, here’s what we provided:

Vendor Security Assessment Form (filled out by accounting firm):
- Encryption methods (at rest and in transit)
- Access control mechanisms (2FA, SSH keys, least privilege)
- Backup procedures (frequency, encryption, testing)
- Incident response plan (detection, notification timelines, remediation)
- Business continuity plan (what happens if key person leaves)
Evidence of implementation:
- Screenshot of GitHub repository settings showing 2FA required
- Screenshot of AWS S3 bucket with encryption enabled
- Sample Git commit log showing audit trail
- Copy of their WISP (Written Information Security Plan)
Annual security review commitment:
- Accounting firm commits to annual security assessment
- Quarterly backup testing verification
- Immediate notification if there’s any incident involving our data

Our auditor accepted this documentation without issue. They noted that documented security practices matter more than whether you have SOC 2 certification.

Cost-Benefit of Security Documentation

From a CFO perspective, here’s the ROI calculation:

Cost of SOC 2 audit for small accounting firm: $15k-30k initial + $10k-20k annual
Cost of documenting security controls without formal audit: $500-2,000 (mostly time)

Value of documentation:

Can bid on enterprise clients (potential $50k-200k additional annual revenue)
Reduces client churn from security concerns
Satisfies insurance and compliance requirements
Provides defensible evidence if there’s ever an incident

The cost-benefit is overwhelmingly in favor of DIY security documentation for small firms serving mid-market clients. You only need formal SOC 2 if you’re pursuing Fortune 500 clients with strict vendor requirements.

What I Want From My Accounting Firm

As a client, here’s what makes me feel confident:

Proactive security communication: Don’t wait for me to ask. Send me your security overview annually.
Plain language + technical details: Give me the business summary (“bank-grade encryption”), but include technical appendix for my IT team.
Evidence, not promises: Show me screenshots, Git logs, configuration settings. I want proof, not marketing claims.
Clear incident response plan: Tell me exactly what happens if there’s a breach. How quickly will you notify me? What steps will you take?
Business continuity planning: What happens if you get hit by a bus? Who has access to my data? How do I recover it?

These aren’t unreasonable requests—they’re basic risk management for any business that takes data protection seriously.

The Competitive Advantage

Here’s something accounting firms might not realize: security documentation is a competitive differentiator in 2026.

When we were evaluating accounting firms, two couldn’t provide any security documentation beyond “we use secure cloud software.” One firm (the one we hired) sent us a comprehensive security overview before we even asked.

Guess which firm won the business?

In a market where clients are asking harder questions about data protection, small firms that can document their security practices have an advantage over larger firms that just say “trust our systems.”

Plain-text accounting firms have a great security story to tell. You’re not competing on “we have the fanciest cloud infrastructure”—you’re competing on transparency, control, and documented practices. That resonates with CFOs who’ve learned not to trust vendor security claims.

The security documentation you’re building isn’t just risk mitigation—it’s a sales tool.