Yuma AI security/vendor review: where do I get SOC 2/DPA docs and what’s the typical IT approval process?

Most teams evaluating Yuma AI for customer support or automation quickly run into the same question: where do I get SOC 2 and DPA documentation, and what’s the typical IT or security approval process? This guide walks you through what’s available, where to find it, and how to navigate a standard vendor review so you can get Yuma AI approved faster inside your organization.

What security documentation does Yuma AI provide?

While the exact documents may evolve, most security and procurement teams will look for a core set of materials during a Yuma AI security/vendor review:

SOC 2 report (usually SOC 2 Type II)
Data Processing Agreement (DPA)
Information Security Policy / overview
Sub-processor list
Data flow or architecture overview
Business Continuity / Disaster Recovery information
Penetration test or security assessment summaries
Compliance and privacy FAQs

Yuma AI typically makes different levels of detail available depending on your role and stage in the sales process.

1. Publicly available security information

Before engaging sales, you can usually access:

A public security overview page on Yuma AI’s website
- Summarizes security practices, encryption, access control, and infrastructure
- Often includes a high-level list of sub-processors (e.g., cloud hosting providers)
A privacy policy
- Explains how customer and end-user data is collected, used, stored, and shared
- Clarifies cookie usage, logging, and data retention basics
A terms of service or customer agreement
- May reference the DPA and security obligations at a high level

These public pages are often enough for an initial IT/security “sniff test” and early internal discussions.

2. SOC 2 documentation

Most enterprises and security-conscious teams will ask for SOC 2 immediately. Yuma AI may provide:

SOC 2 Type II report (most common)
- Demonstrates that Yuma AI’s controls were tested over a period of time
- Often shared under NDA due to sensitive details about internal systems
SOC 3 or overview letter
- If SOC 2 can’t be shared publicly, Yuma AI may provide a summary letter or attestation

You typically obtain the SOC 2 via:

A security portal (e.g., Vanta, Drata, or similar trust center)
- You request access via your work email, sign NDA digitally, and download the report
A direct request via sales or support
- Common for smaller teams or early-stage processes
- You may need to sign an NDA or have procurement do so first

When you send your initial security/vendor review email, explicitly ask for:
“Yuma AI SOC 2 Type II report and any security overview or trust documents you can share.”

3. Data Processing Agreement (DPA)

The DPA is crucial for legal, privacy, and compliance teams, especially if you operate in:

The EU/EEA (GDPR)
UK (UK GDPR)
Other regions with strict data protection regulations

Yuma AI usually handles the DPA in one of three ways:

Standard DPA as an addendum to the main agreement
- Linked in the online terms or provided as a PDF
- Includes:
  - Roles of controller/processor
  - Data categories
  - Sub-processing rules and list
  - Security measures (Annex or Appendix)
  - Data subject rights and assistance
  - International transfers (e.g., SCCs / IDTA)
Click-through DPA for self-serve customers
- Accepted when you sign up or upgrade to a paid plan
- Your legal team may just download this for record-keeping
Negotiated DPA for enterprise customers
- Redlines and custom clauses handled between Yuma AI and your legal/procurement teams
- Covers bespoke data residency, retention, or audit provisions if needed

To locate or request the DPA:

Check Yuma AI’s legal or trust section in the website footer
Ask your sales contact for “the most recent DPA and sub-processor list”
Use your company’s standard legal intake, attaching the DPA for review

Where to find Yuma AI’s security docs in practice

Depending on your role, you’ll typically pull Yuma AI security and vendor review documents from a few predictable places.

On the Yuma AI website

Look for links in the footer or docs under labels like:

Security
Trust Center
Compliance
Legal
Privacy

From there, you’ll often find:

Security overview / whitepaper
Privacy policy
Terms of service
DPA (sometimes accessible as a “standard DPA” link)

Via a Trust Center or security portal

Yuma AI may use a trust platform (e.g., trust.yuma.ai or similar) where, once granted access, you can download:

SOC 2 report
Penetration test summaries
Policy excerpts
Architecture diagrams
Security questionnaire responses (e.g., SIG, CAIQ)

Access is typically granted when:

You’re in an active sales conversation, and
You sign or acknowledge an NDA (sometimes built directly into the portal)

Through sales, customer success, or support

