How it works today in most organizations
The first list is created in IT, for a good reason: things have to be purchased, renewed and licensed. So there is a workbook called "Hardware_Software.xlsx" – one worksheet for notebooks and servers, one for software licenses, one for cloud services. The columns are named description, manufacturer, quantity, cost center, contract end and maintenance until. For procurement and budget planning that is the right tool, and the list is usually kept with care.
A second list emerges in parallel, elsewhere and for a different reason. The records of processing activities under Art. 30 GDPR require a statement of which systems process personal data. So the data protection officer keeps a systems list of their own – an extra worksheet in the records, or a section in the Word template. It holds providers, data categories and, if things go well, a reference to the data processing agreement.
Two lists, two purposes, two languages. The IT list says "M365 E3, 240 licenses". The data protection list says "Microsoft 365 (Exchange, SharePoint, Teams)". The ticket system is named after the manufacturer in one place and after the department using it in the other. Whether the same system is meant is known only to whoever has read both files side by side. And when a provider is replaced, usually only one of the two lists changes.
The real problem, though, is what neither holds. Nothing states how much protection a system needs – not for confidentiality, not for integrity, not for availability. Nobody owns an individual asset; the owner is "IT". Nothing connects the rows: that the CRM cannot authenticate without the directory service, and that both run on the same hypervisor, appears nowhere. And decommissioned systems simply stay, because deleting a row is something nobody notices.
The moment it becomes visible
In day-to-day work none of this hurts. It becomes visible in four situations: at the first certification audit, when the scope of the management system and the protection needs assessment come up. During a supplier review, when a customer wants to know which systems hold their data. After an outage, when someone has to reconstruct which processes were affected and in which order they are restarted. And when the administrator leaves who alone knew what was behind which row.
In all four cases the question is not "Do you have an inventory list?" but "Which systems are critical for which process – and who owns them?" A procurement list has no answer. Not because it is poorly kept, but because it structurally knows nothing about protection needs, ownership and dependency.
The analysis
Five Problems Two Separate Lists Create
They arise regardless of how carefully the two lists are kept – they follow from the separation, not from the way people work.
View Asset Management in preecoThe same system, two names
Every system is recorded twice and named differently each time. The two states cannot be reconciled reliably, and when a provider is replaced usually only one of them is updated. The question of how many systems are in use therefore has two answers.
The protection needs are stated nowhere
Neither list says what protection a system needs for confidentiality, integrity and availability. Without that classification there is no justified prioritization: the file server holding personnel records is treated like the meeting room calendar.
No responsible person per asset
Responsibility rests with "IT" or "data protection", not with a named person per system. Follow-up questions from an audit therefore always land in the same place, and maintenance happens only when that place has time.
Dependencies are invisible
A spreadsheet knows rows, not relationships. Which application depends on which service, and which systems share a platform, appears nowhere. That makes it impossible to assess an outage scenario or to justify a restart sequence.
No link to measures and risks
Protective measures sit in a document of their own, risks in a third. Whether a critical system is actually covered by measures can only be answered by manual comparison – and nobody makes that comparison between two audits.
The target process in six steps
Workable asset management differs from an inventory list not by having more rows, but by what hangs off each row. These six steps describe the process – independent of the tool.
1. Keep one inventory instead of two lists. Every system is created exactly once, under a name both sides use. Data protection and information security see the same record from their own perspective: data protection as a data processing system with provider and data categories, information security as an asset with configuration, hosting and operating system. That is precisely why preeco | data protection and preeco | information security share one platform.
2. Categorize assets and assign them to processes. Servers, clients, applications and cloud services are assigned to categories and connected to the business processes they carry. Only that assignment makes the word "critical" verifiable: a system is critical not because it was expensive, but because an important process stops without it.
3. Name a responsible person per asset. Every system has a business owner as well as manufacturer and supplier contacts. That makes it clear who answers any follow-up question – in an audit, in an incident and at the annual review.
4. Determine the protection needs instead of estimating them. For confidentiality, integrity and availability they are determined via a damage-scenario matrix following the maximum principle, either manually or AI-assisted. Linked systems are taken into account including the accumulation effect. The result exports as PDF or DOCX – with the overall protection need, the matrix and the inherited sources.
5. Map the dependencies. Systems are ranked above and below one another, the data flows between them documented. Added to that are the details that count in an emergency: hosting and location, encryption, availability, known vulnerabilities and whether a system falls within the scope of the NIS2 requirements.
6. A lifecycle instead of a list. An asset is not deleted when it goes out of service – it gets a status. All changes are logged with timestamp and user, so that years later it stays traceable when a system was introduced and when it was replaced.
Why a shared inventory is more than one merged file
Two Excel lists could also just be copied together. The difference lies not in merging, but in what becomes possible afterwards. An asset is then an object other objects hang off: the processing activities that run on it, the measures that protect it, the audits that examined it, and the risk analyses that assess it.
That changes the direction of the work. Instead of collecting five documents for an audit, you open the system and see what is attached to it. If a service provider fails, the list of affected processing activities is a view instead of a research task. And if the protection needs of a system rise, it becomes visible which measures and risk analyses that touches.
Before and after in direct comparison
| Criterion | Before: two Excel lists | After: shared asset inventory |
|---|---|---|
| Maintenance effort | Every system recorded twice and changed twice | One record, two views for data protection and information security |
| Currency | A change reaches only one of the two lists | A change takes effect for both areas at once |
| Completeness | Decommissioned systems stay, new ones are missing | Status per asset, additions and removals documented |
| Protection needs | Stated nowhere, estimated in case of doubt | Confidentiality, integrity and availability by the maximum principle |
| Ownership | "IT" | A named person per asset, plus manufacturer and supplier contact |
| Dependencies | Not mapped, outage scenarios cannot be assessed | Hierarchy and data flows documented |
| Evidence | A file state without history | Changes logged with timestamp and user, export as PDF and DOCX |
| Failure risk | The knowledge sits with one person | Inventory, assessment and history sit in the system |
In practice
What this looks like in preeco | information security
The three building blocks that carry the process described above.
Asset Management
Record servers, clients, applications and cloud services centrally – with owners, providers, hosting and location. Hierarchies and data flows are mapped, and the protection needs for confidentiality, integrity and availability are determined via a damage-scenario matrix.
Risk Analyses
Protection needs, resource, threshold and threat analyses build on the asset inventory. Risks are linked directly to measures, approved analyses are revisioned automatically and output as PDF or DOCX.
Processing Activities and Systems
The same systems appear in data protection as data processing systems – with data categories, assigned processing activities and the data processing agreements. The inventory is maintained only once.
What the switch means in practice
The most common objection is that everything would have to be recorded from scratch. It would not. The inventory list you have is the basis: it is taken over and mapped onto structured fields. The only additions are what the spreadsheet was missing anyway – owners, protection needs and dependencies. Those gaps are the actual return, because they surface before an auditor or an outage surfaces them.
The effort rarely lies in the technology. In a mid-sized organization with 60 to 120 assets, the larger part goes into clarifying the substance: who owns which system, which process depends on it, and how high the protection needs really are. That clarification is due in any case – if in doubt under time pressure, shortly before the audit.
Three mistakes that make the switch harder than it needs to be
Going too deep. An asset inventory is not a configuration management database. Record the systems that carry business processes or process personal data – not every single peripheral device.
Postponing the protection needs. An inventory without classification is just a list again. The protection needs are the point where the inventory turns into a prioritization and where risk analyses can dock onto it.
Introducing data protection and information security separately. Setting up both areas one after the other rebuilds the two lists in the new tool. A shared inventory is the precondition for the maintenance effort actually going down.
How to tell that it is time
An inventory list in Excel is not a mistake. It becomes a risk as soon as one of these points applies:
- You cannot say for certain how many systems are in use.
- No responsible person can be named for a system.
- The protection needs are documented for no system at all.
- In an outage it would be unclear which processes are affected.
- A certification or a customer review is coming up.
If none applies, the list will do for now. If two or more apply, it stopped describing what is actually operated long ago.
FAQ
Frequently asked questions about asset management
Everything that carries a business process or processes data: servers, clients, applications, cloud services, network components and the service providers involved. The usual mistake is not recording too little, but going too deep. Begin with the systems that carry processes or process personal data, and refine later.
Via damage scenarios: for each protection goal – confidentiality, integrity and availability – you assess what damage a breach would cause. The highest value determines the classification (maximum principle). In preeco | information security this is done via a damage-scenario matrix, either manually or AI-assisted; linked systems are taken into account including the accumulation effect. The result can be exported as PDF or DOCX.
No. Both areas describe the same systems, only with a different focus. preeco | data protection and preeco | information security share one platform: a system is maintained once and appears in data protection as a data processing system and in information security as an asset. Duplicate maintenance and diverging names are gone.
When prompted and on a cycle. When prompted, at every introduction, replacement or material change of a system, and whenever a provider is replaced. In addition, a full review once a year has proven itself, confirming owners and protection needs. A fixed cycle matters because additions usually get noticed while removals do not.
The standard expects an inventory of the assets within the scope of the management system, an assigned responsibility per asset and rules for their acceptable use. An audit therefore looks less at the completeness of a list than at traceability: whether classification, responsibility and measures fit together, and whether the inventory is being maintained.
Go through your inventory list together
Bring the spreadsheet you already have. In 30 minutes we will show you how it becomes one shared inventory for data protection and information security.