SOC 2 vs ISO 27001 for Broker Tech: 20 Due‑Diligence Questions Before You Sign

Brokers and prop firms rarely buy “software.” You buy operational dependency: onboarding, KYC/AML workflows, payments, trading access, client data, and reporting—all sitting inside a CRM and platform stack.

That’s why SOC 2 and ISO 27001 matter—but only if you ask the right questions. A logo on a pitch deck doesn’t tell you what systems were audited, what the vendor actually controls, or what you’re still responsible for.

SOC 2 vs ISO 27001: what they signal (and what they don’t)

SOC 2 is an attestation report (by a CPA firm) against the AICPA Trust Services Criteria (security, availability, confidentiality, processing integrity, privacy). For buyers, the practical value is in the details: scope, control testing results, and exceptions.

ISO 27001 is a certification of an information security management system (ISMS). It’s strong for governance: risk assessment, policies, continuous improvement, internal audits. But it can still be broad unless you verify the Statement of Applicability (SoA) and certification scope.

Key takeaway for brokers: either can be credible, but neither automatically means “secure,” “compliant with your regulator,” or “safe to outsource everything.” Treat both as a starting point for due diligence.

Question 1: “What exactly is in scope?” (the most important buyer question)

A vendor can be “SOC 2” or “ISO 27001” while critical components are excluded. Your first job is to map the vendor’s audit scope to your actual use case.

Ask for a simple scope map that answers:

• Which products are covered: CRM, client portal, IB portal, payments module, reporting, risk backoffice, platform management
• Which environments are covered: production only vs staging/dev
• Which regions/tenants are covered (important for multi-entity broker groups)
• Which infrastructure is included: cloud accounts, Kubernetes clusters, databases, object storage
• Whether support tooling is included (ticketing, remote access, logging, call recordings)

If you’re buying a forex CRM integrated with MT4/MT5/cTrader/bridges and PSPs, confirm whether integration services and data flows are included in scope—or treated as “customer responsibility.”

Question 2: “SOC 2 Type I or Type II—and what period?”

For SOC 2, the difference is not academic:

• Type I: design of controls at a point in time
• Type II: design and operating effectiveness over a period (often 6–12 months)

Brokers should prefer SOC 2 Type II for core systems handling client PII, KYC documents, payment events, and trading account provisioning.

What to request (and actually read):

• The report type (I vs II)
• The coverage period dates
• The auditor’s opinion and any exceptions
• A management response and remediation plan for findings

If the vendor is “in progress,” ask what controls are already implemented and what timeline they’re committing to—then bake that into the contract.

Question 3: “Show me your control evidence—without hiding behind the certificate”

Serious vendors can provide buyer-friendly evidence without handing you sensitive internals.

Ask for:

• A redacted SOC 2 report under NDA, or an executive bridge letter
• ISO 27001 certificate and the certification scope statement
• The Statement of Applicability (SoA) summary (which Annex A controls apply and why)
• A recent penetration test executive summary and remediation status
• A high-level security architecture diagram (data stores, encryption points, network boundaries)

If the vendor refuses all evidence and only offers marketing PDFs, treat it as a procurement risk—especially if you operate in or serve clients in stricter jurisdictions (FCA, ASIC, CySEC, DFSA, etc.). Requirements vary by jurisdiction; confirm with your compliance team.

Question 4: Access control: “Who can touch production, and how is it logged?”

For brokers, the most common real-world failure mode isn’t “hackers”—it’s over-privileged access and weak operational discipline.

Your due-diligence checklist for access management:

• Is MFA enforced for all staff and admin consoles?
• Do they use SSO (Okta/Azure AD/Google Workspace) and role-based access control (RBAC)?
• How is privileged access granted: ticketed approvals, time-bound access, break-glass accounts?
• Are admin actions logged to a tamper-resistant system?
• Can the vendor provide an access log export for investigations?

Also ask about support access:

• How do support engineers access your tenant?
• Is access session-recorded?
• Can you require customer approval for sensitive actions (e.g., wallet adjustments, KYC overrides, account provisioning changes)?

Question 5: Data handling: residency, encryption, retention, and deletion

CRMs and trading platforms concentrate sensitive data: identity documents, addresses, device fingerprints, payment events, trading activity, and communications.

Ask the vendor to document:

• Where data is hosted (regions) and options for data residency
• Encryption in transit (TLS) and at rest (database/object storage)
• Key management model (KMS/HSM; who can access keys)
• Backup frequency, retention, and restore testing
• Data retention defaults and how you configure retention to match policy
• Deletion processes: soft delete vs hard delete; timelines; audit trails

If you have GDPR exposure or similar privacy obligations, confirm how the vendor supports data subject rights (export, deletion, correction). Regulations change frequently—treat this as general guidance, not legal advice.

Question 6: Incident response: “How will you tell us, and how fast?”

When something breaks—outage, breach, compromised credentials—speed and clarity matter more than perfect paperwork.

Minimum questions to ask:

• Do they have a written incident response plan and on-call rotation?
• What are the notification timelines (e.g., initial notice within X hours)?
• What’s included in a post-incident report (root cause, impact, corrective actions)?
• Do they run tabletop exercises or simulations?
• How do they handle third-party incidents (cloud provider, email provider, PSP integrations)?

Contractually, align this with your regulator and client commitments. Many brokers also want a security contact channel and a defined severity matrix.

Question 7: Third-party risk: “Which vendors sit under your stack?”

Your vendor’s security posture is partly inherited from their suppliers. You don’t need every internal detail—but you do need transparency.

Ask for:

• A list of critical subprocessors (cloud hosting, monitoring, email/SMS, KYC providers, analytics)
• How they assess vendors (security reviews, SOC reports, ISO certs)
• Whether they have a formal third-party risk management process
• How changes are communicated (new subprocessors, region changes)

For brokers, this matters most where client identity verification, communications, and payment workflows depend on external providers.

Question 8: Commercial terms that actually reduce risk (not just legal boilerplate)

Security due diligence should translate into operationally enforceable contract terms.

Consider negotiating:

• Named uptime targets and service credits (availability)
• Backup/restore RTO/RPO commitments
• Breach notification timelines and cooperation obligations
• Right to receive updated SOC 2/ISO artifacts annually
• Clear responsibility matrix (shared responsibility model) for:
  • KYC/AML configurations and rule tuning
  • User access management on your side
  • Data retention settings
  • Integration security (APIs, webhooks, keys)

Also validate offboarding: data export formats, timeline, and deletion confirmation.

The Bottom Line

SOC 2 and ISO 27001 are useful signals—but brokers should buy based on scope, evidence, and operational controls, not badges.

Focus your diligence on what touches client data and production access: audit scope, access logging, encryption, incident response, and third-party dependencies.

If you want a walkthrough of what “good” looks like for brokerage CRM/platform security in practice, talk to Brokeret at /get-started.