Answering the Security Questionnaires Aimed at You

The spreadsheet lands on a Tuesday. It has a hundred and forty security questions from a large customer, a new trading partner, or your organization's insurer. There is a two-week deadline, and a note that the contract depends on it. Most of this series teaches you to interrogate vendors; this morning the direction has reversed. Somewhere around question thirty — "Describe your cryptographic key management program" — the panic sets in. That is because nobody ever wrote your answers down, and some of the honest ones are "no."

Take a breath. Questionnaires are a genre, and genres can be learned. The askers are doing to you exactly what this series teaches you to do to vendors. So you already understand their real goal: evidence that you will not become their breach. This article covers the craft of responding. It explains decoding generic questionnaire language into your transfer reality, and answering honestly without oversharing. It covers saying "no" in a way that builds trust instead of ending deals. It covers building an answer library so the next questionnaire takes hours instead of weeks, and handling the dreaded "we require X" clause. It belongs to our Vendor Assessment series. It is advice we use ourselves: Sysax answers these questionnaires too, and everything below is the practice we try to hold.

Why You Are Receiving This

The first useful realization is that you are someone's vendor. You are not necessarily a software vendor. But if files flow between your organization and theirs, you are part of their supply chain. That is the web of outside parties whose failures can become their failures. Modern security programs assess the supply chain. The well-publicized breaches that traveled through file transfer products taught everyone that lesson, which is why transfer questions now appear prominently in almost every questionnaire.

The second useful realization is that the person reading your answers is drowning. They sent the same spreadsheet to dozens of suppliers and are wading through vague, defensive boilerplate. An answer set that is specific, honest, and clearly written by someone who knows the systems stands out immediately. It tends to generate fewer follow-up rounds, not more. You experienced this from the other side in the security questions to ask a transfer vendor: recall which vendor answers impressed you, and be that vendor.

The third realization is about stakes: in many deals, your answers get attached to the contract as representations. That is why the ground rule of this entire article is never answer better than the truth. It is also why final review of what gets submitted belongs with management, procurement, or legal, not the admin alone. As throughout this series, this is education, not legal advice; your job is to make the technical content accurate. I have drafted these from this side of the table too, and the first draft is always more optimistic than the server.

Decoding Questionnaire Language

Questionnaires are written generically, for every kind of supplier at once, so the questions arrive in abstract compliance language. Your first task is translation — mapping each abstraction onto your concrete transfer estate. Some frequent translations:

• "Is data encrypted in transit?" means: which protocols do your transfer flows use, on which connections? Your answer names them — for example SFTP and FTPS for partner flows — and states what is not allowed, such as plain FTP. If any cleartext legacy flow survives, this question is where you disclose it and describe the containment.
• "Describe your access control" means: how do accounts get created, approved, scoped, and removed on the systems that touch the asker's data? Named accounts, least-privilege folder access, and a leaver process are the substance they are looking for.
• "Do you log access to data?" means: if the asker's file went missing, could you reconstruct who touched it, from where, and when? Transfer logs are your answer, and the baseline in what to log on a transfer server is a good self-check before you claim it.
• "Describe your vulnerability management program" means: how do you learn about flaws in what you run, and how fast do you patch? A named owner, an advisory subscription, and a patch rhythm are a complete answer at most scales.
• "Do you assess your own third parties?" means: the recursion is real — they want to know whether your vendors get vetted. The assessment habits from this very series are your answer.
• "Is data encrypted at rest?" means: what protects the asker's files while they sit on your server between transfers — and, just as important, how long they sit there. An answer that pairs the storage protection you have with a short, automated retention window is stronger than either alone. The retention half of that story is covered in our retention and deletion series.
• "How is our data returned or destroyed at the end of the relationship?" means: do you have a deletion practice you could actually demonstrate? That would be a purge policy with a schedule, and a log of what was removed. Or would their files quietly outlive the contract in a forgotten folder?
• "Have you experienced a security incident?" means: answer carefully, truthfully, and with legal review if anything reportable exists. "No" written casually over a forgotten incident is the single most dangerous sentence in the genre.

One more decoding rule saves enormous effort: establish scope before answering anything. The questionnaire concerns the systems and flows that touch the asker's data. Usually, that means your transfer server, the folder structure their files land in, and the staff who administer them. You are not obliged to describe your entire estate. A one-line scoping preface ("answers below cover the managed transfer environment through which your data flows") keeps both sides oriented and keeps you from over-disclosing. Nobody asking about their files needs to hear about your print server.

