# Yes, you should vibe code in the enterprise.

I want people across the organisation to have access to approved AI tools, somewhere safe to experiment and time to use them. Encourage them to build things that solve problems in their own work.

The people doing the work usually have a pretty good idea of what's wrong with it. If someone thinks they can fix a slow approval process or automate the spreadsheet they keep rebuilding, let them have a go. Let them get the first version wrong, show it to colleagues and try again. A small application with synthetic or otherwise approved data can make the problem much easier to discuss than another requirements meeting.

People need to know which tools they can use, what data they can put into them and where to get help when an idea starts working. The company should make that easy to find.

A purchasing tool might start with a sample spreadsheet. Then its users want live supplier data. Next they want it to update purchase orders. Eventually another team starts depending on it, and the person who built it moves to a different role.

It might still look like the same little app. But now it can place orders, and someone else has to keep it running.

**Before you put confidential data into it, give it an API key that can do damage, or let a business process depend on it, you need to know what it can do and who's responsible for it.**

That goes for the coding agent too. If it can read your repository, run commands, retrieve secrets and reach the production network, it already has access that needs controlling. You don't get to leave that discussion until deployment.

I've put together 300 checks for the application lifecycle, plus 36 for EU regulatory readiness through the end of 2027. Yes, it's a long list. I want engineering, security, platform, operations and business owners to be able to work through the same questions without each team having to start its own list.

A lot of this is work the enterprise can do once and make available to everyone. Approved hosting, identity, secrets management, deployment pipelines, monitoring and maintenance should already have a home. Asking every employee with a useful idea to assemble all of that themselves is a fairly good way to make sure their idea goes nowhere.

The application still needs its own decisions about business rules, data and permissions. Your identity provider can't decide who should be allowed to approve a supplier payment. Having a backup service doesn't tell you whether the restored purchasing app produces the right orders.

## Using this checklist

For each check, record whether it applies, who owns it, what evidence you have, its status and when you'll review it again. Evidence can be an approved decision, configuration, test result or operating record. The leads below are suggestions; put actual names against the work.

Work out which checks apply before granting access to confidential data or permissions to change things. Agree what has to be verified before data processing, before write access and before production use, and what you'll keep checking afterwards. Read-only access can still expose an entire customer database.

If the application doesn't bill anyone, the billing section won't apply. Runtime AI checks matter when there's AI in the running application. Whether you need a second region depends on how the business needs to recover. Record any exception with a reason, an owner, an expiry date and suitable safeguards. An internal risk acceptance doesn't let you waive a legal or contractual obligation.

The numbered ranges should help you find the part you own:

| Checks  | Coverage                                                                                       |
| ------- | ---------------------------------------------------------------------------------------------- |
| 1–80    | Ownership, approved environments, assets, data, authority, development tools and documentation |
| 81–160  | Authentication, authorisation, security, databases, business rules and integrations            |
| 161–240 | Software supply chain, updates, releases, testing, monitoring, recovery and incidents          |
| 241–300 | Runtime AI, user experience, support, contracts, billing and the end of the application's life |
| B01–B36 | EU regulatory applicability and readiness through 31 December 2027                             |

## 1–10. Ownership and purpose

Lead: the business owner. Evidence: an approved application record.

1. A named business owner is responsible for the application's purpose and continued use.
2. A named technical owner is responsible for maintenance, fixes and technical decisions.
3. Both owners have deputies and cover for when they're away or move on.
4. Write down who the application is for, what it's for and which uses are allowed.
5. Spell out what the application mustn't be used for and where its scope ends.
6. The process owner approves the workflow and its effects on other teams.
7. Assess the impact of incorrect results, data exposure and service interruption separately.
8. Business criticality determines approval authority, monitoring and support coverage.
9. Maintenance, licences, infrastructure and future changes have a budget, with someone responsible for it.
10. A named owner approves the purpose and release policy; you can trace approval of each deployed version through that policy.

## 11–20. An approved place to run

Lead: the platform team. Evidence: the environment identity and approved deployment route.

11. The application runs on an organisation-approved platform, such as its own datacentre or an approved Azure environment.
12. The approval names the subscription, account, tenant or cluster, including allowed regions and services.
13. Cloud accounts, hosting arrangements and service contracts are under company control.
14. The environment follows the organisation's security configuration, network design and resource-creation policies.
15. Public endpoints and internet exposure receive the required approval.
16. Restrict network access to databases, administration interfaces and internal services.
17. Control outbound connections, including those to AI providers and external storage.
18. Development, test and production have separate data, identities and permissions.
19. Make clear what the hosting provider handles and what your own teams handle for each component.
20. Prevent deployment to personal hosting accounts or unapproved fallback environments, or detect it and act on it.

## 21–30. Application inventory and asset management

Lead: IT service management and the technical owner. Evidence: a current asset record linked to actual resources.

