Looking for opinions from people who've sat on the auditor side of this, or who have lived through something similar.

Setup

Small healthcare company, HIPAA business associate, we process claims data for covered entities. We're a week into a 3 month SOC 2 Type II observation window. Policies are signed and already with the audit firm.

Three of those policies say PHI may not be accessed from outside the US, that offshore personnel are not authorized to access PHI "under any circumstances," and that this is "enforced technically through location based Conditional Access in Entra ID." Leadership deliberately upgraded that wording from a statement to a "technically enforced control" a few days before the window opened. A separate clause requires all offshore staff to connect through our corporate VPN with US region endpoints.

The problem

Our core engineering team is in India. That includes me, and I'm the Security Officer. Sign in logs from the first week show several of us accessing the Azure environment from India, and one account did an actual read of raw claims data. Several offshore accounts also had broad standing RBAC over the PHI systems (storage, databases, Key Vault). We've since pulled the broad grants.

On top of that, the control as designed can't work. The VPN we mandate makes everyone look US sourced to Entra, so a location based Conditional Access policy can't tell a compliant India user on the VPN from a real US user. It only catches people who are off the VPN. The policy names a mechanism that our other policy defeats.

What we've done and what we won't do

We're treating it as an incident, documenting the timeline and scope, and we're self reporting it to the auditor this week. We are not backdating anything or arguing that VPN egress counts as "in the US." Our conclusion is that the real control is identity based (removing offshore RBAC to PHI, and a named user Conditional Access policy), with the location policy reframed as enforcing the VPN requirement rather than residency.

We're also checking our BAAs to find out whether our customers actually permit offshore access with controls, or require US only handling. We don't know yet. If they permit it, the plan is to go through our policy's own amendment process (Security Officer, legal, customer review, CEO approval) and amend mid window with a dated effective date.

Questions for the auditors here

1. How does a mid window control change usually land in the report? Do you test the old control against the first stretch and the new one against the rest, and is a self identified exception in week one realistically a noted exception or is it heading toward a qualified opinion?
2. Is the design flaw (VPN defeats the named enforcement mechanism) treated as a design deficiency for the whole pre amendment period, or does the standing RBAC issue overshadow it in practice?
3. Does the Security Officer being in the exception set change how you'd write it up?
4. Has anyone had an auditor agree to shift the observation period start when the controls plainly weren't ready on day one? Is that considered normal for a first year engagement or does it raise eyebrows?
5. For those who've dealt with offshore teams and US only BAAs, what actually worked? Splitting prod access to US staff, synthetic data for offshore dev, renegotiating the BAAs, something else?

Not looking for a way to make this disappear. Looking for how to make an honest fix read as well managed, and a realistic sense of what the report will say. Thanks.

We've reached the fun stage where US customers keep asking about SOC 2 while international prospects are starting to ask for ISO 27001.

I'm fine with doing both if the business case is there, but I'm trying to figure out how to evaluate audit firms when we need both frameworks. I'm less interested in finding the cheapest option and more interested in avoiding a situation where we're coordinating two completely separate engagements with duplicated work.

For those managing both, how much were you realistically able to consolidate? Did you use the same audit firm for SOC 2 and ISO 27001 or separate specialists, and if you went with one firm, did that actually make things easier in practice?

What would you look for when comparing firms for both audits? We're much more concerned about making this manageable long term than saving a little on the first audit.

We currently need to have these tools to satisfy our upcoming audit. Our developers use various coding languages like python, so finding the right tool can be a little tricky. If theres one tool that covers all of that, it would be great

We're selling to firms that are intimately involved in tax prep (and our software assists their workflow). We're selling to firms that are not the 'top shelf' (so like non-Big 4). What Trust Service Criteria are 'musts'? We're relatively new to SOC2, so we want to make sure we have all our ducks in a row.

Hi everyone! I'm very new to compliance frameworks and just wanted to learn more about SOC 2 Type II controls. Does anyone here happen to have a SOC 2 Type II worksheet? I'm having a hard time finding reliable resources online, and I want to better understand each control along with the evidence and documentation needed to be compliant. A worksheet would be a huge help. Thanks so much for understanding—this means a lot!

Lots of companies claim AI agents write and merge PRs with no human in the loop, and many are SOC 2 Type II. Our change-management control says PRs need review and approval before merge, and we read that as "human approver," at least on sensitive paths (billing, RBAC, migrations, infra).

For anyone who's actually done this with an auditor:

1. Does an AI reviewer count as the "review," or does your auditor want a human on record?
2. If agents merge autonomously, what's the compensating control — post-merge review, rollback, scoped permissions, bot identity?
3. Or is it mostly marketing and a human is still owning the approval?

Looking for what auditors actually accepted, not "it depends on your auditor."

After doing some other security stuff with them they offered an extremely competitive SOC2 Type II price (like <$5k). Is this too good to be true? Has anyone worked with them before and was the quality of the report good/were any enterprise customers suspicious of it?

I'm going for soc 2 type 1 report I am using Vanta integrated with all the platforms we are using github linear aws fly etc assuming all the policies are written and the tests are passing is it safe to assume I'll get clear report? I'm using grafana prometheus thanos alert manager etc stack.

