The business unit built an app: what IT checks before taking it over

01

What does IT actually decide about a business-unit app?

IT does not decide on the quality of the idea, and rarely on the elegance of the code. It decides whether the application can move into a state where outages, staff changes and modifications stay manageable. The yardstick is whether someone other than the person who built it can operate the app.

The situation has become an everyday one. Procurement builds a small web application for supplier ratings with an AI tool; sales grows a quotation tool out of a spreadsheet. The application gets used, it saves time, and eventually the question reaches IT: can it take this over?

The move from a working tool to an operable application is the subject of the series From prototype to production-ready application. The perspective taken here is that of the IT leadership expected to decide. It does not assume that something was done wrong. A business unit builds for its own purpose, IT reviews for operations, and both viewpoints are legitimate. Whether the app was built with Lovable, Power Apps, n8n or by hand barely changes the review areas, only how easily the answers can be found.

02

Is a self-built business-unit app shadow IT?

Formally yes, as long as it runs outside the agreed IT processes. A second reading is more useful for the decision: the app reveals a need that the existing IT landscape had not covered, and it describes that need more precisely than a requirements document would, because it is already used in everyday work.

Shadow IT rarely arises out of defiance. It arises when a process needs support faster than a project can deliver it, and when the tools for that are easy to reach. AI-assisted development tools have lowered that threshold considerably. Anyone who treats the app purely as a risk loses the information built into it: which fields are actually needed, which exceptions the process handles, and which systems would need to connect to it.

Shutting it down with no replacement usually just shifts the problem. The need remains, and the next solution appears somewhere IT sees even less of. That is why the takeover conversation is worthwhile even when a different technical solution ends up being the outcome.

03

Which points does IT check before approval?

Six review areas cover the approval decision: operational accountability, interfaces, permissions, data classes, recovery, and points of contact. Each area comes with a question answerable yes or no, and evidence to ask to see rather than take on trust. The list can be used directly in the takeover conversation.

Operational accountability and interfaces

The first question sounds organisational and is the most consequential: who gets called if the application is unreachable on a Monday morning? As long as the answer is the name of the person who built it, operations hinge on that person's holidays and continued employment. For interfaces, a simple test helps: ask to be shown which credentials the app uses to reach other systems. Personal access to an ERP system, or a private account with an AI provider, are common finds, and can be switched to technical accounts before approval.

Permissions and data classes

Quickly built applications often control rights through the interface: the button is missing, but the data is still retrievable. A tool-free check is to sign in with a low-privilege account and call up the address of someone else's detail page directly. In the BSI's IT-Grundschutz compendium (2023 edition), module ORP.4 covers identity and permissions management, which the review can take as a reference.

For data classes, a classification many IT departments already know is enough to start with. BSI standard 200-2 (BSI, 2017) distinguishes three protection-need categories: "normal," with limited and manageable damage, "high," with considerable damage, and "very high," with existentially threatening damage. The category determines how strictly the remaining points get applied. A room-booking tool and an app holding applicant data do not need the same depth of review. Data protection questions in detail are covered on the page for GDPR-compliant AI.

Recovery and points of contact

For recovery, two terms from BSI standard 200-4 (BSI, 2023) help: the required recovery time objective (RTO), meaning how long the application may be down, and the maximum tolerable data loss, the recovery point objective (RPO), meaning how old restored data may be at most. The business unit sets both values, because only it knows the consequences. IT checks whether the backup and the instructions actually reach those values. Module CON.3 in the IT-Grundschutz compendium (BSI, 2023 edition) requires tests of whether backed-up data can be restored within a reasonable time. Contacts are recorded as roles, so the handover survives a change of staff.

04

What must be settled before approval, and what can follow?

Before approval, it must be settled what would expose, corrupt or irretrievably lose data if something went wrong: server-side permissions, credentials kept outside the code, a tested backup, and a named operational owner. What can follow later is whatever makes operations more laborious but not more dangerous, such as automation, detailed monitoring and documentation depth.

The line shifts with the protection need. In the "very high" category, points migrate from the middle column to the left one, such as logging permission changes. With normal protection needs and a small user base, approval with written conditions is often the more honest path than a long holding pattern in which the app keeps getting used anyway.

05

How is a handover document structured?

A handover document describes the state of the application at the point of approval and the conditions agreed. It is not a form with mandatory fields that has to be maintained, but a brief eight-chapter outline that sits alongside the source code and gets updated when operations change significantly.

The most common mistake with handover documents is their form. An extensive form creates maintenance work, goes stale unnoticed, and so does not get read. A short text file in the repository holds up better: it gets versioned along with the application, and a change to operations gets noticed exactly where the code changes too.

1. Purpose and user base: which problem the application solves, for whom, and what explicitly falls outside its purpose.
2. Ownership: business ownership, operational ownership and deputies, each as a role.
3. Hosting and components: where the application runs, what it consists of, and which external services it uses.
4. Interfaces and data flows: which data comes from which systems and where it goes, with the type of access.
5. Data classes and protection needs: classified by confidentiality, integrity and availability, with a sentence of justification.
6. Permissions: roles, the connection to user management, and how departures are handled.
7. Backup and recovery: RTO and RPO, the backup method, the date of the last tested restore, and a short restart guide.
8. Open points and conditions: what is deliberately left to follow after approval, with the role responsible.

The document is a basis for decisions, not complete technical documentation. Which further artefacts get produced for lasting regular operation, such as an architecture description and a data model with migration history, is covered in From proof of concept to regular operation.

06

How does a takeover conversation with the business unit go?

The conversation works better as a joint stocktake than as an exam the business unit has to pass. The person who built the application often knows its weaknesses precisely and will name them openly, if doing so carries no downside.

At the "decide the path" step, there are three honest options. IT takes the application into its own operations. The business unit keeps running it, but within guardrails IT sets, such as central sign-in and a specified hosting location. Or the app serves as an executable requirement, and the real solution gets built from scratch. The third option is not a failure: the app has then fulfilled its purpose as a prototype.

What ongoing operation then requires, from monitoring to updates, is covered in Running an application in-house. Where questions of liability or regulation come up, Who is liable when AI-generated code causes harm? sets out the legal position.

iiterate Technologies GmbH, based in Adenau, builds custom software and AI applications from architecture through implementation to operation, handing over source code and documentation (Services).