Opinion
How to Read the Compliance Checklist Your Enterprise Buyer Just Sent
September 22, 2026
If an enterprise buyer has sent you a compliance checklist for your no-code or AI-built app, the worst thing you can do is treat it as ten separate things to get quotes for. Most of those line items depend on each other, several can't be started until an earlier one finishes, and two or three were decided the day you chose your build platform. Going out for three quotes on the list as written will get you three numbers that all turn out to be wrong.
I've watched this happen more than once now. A founder builds something good on Replit, Lovable, Base44, Bubble or similar, it works, and a large customer or an ecosystem marketplace gets interested. Then the checklist lands, and the founder does the sensible, procurement-trained thing: forwards it to suppliers and asks for pricing. That's usually the moment the timeline doubles, because the quotes come back priced as if the ten items were independent of each other.
Updated 22 September 2026. I corrected several things in the August version. The two that matter most are what the Cyber Essentials requirements say about who implements each control on cloud services, and how long a first SOC 2 Type II takes end to end. I also added what Lovable, Base44 and Supabase publish about their own certifications, and a section on the EU AI Act and the European Accessibility Act. The closing section now describes the free check we offer founders with an AI-built app.
The lists vary in wording but not much in substance. In our experience the enterprise version runs to roughly ten headline items.
Cyber Essentials, and then Cyber Essentials Plus. The UK government-backed baseline, run by the NCSC through IASME.
ISO/IEC 27001 implementation and certification. Broken out as gap analysis, documentation, internal audit and certification audit.
A UK GDPR package. Review, data protection impact assessment, and a data processing agreement.
Legal documentation. Privacy policy, terms and conditions, cookie policy.
Independent penetration testing. The web application and the API, with a remediation report and a retest after fixes.
A secure cloud infrastructure review. Hardening, backup strategy, encryption, access controls and monitoring.
Incident response, disaster recovery and business continuity plans. Three separate documents, usually.
An API security assessment. Authentication review, vulnerability testing, recommendations.
SOC 2 Type II. Usually flagged as a later phase, tied to US expansion.
ISO/IEC 27701 for privacy. Usually flagged as following on from ISO 27001.
Marketplaces add their own gate on top. Trimble, to take a public example from construction tech, states that every verified solution has passed a technical evaluation and security review before it carries the verified badge. That evaluation isn't something your supplier can deliver. It's a queue you join, on someone else's calendar.
None of the individual items are unreasonable. Presented as a flat list, though, they hide which ones you can buy, which ones your platform has already answered for you, and which ones run on a clock nobody can speed up.
Because several of them describe how your system is built. The ISO 27001 line, the secure cloud infrastructure review and the API security assessment all assume a system that's already built a certain way, and no supplier can sell you an architecture you haven't got.
Take Cyber Essentials. Assessments started after 27 April 2026 use version 3.3 of the requirements, and IASME's summary of the changes is blunt on the point that matters here: cloud services can't be excluded from scope, and if you leave any other part of your infrastructure out, you have to explain what, why and how it's segregated. You don't get to leave the platform your product runs on outside the boundary because someone else operates it. Multi-factor authentication is mandatory on every cloud service where it's available, and an organisation that hasn't turned it on fails the assessment automatically.
The same update pointed the software development section at the UK Government's Software Security Code of Practice, published by DSIT and the NCSC on 7 May 2025. Cyber Essentials treats the custom parts of a web application as out of scope, so an assessor won't check your code against it. The scheme points you there for how to build well. The code has fourteen principles across four themes, and if an AI agent builds your app, read theme two, build environment security, first. Principle 2.1 is "protect the build environment against unauthorised access". Principle 2.2 is "control and log changes to the build environment". Principle 1.3 asks for "a clear process for testing software and software updates before distribution".
Now think about what your build environment actually is when an AI agent writes and deploys your code. There's often no separate staging environment, no reviewed change, no log of who approved what, and nothing standing between a prompt and production. Paperwork won't close that gap, and ISO 27001 pokes at the same one from a different angle: Annex A control 8.31 covers separating and securing development, test and production environments, and 8.25 covers rules for secure development across the lifecycle.
So when the checklist says "ISO 27001 implementation", part of what's being asked for is an environment topology you may not currently have. A consultancy can write your ISMS documentation in a few weeks. Nobody can document their way to a staging environment that doesn't exist.
No, and this is the most common and most understandable misreading on the list.
Replit, to use a specific example, states that it has achieved SOC 2 Type 2 attestation and maintains logical separation between different users and organisations. That's a real control set and it reduces your scope. Base44 lists SOC 2 Type II and ISO 27001 on its security page, Lovable commits to maintaining both in its data processing agreement, and Supabase gives Team and Enterprise customers its SOC 2 Type 2 report. But a provider's report covers the provider's controls, not yours. Supabase's own documentation says customers must "implement their own compliance controls". As Secureframe's analysis of the AWS report puts it, a cloud provider can support your compliance but can't own it for you. You still have to evidence your own logging, your own access management, your own vulnerability handling and your own change control, and you still have to show the auditor how you did it.
The Cyber Essentials requirements draw the same line. For cloud services, the applicant is always responsible for making sure all five controls are in place, even where the provider implements some of them, and user access control is yours whether the service is infrastructure, platform or software. Your provider's certificate belongs in your evidence pack as one component of it, and founders routinely mistake it for the whole thing.
If you built on Lovable or Base44, our pages on taking Lovable apps and Base44 apps to production cover what you own on each platform and what moves when you leave.
Two, and in my experience they're the ones founders discover last.
A first-time SOC 2 Type II needs an observation window, and a first audit usually uses a window of three to six months, with six the common choice. Shorter windows are accepted, but they give the auditor less to sample. That window is real elapsed time during which your controls have to be operating and generating evidence. You cannot shorten it by paying more, and you cannot start it before the controls exist. Add scoping, fixing the gaps, the auditor's fieldwork and the report, and the same guide puts a first Type II at six to eighteen months end to end.
ISO 27001 has a similar floor. Certification comes through a two-stage audit: stage one reviews the ISMS on paper, stage two tests whether it's actually operating. Between the two you need evidence that the management system has been running, which means an internal audit and a management review that actually happened, not one dated last Tuesday.
Cyber Essentials Plus is faster. Its assessors test live systems, sampling real machines and checking the actual configuration state. If your patching story is "the platform handles it", you'll want to know whether that's true before an assessor finds out for you, because critical and high-risk updates have to be installed within 14 days of release.
Put those together and the honest answer to "can we be compliant by November" depends almost entirely on which certificates the buyer will accept at signature versus on a committed roadmap. That's a negotiation worth having early, and most founders don't realise it's available to them.
The line item usually reads: web application penetration test, API penetration test, remediation report, retest after fixes. That's four deliverables from one supplier at one price, and nothing about it looks wrong.
The trap is in the word "remediation". It assumes you can change the thing that failed. On a conventional stack that's a given. On a no-code or AI-generated build, a decent tester will hand you findings in three buckets, and only one of them is yours to fix.
Findings in your application logic, you can fix. Findings in the platform's generated scaffolding, you might be able to fix, depending on how much of the output you actually control. Findings in the platform's own infrastructure or default configuration, you cannot fix at all. You can only report them upstream and wait, or move. And that third bucket is exactly where the ugliest issues tend to sit, because default configuration is what catches people out: publicly readable projects, secrets that follow a fork, endpoints the agent generated without an authorisation check.
There's a second, more procedural problem. Testing infrastructure you don't own usually needs the provider's authorisation, and your tester will ask for it before they touch anything. If your platform's terms don't permit it, the scope shrinks to whatever sits above their boundary, and the report your buyer receives says so in the limitations section, which buyers do read.
So the retest you paid for can arrive with findings still open and a note explaining they're outside your control. That's a worse position than not having tested, because it's now written down in a document your buyer holds.
It needs looking at, and the evidence on this got harder to argue with in 2026.
Researchers at Georgia Tech's Systems Software and Security Lab built a tracker that scans public vulnerability databases and traces each bug back through the code's history to find the tool that introduced it. Their April 2026 write-up reports 74 confirmed vulnerabilities attributable to AI-generated code out of more than 43,000 advisories scanned, 14 of them critical and 25 high. The trend is the part I'd pay attention to: 18 cases across seven months of late 2025, then 56 in the first quarter of 2026 alone, with 35 in March.
I want to be fair about what that does and doesn't prove. Seventy-four is a small number against 43,000, the attribution method depends on detectable tool signatures so it will undercount, and the sharp rise partly reflects how much more AI-written code exists now, which tells you nothing about whether it has become more dangerous. Treat it as a reason to have someone read your code before a buyer's tester does, which brings us back to the awkward question of whether you can read it at all, and whether you'd be allowed to change what you found.
Two regulations, if your app has AI features used in the EU or sells to consumers there. The EU AI Act's transparency rules in Article 50 have applied since 2 August 2026, including to apps launched before that date. If people talk to an AI in your app, they have to be told, unless it's obvious. If your app generates text, images, audio or video, the provider of that AI system has to mark the output as AI-generated in a machine-readable way, with exceptions such as standard editing help. If you build on someone else's model, check which of you that duty falls on. Under the 2026 amending regulation, generative systems already on the market before 2 August 2026 have until 2 December 2026 for the marking duty only.
The European Accessibility Act has applied since 28 June 2025 to certain services provided to consumers. Those include selling any product or service to consumers through a website or app, and banking. Apps sold only to businesses aren't covered, and microenterprises providing those services (fewer than 10 staff, and turnover or balance sheet of €2 million or less) are exempt. In our experience a UK enterprise buyer's list rarely mentions either regulation, but both can reach a UK app that serves users in the EU.
The buyer's own list usually ends with a set of questions to put to each supplier: full cost, certification costs, timescale, what's included, annual renewals, ongoing support, SaaS experience, references, payment schedule. They're sensible questions aimed at the wrong thing, because they assume the ten items are ten purchases.
Four extra questions do more to separate the suppliers who've done this from the ones who haven't.
Ask which items are architecture and which are paperwork. Anyone who says it's all paperwork is quoting for a document pack, and anyone who can't answer hasn't read the list properly. Then ask what has to be true before each item can start, which is really asking them for the dependency order now, before you pay for them to discover it mid-project.
Ask what happens to a penetration test finding you can't fix. A supplier who's worked on a no-code migration will already be thinking about which findings land in platform infrastructure. One who's quoting a generic engagement won't have considered it.
The fourth is strictly a question for your buyer, but a good supplier will tell you to go and ask it: which certificates do they need in hand at signature, and which will they accept on a committed roadmap? The answer changes the sequence, the cost and the launch date of everything downstream, and I've yet to meet a founder who knew they were allowed to ask.
Then there's data. UK GDPR Article 28(3) requires your processor contracts to cover documented instructions, sub-processor authorisation and audit rights, and the ICO sets out the full list. Your customer will want commitments on deletion, breach notification and sub-processor change control. You can only promise what your own platform has promised you, so find out where your data physically sits and who the sub-processors are before you sign anything that says otherwise.
Reading this back, it sounds like bad news, but I don't think it is.
Every item on that checklist is a solved problem with a known playbook. Separated environments, change control, encrypted managed databases, real authentication, monitoring, tamper-evident audit logs: none of it is research. It's a defined programme of work with a defined cost, and the engineering side of it is our day job.
What nobody can buy is the bit you've already finished. You worked out what to build, you built something people want, and you got a large organisation interested enough to send you their checklist. That carries through whatever work comes next. What changes underneath it is the foundation the certificates are actually auditing.
Building on a no-code platform wasn't the mistake. For proving an idea it's often the right call, and I'd say so to anyone. The mistake is going out for three quotes on a list you haven't yet read as a dependency order, and then promising your buyer a launch date built on the total.
If a checklist like this has landed on your desk, start with a free check. Tell us about your app through a short form, and a person reads it and replies in writing with what we'd look at first. If there's more to find, a £95 review goes deeper: whether you can charge for your app, whether your business rules hold, whether search engines and AI assistants can find it, and what you own. The £95 is credited in full against any paid work we do next.
Getting your existing app to production is a fixed £999 to £1,999, depending on complexity. That covers fixes, security, moving your backend, in-app payments, store submission, or a wrapper route to the stores.
Bigger work to meet an enterprise checklist, such as retrofitting tenant isolation, separating your environments or a full native or cross-platform rebuild, gets a fixed-price quote after the review. The certification audits and the penetration test come from independent audit and testing firms and aren't part of our price. Our Vibe Code to Production page sets out the whole route.
Get a free check and bring the checklist with you.
Your organisation can be certified, and the app's hosting is part of that assessment. Under version 3.3 of the requirements, used for assessments started after 27 April 2026, cloud services can't be excluded from scope. What matters in practice is whether you can evidence multi-factor authentication on every cloud service where it's available, install critical and high-risk updates within 14 days, and, for Cyber Essentials Plus, show the assessor live configuration. Some platforms make that easy to show, and on others you can't see enough of the configuration to prove it.
Plan on at least six months, and often a year or more, if SOC 2 Type II or ISO 27001 is required at signature, and considerably less if the buyer will accept them on a committed roadmap. The part you can't speed up is the SOC 2 observation window, typically three to six months for a first Type II, which paying more doesn't shorten, plus preparation and audit either side. Cyber Essentials, legal documentation and cloud hardening move much faster and should be sequenced first because later items depend on them.
No. A provider's SOC 2 report covers the provider's controls. You still have to evidence your own access management, logging, vulnerability handling and change control, and an auditor will assess those separately. The provider's report is a useful component of your evidence pack and a real reduction in scope, but treating it as your certification is the single most expensive misunderstanding on the list.
You report it upstream to your platform provider and disclose it to your buyer, and the finding stays open in the retest. This is why the pen test line item deserves scrutiny before you commission it: on a no-code build, some findings sit in platform infrastructure you have no ability to change, and testing that infrastructure may need the provider's authorisation in the first place. Work out which bucket each finding will land in while you scope the test.
Not by default. The domain logic, the interface, the business rules and the validated demand carry forward. What usually needs replacing is underneath: the data model and tenant isolation, authentication, the deployment pipeline and the separated environments that ISO 27001 and the Software Security Code of Practice both assume you have. Sort out tenant isolation first, because every new customer adds data to the tables you'd have to change. The free check tells you which of those your app needs.