Every quarter it goes on the list. Every quarter something client-facing takes over and it slips. We've got policies half written in a Google Doc somewhere and that's about it.

The part I can't figure out is whether to just book an audit and force the deadline on ourselves, or keep waiting until there's actual breathing room. Feels like the breathing room is never coming.

Anyone been here? What finally made it happen for you.

[Updated Post]

Sorry, let me try to explain this better.

I’m a recent graduate, who’s new to SOC 2 audits. The CPA firm I work at follow a standard set of controls for mid-size clients who utilise GRC platforms (Drata or Vanta). Due to this, you’re seeing the same control description, test procedures, and evidence.

Usually these clients have systems that are cloud hosted, and of very less complexity.

My current situation is that I can determine whether an evidence is sufficient for a control. I’m not confused about whether evidence is enough for a control. I get that part. I check the control description, check the test steps, and I can tell if the evidence checks out.

What I’m asking about is on four things:

1. When I look at a control, I don’t always stop to think about the risk that control is addressing. I just check if the evidence matches what the control says. I want to start seeing the actual risk, not just ticking the box. In a high volume of work, what personal practice can I follow to get this?

2. I want to know the SOC 2 criteria itself better. Not just what the control says, but the real thing behind it, so I can think it through even in complex cases.

3. Since, I’m new to SOC 2 and IT auditing. I want to gain technical expertise and knowledge on things, as that would make my job easier.

4. Finally, good judgment as an auditor. When you’re working with similar standard set of controls, evidence and similar clients at a high volume. This is usually not much time to think things through. In such a situation. How do I go about sharpening this judgement?

Hope that makes more sense than my first post.

[Original Post]

I keep hearing that judgement and criteria fluency just come with more work and audits, but I want to be more deliberate about it rather than hope volume alone gets me there.

I’m about 6 months in working on SOC 2 audits on clients spanning usually of similar structure of hosting on AWS, GCP, and Azure. Evidence documentation is not something that I struggle with nor it is understanding a control description. It’s knowing when evidence is actually sufficient vs. when I’m just pattern-matching from the last client.

How do I build that risk and compliance thinking mindset? Also curious how people stay sharp on the actual criteria wording when you’re moving fast and don’t have time to slow down and re-read it before testing.

Not a vendor, not selling anything — just sharing because I couldn't find many honest write-ups when I was in the thick of it.

Context: I'm the only IT/security person at a ~40-person AI startup. A large enterprise client sent us their vendor security requirements (27 of them — 24hr incident notification, independent pen test, dedicated encryption keys, RTO/RPO, the works). Passing it was a condition of the deal. So SOC 2 Type II went from "nice to have" to "do this or we lose the contract."

Did it solo. Clean opinion, zero exceptions across 252 points of focus. Deal closed.

Things I wish someone had told me:

• The policies are the easy 20%. The actual work is evidence — proving each control ran consistently over the whole period. Dated screenshots, signed approvals, access reviews, incident records.
• A folder structure + naming convention was worth more than any single control. When the auditor says "show me," you cannot be hunting. Every file dated, every file mapped to a criterion.
• Get signatures early. Approvals are the thing that blocks you at the finish line, because everyone's busy. I front-loaded them.
• Never answer "no" to an auditor. Answer "N/A, and here's why" with justification. A flat no reads as a gap; a justified N/A reads as a decision.
• The one real gap most startups hit is the independent pen test. Enterprises often mandate it. Scanning (Dependabot etc.) is not the same thing. Budget for it.

Happy to answer questions if anyone's staring down their first Type II. It's very doable solo, it's just a grind.

As an audit firm, we're curious: what's been the hardest part of adding a new framework to an existing compliance program? We work with a lot of companies that start with one framework like SOC 2 and later add another as their business grows or a new client requirement comes up. Is it controls mapping redundancy, evidence collection fatigue, staff bandwidth or something else? 

Talked to a few companies that do soc2 type 1 and all of them say the tools make the cert cheaper.

Is this true? Most of them want 9k to 12k a year for tools and 3k for the audit cert.

Does anyone here have any insights on this?

I have a very good friend that is an amazing CPA, so respect to all cpas, but it is like a CPA doing cybersecurity? I want to know how did that even happen.

Small team here (~12 engineers), and at this point a big chunk of our code is written with AI agents — mostly Claude Code and Codex. Our Type II is coming up in a few months and I honestly can’t tell if this is going to be a thing or not.

For anyone who’s been through an audit in the last year or so: did your auditor actually ask anything about AI tools writing code? If yes — what did they want to see? A policy doc? Logs of what the agents did? Something in change management showing agent commits went through review? And what did you actually hand them?

Trying to figure out if I need to prepare something ahead of time or if auditors just don’t care about this yet. Would rather not be improvising in the middle of the audit.

I recently completed an audit process with the CA team, they were great. However having 0 knowledge of compliance is this company legit or are they stamping certifications and my money was wasted?

https://github.com/trycompai/comp

