Selling Software to Enterprise Clients: The Security and Continuity Evidence They Will Ask For
Before a large organisation buys your software, its procurement and security teams will ask how their data is protected, what happens when your system fails, and who else can reach it. Those questions arrive after the commercial handshake and before signature, and preparing for them at that point is what turns a two-week review into a two-month one.
- The pack runs to about eight documents, covering security, data protection, continuity, and commercial assurance.
- Gaps are normal in a young product, and a written remediation plan with dates passes review where an overstated control does not.
- Most of the work is documentation and testing rather than rebuilding, which is why it usually costs less than founders expect.
If you are also unsure what you control in your own product, start with the software ownership checklist.
Why this catches product companies out
A small software business wins on product. The demo is good, the buyer’s operational team wants it, and a commercial agreement gets reached quickly, often between people who like each other.
Then the buyer’s procurement process starts, and a different set of people ask a different set of questions. They are not evaluating whether your product is good, because that decision has already been taken by somebody else. They are evaluating whether contracting with you introduces a risk their organisation cannot carry.
This is where we see deals stall, and the reason is usually not that the answers are bad. It is that nobody has written them down, so each question goes back to a founder who has to work out the answer from scratch while the reviewer waits. A founder inventing a disaster recovery position during a review call will not sound convincing, and noticing that is the reviewer’s job.
There is an asymmetry underneath all of it. A buyer with ten thousand employees is putting its workforce data, or a piece of its daily operation, into the hands of a company with a handful of people and very little trading history. Their caution is proportionate to what they are risking, and the thing that satisfies it is evidence rather than reassurance.
Where the security review sits in an enterprise deal
The people who assess your product and the people who assess your company are not the same people.
Preparing the evidence pack at stage three is what turns a two-week review into a two-month one. Preparing it before stage one costs a fraction as much.
What triggers the deepest scrutiny
Not every deal gets the full treatment, and the depth of review tends to scale with four factors.
- Personal data volume and sensitivity. Workforce records, training histories, health data, and anything involving children raise the bar sharply.
- Operational dependency. If your system stopping means their site stops, their vehicles stop, or their staff cannot start a shift, continuity becomes the dominant question and everything else is secondary.
- Access to their environment. Any integration into their systems brings their own security team into the conversation, with a different and more technical set of questions.
- Regulatory exposure. Financial services, healthcare, education, and government buyers pass their own obligations down the supply chain, so their questions are not negotiable even when the reviewer would like to be helpful.
Where two or more of those apply, we would plan for the full review and prepare accordingly. It is also worth asking your sponsor inside the buyer which of these applies, because they usually know, and the answer tells you how much preparation the deal justifies.
The evidence pack
The eight-part evidence pack
Written once, maintained, and reused. Each subsequent buyer becomes a mapping exercise rather than a fresh project.
1. Security questionnaire responses
Most large buyers send a questionnaire. Formats vary and the underlying questions are stable. They cover access control, encryption in transit and at rest, patching cadence, logging and monitoring, secure development practice, incident response, staff vetting, and how you manage your own suppliers.
Answer the whole set once, properly, and keep those answers in a single maintained document. Each subsequent questionnaire then becomes a mapping exercise rather than a fresh project, which is the difference between a day and a fortnight. Keep a dated version history as well, because reviewers do notice when an answer contradicts one you gave six months earlier, and an inconsistency costs more credibility than the original gap would have.
A few answers are worth preparing with particular care, because they come up almost every time and a weak answer invites follow-up questions:
- How access to production is controlled, including who has it, how it is approved, and whether it is logged.
- How you separate one customer’s data from another’s, which is the question behind most technical scrutiny of a multi-tenant product.
- What happens when an employee or contractor leaves, covering account removal and credential rotation.
- How you handle vulnerabilities in third-party dependencies, which is where our guide to keeping software up to date is useful.
2. A data processing agreement
If you hold personal data on behalf of your customer, you need a data processing agreement (DPA) containing the terms Article 28 of the UK GDPR requires. The key clauses cover:
- The subject matter, duration, nature, and purpose of the processing
- The categories of data subject and of personal data
- Your obligation to process only on the controller’s documented instructions
- Confidentiality obligations binding your staff
- Security measures, described specifically rather than in generic language
- Rules on engaging sub-processors, including notice periods and objection rights
- Assistance with data subject rights and with breach notification
- Deletion or return of data at the end of the contract
- Audit and information rights
Have a template of your own ready. Buyers frequently insist on their own paper, and arriving with a competent DPA signals that you have been through this before, which is worth more than the document itself.
You will also be asked to help with the customer’s data protection impact assessment (DPIA). Under Article 35 of the UK GDPR that assessment belongs to the controller, which is your customer, and it is required where processing is likely to result in a high risk to individuals. Rolling your product out across a workforce of ten thousand people usually qualifies.
Your obligation is to assist, which in practice means answering a detailed set of questions about what data you hold, where it goes, how long you keep it, and what could go wrong. Preparing those answers once and keeping them with the rest of the pack saves repeating the exercise for every customer, and it also gives you a head start if you ever need a DPIA of your own for a new feature.
Two further points catch smaller vendors out. The first is sub-processor notice. If your DPA promises thirty days’ notice before you add a sub-processor, you have committed to a process you need to actually run, including for any new AI service somebody adds to the product. The second is your own role, because using customer data for product analytics or model improvement can make you a controller for that processing, with its own lawful basis and transparency obligations.
Our guide to data protection by design covers the engineering that sits underneath these commitments, and data subject rights, retention, and erasure covers the features you will be asked to demonstrate.
3. Certification evidence
Two certifications carry real weight with UK buyers.
Cyber Essentials and Cyber Essentials Plus come from the National Cyber Security Centre scheme. Plus adds independent technical verification rather than self-assessment. It is achievable for a small company within a reasonable timescale, and it is a hard requirement for many public sector contracts.
ISO 27001 certifies an audited information security management system. It is heavier, slower, and more expensive, and it is the one large enterprise buyers ask for by name. Expect it to take months rather than weeks, and start it well before a deal depends on it.
If you hold neither yet, say so plainly and describe what you do instead, with dates for what you intend to achieve and evidence of the controls already in place. Where your development partner holds certifications, state that too, because it covers the environment your product is built and operated in. We hold both ISO 27001 and Cyber Essentials Plus, and for clients whose platforms we run that answers a meaningful part of a buyer’s questionnaire. It never replaces the buyer’s assessment of the company they are contracting with.
4. A disaster recovery and continuity statement
This is the question founders are least prepared for and buyers care most about, particularly where the software gates a physical operation.
State plainly:
- Recovery time objective (RTO). How long to restore service.
- Recovery point objective (RPO). How much data could be lost, expressed in time.
- Which failure modes are covered. Component failure, regional outage, data corruption, and accidental deletion are four different problems with four different answers, and a plan that only covers the first is common.
- When the plan was last tested, and what the test showed, including anything it uncovered.
- What the customer should do during an outage, because a documented manual fallback is often what makes an operational buyer comfortable.
That last point carries more weight than the numbers do. If your product issues a compliance status that controls whether somebody can start work, the buyer’s real question is what their site manager does at six in the morning when your service is unavailable. A four-hour recovery time with a workable paper fallback will pass a review that a claimed fifteen-minute recovery with no fallback will not, because the reviewer has seen enough optimistic recovery times to discount them.
Untested plans carry no weight with an experienced reviewer, and rightly so. We treat a restore that has never been performed as an assumption rather than a control, and it is one of the first things we verify when we take a system on.
5. Hosting, data residency, and sub-processors
Buyers need to know where their data physically sits and who else can reach it. Prepare:
- The cloud provider and the regions in which data is stored and processed
- Whether any data leaves the UK or the European Economic Area, and on what transfer mechanism
- A complete list of sub-processors, what each one does, where it operates, and what data it sees
Sub-processors are easy to under-declare, and an incomplete list is one of the more damaging findings because it reads as carelessness about the buyer’s data. Email delivery, SMS gateways, error tracking, analytics, customer support tooling, document storage, and any AI service all count where personal data passes through them.
AI services deserve their own paragraph in your answers. Buyers now ask specifically whether their data is used to train a model, where inference happens, and what retention the provider applies. Get those answers from your provider’s terms rather than from memory, and keep them with the sub-processor list. Our guide to multi-jurisdiction data residency covers the transfer questions in more depth, including the sub-processor residency trap.
6. Penetration test evidence
An annual external penetration test by an independent firm is the expected standard once you are selling to enterprise. You do not hand over the raw report, which contains exploitable detail, and you provide a summary letter confirming scope, date, tester, and that findings have been remediated or are tracked with dates.
Scope matters as much as the result. A test covering only your marketing site tells a reviewer nothing about the application holding their workforce data, and an experienced reviewer will read the scope before the findings. Test the application, the application programming interfaces behind it, and the authentication flows, and have the tester retest anything material rather than accepting your word that it was fixed.
If you have never had one, arrange it before a deal depends on it, and close the obvious issues first so the summary letter reads cleanly.
7. A service level agreement you can meet
Your SLA defines what you are promising and, by implication, what you are liable for. It should state:
- The availability target and how it is measured, including what counts as downtime
- Support hours, including whether cover extends beyond office hours
- Response and resolution targets by incident severity, with each severity defined by business impact rather than by technical symptom
- The escalation path, with roles named rather than individuals
- Planned maintenance windows and the notice you will give
- What happens when a target is missed, whether that is service credits or another remedy
Promise what your architecture and your team can deliver today rather than what you hope to deliver next year. An availability figure you cannot evidence is a liability you have written for yourself, and a resolution target that assumes one engineer never takes a holiday will be missed in the first quarter.
Where the customer’s operation runs outside office hours, your cover has to match, which is a genuine constraint for a small team. We see founders reach for a rota built from two or three people, which works until somebody is ill or leaves. Partnering for managed application support is usually cheaper and more durable than an internal rota that is one person deep, and our guide to managed support versus hiring sets out the comparison.
8. Insurance and corporate assurance
Expect requests for professional indemnity insurance, cyber insurance, and public liability, each at a stated minimum level. Expect basic corporate due diligence alongside it, covering filed accounts, company structure, ultimate beneficial ownership, and sometimes a credit check.
For a young, pre-revenue company this is the section most likely to produce an awkward conversation, because a buyer’s standard minimum cover can look disproportionate against your turnover. Find out the buyer’s required levels early, price the cover into your commercials, and raise it with your sponsor before it reaches procurement. Cover can usually be arranged quickly, and it is better handled as a cost than as a surprise.
Incident response, and what you owe when something goes wrong
Every questionnaire asks about incident response, and the answers we see from smaller vendors are often the weakest part of the pack. The reason is understandable, because a team that has never had a serious incident has nothing to describe, and writing a plan feels like paperwork until the day it is not.
Your customer is asking two separate things. The first is operational: when your service breaks, how quickly do you notice, who responds, and how do you keep them informed. The second is regulatory: when personal data is exposed, what do you tell them and when.
On the regulatory side, the UK GDPR gives a controller 72 hours to notify the Information Commissioner’s Office of a reportable personal data breach. As a processor you are not the one notifying the regulator, and you are obliged to notify your customer without undue delay so that they can meet their own deadline. That obligation will be written into the DPA you sign, sometimes with a specific number of hours attached. Read it before you agree to it, and check that your own detection is capable of meeting it.
A workable incident plan does not need to be long. What a reviewer looks for is that these things exist and have owners:
- Detection. What alerts you, and who receives the alert outside working hours.
- Severity classification. How you decide whether an event is a service incident, a security incident, or a personal data breach, since the three trigger different obligations.
- Named roles. Who leads the response, who communicates with customers, and who makes the call on regulatory notification.
- Customer communication. How and when you tell affected customers, and what you commit to telling them in the first message rather than waiting until you know everything.
- Evidence preservation. Keeping logs and forensic material rather than rebuilding the environment and destroying the evidence, which is a common instinct under pressure.
- Post-incident review. A written review with actions and owners, which is also the artefact a buyer will ask to see after any incident that affects them.
Test the plan at least once a year, even if the test is a tabletop exercise around a scenario rather than a live simulation. We run these with clients whose platforms we support, and the value is rarely in the plan itself. It is in discovering that the person named for out-of-hours response has changed roles, or that nobody has the phone number for the customer’s IT team.
What the buyer expects after you have won
Passing the review is not the end of the obligations, and the ongoing commitments are the ones smaller vendors tend to miss when pricing a contract.
- Annual reassessment. Many buyers re-issue the questionnaire each year, and some require an updated penetration test summary and evidence of continuing certification.
- Notification of change. Contracts commonly require notice before you change hosting regions, add a sub-processor, or make a significant architectural change. Build a habit of checking the contract before adding a service rather than after.
- Right to audit. Most enterprise DPAs include one. Few buyers exercise it, and the ones who do tend to accept an evidence pack and a call in place of an on-site audit, provided the pack is credible.
- Incident reporting. Beyond breach notification, larger customers often want a summary of any significant service incident affecting them, along with the post-incident review.
- Certificate and insurance renewals. Expect to be asked for current certificates annually, and diarise the renewals rather than waiting for the request.
None of this is heavy once the pack exists and somebody owns it. Where it goes wrong is when the pack was assembled by a founder during a single deal and then left untouched, so the first annual reassessment turns into the original project repeated.
Handling gaps without overstating
You will have gaps. Every young product does, and experienced reviewers know it.
What works is a documented position for each gap containing three things: what the current state is, what compensating controls exist in the meantime, and what the remediation is with a date against it. Reviewers are assessing whether you understand your own risk, and a specific plan demonstrates that better than a clean sheet would.
A worked example helps. If you do not yet have single sign-on, the position might read like this. Password authentication with enforced multi-factor authentication and a ninety-day credential rotation today, single sign-on via Microsoft Entra ID scheduled for the second quarter, and the customer’s rollout able to proceed on the current mechanism. That is a reviewer’s answer. “Single sign-on is on the roadmap” is not.
Claiming a control you do not have is the version that ends badly. It surfaces during an audit or an incident, and at that point the conversation is no longer about a missing control. It is about whether your statements can be relied on, which is a much harder thing to recover.
There is a commercial argument for the same discipline. A gap you have named is a gap the buyer has accepted, and it sits in the contract file alongside their decision to proceed. A gap you concealed becomes something they will say they were misled about, with everything that follows from that.
Preparing the pack before you need it
The sequence we use with clients runs like this.
- Assess the current position. An independent technical review of security, data protection, and recovery, producing a gap list ranked by what a buyer will actually ask about rather than by theoretical severity.
- Fix the cheap and visible items first. Multi-factor authentication everywhere, secrets moved out of code and into a key vault, logging and alerting, dependency patching, and a tested restore. These are days of work and they remove the most common questionnaire failures.
- Write the documents. Questionnaire master answers, DPA template, disaster recovery statement, sub-processor list, and SLA.
- Book the penetration test once the obvious issues are closed, so the summary letter reads cleanly and you are not paying to be told what you already knew.
- Decide on certification based on who you are selling to, and start early, because ISO 27001 runs to months and no amount of urgency compresses the audit cycle.
- Keep it current. Diarise a quarterly review, and revisit the pack after any significant architectural change, new sub-processor, or incident.
Most of this is documentation, configuration, and testing rather than rebuilding, which is why the total cost usually lands below what founders brace for. The exception is where the architecture itself cannot support a commitment you need to make, for example data isolation your current design does not provide or a recovery time your current hosting cannot achieve. Finding that out at step one, rather than at step three of a customer’s review, is the reason we run the assessment first.
Glossary: the terms and evidence buyers ask for
Procurement and security teams use a vocabulary of their own, and a request that looks alarming is often a routine ask with an acronym attached. The tables below cover what we see most often, what each term means, and what a buyer is usually looking for from you.
Data protection
| Term | What it means | What the buyer wants from you |
|---|---|---|
| DPA (data processing agreement) | The contract required by Article 28 of the UK GDPR wherever you process personal data on a customer’s behalf | Your template, or your agreement to sign theirs, with the Article 28 terms present |
| Controller and processor | The controller decides the purposes and means of processing; the processor acts on the controller’s instructions | A clear statement of which role you hold for each flow of data |
| DPIA (data protection impact assessment) | The controller’s assessment of high-risk processing under Article 35 | Detailed answers about your processing so they can complete theirs. The assessment is theirs, and assisting is your obligation |
| TOMs (technical and organisational measures) | The security measures required by Article 32 | A specific description of your controls rather than generic wording |
| Sub-processor | Any third party you engage that processes the customer’s personal data | A current list with purpose and location, plus notice and objection rights before you add another |
| ROPA (record of processing activities) | The Article 30 record. Processors keep their own for processing carried out on behalf of controllers | Confirmation that you maintain one, and occasionally an extract |
| IDTA and the UK Addendum | The UK International Data Transfer Agreement, and the UK Addendum to the EU standard contractual clauses, used for restricted transfers out of the UK | Which mechanism covers any transfer, with a transfer risk assessment alongside it |
| DSAR (data subject access request) | An individual’s request for their personal data | Tooling or a documented process that lets the customer respond inside their one-month deadline |
| Breach notification | A controller has 72 hours to notify the Information Commissioner’s Office of a reportable breach | Your commitment to notify them without undue delay, often with a specific number of hours in the DPA |
Certifications and assurance reports
| Term | What it means | What the buyer wants from you |
|---|---|---|
| Cyber Essentials | The National Cyber Security Centre scheme, assessed by self-declaration | A current certificate |
| Cyber Essentials Plus | The same scheme with independent technical verification | A current certificate, and often this rather than the base level |
| ISO/IEC 27001 | Certification of an audited information security management system, currently the 2022 revision | The certificate plus the scope statement, since a certificate covering only your office is not the same as one covering the platform |
| ISO/IEC 27701 | A privacy extension to ISO 27001 | Rarely mandatory, and useful where the product is privacy-heavy |
| SOC 2 Type I and Type II | Reports developed by the American Institute of Certified Public Accountants. Type I covers control design at a point in time; Type II covers operating effectiveness across a period | The report under a non-disclosure agreement. More common with US-headquartered buyers, and increasingly requested in the UK |
| Penetration test | Independent testing of the application, its interfaces, and its authentication | A summary letter with scope, date, tester, and remediation status. UK buyers often ask for an accredited testing firm |
| Vulnerability scanning | Automated, recurring scanning of code, dependencies, and infrastructure | Evidence that it runs, and your process for acting on what it finds |
Questionnaires and frameworks
| Term | What it means | What the buyer wants from you |
|---|---|---|
| TPRM (third-party risk management) | The buyer’s own programme for assessing suppliers, which is what generates most of these requests | Cooperation with whichever process their programme prescribes |
| SAQ (self-assessment questionnaire) | A supplier-completed questionnaire, often the buyer’s own format | Complete answers with evidence attached where available |
| SIG (Standardized Information Gathering questionnaire) | An industry questionnaire from Shared Assessments, issued in a full and a lighter version | Your master answers mapped onto their format |
| CAIQ (Consensus Assessments Initiative Questionnaire) | A cloud-focused questionnaire from the Cloud Security Alliance | The completed questionnaire, sometimes via the public STAR registry |
| Right to audit | A contractual right for the buyer to audit your controls | Willingness to accept the clause. Most buyers take an evidence pack and a call instead of attending in person |
| DORA (Digital Operational Resilience Act) | EU regulation on operational resilience for financial entities, applying since 17 January 2025 | Additional contractual terms where you supply a financial services customer in the EU |
Security controls they ask about
| Term | What it means | What the buyer wants from you |
|---|---|---|
| MFA (multi-factor authentication) | A second factor beyond a password | Enforcement for all administrative and production access, with no exceptions list |
| SSO (single sign-on) | Staff signing in with corporate credentials, usually over SAML 2.0 or OpenID Connect | Support for their identity provider, most often Microsoft Entra ID |
| SCIM (System for Cross-domain Identity Management) | Automated provisioning and deprovisioning of user accounts | Automatic account removal when somebody leaves their organisation |
| RBAC (role-based access control) | Permissions granted by role rather than individually | A role model that matches their organisational hierarchy |
| JML (joiners, movers, leavers) | The process for granting and removing access as staff change roles | Your own internal process, with evidence of periodic access reviews |
| Encryption in transit and at rest | Protection of data on the network and in storage | Modern protocols in transit and encrypted storage, plus how keys are held |
| CMK or BYOK (customer-managed keys, bring your own key) | The customer supplying or controlling the encryption keys | Usually asked by regulated buyers only, and expensive to retrofit |
| SBOM (software bill of materials) | An inventory of every component in your product with versions and licences | A current SBOM, commonly in CycloneDX or SPDX format |
| SAST, DAST, and SCA | Static analysis, dynamic analysis, and dependency scanning in your build | Evidence that these run in the pipeline and that findings are triaged |
| CVSS (Common Vulnerability Scoring System) | The severity score attached to a known vulnerability | Your patching commitments expressed by severity, for example critical issues within a stated number of days |
| SIEM and log retention | Centralised collection of security logs, and how long you keep them | Confirmation that logs exist, are protected from tampering, and are retained long enough to investigate |
Continuity and commercial
| Term | What it means | What the buyer wants from you |
|---|---|---|
| RTO (recovery time objective) | How long you would take to restore service after a failure | A number you have tested, matched to what their operation can tolerate |
| RPO (recovery point objective) | How much data you could lose, expressed in time | A number consistent with your actual backup frequency |
| BCP and DR plan | Business continuity and disaster recovery plans | Documents with a last-tested date, plus what their staff should do during an outage |
| BIA (business impact analysis) | An assessment of what a disruption would cost and how quickly it bites | Usually theirs rather than yours, and it drives the RTO they will ask for |
| Tabletop exercise | A walkthrough of an incident scenario with the people who would respond | Evidence that you rehearse, even without a live simulation |
| SLA (service level agreement) | Availability, support hours, and response and resolution targets by severity | Commitments you can evidence, with severity defined by business impact |
| Service credits | Money returned when a service level is missed | Acceptance of a credit regime, with a cap you can live with |
| PI and cyber insurance | Professional indemnity and cyber cover | Certificates at their stated minimum levels |
| Exit plan and data return | How the customer leaves and gets their data back | A documented export format, a return or deletion commitment, and a timescale |
If a term arrives that is not on this list, ask the reviewer what evidence would satisfy them rather than guessing. In our experience they would far rather explain the requirement than receive a document that misses it, because a wrong answer costs them another round as well.
Where to go next
- If you are not yet certain what you control in your own product: do you actually own your software
- If your first large customer is about to multiply your user count: from MVP to first enterprise customer
- For the engineering behind the data protection answers: data protection by design
- On the subject rights features buyers ask you to demonstrate: data subject rights, retention, and erasure
- On keeping the platform patched once it is live: keeping software up to date
- If the continuity question is about your supplier rather than your platform: software escrow
We run security, data protection, and disaster recovery assessments on software products built by other teams, and we provide the SLA-backed support that enterprise buyers ask about. To talk through what your pipeline will require, book a consultation.
Frequently asked questions
What do enterprise customers ask software suppliers for?
Do we need ISO 27001 to sell to large companies?
What are RTO and RPO, and what should ours be?
Who is the data controller when we sell our platform to a client?
How much does it cost to become enterprise-ready?
When should we start preparing this evidence?
What if we have gaps in our security posture?
Do we need our own certifications if our development partner holds them?
What should we do about AI services in our product?
How long does a security review take?
What is a DPIA and do we have to produce one?
What is the difference between SOC 2 Type I and Type II?
Related guides
Do You Actually Own Your Software? A Control Checklist for Non-Technical Founders
An agency built your product. Can you move it, keep it running, or stop someone switching it off? A plain-English checklist of the rights, the code, and the accounts you should hold.
The EU AI Act and Custom Software: What UK Businesses Commissioning AI Need to Know
When you commission custom AI-powered software, the EU AI Act determines who carries which obligations. This guide explains provider vs deployer, risk classification, and what the deferred high-risk deadline of 2 December 2027 means for UK businesses.
The UK's New Subscription Contracts Regime: A Compliance Guide for Software Teams
The UK's subscription contracts regime is due to take effect from January 2027. What it requires for pre-contract information, renewal reminders, cooling-off periods, and cancellation flows, and how to build for it.