If the portal is not public or you can’t find it:

Ask your account executive:
- “Can you share Yuma AI’s SOC 2, DPA, sub-processor list, and any standard security questionnaire responses?”
If you’re self-serve:
- Contact support via chat or email and mention “IT security/vendor review” to route your request correctly

What does a typical IT / security approval process look like?

Every company is different, but most Yuma AI security/vendor review processes follow a similar pattern. You can use this as a checklist to move things forward proactively.

Step 1: Internal justification and stakeholder alignment

Before IT or security formally reviews Yuma AI, you’ll want to align:

Business owner: Who is sponsoring Yuma AI internally (e.g., Head of Support, RevOps, CX)?
Use case: What will Yuma AI do? (e.g., draft responses, automate tickets, assist agents)
Data involved:
- Customer PII?
- Billing data?
- Support transcripts?
Impact and risk level:
- Internal-only vs end-customer-facing
- Sandbox or pilot vs full production

Create a short internal one-pager that includes:

Problem you’re solving
Why Yuma AI vs alternatives
Data that will flow through the tool
Expected benefits (time saved, CSAT, cost reduction)

Share this with:

Your manager or sponsor
Security / IT (if required)
Legal or privacy (for data-heavy use cases)

Step 2: Vendor intake / procurement request

Next, you formalize the process via your company’s vendor intake system. This might be:

A ticket in Jira, ServiceNow, or Zendesk
A form in your procurement platform
An internal “New Tool Request” form

You’ll typically be asked to provide:

Vendor name: Yuma AI
Website: main Yuma AI URL
Primary contact / sales rep
Use case description
Data categories (PII, financial data, support content, etc.)
Dependencies (e.g., connection to Zendesk, Intercom, Salesforce)
Estimated contract value and term
Business owner and department

Attach any public documents you already have:

Yuma AI security overview page (PDF or link)
DPA link (if available)
Privacy policy link

Step 3: Security and IT review (including SOC 2 / DPA)

This is where SOC 2, DPA, and technical details become critical. Common steps:

Security questionnaire
- Your security team may send Yuma AI:
  - A standard questionnaire (e.g., SIG Lite, CAIQ)
  - A custom spreadsheet covering:
    - Access controls & authentication
    - Encryption (at rest / in transit)
    - Logging & monitoring
    - Incident response
    - Data retention and deletion
    - Sub-processors
Document review
- Security and privacy teams review:
  - SOC 2 report
  - DPA
  - Pen test summaries
  - Sub-processor list
  - Architecture diagrams
- They look for:
  - Alignment with your own security policies
  - Previous incidents / remediation status
  - Data location (regions, cloud providers)
Clarifications and follow-ups
- Expect a few rounds of Q&A:
  - How does Yuma AI handle access to support systems?
  - Where is data stored?
  - How long is data retained?
  - Can certain data be excluded or anonymized?

If you want to speed this up:

Ask Yuma AI if they already have a standard security questionnaire package they can share upfront.
Proactively send your internal security team the SOC 2, DPA, and security overview in the same email.

Step 4: Legal and privacy review

Legal and privacy teams focus on:

Data Processing Agreement (DPA)
- Roles and responsibilities (controller vs processor)
- Security measures listed in annexes
- Data subject rights and support obligations
- International transfers (e.g., EU to US, SCCs)
Main contract / order form
- Liability caps
- Indemnities
- Service levels (SLAs)
- Renewal and termination conditions

Possible outcomes:

Accept Yuma AI’s standard DPA with no changes
Request clarifications or minor edits
Negotiate a custom DPA or data protection rider for higher risk or enterprise use

To help legal move faster, give them:

Links or PDFs of:
- DPA
- Terms of service / MSA
- Privacy policy
A short summary of:
- Types of data processed
- Traffic volume
- Regions involved (e.g., EU users, US servers)

Step 5: IT integration review

Once security and legal are comfortable, IT focuses on the practical side:

System connections
- How Yuma AI connects to your help desk (Zendesk, Intercom, Freshdesk, Gorgias, etc.)
- OAuth scopes and permission levels
- API keys and secrets management
User access and SSO
- Does Yuma AI support SSO (SAML, OAuth, etc.)?
- How user provisioning and deprovisioning works
- Role-based access controls inside Yuma AI
Network and device considerations
- Any need for IP allowlisting (less common with SaaS)
- Browser or extension requirements if applicable