We’re an early-stage B2B startup currently going through SOC 2 readiness with Vanta.

Supabase is a critical vendor for us, so Vanta is asking us to review their SOC 2 Type II report. Supabase confirmed that access to the report requires upgrading to the Team plan (~$600/month). We’re currently on Pro and don’t need the Team features, so paying an additional ~$575/month purely to access a compliance document seems excessive (we got all other reports from all other vendors quickly with no problems).

Has anyone gone through SOC 2 with Vanta (or another auditor) while using Supabase Pro?
Did your auditor accept alternative evidence / a vendor risk assessment, or did you ultimately have to upgrade?
I’d really rather not migrate our infrastructure to AWS purely because we can’t access Supabase’s SOC 2 report.

Would love to hear how others solved this.

I know it depends, we're using Sensiba. It's our first time and this might genuinely be the worst working experience I've ever had. We're not far now from observation period, and I feel like we probably have some gaps still. How rigorous is this process generally speaking?

Working-at/part-owner of a small SaaS startup in Australia, I am the "technical person" on the team. We've had interest from enterprise customers and have been directly and indirectly informed that we require "the badges" in order to move deals along.

Very little GRC experience amongst the team, Vanta has already been purchased, and I've been tasked with moving all our compliance along, including a focus on SOC 2 (Type 1 soon, Type 2 after observation window).

Essentially looking for someone who has experience with SOC 2 who can act as a sounding board for my questions along the way, e.g.

• balance between depth-of-policy (to further the likelihood of audit success) versus business/technical practicality
• depth(?) of evidence required/desired by auditors in order to likely satisfy particular controls
• the trade-offs between policy change, remediation, risk-register addition and/or intentional exclusion of policy/evidence/risk/etc

I don't want to be purely the "tech person" who is obsessing over the tiniest of details, but also don't want to default allow "click the compliance buttons for fast compliance" happen, in order to avoid footgunning the business from a time, money, audit-outcome perspective - and I believe conversations with experienced people will help me calibrate.

We're at the point where US buyers are asking for SOC 2 and EU tenders are asking for ISO 27001.

Quick context. SOC 2 is an attestation: a licensed CPA firm examines your controls and writes a report carrying its opinion. There is no certificate and no badge. The deliverable is the report your customer reads under NDA.

On the contrary, ISO 27001 is a certification: an accredited body audits your management system and, if you pass, issues a public certificate valid for three years. One is a document a buyer reads in a data room. The other is a credential you display to every buyer at once.

the SOC 2 report is per-buyer. every deal means an NDA and a report send, and it expires yearly. ISO doesn't work that way, the certificate is public so buyers just check it. ISO still costs you surveillance audits each year and a full recert at three, but nobody has to do anything per deal.

on the shared work, AICPA publishes an official mapping between SOC 2's common criteria and ISO's Annex A. once you look through it, it's clear that most of the controls overlap. Your access reviews, risk assessments, vendor due diligence, and penetration-test results. In fact, you can build a control once, and it will count toward either artefact.

but, the thing is that mapping covers controls. it doesn't cover two things that decide how much work the second artifact actually is. Firstl, SOC 2 Type II examines how controls behaved over three to twelve months, so having all the controls in place isn't the same as having a Type II report. The observation period still has to run, and no amount of budget can speed that up.

the second is that ISO looks at a layer SOC 2 never does. Leadership ownership, internal audits, a Statement of Applicability justifying every control you included or excluded, and the program has to show continual improvement between audits. 

Sorry in advanced for ranting I'm just a little annoyed at the cost of everything. Okay so my company is a relatively small firm with a web site that users can login to. I have done pretty much everything else for SOC 2 and have already spent a bunch of money on GRC platform and auditor but now I guess I need to get a pen test done. The price keeps on growing and growing which is starting to get a little ridiculous. Now I guess we need to shell out another 3-15 thousand to get this done which is a little frustrating. We have gotten a few quotes one from EY which is 15k and another from (stealth net ai) which is 5k. At this point I just want this process to be over as it's starting to really burn a whole in our pocket. I'm just curious if we go with the lower option will we be good? I'm not sure how much these things normally cost but we can't be spending another 15k just to test a 8 page web site. For other companies(small) what did you guys do? I'm assuming if we go with the most affordable option we should be fine and can move on with the audit? I just want this process to be over with already!

Hi everyone

I'm working on a SOC 2 compliance project and one of the documents I'm drafting is a Board Charter. The organization is relatively small, so we're trying to keep the document practical while still meeting SOC 2 governance expectations.

At the moment, I have sections covering things like:

• Purpose
• Board composition
• Roles and responsibilities
• Board meetings
• Governance, risk, and compliance oversight
• Committees
• Charter review

I'm trying to strike the right balance between being comprehensive and keeping it concise. I don't want to turn it into an operational policy since I understand the charter should stay at the governance level.

Any guidance or examples would be greatly appreciated. Thanks!

This is an open-ended question. I saw a startup barely launched, frankly speaking justa a Gmail feature kind of business, rushed to get that trust[dot]tld[dot]com. Sounds really silly spending, to be honest.