Production Readiness Checklist for AI-Built Apps: OWASP ASVS and Cyber Essentials Plus

Why does an AI-built app need a production readiness checklist?

AI coding tools optimise for a working demo, and a working demo is not the same as a system that is safe to put in front of customers. In our experience, the gaps are predictable: secrets in the code, missing authorisation checks, dependencies nobody has reviewed, and tests that pass without asserting much.

A checklist turns ‘it seems fine’ into a list of questions with yes or no answers. Kept with a date and the name of whoever checked it, it also becomes evidence. That matters when a customer, procurement team or insurer asks how the software was checked.

Our guide to taking a prototype to production covers the wider engineering journey: whether to stabilise, refactor or rebuild. This guide is narrower. It is the checklist we would use to decide whether an application is ready for real users.

Does Cyber Essentials Plus cover your application’s code?

No. Cyber Essentials Plus covers your organisation’s IT infrastructure, including the cloud services your application runs on, but not the code you wrote. The NCSC’s Requirements for IT Infrastructure v3.3 says it directly: ‘Bespoke and custom components of web applications are out of scope.’

That surprises many people, because Cyber Essentials Plus is often the first certification a buyer asks for. Here is what it does cover:

• Five technical controls: firewalls, secure configuration, security update management, user access control, and malware protection.
• Cloud services: since version 3.3 (April 2026), cloud services that hold your data or run your services cannot be excluded from scope. That includes platform services such as Azure Web Apps, where the provider runs the infrastructure and you manage the application.
• Independent testing: Cyber Essentials Plus assesses the same controls as Cyber Essentials, with what the NCSC describes as more rigorous, independent technical testing.

For the code itself, the same document points to robust development and testing in line with commercial best practice, and to the Software Security Code of Practice. That is where OWASP ASVS comes in.

Which references does this checklist use?

Each item below is tagged with the reference it maps to. There are three:

• OWASP ASVS 5.0, the Application Security Verification Standard from the Open Worldwide Application Security Project (OWASP). Version 5.0, released in May 2025, has 17 chapters, numbered V1 to V17, and three levels of increasing depth. We use chapter numbers from 5.0.
• Cyber Essentials Plus v3.3, for the infrastructure and cloud services the application runs on.
• WCAG 2.2 AA, the Web Content Accessibility Guidelines, for accessibility.

Some items have no formal reference. They are there because, in our experience, their absence is what causes the first serious incident after launch.

Which ASVS level should you aim for?

Level 2 is the right target for most business-critical applications, including anything that handles personal data. Level 1 is a reasonable floor for a prototype that is not yet in front of customers. Level 3 is for the highest-risk systems.

Full verification at any level includes some configuration and architecture requirements that a code review cannot reach on its own. Record which requirements you checked and which you left out of scope, rather than claiming compliance with the whole level.

The production readiness checklist

Items marked (you) can usually be checked by someone without development experience, given access to the right accounts. Items marked (engineer) need someone who can read the code.

Secrets and configuration

• No API keys, passwords or connection strings in the code or its history (engineer). ASVS V13 Configuration.
• Secrets live in a managed store, such as Azure Key Vault, and any that were ever exposed have been rotated (engineer). ASVS V13.
• Debug modes, sample accounts and default credentials are switched off in production (engineer). ASVS V13; Cyber Essentials Plus secure configuration.
• Secret scanning runs automatically on every change, for example GitHub secret scanning (you, if someone set it up).

Accounts and access to your cloud services

• Every account on your cloud, hosting, code repository and domain registrar uses multi-factor authentication (MFA) (you). Cyber Essentials Plus user access control: authentication to cloud services must always use MFA.
• Administrative work uses separate admin accounts, not everyday accounts (you). Cyber Essentials Plus user access control.
• Accounts for people who have left, and for former suppliers, are removed (you). Cyber Essentials Plus user access control.
• Your organisation, not a former agency or freelancer, owns the cloud, repository and domain accounts (you).

Authentication and sessions in the app

• Sign-in uses a proven identity provider or library rather than custom code (engineer). ASVS V6 Authentication.
• Repeated failed sign-ins are slowed or blocked, and MFA is available for privileged users (engineer). ASVS V6.
• Sessions expire, and signing out ends the session on the server (engineer). ASVS V7 Session Management.
• Tokens are validated properly, including signature, expiry and audience (engineer). ASVS V9 Self-contained Tokens and V10 OAuth and OIDC.

Authorisation

• Every page and API endpoint checks the user’s permissions on the server, not only in the browser (engineer). ASVS V8 Authorization.
• Users cannot see or change another user’s or organisation’s records by changing an ID in a URL or request (engineer). ASVS V8.
• Admin functions cannot be reached by ordinary users (engineer, with a test account you can try yourself). ASVS V8.

Input, output and business logic

