Your Software Can't Pass Enterprise Procurement: Fix These 10 Security Gaps

An enterprise software security readiness checklist is the set of controls, and the documented evidence for each one, that a large buyer's security team requires before approving a purchase. Most stalled deals fail on missing evidence rather than missing controls. The blocker is usually ownership, documentation, and export, not architecture.

The security questionnaire looks like a compliance form and behaves like a sales gate. Your champion loves the product, pricing is agreed, then a spreadsheet with 180 rows lands and the deal goes quiet. Usually the product wasn't insecure. Nobody could produce the artefact that proved it.

Most teams already do half of what's on this list. They encrypt things. They have roles. They just can't hand anyone a document that says so.

What actually happens inside an enterprise security review?

An enterprise security review is a gated approval run by the buyer's information security or vendor-risk team, in parallel with commercial negotiation. A questionnaire arrives, often SIG Lite, a CSA CAIQ, or a custom spreadsheet, gets scored, and produces findings. Procurement can't raise a purchase order until security signs off.

The person reading it isn't your champion. It's an analyst working a queue against a rubric they didn't write, sometimes an outsourced firm paid per assessment. They hunt contradictions, not excellence. A blank cell, or an "in progress" with no date, does more damage than an honest no with a compensating control beside it.

Why isn't "we support Google login" the same as SSO?

Enterprise SSO means the buyer's identity provider, typically Okta, Microsoft Entra ID, or Ping, authenticates users into your app over SAML 2.0 or OIDC, with your app as the service provider. "Sign in with Google" is social login against one consumer IdP. SCIM 2.0 handles provisioning and deprovisioning.

Deprovisioning is the real question. Nobody cares much how users get in. They care what happens when HR marks a leaver at 4pm on a Friday, because just-in-time provisioning creates accounts happily and leaves orphans forever. Charge for your enterprise tier by all means, but a 4x markup on SSO alone taxes the control that lowers your own breach risk.

Can you prove who inside your company sees customer data?

Role-based access control assigns permissions to roles rather than individuals, so access follows job function and is revoked by changing one assignment. Least privilege means every human, service account, and CI job holds the minimum access needed. Reviewers ask who can read customer data, and how you demonstrate it.

Half this answer is about your team. If an engineer can open a production console at 2am and read a customer record with nobody notified, your logs say so anyway. Kill standing access. Replace it with break-glass that expires on its own, and put the "view as user" support button into the customer's audit trail.

Can the customer export their own audit log?

An enterprise-grade audit log records who did what, to which object, when, and from which IP address, in append-only storage the customer's admin can export without opening a support ticket. Reviewers check retention period, tamper resistance, and export format. Logs only your engineers can query don't count.

The word doing the work is "export". Their auditor asks them, they ask you, an engineer produces a CSV four days later. Removing that loop is half of why they're buying software with a log in it. Baseline: JSON or CSV from the admin UI, 90 days hot, twelve months archived, optional SIEM streaming.

Is your encryption story anything more than "we use HTTPS"?

In transit means TLS 1.2 or higher, ideally 1.3, on every path including internal service calls and database connections. At rest means AES-256 across disks, databases, backups, and object storage. Key management is where reviewers push hardest: where keys live, which identities can use them, how often they rotate.

Everybody passes the HTTPS question. Fewer survive the next three. Is TLS terminated at the load balancer and plaintext across the VPC after that? Are backups encrypted under a different key than the primary store? Who holds decrypt permission today? Keep a key inventory: what each key protects, who owns it, when it rotates.

How do you prove one tenant can't read another tenant's data?

Tenant isolation is the guarantee that one customer's data can't be reached by another, enforced below application code. The usual models are a shared database with a tenant identifier column, a schema per tenant, or a database per tenant. Reviewers want to know what stops a forgotten WHERE clause from leaking across tenants.

Shared tables with a tenant column are defensible, and most SaaS runs that way. Isolation that depends on every developer remembering is not. Push enforcement down a layer, into Postgres row-level security or a data layer that refuses unscoped queries. Then write the test that attempts a cross-tenant read and fails the build when it succeeds.

What's still sitting in your .env files?

Secrets management covers where API keys, database passwords, and signing keys live, who can read them, and how they rotate. A .env file on a server is acceptable only when it's generated at deploy time from a managed store, never committed, and readable by one service account. Git history counts as storage.

The file is rarely the problem. The copies are: the one pasted into Slack in 2023, the screenshot in a runbook, the CI variable nobody has touched since, the contractor laptop that never got wiped. Run gitleaks across full history before the buyer's tooling does, and rotate whatever surfaces. AI-assisted code widened this crack, as our breakdown of the security bill that comes due after vibe coding covers.

How fast do you patch, and can you prove last quarter?

Vulnerability management is the loop that finds, ranks, and fixes known weaknesses on a clock. It needs three parts: automated dependency and container scanning in CI, a severity ranking (CVSS is the common one), and a written patch SLA committing to a fix window per severity. Reviewers ask for last quarter's evidence.

"We patch quickly" scores zero. A table scores: critical inside 7 days, high inside 30, medium inside 90, with real ticket numbers behind a few. Add an SBOM in CycloneDX or SPDX, plus an annual pen test summary. Ship AI features and your scope grew, so the new attack surfaces AI systems introduce join the same loop.

