System audit: process, duration and cost.

A system audit is a structured inventory of your software and how it is run. It describes the current state with every dependency and open flank, without painting a picture of how things ought to be. The aim is a dependable basis for the next decision, not a catalogue of recommendations nobody acts on.

Four areas get examined:

• The architecture, meaning how the systems are built, where they carry and where they run into limits.
• The data flows, meaning which data goes where and at which points it is moved by hand today.
• The service provider position, meaning who runs which part, which contracts exist and where dependencies arise.
• The automation potential, meaning which processes can be freed from manual work for good.

Along the way the operational risk becomes visible: outdated components, unprotected access paths or knowledge that hangs on a single person. If you want to gauge the scope roughly yourself first, you can work through our system audit self-check beforehand. It does not replace the audit, but it sorts your own thinking.

A system audit is not a certification procedure and it does not stand in for a recognised methodology. The German Federal Office for Information Security sets out three approaches to building information security in its Standard 200-2, from basic protection through core protection to standard protection. An audit replaces none of them. It establishes first what is actually there, how dependable it is, and which route would be proportionate in this particular case.

The value lies in the outside view. A team that did not build the systems itself recognises assumptions nobody internally questions any more, and names dependencies that have become invisible in day-to-day work. The result is not a verdict on the past but an ordered starting position for the next decision.

The system audit runs across five working days. The fixed frame keeps the analysis moving and stops it spreading sideways. Across that week, review, conversation and assessment alternate:

• Review of the existing documentation, the environment and, where useful, the source code.
• Conversations with the people who run and develop the systems day to day.
• Tracing the most important data flows and the handovers between systems.
• Assessment of architecture, operational risk and automation potential.
• Condensing the findings into priorities and effort per measure.

Your own effort stays small. You provide access and points of contact and make yourself available for a few conversations. Day-to-day business carries on. Where the audit also touches security questions, we mark out on request where a dedicated penetration test would need to go deeper.

One point belongs in the week explicitly: recovery. Having backups is a different thing from being able to restore from them when it counts. How far a company can take that is set out by the Federal Office in its Standard 200-4 on business continuity management. The audit does not examine the whole framework, it establishes whether recovery has ever been rehearsed at all.

The system audit has a fixed price. Five working days, one fixed amount, no timesheets and no renegotiation. It is a one-off engagement with no follow-on obligation. Whether anything follows is your decision, made with the result in hand.

At the end of the week you receive two things:

• A prioritised implementation plan that orders the findings by impact and effort.
• A fixed-price offer for the next sensible position, should you want to go further.

The fixed price creates planning certainty on both sides. You know in advance what the audit costs, and we know the frame we are working within. No additional costs arise, not even when the systems turn out to be less tidy than first assumed.

The plan is written so that it carries without us too. You can implement it internally, hand it to an existing service provider, or commission us with the implementation. The audit creates no tie. The further positions, from implementation through to operations, are set out openly on the Services page.

A system audit is worth it whenever a decision is due and the basis for it is missing:

• Before a larger implementation or replacement, so the scope is dependable.
• Before taking over the operation of someone else's system, because nobody should answer for what they have not seen.
• Before preparing for NIS2, to make technical gaps and operational risks visible.
• When operations are increasingly stalling and the reason is unclear.

The third point has a concrete trigger. § 30 of the German BSI Act requires entities in scope not only to take measures but to hold policies and procedures for assessing how effective those measures are. Anyone who cannot say with confidence which systems they run and who touches them cannot assess that effectiveness. The audit supplies the basis for it, but it replaces neither the measures nor the legal assessment of scope. What that looks like sits in the article on NIS2 scope.

The fourth point has a less concrete but more permanent one. The Federal Office continues to describe the IT security situation in Germany as tense in its annual report. Stalling operations are therefore rarely just a comfort problem.

In closing

A system audit is the smallest sensible step towards clarity. Fixed scope, fixed price, five days, and at the end a plan you can carry on with without being tied in. Further answers on pricing, contracts and where data is held sit under Knowledge. If you want to set an audit in motion, a short first call is enough.