Asistencia 24/7/365 · Oficina 9–17 h MT, lun–vie +1 (208) 391-7176 team@alcousa.org

What an enterprise security review actually asks

Mid-market companies lose enterprise deals at the security questionnaire, usually over things that were cheap to fix a year earlier. What reviewers really check, which answers end a deal, and how to be ready before the questionnaire arrives.

There is a moment in an enterprise sale where the commercial conversation stops and a document arrives. It might be a vendor security questionnaire, a SIG Lite, a CAIQ, or a bespoke spreadsheet from someone's risk team. It usually turns up after everyone has agreed on price, which is exactly when it is most expensive to fail.

We sit on both sides of this. We complete them for ourselves, and we prepare clients for them. The pattern is consistent enough to be worth writing down, because most of what sinks a deal at this stage was cheap to fix a year earlier and is expensive to fix in the two weeks you are given.

What the reviewer is actually doing

They are not trying to establish that you are secure. That is not a thing a questionnaire can determine. They are trying to establish two narrower things: whether you are a risk they can characterise, and whether your answers are credible.

Characterisable risk is fine. "We do not hold cardholder data" is a good answer. "We hold it, here is the scope, here are the controls" is also a good answer. What is not fine is an answer that reveals nobody has thought about the question, because that implies the same is true of the questions they did not ask.

Credibility is the second axis, and it is the one people underestimate. A reviewer who catches one overstatement will re-read every other answer as marketing. This is why claiming a certification you do not hold is not a shortcut — it is the single most reliable way to turn a routine review into an adversarial one.

The questions that actually decide it

Access control, and specifically offboarding. Not "do you have a policy" but "show me the last three people who left and when their access was revoked". This is asked because it is the control most likely to be theoretically present and practically absent. If you cannot produce the evidence quickly, that is the answer.

Multi-factor authentication, everywhere, without exceptions. Not on email only. On the hosting console, the DNS registrar, the source repository, the payment processor, the backup system. Reviewers ask about the registrar specifically, because domain control is the root of most catastrophic compromises and it is routinely the account with the weakest protection.

Backups, and whether restoration has been tested. "We back up nightly" answers half the question. The other half is when you last restored, and what the recovery time actually was, measured rather than estimated. An untested backup is a belief, not a control.

Change management. Who can deploy to production, what record exists of what changed, and can you show a specific change from last month end to end. This is where organizations without written procedure struggle, because the honest answer is that a competent person did something sensible and nobody wrote it down.

Logging and retention. What is logged, where it goes, how long it is kept, and who can alter it. The follow-up question is whether an administrator could delete their own trail. If the answer is yes, that undermines every other log-based control.

Encryption, at rest and in transit, with specifics. TLS versions and whether older ones are disabled. What "at rest" means concretely — full disk, database-level, or field-level — because those provide very different protection and are frequently conflated in answers.

Subprocessors. Everyone you send their data to, including the ones that feel invisible: analytics, error tracking, email delivery, support tooling. An incomplete list found later is treated as concealment, whether or not it was.

Incident response. Not the plan, but whether it has been exercised, and what your notification commitment is in hours. An organization that has never run the plan has a document, not a capability.

The answers that end deals

Some responses stop a review immediately, and they are worth knowing in advance.

Claiming a certification you do not hold. It is checkable in minutes, and the recovery from being caught is worse than the recovery from saying no.

Shared administrator credentials. If four people use the same login, no log is attributable to a person, and every access-control answer collapses.

No MFA on the domain registrar or DNS provider. Whoever controls DNS can obtain certificates for your domains and redirect your mail. Reviewers know this even when clients do not.

Backups on the same machine as the data. A backup that shares a failure domain with the thing it protects is not a backup.

"Our provider handles that." Sometimes correct, but you are accountable for it, and you need to be able to say what they do and produce their attestation. Not knowing where your responsibility ends is itself the finding.

How to be ready before it arrives

The work is unglamorous and mostly not technical.

Write down what you have. An inventory of systems, what data each holds, who can reach it, and which supplier is behind it. Most questions are answerable from that document, and organizations that cannot answer usually cannot because nobody has ever assembled it.

Turn on MFA everywhere, starting with the registrar, DNS, hosting console and repository. This is a day of work and it removes several deal-ending answers permanently.

Make offboarding a checklist with a record. It is the most-tested control and the easiest to demonstrate once it exists.

Test a restore, and write down the date and the elapsed time. That single sentence answers a question most respondents fudge.

Keep a change record. It does not need a tool. A dated log of what changed, by whom, and why, is enough — and it converts a weak answer into a strong one.

Choose a framework and assess against it. NIST CSF works well for organizations that are not required to hold anything specific. The point is not the framework; it is that "we assessed against X in March and here is what we fixed" is a fundamentally different answer from "we take security seriously".

Say no clearly when the answer is no. "We do not do that today. Here is the compensating control, and here is when it is scheduled." Reviewers accept this constantly. What they do not accept is discovering it themselves.

Where we fit

We run this work for clients as part of a managed agreement, which mostly means the boring parts happen continuously instead of in a panic: the inventory stays current because it is generated, change control is recorded because our tooling records it, credentials are held encrypted with every access audited, and monitoring produces the evidence rather than an assertion.

None of that is exotic. Our healthcare, government and financial clients set the bar because their regulators do, and it turned out to be cheaper to apply the same controls to everyone than to maintain two standards. That is why the questionnaire is not an event here. It is a document we can already answer.

The uncomfortable truth is that most organizations fail these reviews on operational hygiene rather than on anything sophisticated. Nobody loses an enterprise deal because their cipher suites were imperfect. They lose it because a leaver still had access in March, and nobody could say when it was removed.

Más de ALCO

Least privilege without breaking everything

Removing local administrator rights is one of the highest-value security changes available and one of the most frequentl

Leer más

What an hour of downtime actually costs

The published averages are enormous and nearly useless, because they average across organizations nothing like yours. He

Leer más

Infrastructure as code for organizations that are not software companies

The practice is usually explained by software companies, to software companies, with examples from software companies. T

Leer más

¿Encaja con lo que necesita?

Cualificamos cada proyecto antes de presupuestarlo. Eso significa una conversación técnica sobre su infraestructura, no una llamada comercial, y una respuesta clara si no somos la firma adecuada.

Veamos qué está ejecutando.

Una conversación de alcance con un ingeniero sénior. Le diremos qué cambiaríamos, cuánto costaría y si somos la firma adecuada para ello.