The Golden Rules of Honest Answering

Four rules cover nearly every judgment call.

1. The truth, exactly. Optimistic answers become liabilities the day an incident invites comparison between what you said and what you ran. If a control is partial, say "partial" and describe the boundary. Truthful answers also stay stable — you will not have to remember what you claimed.
2. Answer what was asked, and stop. Honesty does not require volunteering your network diagram, your exact software versions, or your firewall rule set. Describe controls: "remote administrative access requires a VPN and is restricted by source address." Do not describe configurations: "the admin interface listens on this port at this address." The asker needs assurance, not a reconnaissance report — and a mature asker respects the difference.
3. Specifics beat adjectives. "We take security very seriously" is the same empty calorie you learned to discount in reading vendor security claims. "Partner uploads land in per-partner folders with per-account permissions, and activity is logged to a database retained for one year" is an answer. Hold your own prose to the standard you hold vendors to.
4. Date and sign everything. Answers describe a moment. Note when they were written and by whom, so that next year's reviewer — possibly you — knows what vintage they are reading.

Saying "No" Gracefully: The Three-Part Answer

Every real environment produces some honest "no" answers, and how you deliver them decides how they land. A bare "no" reads as negligence. A defensive paragraph reads as evasion. The professional form has three parts: the honest no, the compensating control, and the trajectory — what you do instead, and where this is heading. Askers accept "no, but" answers constantly; what they cannot accept is discovering later that "yes" meant "no."

Worked examples you can adapt:

Q: "Is multi-factor authentication enforced for all access?"

WEAK:   "No."
BETTER: "No. Interactive administrative access to the transfer server
        requires VPN access, which itself enforces a second factor.
        Partner transfer accounts authenticate with public keys rather
        than passwords, which resists phishing and credential guessing.
        MFA for the remaining interactive accounts is on our roadmap
        for the coming year."

Q: "Do you hold a SOC 2 report or equivalent certification?"

WEAK:   "No."
BETTER: "No — at our size we have not undergone a formal attestation.
        In its place we can provide: our transfer security policy, a
        summary of controls (encryption in transit, per-account access,
        activity logging, patch process), and a walkthrough session
        with the administrator. We are open to discussing which
        evidence would satisfy your requirement."

Q: "Is a twenty-four hour security operations center monitoring your
    systems?"

WEAK:   "No."
BETTER: "No. Failed sign-in alerts and transfer job failures notify
        the on-call administrator by email in real time; alerts are
        reviewed on the next business day at latest. Given the size of
        our environment we believe this is proportionate; we are happy
        to discuss the specific monitoring your data class requires."

Q: "Is stored data encrypted at rest?"

WEAK:   "No."
BETTER: "Not at the disk level today. Partner files rest on the
        transfer server only briefly - an automated cleanup removes
        them within seven days of delivery - and our most sensitive
        feeds are encrypted at the file level before they leave the
        sending system, so those files are never stored in the clear.
        We can extend file-level encryption to your flows on request."

Notice what the better answers share: no apology, no bluster, a real control in the middle, and an invitation to keep talking. The middle part must be true — a compensating control you do not actually operate is just a slower lie. If the honest middle is thin ("no, and nothing currently compensates"), say that. In that case, let the trajectory carry the answer: "we recognize the gap; remediation is planned and we can commit to a date." If the phrasing "on our roadmap" is not true either, do not write it; askers remember roadmaps.

Building the Reusable Answer Library

The first questionnaire is expensive; the tenth should be cheap. The difference is an answer library: one maintained document holding your standard answers, so each new questionnaire becomes assembly rather than authorship. Assembly takes an afternoon, one cup of coffee, and no panic at question thirty.

Structure it by theme rather than by any single questionnaire's numbering. Use themes such as encryption in transit, authentication, access control, logging and monitoring, patching, incident response, data retention, and sub-vendors. For each theme keep four fields. Start with the current answer (a short paragraph in the three-part style where relevant) and the evidence pointer (where proof lives if a follow-up asks). Add the last-reviewed date and the owner. The evidence pointers do double duty at audit time. If you already maintain the evidence habits from our audit-ready reporting series, the library mostly indexes what exists.

Concreteness makes evidence pointers work. For the logging theme, for instance, the pointer should name the actual mechanism. In our own environment that is the activity logging in Sysax Multi Server, which records transfer activity to file and to a database. So "can you evidence access logging?" is answered with a sample export rather than a promise. Whatever software you run, the pattern is the same: name the mechanism, know the export, keep a sanitized sample ready.