21. The application is registered in the organisation's application inventory, asset system or configuration management database.
22. The record includes owners, contacts, criticality, data classification and lifecycle status.
23. Link source repositories, build pipelines and artefact repositories to the same application record.
24. Servers, containers, functions, databases, storage and scheduled jobs are inventoried.
25. Record domains, DNS, certificates and who renews them; registrar accounts and recovery channels belong to the company.
26. The company controls external accounts, service identities, integrations and keys; store references in the inventory, not the secrets themselves.
27. Dependency records show which business processes stop working when a connected service goes down.
28. Resource identifiers connect costs, logs and alerts to the correct application.
29. Check the inventory against what's actually deployed, including manually created or forgotten environments.
30. Update the inventory when owners, deployed versions or dependencies change.

## 31–40. Data and where it goes

Lead: the data owner and application team. Evidence: a data inventory and flow diagram.

31. Each data category has an owner and classification, including personal information and trade secrets.
32. Collect and retrieve only the data the application needs for its purpose.
33. Document where data goes, from source systems through the application to external services.
34. Those flows include logs, caches, search indexes, analytics, backups and support tools.
35. Know where data is stored and processed, including subcontractors and support access.
36. Moving data to another region or provider follows the required approval process.
37. Tests and demonstrations use suitable synthetic data or data whose anonymisation has been assessed.
38. Any copy of production data used for testing has a justified purpose, suitable safeguards and approval.
39. Reports, downloads and temporary files keep the classification their contents require.
40. The data owner has approved confidential-data use in this application and this environment.

## 41–50. Identities, secrets and administrative access

Lead: identity, platform and application teams. Evidence: a permission inventory and revocation tests.

41. Unattended integrations use dedicated service identities; access on behalf of a user keeps that user's identity and authorised scope.
42. Use short-lived workload identity in place of long-lived keys where it's supported.
43. Keep required secrets in an approved secrets-management service.
44. Secrets stay out of source code, browser bundles, URLs, logs and AI conversations.
45. Every identity receives only the actions and data access required for its task.
46. Development, deployment, administration and runtime identities are separated.
47. Administrators use individual accounts and strong authentication; elevated access is time-limited where appropriate.
48. Track who owns each key, when it expires and how it's rotated. Exercise emergency revocation.
49. When an employee leaves, remove access through active sessions, development tools and administrative connections.
50. Emergency access has a controlled procedure, an audit trail and a subsequent review.

## 51–60. Permission to change, delete, send or spend

Lead: the business owner and connected-system owners. Evidence: authority limits and tests of forbidden actions.

51. Each integration states whether it can read, modify, delete, send, publish or spend money.
52. Integrations that only retrieve data get read access without unnecessary write permissions.
53. Write access is restricted to the required objects, records, customers or organisational units.
54. The receiving system enforces permissions when the caller is an AI agent as well as a human.
55. Large, irreversible or otherwise consequential actions need human approval suited to their risk.
56. The approval shows the target, proposed change and expected effect, and applies only to that specific action.
57. Payments, bulk changes, messages and resource creation have enforceable quantity or value limits.
58. Destructive operations support previews or dry runs where technically possible.
59. An administrator can stop automation and revoke its access even when the application isn't working properly.
60. Have separate procedures for stopping queued work and correcting actions that have already happened.

## 61–70. AI tools used during development

Lead: the development-platform owner and security team. Evidence: approved tools, configurations and execution records.

61. Coding agents, models, extensions and MCP servers are approved for organisational use.
62. Check their terms, retention and possible training use before giving them confidential information.
63. Give agents only the files, directories and network access they need for the task.
64. Agent execution environments are isolated from production and unrelated projects.
65. Treat documents, websites and dependencies that agents read as possible sources of malicious instructions.
66. Code or the platform enforces tool permissions, even when a prompt asks otherwise.
67. Agents can't grant themselves more privileges, approve their own exceptions or disable required checks.
68. Changes to agent tools and instructions are versioned and reviewed.
69. Execution records identify models, changes, checks and approvals without exposing secrets.
70. Set retention and deletion rules for development conversations, temporary files and logs.

## 71–80. Documentation another person can use

Lead: the technical owner. Evidence: documentation tied to the release and a successful handover exercise.

71. The specification explains what the application does, for whom and under which acceptance criteria.
72. User journeys cover errors, exceptions and interrupted work too.
73. Architecture documentation shows components, external dependencies and trust boundaries.
74. The data model explains meaning, relationships, ownership and lifecycle.
75. Keep the reasoning behind significant technical decisions, including the alternatives considered.
76. The threat model and risk register reflect the actual implementation and are updated when it changes.
77. APIs, events, configuration and differences between environments are documented.
78. Another developer can run the application from the README without asking its author to explain the missing steps.
79. Operating, maintenance, recovery and incident instructions are accessible when the application is down.
80. Documentation has an owner, a review date and a link to the deployed version.

## 81–90. Authentication and the user lifecycle

Lead: the identity and application teams. Evidence: login, role-change and departure tests.