Who else touches the data, and where does it physically live?

Sub-processors are third parties that process customer data on your behalf: cloud hosting, email delivery, analytics, error tracking, support tooling, model providers. Enterprise buyers expect a public sub-processor list, a Data Processing Agreement carrying standard contractual clauses where transfers need them, and a statement of which regions hold the data.

Most teams undercount by half. The session-replay script, the analytics SDK, the LLM API quietly powering a summarise button. Each is a processor, and the last is why shadow AI needs an actual governance policy rather than a Slack thread. Residency answers need geography. "We're on AWS" fails. "Primary in eu-central-1, backups in eu-west-1" passes.

What happens in the first 24 hours after a breach?

Incident response is a written plan naming who declares an incident, how severity is classified, who contacts affected customers, and inside what window. Enterprise contracts convert this into a breach notification clause with a fixed deadline, commonly 24 to 72 hours, plus obligations to preserve evidence and cooperate with the investigation.

Deals die quietly here, in legal redlines rather than security review. The clause usually arrives carrying uncapped liability for data incidents, or a super-cap at some multiple of annual fees. Decide your position before it lands. GDPR's 72-hour clock in Article 33 runs to the supervisory authority, not to your customer, who wants to hear sooner.

Do you actually need SOC 2 or ISO 27001 yet?

SOC 2 is an attestation report issued by a CPA firm against the AICPA's Trust Services Criteria. Type I tests control design at a point in time; Type II tests operating effectiveness across a period, commonly three to twelve months. ISO 27001 certifies a management system through an accredited body. Neither is a feature you build.

Both audit what you already do, so a rushed audit over shaky controls buys an expensive report with exceptions in it. Do the ten items below first. You need one when a target buyer has a hard policy, when you sell into finance, health, or public sector, or when the same questionnaire lands monthly.

One honest note on our own credentials. At Shanti Infosoft we hold a CMMI Level 5 appraisal, which speaks to engineering process maturity: how work gets planned, measured, and improved across 80+ engineers. That answers a real procurement question about delivery. It isn't a security certification, and I won't pretend it substitutes for SOC 2.

What artefact satisfies each question on the questionnaire?

The questionnaire asks in compliance language. The analyst wants a file they can attach. Here's the translation for the ten questions that stall the most deals.

The 10-gap checklist

Each item is done when the artefact exists and someone outside your team can read it.

1. No SAML 2.0 or OIDC SSO, or SSO without SCIM. Provisioning without deprovisioning gets flagged every time.
2. Standing production access. Swap it for time-boxed break-glass, and log impersonation into the customer's trail.
3. An audit log the customer can't export. Self-serve export, a stated retention window, optional SIEM streaming.
4. Encryption you describe but can't evidence. Name the key owner, publish the rotation schedule, audit decrypt rights.
5. Isolation enforced by developer discipline. Move it into row-level security or a scoped data layer, prove it in CI.
6. Secrets in .env files, git history, or stale CI variables. Scan history, rotate what surfaces, use a managed store.
7. No written patch SLA. Publish fix windows by severity, keep last quarter's scan output ready to send.
8. No sub-processor list, DPA, or residency answer. One public page, one signed template, one sentence naming regions.
9. No incident response plan with a named owner and a clock. Write it, rehearse it once, record the date.
10. No certification and no roadmap. Say when you'll be audited, show compensating evidence meanwhile.

More than half of this is documentation you can write in a fortnight, because the controls already exist. The rest, usually SCIM, isolation testing, key rotation, and the DPA, needs engineering time and a lawyer.

Our software development teams fold this readiness pass into delivery rather than bolting it on when a deal stalls. Book a call and bring your worst questionnaire.

Frequently Asked Questions

How long does an enterprise security review take?

It depends on buyer size and how complete your first submission is. Reviews stretch when answers arrive in batches, because each round trip resets your position in the analyst's queue.

Can we win an enterprise deal without SOC 2?

Yes, when the buyer's policy allows exceptions and your evidence is strong. Bring a completed CAIQ, a pen test summary, your sub-processor list, and a dated audit roadmap. You'll still lose deals where SOC 2 is mandatory.

What's the difference between SOC 2 Type I and Type II?

Type I says controls were designed appropriately on a given date. Type II says they operated over a period, commonly three to twelve months. Buyers who know the difference want Type II. Type I is a fair stepping stone.

Do we still need a DPA if we already signed an MSA?

Usually yes. The MSA governs the commercial relationship. The DPA governs personal data processing, names sub-processors, and carries the transfer mechanism such as standard contractual clauses. Legal teams ask for both.

Does CMMI Level 5 count as a security certification?

No. It appraises process maturity: how consistently an organisation plans, measures, and improves engineering work. That's genuine evidence about delivery quality, but it doesn't attest to security controls the way SOC 2 or ISO 27001 does.

We have four weeks before a review. What do we fix first?

Documentation, then deprovisioning. Write the access-control matrix, retention policy, sub-processor list, patch SLA, and incident response plan, since those need no code. Spend the engineering time on SCIM and audit-log export.