How CrowdComms and Henchman use ISO 27001 and SOC 2 together

If you’re a growing startup, you’ll eventually need to prove trust to customers. For many B2B teams, that means showing either ISO 27001 certification or a SOC 2 report—and, as you expand internationally, it often becomes both.

You might start out answering security questionnaires and sharing policies on request. But once deals get bigger (or procurement gets stricter), buyers commonly ask: Which standard do you have? When was it audited? Can we see the report?

To understand what it looks like in practice, we spoke with security and operations leaders at CrowdComms (UK-based event technology) and Henchman (Belgium-based legal AI) about how they approached ISO 27001 and SOC 2—and how the two frameworks can reinforce each other when you plan them together.

This guide covers:

What ISO 27001 and SOC 2 are (and what they’re not)
How CrowdComms and Henchman sequenced each framework across regions
Where the overlap is real (controls, evidence, and audit execution)
A practical decision guide for choosing “ISO first,” “SOC 2 first,” or “both”

When you realize you’re doing the same evidence work twice

GIF via GIPHY

Related guides:

Key takeaways

ISO 27001 is an ISMS (management system) with certification. It’s risk-based and process-oriented, with an auditor issuing a certification when you meet requirements.
SOC 2 is an attestation report against Trust Services Criteria. It tests whether controls are designed and operating (Type 1 vs Type 2) and produces a report (not a “certification”).
The “right” order is usually driven by your buyers and region. In Europe, ISO 27001 is often the default ask; in North America, SOC 2 is often the fastest way through security review.
The overlap is where you win. If you design one control set and map it to both frameworks, you can reuse owners, evidence, and testing rhythm instead of duplicating work.
Tools help—but sequencing and ownership matter more. The fastest path is clear scope, named control owners, and a single evidence workflow that supports both audits.

Why buyers ask for ISO 27001 or SOC 2

Buyers use ISO 27001 and SOC 2 as shortcuts for “does this vendor take security seriously?”

In a procurement process, a strong trust artifact can:

Reduce the number of custom security questionnaires you have to answer
Speed up legal and security review cycles
Give security teams something consistent to validate (instead of ad hoc screenshots)
Set expectations for ongoing controls (access reviews, incident management, vendor oversight)

The catch is that you don’t always get to choose. Your customers will often anchor on what’s common in their market:

Europe / UK-heavy pipeline → ISO 27001 is a common baseline
North America-heavy pipeline → SOC 2 is frequently the default

ISO 27001 vs. SOC 2 (what’s actually different)

Both standards help you build and demonstrate strong security practices—but they’re not the same thing.

The simplest mental model

ISO 27001: “We run a formal information security management system (ISMS) and manage risk continuously.”
SOC 2: “We have controls aligned to Trust Services Criteria, and an independent auditor tested them.”

Quick comparison table

Dimension	ISO 27001	SOC 2
Origin	International standard (ISO/IEC 27001)	AICPA standard (Trust Services Criteria)
Output	Certification (pass/fail + surveillance cycle)	Report (Type 1 / Type 2)
Primary focus	ISMS + risk management + continual improvement	Control design + operational effectiveness
Geography (common demand)	Europe + global enterprises	North America + SaaS-heavy ecosystems
Audit cadence (typical)	Initial certification + surveillance audits	Type 1 at a point in time; Type 2 over a period
Best for	Proving a mature, risk-based security program	Proving your controls operate over time

If you’re deciding which one to start with, the honest answer is: start with what your buyers will accept this quarter, then plan for the other if your growth trajectory makes it inevitable.

How CrowdComms and Henchman used ISO 27001 and SOC 2 together

Both companies followed a similar pattern:

Start with the framework their home market expected
Expand into a region where the other framework is more common
Reuse what they already built—policies, control ownership, and evidence—so the second audit wasn’t starting from zero

Henchman: ISO 27001 first, then SOC 2 for US expansion

Henchman is an AI-powered legal contract drafting company based in Belgium. The company’s early growth was Europe-focused, where ISO 27001 is widely recognized—so they pursued ISO 27001 certification first.

Later, as the team prepared to expand into the US, they planned for a SOC 2 report to meet expectations in that market. Because the company already had an ISMS foundation—defined policies, risk management routines, ownership, and evidence habits—the SOC 2 program moved faster than it would have otherwise.

CrowdComms: ISO 27001 expectations in the UK, SOC 2 to unblock supplier onboarding

CrowdComms is an end-to-end event tech company based in the UK. Early customers were primarily looking for ISO 27001-aligned security practices, which shaped how the team organized their security program.