81. Enterprise users authenticate through the approved identity provider and single sign-on.
82. OIDC or SAML integrations meet the organisation's identity-provider requirements.
83. Multi-factor authentication and applicable conditional-access policies cover administrators too.
84. Provisioning, role changes and removal follow the user's lifecycle through SCIM or another controlled process.
85. Test that removing a user removes their permissions and ends their sessions within the agreed time.
86. Sessions have appropriate lifetimes, and administrators can terminate all sessions for a user.
87. Any required local-password storage and recovery use an approved implementation.
88. Recovery links expire, work once and resist abuse.
89. Replacing a lost authentication factor doesn't create an easier way around authentication.
90. Login throttling, lockout and identifier handling are tested with legitimate unusual inputs and hostile attempts.

## 91–100. Authorisation, isolation and privilege escalation

Lead: the process owner and application team. Evidence: a permission matrix and negative tests.

91. Roles match actual responsibilities and define allowed actions precisely enough to enforce them.
92. The server checks authorisation for every protected operation and data object.
93. Changing `/documents/15` to `/documents/16`, or calling the API directly, can't expose an unauthorised document.
94. Tenant and organisational-unit isolation covers background jobs, searches, caches and exports.
95. Missing permissions or failed permission checks result in a safe denial.
96. Approvals, payments and access grants follow the required separation of duties.
97. Support impersonation is restricted, time-limited and auditable.
98. Guest and supplier access has a sponsor, limited scope and an expiry date.
99. Owners review access on a schedule based on risk, and whenever responsibilities change.
100.  Identify inherited permissions and escalation paths through groups, role assumption, service identities and integrations; block unintended elevation and test that the blocks work.

## 101–110. Application security

Lead: the application and security teams. Evidence: security-test results and verified fixes.

101. The server validates input types, bounds and allowed values, regardless of what the interface checks.
102. Database access uses parameterised queries or equivalent safe interfaces.
103. Displayed content uses context-appropriate encoding to prevent cross-site scripting.
104. The session model's required cross-site request-forgery protection is implemented and tested.
105. User-supplied URLs can't provide unauthorised access to internal networks or cloud metadata services.
106. User input cannot become an uncontrolled shell command, filesystem path or executable template.
107. CORS, cookies, security headers and browser policies match the application's access model.
108. Remove debug endpoints, default credentials and unnecessary services from production.
109. Security testing and required independent penetration testing cover the actual operating environment.
110. Define which findings block release, fix them and retest before approving the affected use.

## 111–120. Files, storage and encryption

Lead: the platform and application teams. Evidence: storage configuration and file-access tests.

111. Network traffic uses encryption appropriate to its classification, with working certificate and peer-authentication checks.
112. Storage encryption covers databases, disks, objects and backups according to the approved classification.
113. Encryption-key access, rotation and recovery dependencies are managed.
114. Check actual file types and size limits on uploads, and run required malware checks.
115. Uploaded content can't execute with the application's privileges.
116. File access and sharing links enforce user and tenant permissions.
117. Archives, unusual filenames and large inputs cannot bypass limits or exhaust storage.
118. Temporary files and obsolete object versions expire under the retention policy.
119. Public exposure and changes to storage-sharing configuration are detected.
120. Assess how data left on workstations, browsers and mobile devices is protected.

## 121–130. Databases and migrations

Lead: the application team and database operator. Evidence: schema reviews and migration rehearsals.

121. The data model is reviewed against business concepts before real information is stored.
122. Keys, referential integrity, required fields and uniqueness constraints protect correctness.
123. Schema changes are versioned and repeatable.
124. Test recovery or repair procedures for migrations; rolling back code won't necessarily bring lost data back.
125. Assess what happens when a migration holds locks for too long, rewrites data or gets interrupted.
126. Old and new application versions coexist safely during deployment where required.
127. Test indexes and query plans with realistic data volumes.
128. Connection pools, timeouts and limits protect the database from overload.
129. Concurrent updates and transactions avoid lost changes and partially completed business operations.
130. Test the model against new tenants and foreseeable next use cases, and record its limits.

## 131–140. Business logic and data quality

Lead: the process owner and application team. Evidence: approved examples and boundary tests.

131. Approval limits, delegations and exceptional cases are specified.
132. One person with several accounts can't bypass a requirement for independent approvers.
133. Monetary calculations use appropriate integer units or exact decimal representations.
134. Rounding, currency conversion, negative values and zero follow the agreed rules.
135. Timestamps, local time and daylight-saving changes work correctly for the use case.
136. Names, identifiers, Unicode and missing values work without invalid assumptions about users.
137. Imports handle encodings, separators, invalid rows and partial failures.
138. Exports contain authorised data and appropriate protection against spreadsheet-formula injection.
139. Pagination, search and sorting handle changing data without silently losing or duplicating records.
140. Corrections and any soft deletion follow defined rules and leave the required history.

## 141–150. APIs and integrations

Lead: the integration owners. Evidence: interface contracts and dependency-failure tests.

