The Enterprise Security Questionnaire Is a Sales Document. Treat It Like One.

A spreadsheet arrives with 180 rows. Sometimes it is a PDF, sometimes a portal on UpGuard or Whistic or SecurityScorecard with a login that expires. A due diligence for an acquisition can run to 250 or 300 questions. The deal you have worked for four months now depends on someone filling it in, and that someone is your best engineer, who had other plans for the week.

The instinct is to treat it as a compliance chore: answer defensively, say yes where you can, hope nobody reads closely. That instinct is what turns a two-week review into a two-month one, and on a platform it is actively dangerous, because every yes is a commitment to produce the document behind it.

A security questionnaire is a sales document. It is read by a person who has to decide whether recommending you will look reasonable in six months. Everything below follows from that.

---

First: you are already being graded

The thing most teams miss is that the questionnaire is only half of it. Platform-based reviews pair the questionnaire with an external scan of your perimeter, run before you answer anything, and reduce it to a letter grade or a score out of 900. Your buyer sees that grade next to your name. Some of them see it before they contact you.

The scan is automated and it looks only at what is reachable from the internet: TLS configuration, HTTP response headers, open ports, exposed admin panels, DNS records, email authentication, and whether anything on your domains looks unpatched.

Two consequences, and both are good news.

The scan is the cheapest part to fix. These are configuration changes, not architecture. Most of a scan grade moves in an afternoon.

The scan is the part you cannot talk your way out of. You can explain a process gap in prose. You cannot explain away a plaintext IMAP port that a machine can see.

So fix the scan before you answer the questionnaire, not after. And answer the questionnaire from a verified state, not from last year's response document. It is very common to find items a previous response reported as closed that are quietly open again: a header lost in a config regeneration, a port reopened by a panel update. If the buyer re-scans, every one of those resurfaces, and now you have a credibility problem rather than a configuration problem.

What the auditor is actually checking

You are usually read by one of three people, and they want different things.

A security auditor is checking for internal contradictions. They will notice if you claim formal quarterly access reviews and also say you have no identity provider, or if you claim source-IP allowlisting on your admin panel while the host has no firewall enabled at all. They are not trying to catch you out. They are calibrating how much of the rest to believe.

A procurement or legal reviewer maps your answers onto their own policy: data location, subprocessors, breach notification timelines, return and destruction of data at the end of the contract, and whether any of it contradicts the agreement you are about to sign.

The business sponsor, the person who actually wants your product, is checking whether this will be painful. They are your ally. Give them something they can forward.

The useful mental model: nobody is asking "are you secure". They are asking "if this goes wrong, will my decision to approve this look careless".

The perimeter half: what a scan sees, and what to do about it

In rough order of how often these show up, and how much they cost you.

Transport security. TLS 1.2 and 1.3 only, older protocols disabled, no weak ciphers. Force HTTPS and add HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains). One honest caveat from practice: fully forcing TLS 1.3 can break older client software, so check what your customers actually connect with before you turn it on. That is a real compatibility decision, not an excuse, and it is worth writing down which clients constrain you.

Response headers. X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy, and a Content-Security-Policy. Start CSP in report-only mode and promote it to enforcing after a week of clean reports, or you will break your own front end on a Friday. If you use a hosting control panel that regenerates vhost configs from templates, set headers in a global include and then verify with curl -I that they actually appear, because a per-vhost directive will silently override you.

Exposed surface. Every open port is a question you will be asked. Admin panels and control panels restricted to trusted IPs, never open to the internet. Databases bound to localhost. Plaintext mail protocols (110, 143) closed in favour of the TLS ports (993, 995). A host firewall actually enabled, with SSH allowed before you enable it, and a second session held open while you do, because the classic way to lose a production box is to enable a firewall that blocks your own way back in.

SSH. Key-based authentication only, PasswordAuthentication no. Many teams plan this and never apply it; the scan and the questionnaire both ask.

Patch level. This is the one that quietly fails audits. A server can have every security update installed on disk and none of them live, because it has not been rebooted since the kernel was replaced. An uptime you are proud of is an uptime the auditor reads as unpatched. Check for a pending reboot, take a snapshot, confirm you have console and rescue access from your provider, and take the maintenance window.

DNS and email authentication. SPF, DKIM, and DMARC. Move DMARC from p=quarantine to p=reject only after reviewing a week of aggregate reports for legitimate senders you forgot about. Add a CAA record naming the certificate authorities allowed to issue for your domain.

