The Security Questions to Ask a Transfer Vendor

The questionnaire came back on a Friday. All two hundred rows were answered, every one of them "Yes" or "Compliant." The document's author field was set to "Marketing." Nobody on your side read past row forty. That is the usual fate of the borrowed enterprise questionnaire, and the opposite failure is just as common: send nothing and buy on faith. A transfer tool's vendor is part of your attack surface — the case made in the Vendor Assessment series opener. Once you accept that, the practical problem is what to actually ask them.

This article is the middle path: a working question set you can copy, grouped into six themes. It is sized so a vendor can answer it properly in a week and you can digest the answers in an afternoon. Every group comes with the reasoning. It explains what a good answer looks like, what a bad one sounds like, and what the question is really probing. Questions you understand are questions you can follow up on. Questions you pasted from a template are not.

A disclosure before we start: Sysax is a transfer-tool vendor, and this is the question set we believe customers should put to us, too. Nothing below is shaped to flatter our products. Several questions are ones where the honest answer from any vendor, us included, is "no" or "it depends." The article treats those answers with the respect they deserve.

Before You Send Anything

Five ground rules make the difference between a question set that works and one that generates paper.

• Send it in writing, get answers in writing. A written answer is a commitment someone reviewed. A verbal assurance on a sales call is a memory. If the relationship ever sours, the written answers are what you will wish you had.
• Ask about specifics, not adjectives. "Is the product secure?" invites "yes." "Which events does it log, and where can the logs be written?" invites facts. Every question below is built to be answerable with facts.
• Scale the set to the stakes. For a tool moving regulated data on an internet-facing server, send all six groups. For a low-stakes internal tool, pick the handful that matter. Proportionality is covered in why vendor security matters; the short version is that assessment nobody digests is ceremony, not security.
• Stay in your lane, and know its edges. Contract terms, liability, service-level commitments, and formal risk acceptance belong to procurement, legal, and management. This series is education for the technical evaluation, not legal advice. Your job is the substance: whether the answers about cryptography, logging, and patching actually mean something.
• Treat "we can't answer that" as an answer. Sometimes a legitimate one — no vendor should email you their internal network diagrams. But a vendor who cannot tell you how customers learn about security fixes is telling you something important.

Group One: Protocols and Cryptography

Encryption in transit is the reason secure transfer products exist, so start where the stakes are clearest.

1. Which transfer protocols does the product support, and which would you
   recommend we disable in a new deployment?
2. What cryptographic settings are used by default, and can we restrict
   protocol versions and ciphers ourselves?
3. Do you offer a mode using government-validated cryptographic modules,
   if our sector requires one?
4. How are stored passwords, private keys, and certificates protected
   on disk?
5. When a cipher or protocol version becomes obsolete, how do existing
   customers find out, and what is the upgrade path?

Question one has a trap built in on purpose. Almost every mature transfer server supports plain FTP alongside the encrypted protocols, because legacy devices still need it. A good vendor says so plainly and tells you to keep it off unless a documented exception forces it. To show the shape of a real answer: for Sysax Multi Server ours is FTP, FTPS, SFTP, and HTTPS. And yes, the FTP part belongs off for new deployments unless you have one of those exceptions. The product also offers a FIPS 140-2 mode, which is the kind of fact question three is fishing for in regulated sectors. A vendor who answers "all protocols, fully secure" without that kind of nuance has answered an easier question than the one you asked.

Question two matters because defaults are destiny: most installations run whatever shipped. You want the vendor to name their defaults and confirm you can tighten them. Cipher policy should be your decision, not theirs alone. Our cipher policy basics article explains what you would tighten and why. Question four is the one vendors stumble on most. Credentials and keys at rest are a favorite target, and "they're in the database" is not a protection story.

Group Two: Authentication and Access Control

Whoever can log in can move files. This group probes how much control you get over that.

1. What authentication methods are supported: passwords, public keys,
   certificates, integration with our existing user directory?
2. Can we enforce password rules, lock accounts after repeated failures,
   and restrict connections by IP address?
3. Is multi-factor authentication available, natively or by integration?
4. How is administrator access separated from user access, and are
   administrator actions themselves logged?
5. Can each account be confined to specific folders and operations?