141. API contracts, versions and retirement dates are documented.
142. Incoming webhooks have authenticity and freshness checks.
143. Receiving the same event again can't unintentionally repeat the same business change.
144. Operators can see outgoing webhook delivery, retries and failures.
145. OAuth refresh, revocation and reauthorisation are tested.
146. External schema changes, missing fields and invalid responses fail in ways the application can handle.
147. Rate limits protect capacity and provide understandable responses to legitimate users.
148. Customer API credentials can be scoped, issued, rotated and revoked through controlled processes.
149. External integration partners have separate test environments and credentials where needed.
150. Reconcile records across systems to catch silent transfer failures and inconsistencies.

## 151–160. Background jobs and automation

Lead: the application team and platform operator. Evidence: failure, retry and shutdown tests.

151. Use a managed queue for slow tasks when the workload needs one.
152. Jobs have bounded execution time, retries and backoff appropriate to the operation.
153. A timeout doesn't trigger blind retries when the first attempt may already have changed data.
154. Jobs that keep failing go to a review queue with an owner and a recovery procedure.
155. Scaling the application or changing clocks can't accidentally multiply scheduled jobs.
156. Duplicate events and repeated form submissions are handled on the server.
157. Interrupted work resumes from a known state or follows a controlled recovery path.
158. Monitor queue depth, the age of the oldest job and processing capacity.
159. A dependency failure can't trigger an unbounded storm of requests to other systems.
160. Replaying jobs and correcting failed batches preserve permissions and required event ordering.

## 161–170. Source code, SBOM and the software supply chain

Lead: the development-platform owner and application team. Evidence: an SBOM linked to each release artefact.

161. Source code and its history reside in company-controlled version control.
162. Changes pass the required reviews and checks, with traceable results.
163. Check package names, publishers, sources and installation scripts to a depth that matches the risk.
164. Dependency versions and lockfiles support controlled, repeatable builds.
165. Each release produces a machine-readable software bill of materials, such as SPDX or CycloneDX.
166. SBOM coverage includes direct and transitive dependencies and runtime or container bases within a defined scope.
167. Record what the SBOM doesn't cover, including any separately downloaded extensions.
168. You can connect the SBOM, source revision, build run and production artefact.
169. Artefact provenance and integrity are checked during release, and repository access is restricted.
170. Licences, required notices and rights to third-party material are reviewed.

## 171–180. Updates and vulnerability handling

Lead: the technical owner and component maintainers. Evidence: coverage reports and production verification.

171. Operating systems, container bases, runtimes, frameworks and libraries have maintainers and a regular update schedule.
172. Include databases, deployment tools, coding agents and extensions in update responsibilities.
173. Dependencies and release artefacts are reassessed as new vulnerabilities emerge; SBOM and inventory gaps are investigated.
174. Prioritise findings by exposure, exploitability and business impact.
175. Remediation targets reflect severity, with a working route for urgent fixes.
176. Exceptions and temporary mitigations have owners, reasons and expiry dates.
177. Test updates against application behaviour, with a way to ship urgent fixes outside routine maintenance cycles.
178. Verify the fix in the version actually deployed, including any older instances still running alongside it.
179. Track supplier end-of-support dates and retiring API or model versions before they cause disruption.
180. The organisation can see which applications are outdated, who owns them and what's blocking fixes.

## 181–190. Builds and releases

Lead: the platform and application teams. Evidence: repeatable deployment and rehearsed recovery.

181. Infrastructure and environment configuration are versioned, with detection of unauthorised drift.
182. Test environments reproduce the relevant production behaviour without sharing production credentials.
183. Pipeline identities can deploy only to authorised environments with the necessary permissions.
184. Code, test and security checks block releases under defined failure conditions.
185. You can identify the deployed artefact as the one that passed testing and approval.
186. Application, configuration and infrastructure changes follow change management, including approved automated routes.
187. Deployment accounts for permitted downtime, traffic management and database changes.
188. Rehearse rollback or forward recovery and check data compatibility.
189. Feature rollout can be limited to appropriate users or controlled with managed feature flags where needed.
190. You can trace the change, deployer, approval, time and production outcome.

## 191–200. Tests before real use

Lead: the application team and process owner. Evidence: results tied to requirements.

191. Expected behaviour comes from approved requirements and business examples.
192. Unit tests cover calculations, state transitions and rule boundaries.
193. Integration tests cover successful responses, errors and timeouts.
194. End-to-end tests cover critical user journeys, including consequential approvals and payments.
195. Negative tests try to bypass object permissions, cross tenant boundaries and escalate privileges both horizontally and vertically.
196. Add regression coverage for significant defects once they're fixed.
197. Load testing uses realistic data, concurrency and peaks.
198. Test selection includes supported browsers, devices, slow connections and enterprise endpoint restrictions.
199. Agent-reported test results can be checked against actual runs; generated tests are challenged with independent cases.
200. The process owner accepts the behaviour and known limitations before users depend on the application.

## 201–210. Capacity, performance and cost

Lead: platform, application and budget owners. Evidence: measurements and tested limits.

