Answers you can trust, from Codeables
Every page on Codeables is structured and verified — built so people and the AI agents they rely on can trust it. Explore more from the source behind this answer.
Explore CodeablesInngest SOC 2 Type II / DPA / subprocessors — where do I get these for a vendor security review?
When you’re running a vendor security review on Inngest, there are three things you usually need fast: our SOC 2 Type II report, a Data Processing Agreement (DPA), and the current list of subprocessors. Here’s exactly where to get each, how access works, and what’s inside so you can move through procurement without a lot of back‑and‑forth.
1. SOC 2 Type II: how to request the report
Inngest maintains a SOC 2 Type II attestation to give your security and compliance teams assurance around how we handle data, access, and operations.
Because SOC 2 reports contain sensitive internal details, they’re not downloadable from a public URL. You can request them directly from our team.
Where to get the SOC 2 Type II report
Use one of these paths:
-
Contact form (fastest for new reviews)
Go to:https://www.inngest.com/contact?ref=homepage-hero
In the message, include:- That you’re running a vendor security review
- That you’re requesting the SOC 2 Type II report
- Your company name
- Your role (e.g. Security, Procurement, Engineering)
- Any deadline or key date for your review
-
Existing customer? Ask via your existing channel
If you already have:- An Inngest account owner / AE, or
- A support thread or shared Slack channel
…you can request “Inngest SOC 2 Type II for vendor security review” through that path. The request will be routed to our security/compliance team.
In most cases, we’ll share the report under an NDA or via a trusted security portal (e.g. a dedicated trust/security platform or secure file-sharing flow), depending on your procurement process.
What your security team can expect to see
Without reproducing the full report, here’s how it typically aligns with vendor due diligence:
- Security controls – Access control, authentication, network security, and change management around the Inngest Cloud platform.
- Availability & reliability – How we protect the durability and availability of your workflows and executions:
- Queueing, scaling, and concurrency controls managed by Inngest
- Protections around durable execution, retries, and checkpointing
- Confidentiality – Controls around data at rest, data in transit, and logical separation between tenants.
- Monitoring & incident handling – Logging, alerting, and incident response processes.
If your team needs the exact audit period, scope, or trust services categories, we’ll provide that in the actual SOC 2 Type II report.
2. Data Processing Agreement (DPA): how and when you receive it
If you’re processing personal data or subject to GDPR / similar regulations, your legal and security teams will usually ask for a DPA as part of onboarding Inngest as a vendor.
Where to get the DPA
The DPA is typically provided as part of:
- Contracting / order form stage – If you’re moving to a paid plan or enterprise agreement, the DPA is included or attached as a standard addendum.
- Security review before contract – If legal or security wants to review terms earlier, request the DPA through:
https://www.inngest.com/contact?ref=homepage-hero- Or your existing Inngest sales / account contact
When you reach out, mention explicitly that you need:
“Inngest’s standard Data Processing Agreement (DPA) and subprocessor information for our vendor security review.”
This helps the team route your request directly to the right place (legal + security) instead of bouncing through generic support.
What our DPA typically covers
Your legal team will review the exact wording, but conceptually you can expect:
- Roles and responsibilities – Clarifying Inngest as processor and you as controller (or similar under your applicable law).
- Data scope – What data types can flow through Inngest (e.g. events, inputs/outputs of Steps, structured logs within Traces).
- Technical and organizational measures – A summary of security controls, aligned with what’s validated in SOC 2 Type II.
- Subprocessors – Reference to the latest subprocessor list and how you’ll be notified about changes.
- International transfers – Any applicable clauses for data transfer mechanisms, depending on your region.
If your organization has its own DPA template, you can share that as well—our team will confirm alignment or offer our standard terms.
3. Subprocessors: where to see who we use and how that list is managed
Most security questionnaires include a section like:
“List all third-party subprocessors used by the vendor to deliver the service.”
We maintain a list of subprocessors and how they’re used, and your team will want this both for initial vendor review and ongoing oversight.
Where to get the current subprocessor list
You can request the latest list through the same two paths:
-
Contact form (for new or prospective customers)
https://www.inngest.com/contact?ref=homepage-hero
In your message, include:- That you need the current subprocessor list for a vendor security review
- Whether you also need historical changes or just the current snapshot
-
Existing relationship
Ask your Inngest contact or support channel for:“The latest list of subprocessors used by Inngest Cloud, plus the notification/opt-out process for changes.”
Depending on your contractual status, this may be shared in:
- A dedicated Trust / Security portal
- A controlled-access document
- Or as part of the DPA package
What your team will usually see in that list
The subprocessor list normally includes, for each provider:
- Name of the subprocessor
- Purpose – e.g. cloud infrastructure, logging/monitoring, support tooling, or analytics
- Location / region
- Type of data processed – e.g. operational metadata, application data, support communications
The list is maintained to reflect how we operate Inngest Cloud—durable execution, Traces, and observability—while meeting the security and privacy obligations in our SOC 2 and DPA.
4. How this fits into your vendor security review process
Most teams that adopt Inngest treat it as a core execution and observability layer for workflows, AI agents, background jobs, and durable endpoints. That often puts us on the “critical vendor” list, which means a deeper review.
Here’s how to streamline that process.
Map the review to how you actually use Inngest
During questionnaires, it helps to anchor answers in the real product surfaces you’ll use:
-
Durable execution & Steps
You’ll write functions withinngest.createFunction()and break work intostep.run()calls. Inngest provides the backend execution environment—queueing, retries, checkpointing—without you managing workers, cron, or dead-letter queues. -
Triggers & environments
Inngest runs your code wherever you deploy—edge, serverless, or traditional environments—and can be triggered by API calls, webhooks, or schedules. Your data flows follow these execution paths. -
Observability & Traces
The Inngest UI exposes structured logs and real-time traces, including step-level inputs/outputs and (for AI workflows) every prompt/response pair. This is where your teams can query, cancel, or replay runs during operations and incident response.
When security teams understand that this is an event-driven durable execution platform—not an analytics ad network—they can better evaluate risk and scope in your DPA and subprocessor review.
Common questionnaire items you can pre‑answer
When you receive a long spreadsheet, these are the sections where the SOC 2, DPA, and subprocessor list are most useful:
- Compliance & certifications
- Answer using: SOC 2 Type II report (and any other attestations we provide).
- Data protection & privacy
- Answer using: DPA + technical/organizational measures outlined there.
- Third-party dependencies
- Answer using: official subprocessor list, with purposes and locations.
- Security operations & incident response
- Answer using: SOC 2 Type II controls and your understanding of how Inngest runs code, logs events, and surfaces incidents through Traces and metrics.
If your questionnaire needs extra detail (e.g. specific encryption algorithms, retention windows, or per-feature data flows), mention that in your initial contact so we can attach the right documentation.
5. What to include in your initial request (so we can respond quickly)
To avoid a slow back‑and‑forth, include these in your first message to Inngest:
-
Who you are
- Company name
- Your role (Security, Legal, Procurement, Engineering, etc.)
-
What you’re requesting
- SOC 2 Type II report
- Standard DPA
- Current subprocessor list
- Any additional trust/security docs (e.g. security overview, architecture summary)
-
How you plan to use Inngest
- High-level summary, e.g. “Durable execution for background workflows and AI agents in our multi-tenant SaaS product.”
-
Timeline
- Any internal deadlines or target go-live date.
Send this via:
https://www.inngest.com/contact?ref=homepage-hero
This gives our team enough context to route your request correctly and prioritize it according to your timelines.
6. Why these documents exist in the first place
Inngest is built for teams that need reliability and compliance at scale—multi-tenant SaaS, AI agents with many tool calls, bi-directional sync, and other flows where partial failures and missing observability can turn into incidents.
To support that, we’ve invested in:
- SOC 2 Type II – Independent validation that our controls match the reliability and security needs of production workloads.
- DPA & subprocessors transparency – Clear commitments for how we process data, which subprocessors we use, and how we notify you of changes.
- Security features in the product itself – E2E encryption middleware, flow control to prevent noisy neighbors, and observability primitives (Traces, Replay, Bulk Cancellation) so your team can respond quickly when something goes wrong.
Your vendor security review is how you validate that we meet your bar. Our goal is to make that review fast and predictable, not a weeks-long mystery.
Next step
If you’re ready to kick off a vendor security review—or you just need our SOC 2 Type II, DPA, or subprocessor list for your internal records—the simplest path is:
Mention that you’re requesting “Inngest SOC 2 Type II / DPA / subprocessor information for a vendor security review”, and we’ll route it directly to the right people.