How software approval works today
A request arrives in the IT ticket system: "New software: AI meeting notes tool for sales". Sales wants a cloud service that records, transcribes and summarizes customer meetings. IT checks sign-in, license costs and storage location, adds the tool to "Software_List_2026.xlsx" and forwards the ticket to the "dataprotection@" mailbox with the note "Please check data protection".
This is where the manual work of the data protection officer begins. She searches the vendor's website for the data center location and sub-processors and retypes name, vendor, data categories and purpose into the records of processing activities: once as a data processing system, once as a draft of the processing activity "Meeting notes in sales". She requests the data processing agreement (DPA) from the vendor by email and sends a reminder two weeks later. The PDF lands in the downloads folder, later in "Data_Protection/DPA/2026".
IT has approved the tool technically, the license is bought, the first customer meetings are already being recorded. Whether the data protection review is complete is written nowhere in the ticket. It gets closed anyway, because IT has finished its part.
Questions also arrive by chat. "Are we allowed to use tool X?", someone from marketing writes in Teams. "Is the meeting notes tool approved now?", asks the sales team lead. The data protection officer answers from memory or looks it up in the records, each time by hand and at the risk of quoting an interim state only she knows.
Two lists that drift apart
One request is a nuisance; the problem lies in the sum. IT keeps its "Software_List_2026.xlsx" or a CMDB, data protection keeps the data processing systems in the records. Both lists describe the same systems, but different people maintain them at different times. When a tool is switched off, data protection rarely hears about it. When another department starts using it, IT rarely hears about it. After a year one list contains 140 systems, the other 118, and nobody can say offhand which difference is a legacy issue and which is an open risk.
The moment it becomes visible
It becomes visible in a review. A customer sends their vendor questionnaire and wants to know which systems work with their data and which sub-processors are involved. IT supplies the software list, data protection the records, and the two answers do not match. Or an auditor pulls three entries from the CMDB and asks for the related processing activity and the contract. For one of them there is neither, only a closed ticket.
The analysis
What Approval by Email Costs
The five points do not stem from a lack of care. They arise because the ticket system, the IT inventory and the records keep the same information separately and are connected only through people.
View preeco | data protectionThe same information is entered twice
Name, vendor and purpose are already in the ticket and are retyped into the records. Every second entry brings typos and diverging spellings with it. In a later reconciliation, no search then finds the system under both names.
The ticket does not know the state of the review
IT closes the request as soon as its part is done. Whether the data protection review is complete is recorded somewhere else. Tools therefore go live before the processing activity is documented and the contract is signed.
Two inventories without a common source
The CMDB and the records describe the same systems and are maintained separately. Shutdowns and new places of use each reach only one side. In the vendor questionnaire your own documents end up contradicting each other.
The contract depends on a mailbox
The data processing agreement is requested by email and lands in a folder. Whoever reads the mailbox knows whether it is there. During vacations or a change of staff the follow-up breaks off, and the evidence is hard to find.
Answers in the chat from memory
"Are we allowed to use tool X?" is answered in the chat without any reference to the documented state. The answer cannot be traced later and depends on one person. Each of these questions takes time, although the answer is in the records.
The target process in six steps
The goal is that every piece of information is entered once and travels automatically between the ticket system, the IT inventory and the records. The review stays with the data protection officer. The basis is the REST API of the shared platform of preeco | data protection and preeco | information security.
1. Have access activated. The API is switched off on delivery. preeco activates it for your team on request, so contact your account manager. An administrator then allows access per user in the settings.
2. Create a separate token for each application. An API token belongs to a person and acts with their role and permissions in every team they are an active member of. There are no service accounts. Create the token for a person whose role fits the task and is as narrow as possible, under API in the profile. Each application gets its own named token with a limited lifetime.
3. Transfer the request automatically. The ticket system's automation, a script or a low-code tool such as n8n creates the data processing system and a draft processing activity, assigns a task to the data protection officer and stores the vendor's data processing agreement. Every change appears in the activity log under the token owner's name.
4. Query the status regularly. preeco does not contact the ticket system; there are no webhooks or push notifications. The ticket system asks every 15 minutes or so whether the data protection officer's task is done, and only then closes the request.
5. Reconcile the IT inventory in both directions. A scheduled run reconciles the CMDB with the assets in preeco | information security. New CMDB systems are created, and preeco information such as protection requirements or responsibilities flows back.
6. Let your own AI assistant answer through the API. Many companies already run an internal AI assistant or agent, for example in the intranet or in the chat. It gets its own API token, owned by a person with a read-only role, and answers questions such as "What is the status of the processing activity Meeting notes in sales?" from the documented state. It uses the same token-based REST API as the ticket system and the CMDB, so your IT reviews one interface, not two.
What the interface brings
The API follows the access rights of the application. It accepts up to 60 requests per minute and token. Developers get an interactive API reference, an OpenAPI file, a changelog and an error catalog, plus a version of the documentation for AI coding assistants (llms.txt). preeco | whistleblower and preeco | sustainability have REST APIs of their own on their own platforms.
Before and after compared
| Criterion | Before | After |
|---|---|---|
| Entry effort | Ticket data is retyped | Ticket creates system, draft and task |
| Timeliness | As of the last manual check | Scheduled reconciliation |
| Completeness | Two lists, different counts | One inventory, reconciled both ways |
| Auditability | Forwarded emails and folders | Activity log with the acting person |
| Closing the ticket | As soon as IT is done | Only once the review task is done |
| Contract | In the mailbox or the downloads folder | Stored with the request |
| Answers | In the chat from memory | From the records, also via AI assistant |
| Absence risk | Knowledge sits with one person | Process continues during vacations |
In practice
How this looks in preeco | data protection
Three building blocks of the shared platform of preeco | data protection and preeco | information security carry the process described.
Transfer software requests automatically
Through the REST API the ticket system creates the data processing system, the draft processing activity and the task. Queries can be filtered, sorted and retrieved page by page, errors come back with a stable error code. Every change appears in the activity log under the name of the person the token belongs to.
Review task for data protection
The review lands as a task with the responsible person, and the dashboard shows it among the open activities. The ticket system queries the status at a fixed interval and only closes the request once the task is done. preeco itself does not notify the ticket system.
Your own AI assistant via the REST API
Your internal AI assistant or agent calls the REST API with its own token, owned by a person with a read-only role. It therefore sees only what that person may see, and the token has a fixed lifetime and can be deleted at any time. For the implementation there is a version of the API documentation that AI coding assistants can read directly.
What the switch means in practice
The effort comes at the start and stays manageable if you start small. Start with one route: a new software request becomes a data processing system and a task in preeco. Once that runs stably for a few weeks, add the draft processing activity, the status query and finally the CMDB reconciliation.
Before the first run, reconcile the software list and the records once by hand and decide which name is authoritative. Otherwise the automation only transfers the old contradictions faster.
Settle three questions: who owns the tokens, who replaces them before they expire, and who checks when a run fails. Document the answers alongside your other interfaces.
Three mistakes that make connections vulnerable
One admin's personal token, without expiry, for every script. Ticket system, CMDB reconciliation and test script share an administrator's key that never expires. It acts with all her permissions in all her teams, and if it leaks, every connection must be switched over at once. Better: a separate token per application with a lifetime of 1, 3, 6 or 12 months, for a person with a role as narrow as possible.
Not planning replacement and handover. The lifetime cannot be changed after creation, and the activity log records every change under the token owner's name. Schedule the replacement before expiry, and decide who creates new tokens and deletes the old ones when that person hands over the task or leaves the company.
Waiting for notifications or asking too often. preeco does not get in touch, so whoever waits for a message waits in vain. Querying the entire inventory every minute runs into the limit of 60 requests per minute. For software approval an interval of about 15 minutes and filtered queries are enough.
How to tell that it is time
- The IT software list and the data processing systems in the records show different numbers of systems.
- Tickets for new software are closed before data protection has reviewed them.
- System information is retyped from forwarded emails into the records.
- Data processing agreements are followed up by email and reminders.
- "Are we allowed to use tool X?" comes up in the chat several times a week.
FAQ
Frequently asked questions about connecting via the REST API
Yes. The shared platform of preeco | data protection and preeco | information security has a REST API that covers almost all modules for reading and writing, among them processing activities, data processing systems, assets, data processing agreements and tasks. It is switched off on delivery. preeco activates it per team on request, after which an administrator allows access per user.
No. preeco does not send notifications to external systems. The external system asks for changes at regular intervals, every 15 minutes for instance. The limit is 60 requests per minute and token; if it is exceeded, the API states when the next attempt is possible.
Exactly the permissions of the person it belongs to, in every team in which that person is an active member. Nothing is possible through the API that this person could not do in the interface. There are no service accounts. Create tokens for a person with a role as narrow as possible, a separate one for each application. Changes appear in the activity log under that person's name.
Yes, through the REST API. The assistant gets its own API token, ideally from a person with a read-only role and with a limited lifetime. It therefore sees only what that person may see, and deleting the token ends access immediately. No separate server for AI tools is needed: the connection runs through the same token-based interface as the ticket system and the CMDB.
As long as you set when creating it: 1, 3, 6 or 12 months or without limit. The lifetime cannot be changed afterwards. The token is shown only once, and as soon as it is deleted, it is invalid. For connections we recommend a limited lifetime and a fixed date for renewal.
Plan your connection together
Bring your ticket system, your CMDB and your software approval process with you. In the call we will go through activation, tokens and the query interval.