201. Response-time, availability and data-freshness objectives reflect business needs.
202. Capacity estimates cover ordinary use, peaks and growing data volumes.
203. Test scaling and set upper bounds that protect systems and budgets.
204. Caching preserves separation between users and customers.
205. Cache expiry and invalidation account for data changes and permission revocation.
206. Content-delivery services use approved locations and handling rules where required.
207. You can attribute cloud, model, storage and external API costs to the application.
208. Unusual consumption alerts a named person in time for them to act.
209. Know how cost limits actually work and how long enforcement takes; a budget alert doesn't block spending.
210. Resource exhaustion or budget limits produce predetermined application behaviour.

## 211–220. Logs, monitoring and audit history

Lead: monitoring owners and the application team. Evidence: useful dashboards and an end-to-end alert test.

211. Searchable structured logs reach an approved central service.
212. You can trace requests, background jobs and integration calls through the same operation.
213. Audit records identify the actor, action, target, time and outcome.
214. Access to sensitive information is logged when the use case or applicable obligation requires it.
215. Keep passwords, keys and unnecessary confidential content out of logs.
216. Log access, tamper protection, time synchronisation and retention are managed.
217. Error monitoring groups related failures and identifies the relevant release.
218. External availability and transaction checks measure behaviour experienced by users.
219. Monitoring covers latency, errors, throughput, queues and business-significant failures.
220. Test that alerts arrive, and review noise, missed incidents and whether escalation works.

## 221–230. Backups, recovery and continuity

Lead: the service owner and platform team. Evidence: dated recovery exercises with measured results.

221. The business agrees how much data it can afford to lose and how long recovery can take.
222. Backup frequency and retention meet those objectives.
223. Recovery coverage includes required files, configuration and encryption-key dependencies.
224. Backups are protected against production-account compromise and ransomware.
225. A restore into a separate environment has succeeded, and you've checked the integrity of what came back.
226. Point-in-time recovery is available where the data-loss objective requires it.
227. Exercise recovery of the whole application, including dependencies, at intervals suited to the risk and after significant changes.
228. Restores account for information deleted since the backup was taken.
229. Additional datacentres or regions follow continuity requirements, with failover tested where used.
230. The business has a workable fallback while the application is down.

## 231–240. Incidents and security events

Lead: the service owner and incident-response function. Evidence: exercises, current contacts and completed corrective actions.

231. Support ownership covers the agreed service hours, with on-call coverage where required.
232. Alerts have severity levels, response targets and escalation routes.
233. Someone other than the original developer can follow the runbooks for common failures.
234. Operators can isolate the application, close a connection or revoke an identity during an incident.
235. A stolen-device or leaked-credential response covers the further access it could give someone.
236. Investigation evidence is preserved with controlled access.
237. Responsibilities and applicable deadlines for notifying customers, staff and authorities are documented.
238. Users have a working incident-communication channel, with an independent status page where needed.
239. External researchers can find a vulnerability-reporting channel that reaches a responsible person.
240. Significant incidents lead to corrective actions, with owners and completion tracked.

## 241–250. AI inside the running application

Lead: the application owner and AI-service owner. Evidence: evaluations, authority tests and model-change approval.

241. The model's task, permitted data sources and decision-making authority are documented.
242. Approve data sent to models against the provider's processing, retention and training terms.
243. Retrieval, documents and memory enforce user permissions and tenant isolation.
244. Prompt-injection tests include malicious instructions in files, search results and tool responses.
245. Validate generated code, SQL, HTML and tool calls, and limit how they can execute.
246. Run application-specific evaluations and known failure cases before material model or workflow changes.
247. Model, prompt, retrieval and tool versions are traceable to production.
248. User and tenant consumption limits constrain runaway use and agent chains.
249. Plan for model outages and retirement; evaluate fallback models before using them.
250. Control prompt and response logging, and give uncertain or incorrect outcomes a route to a human.

## 251–260. Usability and accessibility

Lead: the application team and process owner. Evidence: user testing and accessibility assessment.

251. Users can tell what the application is for, which environment they're in and which object they're acting on.
252. Empty states, loading and failures have understandable presentations.
253. Error messages give users a next step without exposing internal information.
254. A correctable form error doesn't throw away the user's work.
255. Going back, refreshing or using several tabs doesn't unexpectedly lose data or repeat actions.
256. Users can tell the difference between a draft, saved information and a completed operation.
257. Offer undo for reversible actions, or a clear way to correct them.
258. Keyboard access, screen readers, focus and contrast are checked against applicable accessibility requirements.
259. The application works on the devices and connections the organisation actually uses.
260. User guidance, onboarding and feedback channels match the released application.

## 261–270. Messages, languages and support tools

Lead: the application team and service support. Evidence: delivery tests and restricted support access.

