> For the complete documentation index, see [llms.txt](https://docs.threatdefence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.threatdefence.com/service-providers-msp-and-mssp-1/soc247-prequalification-1.md).

# soc247 prequalification (1)

> A 5-minute fit check for ThreatDefence SOC247 services. Replaces a 60-minute discovery call and tells you within minutes whether we're the right partner — and whether you're ready to onboard.

## Who this page is for

This form has two modes — toggle at the top of the form below:

{% tabs %}
{% tab title="Direct enterprise" %}
You're a security or IT leader evaluating a 24/7 SOC + SIEM service for your own organisation.
{% endtab %}

{% tab title="MSP partner" %}
You're a managed services provider looking to resell, white-label, or augment your existing SOC capability.
{% endtab %}
{% endtabs %}

Pick whichever applies. The questions adapt accordingly.

## What happens after you submit

Each submission is reviewed by our team within one business day. You'll receive a direct response from a ThreatDefence team member matched to your profile (channel team for MSPs, enterprise team for direct), a summary of where we see strong fit and any areas worth a deeper conversation, and where appropriate a calendar link for a 30-minute scoping call. We don't pass details to a generic SDR pool.

## The form

{% embed url="<https://tally.so/r/ODoo0R>" %}

{% embed url="<https://wassets.deploydefend.io/webDocuments/td-prequalification.html>" %}

***

## Why we ask these questions (and not the usual ones)

Most SIEM vendors lead their pre-qualification with **ingest volume**: how many gigabytes per day, which sourcetypes, what retention. That framing turns the buyer into a meter reading and pushes the real conversation — outcomes, ownership, response — into a much later stage where switching cost is already high.

We do it the other way around. The questions in the form are the ones that genuinely predict whether the engagement will succeed — why now, who actions an alert at 2am, where data lives, and who decides. Five minutes spent here saves both of us five weeks of wrong-fit discovery.

## Frequently asked

<details>

<summary>Is this a sales-qualification form for your benefit, or for ours?</summary>

Both. The verdict logic is calibrated so that *you* see whether ThreatDefence is the right fit — not just whether you'd be a good prospect for us. If the form returns "Disqualify" or "Marginal — nurture", that's a genuine signal that another approach (or another vendor) might serve you better, and we'll say so.

</details>

<details>

<summary>What if my situation doesn't fit cleanly into the options?</summary>

Pick the closest match and use the contact details to add context. The form is a fast filter, not a contract — anything that needs nuance gets covered in the follow-up call.

</details>

<details>

<summary>Do you really not ask for ingest GB/day?</summary>

Correct. We size pricing based on user count, endpoint count, and active-license formula — not raw ingestion volume. This is a deliberate commercial choice that aligns our incentives with yours: we don't make more money the noisier your environment gets.

</details>

<details>

<summary>How is my data handled?</summary>

The form submits via an encrypted relay (Web3Forms) directly to a monitored ThreatDefence inbox. Submissions are not stored on third-party servers beyond delivery; they're treated as commercial enquiry data under our standard privacy posture. No data from this form is used for marketing automation or shared with third parties.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.threatdefence.com/service-providers-msp-and-mssp-1/soc247-prequalification-1.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.