• All input is validated on the server, whatever the browser already checked (engineer). ASVS V2 Validation and Business Logic.
• Output is encoded so user content cannot run as script, and database queries are parameterised (engineer). ASVS V1 Encoding and Sanitization.
• File uploads are checked for type and size, and stored outside the web root (engineer). ASVS V5 File Handling.
• Business rules, such as prices, limits and approvals, are enforced on the server (engineer). ASVS V2.

APIs

• Every endpoint requires authentication unless it is deliberately public, and the public ones are listed (engineer). ASVS V4 API and Web Service.
• Endpoints return only the fields the caller needs, not whole database records (engineer). ASVS V4.
• Rate limits protect expensive or sensitive endpoints (engineer). ASVS V4.

Data protection and encryption

• All traffic uses HTTPS, with no fallback to plain HTTP (you can check the browser padlock; engineer for internal traffic). ASVS V12 Secure Communication.
• Personal data is identified, kept only as long as needed, and not written to logs (engineer). ASVS V14 Data Protection; UK GDPR.
• Passwords, if you store them, are hashed with a modern algorithm, and encryption uses standard libraries (engineer). ASVS V11 Cryptography.

Dependencies and updates

• Every third-party package is known, still maintained, and free of known critical or high vulnerabilities (engineer). ASVS V15 Secure Coding and Architecture.
• Dependency alerts run automatically, for example Dependabot (you, if someone set it up).
• Critical and high-risk updates to the platform, runtime and operating systems are applied within 14 days of release (engineer). Cyber Essentials Plus security update management, which defines these as a CVSS v3 base score of 7 or above, or as rated by the vendor.
• Nothing in production runs on a version that is out of vendor support (engineer). Cyber Essentials Plus security update management.

Cyber Essentials Plus does not assess your application’s own dependencies, because the code is out of scope. We still apply the same 14-day discipline to them. A vulnerable package in your app is as exploitable as an unpatched server.

Hosting and network exposure

• Only the ports and services the app needs are reachable from the internet (engineer). Cyber Essentials Plus firewalls.
• Databases and storage are not publicly accessible (engineer). Cyber Essentials Plus secure configuration; ASVS V13.
• Production, staging and development are separate, with separate data (engineer).

Logging, monitoring and errors

• Sign-ins, permission failures and admin actions are logged, without secrets or personal data in the logs (engineer). ASVS V16 Security Logging and Error Handling.
• Errors show users a friendly message, not stack traces or database details (you can spot these; engineer to fix). ASVS V16.
• Someone is alerted when the app fails or slows down, and knows what to do (you).

Backups and recovery

• Backups run automatically and are stored separately from production (engineer).
• A restore has been tested, and you know how long it takes (you can ask for proof).

Backups are not a technical requirement of Cyber Essentials, but version 3.3 highly recommends them. In our experience, a backup that has never been restored is the most common false comfort in a new application.

Accessibility

• Key journeys pass an automated scan against WCAG 2.2 AA (you, with a free browser extension). WCAG 2.2 AA.
• Every function works with a keyboard alone, and form fields have labels (you). WCAG 2.2 AA.

Automated tools catch only part of WCAG. Our guide to accessible software design explains what they miss and when you need more.

Tests and deployment

• Automated tests cover the business logic that matters most, and they check results rather than just running (engineer).
• Every change reaches production through an automated pipeline, not by hand from someone’s laptop (engineer).
• You can roll back a bad release, and someone has tried it (engineer).

AI features inside the app

If the app calls a language model, add these:

• User input cannot instruct the model to ignore its rules or reveal its prompt, which is known as prompt injection (engineer).
• The model can only reach the data and actions the current user is allowed (engineer). ASVS V8.
• Model output is treated as untrusted input before it is shown or acted on (engineer). ASVS V1.

The OWASP Top 10 for LLM Applications covers these risks in more depth.

What should you do with the results?

Rank every unticked item by severity, then fix the critical ones before launch. A checklist with gaps is still useful, provided you know which gaps you are accepting and why.

Keep a dated record of each pass: what was checked, by whom, against which references, and what was left out of scope. That record is what you can show a buyer who sends a security questionnaire. It is evidence of what was checked. It is not a certificate, and it does not prove the application is secure.

Run the automated parts on every change. Repeat the full checklist before major releases, and whenever a customer or insurer asks.

How do we use this checklist?

This checklist is the basis of our Production Readiness Review, a fixed-fee, two-week review for AI-built and AI-generated applications. Senior engineers validate the code against OWASP ASVS, Level 2 by default, alongside our own suite of checks built from penetration test findings on previous projects. Static analysis runs with GitHub Advanced Security and our in-house rules.

You receive an evidence pack listing what was checked, what was out of scope and every finding by severity, with a prioritised plan. The review is carried out by our ISO 27001 and Cyber Essentials Plus certified team.

If your app is already failing in production, start with vibe coding rescue instead. Once it is live, our guide to keeping supported software secure explains how the checks continue under managed support.