261. Supported languages, date formats, numbers and any required right-to-left layouts work correctly.
262. Reminder time zones, daylight-saving changes and quiet hours work as users expect.
263. Sending domains are approved, and SPF, DKIM and DMARC are verified against actual application messages.
264. Test messages with the email clients and filtering systems the enterprise uses.
265. Bounces, complaints and delivery failures are handled.
266. Users can manage optional notifications, with mandatory messages identified separately.
267. Check message content and recipients so information doesn't go to the wrong person.
268. Support can investigate and perform permitted corrections through a restricted administrative interface.
269. Routine support doesn't depend on manual database edits or a developer's personal privileges.
270. Users can find relevant release notes and explanations of what's changed.

## 271–280. Privacy, contracts and procurement

Lead: the business owner, privacy function and procurement. Evidence: applicability decisions and current agreements.

271. Personal-data purposes, legal bases, parties and required processing records are defined.
272. DPIA applicability is assessed, and required assessments are completed before processing.
273. Retention, deletion and preservation obligations cover relevant copies, indexes and derived data.
274. Access, correction and deletion procedures cover connected systems and controlled backup expiry.
275. Terms and privacy notices describe what the application actually does.
276. Suppliers, subprocessors, assurance scope, processing agreements and required transfer mechanisms are assessed.
277. Security-questionnaire answers and applicable assurance reports have evidence, defined scope and responsible owners.
278. Sector and use-specific obligations are assessed, including relevant GDPR, CRA, AI Act, Data Act, NIS2, DORA or HIPAA requirements.
279. Applicable healthcare processing agreements and payment-card-data compliance scope are resolved before that use begins.
280. Contracts cover support, data return, material changes and how to leave the service.

## 281–290. Billing, when the application bills

Lead: finance and the application team. Evidence: reconciled trial transactions and payment-failure tests.

281. Payments use an approved provider, with card-data handling minimised.
282. Payment retries and repeated clicks can't accidentally charge twice.
283. Subscriptions, renewals, cancellations and access expiry work together.
284. Plan changes and partial-period charges follow the contract.
285. Control failed-payment retries, reminders and service restrictions.
286. Invoices contain correct company details, order references and required purchase-order numbers.
287. Tax, currency and rounding treatment match the relevant sales and transaction rules.
288. Credits, refunds and partial refunds can be traced to the original transaction.
289. Usage records, invoice lines, payments and accounting reports reconcile with agreed pricing.
290. Annual billing and customer-specific terms are tested through contract changes.

## 291–300. Maintenance, handover and retirement

Lead: the business and technical owners. Evidence: a handover exercise and lifecycle plan.

291. Maintenance has access to architecture, development, security, operations and testing expertise, including people who can debug generated code when agents can't fix it.
292. A second person can build, deploy, recover and diagnose the application.
293. The code is understandable, its modules can be maintained, and abandoned or unnecessary code is removed.
294. Parallel development keeps the required checks; the technical owner can stop unsafe releases and changes that break other functions.
295. Review benefits, usage, costs and emerging risks on an agreed schedule.
296. New data, integrations, purposes or permissions trigger the required reassessment.
297. When an owner or supplier changes, transfer access, documentation and the knowledge needed to run the application.
298. Export required data in a usable format and verify that migration preserves its integrity.
299. On retirement, close integrations, schedules, identities and resources; handle domains and DNS so nobody can take over abandoned connections.
300. Retirement updates inventories, contracts and costs; any copies left behind have an owner and a defined retention period.

## The regulatory bonus: building today for obligations through 2027

You might still be running an application built today several years from now. The way you record releases, manage permissions and organise data will affect how much work a new obligation creates. If you don't record a development risk assessment or where training data came from, the person maintaining the application later may have no way to recover that information.

This section was researched on 16 October 2026 and covers existing obligations and confirmed application dates through 31 December 2027. These are the engineering and operating questions to work through with the people responsible for compliance. Which rules apply depends on your organisation, product, data, role and use case.