Here is what a single finished entry looks like on the page:

ONE LIBRARY ENTRY, WORKED

THEME:         Logging and monitoring
ANSWER:        "All transfer activity - sign-ins and failures, uploads,
               downloads, deletions - is logged with account, source
               address, and timestamp. Logs are written to file and to
               a database and retained for one year. Repeated failed
               sign-ins raise an alert to the administrator."
EVIDENCE:      one-page sanitized activity-log export; sample alert
               email; retention configuration shown on request
LAST REVIEWED: <month>, by <name>
OWNER:         transfer server administrator

Ten to fifteen entries of that shape cover the transfer-relevant portion of nearly every questionnaire you will ever receive. The discipline of writing them surfaces gaps on your schedule instead of a customer's.

Two maintenance rules keep the library alive. First, review it on a rhythm — twice a year suits most teams — and after any meaningful change to the transfer estate. A stale library quietly turns honest answers into false ones. Second, keep it consistent: when two customers receive contradictory answers to the same question, the contradiction eventually surfaces, usually at the worst moment. One library, one truth, many recipients. File a copy of every completed questionnaire you send back, because askers do re-read their archives.

Acme once answered a customer's questionnaire in a single afternoon, with "yes" in every row that looked reasonable, including "activity logs retained for one year." Eighteen months later the customer's auditor asked for a sample from a particular month. The actual retention setting turned out to be ninety days. Nobody had lied; somebody had guessed. Fixing the setting took an hour. Explaining the discrepancy took a week of careful email. The answer library was born that Friday, with a date and a name on every entry.

Handling the "We Require X" Clause

Sooner or later a questionnaire arrives with teeth: "suppliers must maintain X" — a specific protocol, encryption at rest, MFA, a certification. When X is something you lack, work the sequence before either capitulating or walking away. Both are popular; neither is usually necessary.

1. Check scope. Does the requirement apply to the systems handling their data, or is it boilerplate meant for cloud platforms holding millions of records? A scoping conversation resolves a surprising fraction of clauses.
2. Check configuration before purchase. X is often available in what you already run, unconfigured. A requirement for key-based SFTP, for example, may be a settings change on your existing multi-protocol server rather than new software. That is worth an hour of checking before any procurement conversation.
3. Offer a compensating control. Many "require X" clauses accept equivalents when asked. A demand for encryption at rest on transferred files, for instance, can sometimes be met by encrypting files before they travel. That is the encrypt-before-send workflow. Tools with OpenPGP support such as Sysax FTP Automation can fold it into a scheduled job. Propose the equivalent in writing and let them rule on it.
4. Price the gap honestly. If X is genuinely absent and uncompensated, someone above you should decide whether the deal justifies the cost of building it. Requirements from big customers are, viewed calmly, a subsidized security roadmap: you were probably going to need MFA eventually anyway.
5. Be willing to say no. Occasionally the honest response is that you cannot meet X at your scale, stated plainly. Losing a mismatch early is cheaper than failing an obligation later.

When the Questionnaire Doesn't Fit You

Small organizations regularly receive questionnaires written for enterprises — questions about staffed security operations centers, dedicated compliance officers, formal committees. Answering "no" ninety times in a row serves nobody. The proportionate move is a short cover note plus honest answers. Use one page stating what you are: team size, what you run, and the handful of controls that genuinely protect the asker's data. Those controls are encryption, named accounts, logging, patching, and backups. Then put the spreadsheet, completed truthfully, underneath. Most reviewers, reading a clear picture of a small-but-careful operation, apply proportionate judgment. The ones who cannot were never going to fit, and you have learned that early. That is the same early-warning gift you get when a vendor answers your own questions badly.

Both Sides of the Table

Every technique in this article — translation, scoping, the three-part no, evidence pointers — is the mirror of what you demand from vendors elsewhere in this series. The symmetry is the point. Practicing one side makes you sharper at the other: you will write better answers for having graded them, and grade better for having written them.

So treat the next questionnaire as a rehearsal rather than an ordeal. Your library gets richer, your gaps get named, and your organization gets a written, honest account of its transfer security. That account serves audits, insurers, and incident response alike. To sharpen the grading side, revisit the security questions to ask a transfer vendor and reading vendor security claims. To keep the whole relationship honest over the years, continue to vendor security after the purchase. And when the next spreadsheet lands on a Tuesday, the library will be open before the panic is.

Frequently Asked Questions