Certificates: trusted, and bankable

Two separate requirements that get conflated.

Trusted means the certificate chains to a CA in the buyer's trust stores. In practice any mainstream automated CA satisfies this, and automated renewal matters far more than the brand: an expired certificate is simultaneously an outage, a scan finding, and an incident you have to explain.

Bankable is the procurement question, and it is about your providers rather than your certificate. When the questionnaire asks about hosting, storage, and subprocessors, the useful answer names providers whose own certifications and audit reports the buyer's procurement team already accepts, and whose reports you can actually hand over. This is the one place where you get to inherit someone else's compliance work: your cloud provider's certifications do real work for you, and it costs you nothing but naming them accurately.

The corollary is that a provider nobody has heard of, or infrastructure sitting under a director's personal account, is a finding no amount of technical hardening offsets. Ownership matters here too: accounts in the company's name, not an individual's.

The questionnaire half: four areas that actually block deals

Most rows are throat-clearing. Four areas do the real work.

1. Identity and access

This is the biggest single cluster, and the one where small companies most often have nothing to point at.

Put everyone on a company identity provider. Not personal accounts, not a shared password manager entry. The reason is not tidiness: a company IdP is what lets you enforce MFA, disable SMS as a second factor (SIM-swap is a real attack, not a theoretical one), require rotation, and revoke everything at once. Federated login to a tool inherits whatever policy sits behind the person's own account, so if that account is a personal one, you control none of it. Expect to pay a few hundred to a thousand a year for this. It is the cheapest control on this page relative to what it unlocks.

There is a soft version of this that matters too. If your contractors log in with their own company's email addresses, an auditor will reasonably ask whether they are internal, and you will spend a paragraph explaining your org chart. Identities on your own domain answer that question before it is asked.

Network access by ACL, not by shared credential. A mesh VPN such as Tailscale, with access rules written per person, per port, per protocol, gets you a defensible answer to "who can reach production" and, more importantly, a single place to cut access when someone leaves. Note the dependency: an overlay network's SSO is only as strong as the identity provider behind it, which is why the previous point comes first.

Least privilege, honestly assessed. Passwordless sudo for a shared operator account is convenient and it is exactly what an auditor is looking for. Separate roles for humans and for automation, no standing production access for people who do not need it daily, and an approval path for the exceptions.

Joiner, mover, leaver. Written down, and actually followed. The mover step is the one everyone forgets: people accumulate access as they change roles and nothing is ever removed. A quarterly review of who has what, with the output kept as evidence, answers several questions at once.

Rotation. Credentials, API keys, and service tokens on a schedule, plus immediately on any departure. If your answer is "we would change the shared password if someone left", say that plainly and put a date on when it changes. Auditors see small companies every week and expect proportionate controls. What they do not accept is not knowing.

2. Data, location, and subprocessors

Region, and the complete list of third parties that touch customer data. This has become harder as AI features have spread: a summarisation feature added last year may route customer text to a model provider nobody has listed. If you cannot name every third party that sees customer data, that is the finding, and you want to find it before the auditor does.

Two clauses the legal reviewer is specifically looking for: return and destruction of data at the end of the contract, and notification if you add a subprocessor. Both are cheap to commit to and expensive to be caught without.

3. Logging, audit trail, and incident response

The question behind all of these is: if something happened, could you reconstruct it?

An audit trail means knowing who did what and when, on the data and on the infrastructure. Authentication events, privileged actions, changes to permissions, access to customer records. It needs to be tamper-evident and retained long enough to be useful, which usually means shipped off the machine that produced it.

Be honest about centralisation and review frequency. There is a large gap between "we have logs" and "we would notice". Plenty of small teams can see logins but have no alerting on them. Saying "logs are retained and reviewed weekly, alerting is on the roadmap for Q1" is a perfectly respectable answer. Claiming continuous monitoring you do not have is not.

For incident response: who gets called, how you reach them, what you have committed to contractually on notification timing. That last one catches people out. A 24-hour notification clause is easy to sign and hard to honour if nobody is monitoring at the weekend.

4. Dependencies and vulnerability management

Automated dependency scanning with something like Renovate or Dependabot, alerts reviewed on a stated cadence, and a named owner. This is an afternoon of setup and it converts one of the weakest common answers ("we update when we notice") into one of the strongest.

The rule that governs every answer

Yes triggers a documentation request. On a platform review, answering yes to a policy question generates a follow-up asking you to attach the policy. So a yes you cannot evidence is worse than a no with a date, because it converts a small gap into a credibility problem in the same thread.

