We don't store your tickets. Here's why that matters.

Every enterprise security review we go through starts with the same question. "Where does our ticket data live?"

The answer is: it doesn't. Not with us, anyway.

Support Fusion moves ticket data between two systems. It doesn't keep a copy. The data comes in, gets translated to the destination platform's format, gets pushed across, and gets discarded. The whole thing happens in memory. Nothing is written to disk.

That's not a workaround. It's a deliberate design choice, and it's worth explaining why.

What we actually store today

Let's be specific, because "we don't store your data" is the kind of claim that sounds great in a pitch and falls apart in a security questionnaire. Here's what Support Fusion stores today.

Ticket IDs. When a ServiceNow incident creates a corresponding ConnectWise ticket, we store the two IDs so we know they're linked. That's how the sync knows which ticket to update when something changes on either side. Without this, you'd get duplicate tickets every time the sync runs.

Comment and attachment IDs. Same logic. We track which comments and attachments have already synced so they don't get duplicated.

Sync history metadata. When a sync succeeds or fails, we log the event. The log tells you the ticket ID, the timestamp, and whether it worked. If it failed, the log tells you why, like "category ID not found" or "required field missing." It doesn't include the ticket's content, the customer's name, or anything from the body of the ticket.

API credentials. Your platform's API keys are stored in a separate secrets manager, not in the main database. They're encrypted at rest and in transit. More detail on our security architecture is here.

That's it. No ticket titles. No descriptions. No comments. No attachments. No customer names or contact details. None of the actual content of the tickets your team works on every day.

In the future, we'll also store a small amount of additional metadata, things like category and priority, to power reporting and relationship dashboards for MSPs. When that happens, we'll update this post and our security documentation. But the core principle won't change: we store the minimum needed to do the job, and we don't store ticket content.

Why this shortens security reviews

If you're an MSP with enterprise clients, you already know the drill. Before your client approves a new vendor, their security team needs to understand what data the vendor touches, where it goes, and how long it stays there.

The less data you store, the smaller the attack surface. And the smaller the attack surface, the shorter the security review.

We've seen MSPs get through their client's vendor onboarding in two weeks instead of two months because the answer to "what data do you store?" was genuinely small. There's no PII sitting in our database. There's no ticket content to encrypt at rest (beyond the IDs). There's no data retention policy to negotiate because there's nothing to retain.

Compare that to an integration built in a general-purpose automation tool. Those tools typically store full payloads. Every ticket, every comment, every attachment, sitting in a third-party database that now needs to be covered by the enterprise's data governance policies. That's a longer review, more questions, and more risk.

What this means in practice

Imagine you're an MSP running HaloPSA. Your enterprise client runs ServiceNow. The client's CISO asks your client's IT team: "What data does this integration tool have access to?"

With Support Fusion, the answer is: "It reads the fields we've configured it to read, translates them, pushes them to the other side, and discards the content. It keeps ticket IDs so it knows what's linked. API keys are in a separate secrets manager."

That's a short, clean answer. It doesn't open follow-up questions about data retention schedules, PII handling, cross-border transfers, or long-term storage encryption. The data simply isn't there.

The principle behind it

We call it least-data. Only touch what you need to move the ticket. Only store what you need to prevent duplicates. Discard everything else.

It's the same principle behind least-privilege access controls, which most enterprise security teams already live by. We just apply it to the data itself, not just the permissions.

The result is an integration layer that does its job and stays out of the way. Your client's ticket data lives in your client's ITSM and in your PSA, where it belongs. Not in a third system that now needs its own security review, its own data retention policy, and its own access controls.

Support Fusion connects IT ticketing systems including ServiceNow, ConnectWise, Autotask, Jira, HaloPSA, Zendesk, and more. If you're heading into a security review with an enterprise client, or you're evaluating integration options and data handling is on your checklist, book a demo and we'll walk you through the architecture in 15 minutes.