The first question is about fit with what you already run. Password, key, and certificate trade-offs get full treatment in authentication methods compared. You are checking the vendor supports the method your policy prefers, not the other way round. Directory integration is the quiet, enormous win here. Transfer accounts die when the employee's main account dies, and orphaned transfer accounts are a classic way in. They are also patient; an orphan will wait years for someone to guess its password.

Questions two and five are the containment questions. Lockout and IP restrictions blunt the credential-guessing attacks every internet-facing server receives daily. Per-account folder confinement decides whether one stolen password exposes one partner's folder or everything. Question three deserves a straight answer even when it is "not natively." Multi-factor support varies widely across transfer products, ours included. How a vendor handles a capability they lack tells you more than the capability itself. Question four is the one people forget. Administrators are the highest-value accounts on the system. A product that cannot log its own admins leaves your investigators blind exactly where it hurts most.

One follow-up worth adding if automation is in your picture: ask how the product handles service accounts. These are the non-human accounts that scheduled jobs use to sign in. They tend to hold long-lived credentials and broad folder access, which makes them a favorite target. A vendor should be able to say how those credentials are stored and scoped on their platform. Our article on service account hygiene covers what good looks like on your side of that equation.

Group Three: Logging and Visibility

When something goes wrong — and the honest premise of this whole series is that someday something will — logs are the difference between an investigation and a guess.

1. Which events are logged: sign-ins and failures, uploads, downloads,
   deletions, renames, permission changes, configuration changes?
2. Where can logs be written - local file, database, an external log
   system - and in what format?
3. Can logs be protected from tampering by the very accounts they record?
4. What is logged about administrator and support activity?
5. Can the product alert us on suspicious patterns, such as repeated
   failed sign-ins, or does that require external tooling?

The first question has a precise benchmark: could you reconstruct, from logs alone, who touched a specific file, from where, and when — including the failed attempts? Our companion piece what to log on a transfer server defines that baseline in detail. The second is about getting logs out of the box and into wherever you centralize evidence. As a concrete example of the shape to expect, Sysax Multi Server writes activity logs to file and to a database. That covers both the quick-look case and the feed-it-elsewhere case. Whatever vendor you assess, insist on a real answer here rather than "full logging." I have seen "full logging" mean a per-file audit trail, and I have seen it mean a text file that records when the service started.

Question three is subtler than it looks. If the transfer service's own administrator can silently truncate the log that records administrators, your evidence has a hole in it precisely where attackers aim. Acceptable answers involve writing logs somewhere the service account cannot rewrite history — an external destination, an append-only store, restrictive permissions on the log path. A log its own subject can edit is a diary, not evidence.

Group Four: Patching, Advisories, and Vulnerability Handling

This group is the heart of the modern assessment, because the industry's worst transfer-tool incidents turned on exactly these behaviors.

1. How do customers learn about security vulnerabilities in the product?
   Where are advisories published, and can we subscribe?
2. Is there a documented way for outside researchers to report a
   vulnerability to you?
3. When a serious flaw is found, how quickly do you aim to release a fix,
   and how does it reach customers?
4. How long is each release supported with security fixes, and how much
   notice do customers get before support ends?
5. Has the product had serious vulnerabilities before, and can we read
   how they were handled?

Question five is the counterintuitive one. A vendor with a published history of vulnerabilities, advisories, and fixes is not thereby worse than a vendor with a spotless page. Every non-trivial product accumulates flaws; the difference is whether they surface through the vendor's own process or through an attacker's exploitation. A documented, calmly handled flaw is evidence of a working process. A perfectly empty record means either an exceptional product or a vendor who does not look hard, does not tell, or has not yet been interesting to attackers. You cannot tell which from the outside.

Questions one and three are about your operational reality: when the bad week comes, how fast can you know, and how fast can you act? Wire the answers directly into your own update and patch strategy — a vendor advisory feed you never subscribed to protects nobody. Question four guards against the slow-motion failure: running a transfer server that quietly aged out of security support. The follow-through on all of these after purchase is its own discipline, covered in staying alert after the purchase.

Group Five: Data Handling, Deployment, and Support Access

The final themed group asks the bluntest question in assessment — who, exactly, can touch our data? — and its answers depend heavily on the delivery model.