| Regime   | Current position and relevant dates                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| GDPR     | Already applicable. Privacy by design, lawful processing, rights, security and required impact assessments belong in the design and operation of the system. [EDPB](https://www.edpb.europa.eu/sme/be-compliant/be-compliant_en)                                                                                                                                                                                                                                                                |
| NIS2     | Apply the relevant national law and sector rules. Finland's obligations entered into force on 8 April 2025. [Traficom](https://www.kyberturvallisuuskeskus.fi/en/news/weekly-review-national-cyber-security-centre-finland-ncsc-fi-152025)                                                                                                                                                                                                                                                      |
| CRA      | Reporting obligations apply from 11 September 2026. Main product requirements apply from 11 December 2027, subject to scope and transition rules. [European Commission](https://digital-strategy.ec.europa.eu/en/policies/cra-summary)                                                                                                                                                                                                                                                          |
| AI Act   | Existing prohibitions, literacy measures and applicable transparency duties already apply. Annex III high-risk requirements apply from 2 December 2027 under the amended timetable. [Article 113](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113)                                                                                                                                                                                                                               |
| Data Act | Generally applicable since 12 September 2025. Access-by-design applies to relevant connected products and related services placed on the market after 12 September 2026. Covered switching charges end on 12 January 2027. Certain older contracts enter the unfair-terms rules on 12 September 2027. [Commission explanation](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained), [Article 50](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A32023R2854) |

## B01–B04. Scope, roles and evidence

Lead: the business owner and relevant legal or compliance specialists. Evidence: a dated applicability record.

- **B01.** Record which laws apply, to which legal entity, in which jurisdiction, and why. If something doesn't apply, record why.
- **B02.** Identify roles separately: controller, processor, product manufacturer, AI provider, AI deployer, data holder and data-processing-service provider.
- **B03.** Keep the first-release, first-use, contract and modification dates you'll need to work out which transition rules apply.
- **B04.** Connect each obligation to a control, owner, evidence and review date. Make clear which work belongs to the application team, the platform or the wider organisation.

## B05–B10. GDPR capabilities needed before processing

Lead: the controller's business owner, privacy function and application team.

- **B05.** Assess the legal basis for each processing purpose, including new uses for analytics, AI evaluation or training. [Lawful processing](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/legal-grounds-processing-data_en)
- **B06.** Implement and test privacy defaults for collection, visibility, retention and access. Complete a DPIA before processing when required. [EDPB](https://www.edpb.europa.eu/sme/be-compliant/be-compliant_en)
- **B07.** Make applicable rights executable across connected systems, including access, correction, erasure, restriction, objection and portability. [Individuals' rights](https://www.edpb.europa.eu/sme/be-compliant/respect-individuals-rights_en)
- **B08.** Apply documented retention and deletion handling to logs, caches, exports, search indexes, AI retrieval stores and backups.
- **B09.** Map supplier processing and international transfers, including support access, telemetry, model providers and subprocessors. [Transfers](https://www.edpb.europa.eu/sme/be-compliant/international-data-transfers_en)
- **B10.** Assess consequential automated decisions separately, including applicable restrictions, information, human intervention and challenge mechanisms. [Automated decisions](https://www.edpb.europa.eu/sme/be-compliant/respect-individuals-rights_en)

Approved hosting is part of this, but your app may also send telemetry to one provider and prompts to another. You need to account for those flows too.

## B11–B15. NIS2 and the organisation operating the application

Lead: the accountable entity's management, security function and service owner.

- **B11.** Link the application asset record to the services it supports, including criticality, dependencies, suppliers and owners.
- **B12.** Connect security measures, effectiveness reviews and unresolved risks to the required management approval and oversight.
- **B13.** Make supplier arrangements support incident notification, vulnerability handling, maintenance and access to evidence.
- **B14.** Detect and escalate significant incidents using the applicable national and sector thresholds and reporting rules.
- **B15.** Exercise recovery and incident response, and track corrective actions to completion.

These obligations concern the organisation and its systems. The evidence for each application needs to feed into the organisation's risk-management process. The NIS2 reporting sequence generally includes an early warning within 24 hours, notification within 72 hours and a subsequent final report. [Risk-management requirements](https://kyberturvallisuuskeskus.fi/en/our-activities/regulation-and-supervision/nis2-european-union-cybersecurity-directive/important-information-european-union-cybersecurity-directive-nis2), [management accountability](https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1725035138877&uri=CELEX%3A32022L2555), [reporting](https://digital-strategy.ec.europa.eu/en/faqs/directive-measures-high-common-level-cybersecurity-across-union-nis2-directive-faqs)

## B16–B21. CRA readiness during development

Lead: the product manufacturer and responsible engineering and security owners, where the product is in scope.

- **B16.** Document product scope and classification, including distributed components and integral remote processing.
- **B17.** Tie risk assessments, architecture, security requirements, test results and vulnerability decisions to product releases.
- **B18.** Use the SBOM to connect vulnerable components to affected releases, installations and remediation decisions.
- **B19.** Operate a vulnerability-reporting channel with responsible triage, investigation, remediation and communication.
- **B20.** Provide secure update delivery throughout the support period, with update integrity and supported versions managed.
- **B21.** Plan the applicable conformity assessment, technical documentation, declaration and CE marking, alongside a justified support period and disclosed end date.

The CRA concerns products with digital elements made available on the market. An application you build for internal use isn't automatically in scope. Its main requirements generally reach products placed on the market before 11 December 2027 when they undergo substantial modification after that date. Reporting also covers earlier products. [CRA scope and transition rules](https://digital-strategy.ec.europa.eu/en/policies/cra-summary)

The legal SBOM minimum covers at least top-level dependencies. I've recommended broader coverage in the main checklist. Support generally lasts at least five years unless expected product use is shorter; longer expected use can require longer support. [CRA legal text](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A32024R2847)

## B22–B29. AI Act responsibilities for the actual use case

Lead: the relevant AI provider and deployer, with the process owner and compliance function.

- **B22.** Inventory AI functionality and intended use, including affected people, decisions and the organisation's provider or deployer role.
- **B23.** Screen prohibited uses before deployment and reassess when purpose or context changes.
- **B24.** Support appropriate AI literacy for staff and others operating the system on the organisation's behalf. [Article 4](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4)
- **B25.** Implement applicable interaction notices, machine-readable output marking and content disclosures. Assess each obligation separately. [Article 50](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50)
- **B26.** Create required high-risk provider evidence during development: risk management, data governance, evaluations, documentation, quality management and conformity work. [Provider duties](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-16)
- **B27.** Give designated human overseers the information, competence, authority and controls needed to intervene or stop use.
- **B28.** Retain required operational logs and traceability with appropriate access and retention rules. [Deployer duties](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26)
- **B29.** Assess GDPR DPIA and AI Act fundamental-rights assessment triggers separately, reusing relevant evidence where permitted. [Article 27](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-27)

Using AI to write code doesn't, by itself, make the resulting software an AI system. If you develop an AI system for your own organisation to use, though, you can have provider responsibilities. [Definitions](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-3)

Additional Article 5 prohibitions concerning non-consensual intimate material and child sexual abuse material apply from 2 December 2026. Assess relevant systems against the provision's definitions, scope and safeguard conditions. [Article 5](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-5), [application dates](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113)

There are two earlier transition dates to account for as well: certain synthetic-content systems placed on the market before 2 August 2026 must meet Article 50(2) by 2 December 2026; general-purpose models placed on the market before 2 August 2025 reach their compliance deadline on 2 August 2027. Existing high-risk systems have separate provisions tied to significant design changes. Record which provision applies to your system. [Article 111](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-111)

## B30–B34. Data access and a usable exit

Lead: the relevant data holder or service provider, with product, engineering and procurement owners.

- **B30.** For relevant connected products, identify eligible data, metadata, entitled users and the required access methods.
- **B31.** Authenticate sharing requests and preserve personal-data permissions, confidentiality and applicable trade-secret safeguards.
- **B32.** Make covered services' exportable data, metadata and digital assets available through appropriate formats and interfaces.
- **B33.** Align switching contracts with actual assistance, continuity, security, retrieval and deletion capabilities.
- **B34.** Remove covered switching charges by 12 January 2027 and review older contracts that enter the unfair-terms rules on 12 September 2027.

The switching provisions concern qualifying data-processing services, including relevant SaaS offerings. They don't require every internal database to expose all its contents. Standard service fees are distinct from switching charges. The older-contract transition covers contracts concluded on or before 12 September 2025 that are indefinite or due to expire on or after 11 January 2034. [Scope](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained), [Articles 25, 29 and 50](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A32023R2854)

## B35–B36. Incidents and changes across regimes

- **B35.** Maintain separate reporting decisions for GDPR, NIS2, CRA and contracts. The same incident can require reports to different recipients, under different thresholds and deadlines.
- **B36.** Reassess obligations when data, markets, users, AI purposes, permissions or distribution change. Give future requirements a budget, an owner and evidence that will show the work is done.

A GDPR processor must notify its controller without undue delay; that is separate from the controller's applicable 72-hour authority-notification deadline. CRA reporting covers actively exploited vulnerabilities and severe product-security incidents, with its own early warning, notification and final-report requirements. [GDPR reporting guidance](https://www.edpb.europa.eu/system/files/2023-04/edpb_guidelines_202209_personal_data_breach_notification_v2.0_en.pdf), [CRA reporting](https://digital-strategy.ec.europa.eu/en/policies/cra-summary)

The applicability review should also consider sector-specific requirements such as DORA and applicable accessibility or medical-device rules. The revised Product Liability Directive deserves attention too: national transposition is due by 9 December 2026, and its product definition expressly includes software and AI. [EU legal summary](https://eur-lex.europa.eu/legal-content/EN/LSU/?uri=OJ%3AL_202402853)

Keep proposed changes on a separate watchlist. Don't treat the wider Digital Omnibus or proposed NIS2 amendments as enacted application deadlines. [Digital Omnibus proposal](https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-regulation-proposal), [NIS2 status](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive)

## What the enterprise should provide

When I talk about an enterprise AI software factory, I mean support for all of this: building, releasing, monitoring and maintaining software under the organisation's rules. The application record should make it clear what the platform provides, what the application team has checked and who can make the business decisions.

The person who found the purchasing problem should be able to get help turning their idea into something the team can use. Give them an approved environment, a supported identity integration, somewhere to keep secrets and a release pipeline. Connect the application to monitoring, asset management and maintenance.

The application team still has work to do. Does the purchaser get access to the right supplier records? Can a cancelled approval still produce an order? Restore the application and check that the result is right. The business owner needs to decide who can commit the company to a purchase and what people should do when the system is down.

A year later, when the original builder has moved on, someone else should be able to find the application, understand its permissions, update it and recover it. The purchasing team should still be able to get its work done.

_Source note._ The starting point for this checklist was [Mark Ajzenstadt's production-readiness post](https://x.com/mardehaym/status/2110705357492203564). I've reorganised and expanded it to cover enterprise ownership, platforms, operations and regulation. For detailed security acceptance criteria, use the [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/); for secure-development practices, the [NIST Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final).