As the business expanded into the US, supplier and customer contracts began to include requirements to obtain and maintain SOC 2. For many teams, that’s the moment you realize ISO 27001 alone may not satisfy procurement in every market—even if your underlying controls are strong.

CrowdComms started with SOC 2 Type 1 to demonstrate that key controls were designed appropriately, then pursued SOC 2 Type 2 to prove those controls operated effectively over a longer period. The outcome wasn’t just “a report”—it also helped reduce friction in repetitive questionnaires and vendor onboarding.

Why ISO 27001 and SOC 2 work better together

ISO 27001 and SOC 2 overlap in the areas that matter operationally:

Policies and governance: information security policy, acceptable use, access control, change management, incident response
Identity and access: onboarding/offboarding, least privilege, periodic access reviews, MFA
Risk management: identifying risks, assigning owners, tracking treatment plans
Evidence: tickets, screenshots, system exports, training attestations, audit logs
External verification: independent auditor review and testing

If you treat the second framework as a brand-new project, you’ll duplicate work. But if you treat both as different lenses on the same security program, you can design one “control operating model” and map it to both.

The “reuse” principle (what to standardize once)

To reuse evidence across ISO 27001 and SOC 2, standardize:

Control owners: one accountable person per control (and a backup)
Evidence sources: where evidence lives and how it’s captured (tickets, exports, integrations)
Cadence: what’s reviewed weekly/monthly/quarterly (access reviews, risk reviews, vendor reviews)
Exception handling: how you document accepted risk, compensating controls, and timelines

When teams do this well, ISO 27001 provides the “management system” foundation and SOC 2 provides the “did it operate over time” proof.

How to sequence ISO 27001 and SOC 2 (a practical decision guide)

There’s no universal rule, but there are reliable patterns.

Decision table: what to do first

If your situation looks like…	Typically start with…	Why
UK/EU-heavy pipeline, global enterprise buyers	ISO 27001	Widely recognized internationally; ISMS foundation supports later SOC 2 work.
US-heavy SaaS pipeline, fast procurement cycles	SOC 2 (Type 1 → Type 2)	SOC 2 is a common procurement requirement; Type 1 can unblock near-term deals.
You have both EU + US expansion in the next 6–12 months	Plan both; start with one control set	You’ll move faster if you map controls once and reuse evidence across audits.
You’re early stage and just need to pass questionnaires	Neither immediately (but build the foundation)	Start with policies, access control hygiene, logging, and ownership so you’re not rebuilding later.

If you’re going for both, align these early

Scope and systems: what’s in-scope (product, environments, supporting processes)
Control library: one set of controls mapped to both ISO 27001 and SOC 2
Audit windows: if possible, align audit timing to reduce evidence churn
Ownership: security can’t do it alone—engineering/IT/HR/legal ops need roles

Accelerate ISO 27001 + SOC 2 with SecureSlate

If ISO 27001 and SOC 2 are both on your roadmap, the highest leverage move is to avoid running two parallel programs. The goal is one operating model—controls, owners, evidence, review cadence—mapped to both frameworks.

SecureSlate helps teams do that by providing a single workspace to:

Map controls across ISO 27001 and SOC 2 so you don’t duplicate tasks
Assign owners and run recurring workflows (like access reviews and policy acknowledgements)
Centralize evidence with timestamps and an audit-friendly trail
Maintain policy versions and track updates as your environment changes
Keep your program moving between audits with repeatable checklists and reminders

If you’re preparing for your first audit (or adding the second framework), start by building a reusable control set and making evidence collection predictable from week one.

Get started for free

Frequently asked questions

Do I need ISO 27001 and SOC 2, or just one?

It depends on your customers and region. Many companies start with whichever framework unblocks deals sooner, then add the other as they expand. If you expect global enterprise procurement, planning for both early reduces rework.

Is SOC 2 a certification like ISO 27001?

No. ISO 27001 results in a certification. SOC 2 results in an attestation report (Type 1 or Type 2) issued by a CPA firm.

Should I do SOC 2 Type 1 or Type 2 first?

Many teams do Type 1 first to show controls are designed appropriately at a point in time, then move to Type 2 to prove those controls operated effectively over a period. The best path depends on buyer expectations and your timeline.

Can I reuse evidence between ISO 27001 and SOC 2?

Often, yes—especially for shared domains like access management, change management, incident response, training, vendor oversight, and risk management. The key is standardizing control ownership and evidence sources so the same artifacts can satisfy both audits.

Disclaimer (legal note)

This article is for general informational purposes and is not legal, security, or audit advice. Your audit scope, control design, and reporting requirements depend on your business, systems, and the specific expectations of your auditor and customers. For SOC 2, you must work with a licensed CPA firm.