1. Does our data ever pass through, or rest on, your infrastructure?
   Where, and under what protections?
2. If the product is a hosted service: how are customers isolated from
   each other, and which of your staff can access customer data?
3. If the product is self-hosted: what does it send back to you -
   telemetry, license checks, update checks - and can we see or limit it?
4. During a support case, what access does your team need? Is it
   time-limited, initiated by us, and logged?
5. If we leave: how do we export our data and configuration, and what
   happens to any copies you hold?

Question one splits the world in two. A hosted transfer service holds your files on the vendor's systems, which makes questions two, four, and five load-bearing. Tenant isolation, staff access controls, and exit terms are the fabric of that trust. A self-hosted product keeps your files on your servers. With our own server product, for instance, transfers terminate on your Windows machine and nothing about your data ever reaches us. That retires question two but raises question three in its place. Even self-hosted software may phone home for licensing or update checks, and you are entitled to know what travels. Neither model wins by default. The full trade-off is the subject of self-hosted vs SaaS risk. Data-location questions matter double when flows cross borders — see the cross-border transfers series for that dimension.

Question four applies to everyone and is routinely overlooked. Support sessions are legitimate, useful, and a real access path. A support engineer remotely driving your admin console has, for that hour, more power than most of your own staff. You want that access to exist only when you start it, and to appear in a log. It should end when the case ends rather than when somebody remembers it.

Reading the Answers

The set above only pays off if you can tell a good answer from a fluent one. Three sorting rules cover most of it.

Good answers are specific, bounded, and checkable. They name events logged, places advisories are published, notice periods for end of support. They volunteer limits — "off by default," "requires an external component," "not supported on that protocol." Specifics invite verification, and vendors who invite verification are usually vendors with little to hide.

A clear "no" is a good answer. Every real product has gaps, so a vendor whose every answer is "yes" has either misunderstood your questions or answered them optimistically. "No, but here is the workaround" or "no, and here is why we chose not to" reflects a vendor who read the question and told the truth. You will want the same grace extended to you when partners send questionnaires in your direction. This series covers that role reversal in its own article.

Adjectives are not evidence. "Military-grade," "bank-level," "fully compliant" — when an answer leans on marketing vocabulary, re-ask the question in facts. And wherever a claim can be tested, test it: install the trial in a lab, speak the protocols, read the logs, fail some logins. We keep trials of our own software on the download page precisely because "verify it yourself" is the only answer to this group that fully counts. That applies to answers from us or from anyone. The art of separating claims from substance — including what attestation reports genuinely prove — is the subject of the next article, reading vendor security claims.

Making It Yours

Copy the six groups into a document, and delete what does not apply to your stakes. Add the two or three questions unique to your environment — your directory service, your regulated data class, your partner quirks. The commercial and operational questions — licensing metrics, support hours, exit terms — are a separate set, collected in questions every transfer server vendor should answer. The two travel well together. Send both early in the conversation, while the vendor is most motivated. File the answers with the purchase records. They are the baseline you will re-check against at renewal time. (A vendor is never more motivated than in the last week of a quarter. Use that.)

A simple scoring habit keeps the exercise honest. Against each answer, mark one of three outcomes. Use verified if you tested it or saw evidence. Use credible if it is specific and consistent but not yet tested. Use open if it is vague, missing, or refused. A purchase can proceed with open items — most do. But every open item should be written down with a named owner and a date. Unwritten concerns evaporate the moment the contract is signed.

Bluewater Bank's assessor once marked all twenty-six of a vendor's yeses as credible rather than verified. That is the only reason the trial included a test of per-account folder confinement. Confinement, it turned out, meant that each account saw its own folder by default and every other folder if it typed the path. The answers had not been false so much as hopeful. The trial cost an afternoon; the same discovery after go-live would have cost a re-audit of every partner folder on the server.

From here, continue with reading vendor security claims without getting fooled for the skeptic's toolkit. Or jump ahead to the self-hosted vs SaaS risk trade if the deployment-model questions hit closest to home. Twenty-something questions, honestly asked and carefully read, will tell you more than any brochure ever will — and more than two hundred rows ever did.

Frequently Asked Questions