A prototype becomes a company tool when eight things are settled: responsibility, access, data, backups, credentials, testing, offboarding and maintenance. Ideally go through the points as two people, and write down who will complete any open points and by when.
Responsibility
- A named person is responsible for the app.
- There is a deputy who knows the app and can access all the necessary accounts.
- The responsible person has working time for this, and their manager knows about it.
- The app is listed with its purpose and responsible person in your overview of all apps.
- All accounts for the app belong to the company, not to a private individual.
- There is a short description: what does the app do, and where is what?
Access
- The app can only be reached after signing in.
- Sign-in runs through the company account. There are no shared passwords.
- It is defined who gets access and who decides on it.
- The app distinguishes roles, if not everyone may see the same things.
- A second person has tried to open other people's data with a normal account, and this did not succeed.
- If external people get access, it is settled how and for how long.
- If the app is meant to be public, this was a conscious decision.
Data
- You know which data the app stores and whether it includes data about people.
- The app only stores what is necessary for its purpose.
- The storage location is known, including at all services the app sends data to.
- It is clear whether data goes to an AI provider and which data, both in operation and while building.
- For data about people, your data protection officer is involved and the app is listed in your record of processing activities (Art. 30 GDPR).
- There are deletion periods for the data, and deletion is technically possible.
- The data can be exported from the app, in case you replace it later.
Backups
- The data is backed up automatically, not by hand.
- The backups are kept apart from the running app.
- You have decided how much data you could afford to lose in the worst case.
- The retention period fits this and your deletion periods.
- A restore has been tested successfully at least once.
- More than one person knows how to restore.
Credentials
- There are no passwords or API keys in the code, not even in earlier versions.
- The credentials are kept apart from the code in a protected place.
- API keys belong to a company account and not to a private one.
- You can replace credentials without the app being down for long.
- There are separate credentials for test and live.
- Where costs depend on usage, for example for an AI model, a limit is set.
Testing
- There is a test version alongside the live version.
- The test version uses its own data, if possible sample data.
- Changes are first tried out in test and then taken live.
- A second person has run through the most important processes, including with incorrect input.
- The code is in a Git repository, which is a store with a version history.
- You can return to an earlier version.
Offboarding
- When a company account is deactivated, access to the app ends too.
- For external people, there is an end date or a regular review.
- If the responsible person leaves the company, the handover to the deputy is described.
- Shared credentials are replaced afterwards.
- It is defined what happens to the data of a person who has left in the app.
Maintenance
- It is clear who keeps the server, the operating system and the certificates up to date.
- Known vulnerabilities in the packages used are checked and fixed regularly.
- Someone finds out when the app stops running.
- The team knows who to contact when there are problems.
- Running costs are known and assigned to a cost centre.
- Once a year, you check whether the app is still needed.
- It is clear how the app will be shut down: back up or delete the data, cancel accounts, remove the entry from the overview.
What do you do if points stay open?
A personal helper without data about people does not need the list. For a small team app, not every point has to be completed, but responsibility, sign-in and tested backups should be in place. If the app contains data about people or is used from outside, the list should be complete before launch. The guide Publish an app built with Claude or Codex describes the routes for running an app. For a broader framework for information security, see IT-Grundschutz, the baseline protection framework of the BSI, Germany's Federal Office for Information Security.
What Auftrieb takes care of
On Auftrieb, some points on this list are already set up. Sign-in runs through Google Workspace or Microsoft Entra. Backups run every night and can be restored directly on the app page. When a company account is deactivated, access to the apps ends automatically. All running apps are checked daily for known vulnerabilities in the packages they use, and findings appear on the app page. Responsibility, roles in the app, deletion periods and the code stay your job. You can read more on the Security page.
Updated: November 2026