Opinion
How to Read the Compliance Checklist Your Enterprise Buyer Just Sent
August 6, 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 quietly 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 genuinely good on Replit, Lovable, 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 quietly doubles, because the quotes come back priced as if the ten items were independent of each other.
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 your architecture rather than a service you can procure. 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. From 27 April 2026 the scheme runs on the v3.3 question set, and IASME's summary of the changes is blunt on the point that matters here: all cloud services are in scope, and organisations have to justify any excluded infrastructure to the assessor. You don't get to leave the platform your product runs on outside the boundary because someone else operates it. Multi-factor authentication is now mandatory on every cloud service that offers it, with failure to enable it an automatic fail rather than a finding to remediate.
The same update renamed the web applications section to "application development" and pointed it at the UK Government's Software Security Code of Practice, published by DSIT and the NCSC in May 2025. That code has fourteen principles across four themes, and theme two is the one that should stop a vibe-coding founder in their tracks. 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. That gap is structural rather than administrative, and ISO 27001 pokes at the same one from a different angle: Annex A control 8.31 requires development, test and production environments to be separated, and 8.25 requires documented 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 genuinely reduces your scope. But a provider's report covers the provider's controls, not yours. As Secureframe's analysis of the AWS report puts it, cloud service providers support your compliance rather than owning it. 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.
IASME draws the same line for Cyber Essentials. For platform-as-a-service, the applicant is responsible for application-level configuration. For infrastructure-as-a-service, all five controls land on you. Your provider's certificate belongs in your evidence pack as one component of it, and founders routinely mistake it for the whole thing.
Two, and in my experience they're the ones founders discover last.
A first-time SOC 2 Type II needs an observation window, and the minimum is three months for a first audit, with six months common. 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 preparation and the audit itself and a realistic first Type II runs six to ten months even with a specialist firm.
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 genuinely happened rather than one dated last Tuesday.
Cyber Essentials Plus is faster, but it's now verified against live systems rather than a policy document. Assessors sample real machines and check 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 high and critical updates carry a fourteen-day window and a miss is a fail rather than an observation.
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. Four deliverables, one supplier, one price, and nothing obviously wrong with it.
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 rather than any change in how dangerous it is. 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.
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. Sensible questions. They're just 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 to hand over the dependency order in advance rather than discover it mid-project at your expense.
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. I don't think it is, and I'd rather say why than leave it hanging.
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 it's the part we do all the time.
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 survives the rebuild intact. 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, our Vibe Code to Production service exists to work through exactly this: what carries forward, what has to be rebuilt, and what order the compliance work has to happen in. If you'd rather know the shape and the number before committing to a build, the App Gameplan is a fixed-price four-week assessment that gives you a board-ready answer. And if you want the wider version of this argument, we wrote about why a working demo isn't yet a sellable product earlier this year.
Get in Touch and bring the checklist with you.
Your organisation can be certified, and the app's hosting is part of that assessment rather than outside it. Under the v3.3 requirements in force from 27 April 2026, all cloud services are in scope and any exclusion has to be justified to the assessor. What matters in practice is whether you can evidence multi-factor authentication on every cloud service that offers it, keep high and critical updates inside a fourteen-day window, and show the assessor live configuration rather than a policy document. Some platforms make that straightforward. Some make it impossible to demonstrate.
Plan on six to twelve months 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 fixed floor is the SOC 2 observation window, which is a minimum of three months for a first Type II and cannot be shortened, 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 genuine 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. Knowing which bucket each finding will land in is part of scoping the test, not part of reading the report.
Usually not. The domain logic, the interface, the business rules and the validated demand carry forward. What gets rebuilt 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. Data isolation in particular can't be retrofitted cleanly, so if it's coming, it's cheaper early.