Practical consequences:

• Answer the question asked, then add the compensating control. "Do you enforce MFA for all staff?" If the honest answer is "for everything touching customer data, yes; for internal tools, not yet, and here is the date", write that.
• Never claim a certification you do not hold. This is the one irrecoverable mistake. Overstating a control is a correction. Claiming a certificate you do not have ends the conversation.
• Distinguish "not applicable" from "no", and say why. Twelve unexplained N/As read as dodging.
• Dispute false positives, with evidence. Automated scans produce them. A finding you can demonstrate is wrong should be challenged rather than remediated, and platforms have a mechanism for exactly that.
• Put the gaps in one covering note, with dates and owners. Auditors approve plans. They escalate surprises.

Fix, document, or decline

Sort every gap by two questions: how long does it take, and would an auditor treat it as disqualifying.

Fix before you answer. MFA everywhere that touches production. Access removed for people who have left. Automated dependency alerts on. SSH keys only. Security headers and HSTS. Admin panels behind an allowlist. Plaintext mail ports closed. Patch and reboot. Each is hours rather than weeks, and each is asked every single time.

Document rather than fix. Anything structural: a single-tenant architecture the buyer would prefer, a region you do not yet offer, an audit trail that covers some actions and not others, background checks that a distributed contractor team makes partially impossible. State the position plainly and, where true, when it changes. A structural migration driven by one questionnaire in a hurry is how you end up with a half-migration nobody owns.

Decline, for now, and say so. Managed detection and response, endpoint agents on every machine, network intrusion detection, a full SIEM: individually reasonable, collectively far beyond what an early-stage company can carry, and an auditor knows it. "Not currently in place, compensating controls are X and Y, under review as we grow" is a normal answer. So is declining a penetration test at this stage: a real one runs roughly €15,000 to €30,000 and pulls your engineers into a sandbox for weeks, and it is the wrong purchase before your architecture has settled enough for the findings to still be true in six months.

Do not buy a compliance automation platform because the questionnaire frightened you. Those tools earn their cost once you have committed to a formal certification. Bought in a panic they produce a dashboard and no change in posture.

Build the answer set once

The real return on the first questionnaire is that it should be the slowest one you ever do.

Keep one internal document, in your own words, organised by topic rather than by any customer's format: access control and identity, network access, data handling and residency, subprocessors, encryption at rest and in transit, logging and audit trail, incident response, business continuity and disaster recovery, secure development, dependency management, staff and contractor practices, physical security. Each answer written once, dated, with a named owner, and with the evidence attached rather than described.

Then treat each new questionnaire as a mapping exercise rather than a research project. Copy from the source of truth, adjust to the question, and note anything the source could not answer. Those gaps are your backlog.

Two things to keep alongside it, because they are always requested and always missing: a business continuity and disaster recovery plan with real recovery objectives rather than aspirations, and NDAs signed by everyone including contractors. Both are documents rather than engineering, and both stall reviews for weeks when absent.

Review the set quarterly and after any material change. An answer set that has drifted from reality is worse than none, because you will now confidently tell a customer something untrue.

The economics are simple. The first questionnaire costs a fortnight of senior attention. The fifth should cost a day, and the fifth arrives in a quarter when you have no attention to spare.

Readiness, certification, and penetration testing are three different things

Worth being exact, because the terms get used loosely and the difference is money.

Readiness, which is what this article describes, means understanding your posture, fixing what matters, and being able to answer accurately and fast. It produces no certificate.

Formal certification such as ISO 27001, or a SOC 2 report, is an audited process run by an accredited third party on a defined timeline at real cost. Start it when buyers ask for the certificate by name rather than sending questionnaires, or when you are losing deals specifically for its absence. Not before.

A penetration test is a specialist engagement where someone actively attacks your systems under contract. It answers a different question: not "what are your controls" but "do they hold".

We do the first. We will tell you when you need one of the other two, and we would rather say so early than sell you an assessment that is not the thing you need.

---

If a security review is currently sitting between you and a deal, that is one of the most common reasons companies come to us for a technical due diligence and scale readiness sprint: security posture assessed alongside architecture, cloud cost, access control and delivery, ending in a prioritised roadmap rather than a report.

If the deeper problem is that nobody senior owns these decisions, that is a fractional CTO question rather than a questionnaire one. And if you are working through this from the Gulf, our UAE and GCC advisory page covers how we work across the two regions.