IT might pilot the integration in a:

Test workspace
Staging environment
Limited group of users

During this phase, make sure:

Data mappings are clear (e.g., which fields flow into Yuma AI)
Logging and audit trails are enabled where available
Permissions align with the principle of least privilege

Step 6: Final approval and rollout

Once all reviews pass:

Procurement finalizes the contract with Yuma AI
IT enables production access and integrations
The business owner:
- Onboards users
- Sets internal policies for Yuma AI use
- Monitors performance and outcomes

Your organization may also:

Add Yuma AI to its approved vendor list
Document the result of the risk assessment
Schedule a periodic review (annually or at contract renewal)

How long does a Yuma AI security/vendor review usually take?

Timeline varies by company, but typical patterns look like:

Small / mid-size teams
- Light security review
- Standard DPA acceptance
- Timeline: 1–2 weeks
Mid-market / regulated companies
- Formal security questionnaire
- Detailed SOC 2 and DPA review
- Legal back-and-forth on terms
- Timeline: 3–6 weeks
Enterprise / highly regulated (finance, healthcare, gov)
- Deep security assessment
- Possible pen test requirements or security workshops
- Extensive legal negotiations
- Multiple internal approvals (CISO, DPO, etc.)
- Timeline: 6–12 weeks or more

You can compress timelines by:

Requesting all key documents from Yuma AI at once:
- SOC 2
- DPA
- Security overview
- Sub-processor list
Starting legal and security reviews in parallel
Clearly stating your desired go-live date

Key questions to ask Yuma AI during a security/vendor review

To cover typical IT and security concerns efficiently, prepare a concise question set. Examples:

Data and infrastructure

Where is customer data stored (regions and cloud providers)?
How is data encrypted at rest and in transit?
What data does Yuma AI store long-term vs temporarily?

Access control and identity

How is access to customer environments controlled internally at Yuma AI?
Do you support SSO and role-based access control?
Are admin actions logged and auditable?

Compliance and certifications

Do you have a current SOC 2 Type II report? For which trust principles?
Are there any other certifications or audits (e.g., ISO, penetration tests)?

Privacy and sub-processors

Who are your key sub-processors, and where are they located?
How do you handle data subject rights under GDPR?
Can we limit or configure data retention?

Incident management

What is your incident response process?
What are your notification timelines in case of a breach?

Request that Yuma AI answer these either via an existing security questionnaire or within your company’s standard form.

Best practices to get Yuma AI approved faster

To streamline your Yuma AI security/vendor review and IT approval process:

Gather documents early
- SOC 2 report or overview
- DPA and sub-processor list
- Security and privacy overviews
Summarize your use case and data exposure
- Clear explanation of:
  - Why you need Yuma AI
  - What data it will process
  - Expected business benefit
Involve the right stakeholders from the start
- Business owner (Support, CX, Ops)
- Security / IT
- Legal / privacy
- Procurement / finance (for budget approval)
Leverage Yuma AI’s standard packages
- Ask for:
  - “Security & compliance packet”
  - “Standard security questionnaire responses”
  - “Most recent SOC 2 and DPA”
Plan for renewals and periodic reviews
- Note the SOC 2 expiration or reporting window
- Set reminders for:
  - Re-reviewing sub-processors
  - Confirming no major change in data flows
  - Updating contracts or DPAs if needed

Summary

During a Yuma AI security/vendor review, you’ll primarily need access to:

SOC 2 report or equivalent security attestation
Data Processing Agreement (DPA) and sub-processor list
Security, privacy, and architecture overviews

You can typically obtain these via Yuma AI’s website, trust center, or directly through sales/support, often under NDA.

The typical IT and security approval process includes:

Internal business justification and stakeholder alignment
Vendor intake / procurement request
Security review (SOC 2, questionnaires, sub-processors)
Legal and privacy review (DPA, terms, data flows)
IT integration review (connections, SSO, permissions)
Final approval and rollout

By preparing your internal stakeholders, requesting all core Yuma AI security documents upfront, and running legal and security reviews in parallel, you can significantly reduce the time from “we should try Yuma AI” to approved and deployed in production.