Why we exist

We don't do slide-deck consulting

You have met the other kind of consultant. Three people in good suits, a 60-slide deck, a "maturity assessment" full of traffic-light colours, and an invoice. Six weeks later you have a PDF and exactly the same network you started with. Nobody touched a single device.

That is not us. We are systems engineers. Our work leaves the room in the form of running configuration, not recommendations. If a firewall rule needs writing, we write it. If a VLAN needs re-segmenting at 6pm because that is the only maintenance window your production line allows, we are the ones on-site with a laptop and a console cable.

Local, and in the building

On-site in Hamburg — not a ticket queue

We are based in Hamburg and we show up in person. During an integration our engineers are in your server room and next to your admins' desks — not on the other end of a support portal in a different time zone.

There is a reason for this beyond politeness. Real networks are full of things that never made it into the documentation: the switch someone patched "temporarily" in 2019, the undocumented static route, the cable that is labelled wrong. You find those by standing in the room, not by reading a Visio diagram over a call.

  • Physically present for the integration — Hamburg and the surrounding region
  • Console cable in hand, in your server room
  • We work your maintenance windows, including evenings
  • Decisions made face to face, not via change-request ping-pong
Your team, not over their heads

Side by side with your IT people

Your internal IT team knows things we never will: which application breaks if latency creeps past 20ms, which department will riot if their share drive moves, who actually approves a reboot. We treat them as the experts on their own environment — because they are.

So we sit next to them and build it together. They watch every command. They ask why. By go-live they are not "trained on a new system" — they have been running it with us for weeks. When we leave, nothing is a black box, because they helped build the box.

What "hands dirty" actually means

Routing tables, not checklists

The slide-deck version

  • "Implement a defence-in-depth strategy"
  • A RACI matrix nobody opens again
  • A compliance checklist with tick-boxes and no evidence behind them
  • "Engage a managed service provider"
  • A roadmap that ends the day the invoice is paid

The XpertOne version

  • Deny-by-default rulesets written, tested, and committed to Git
  • VLANs re-segmented and verified with a packet capture, not a promise
  • 802.1X rolled out port by port until nothing unknown gets a lease
  • step-ca issuing certs, Suricata dropping traffic — live, on your kit
  • NIS2 & DORA mandates mapped to concrete design principles — an architecture that is compliant, not a tick-box
  • Runbooks your team wrote with us, because they were in the room
And it is not improvised — every engagement follows this sequence

How we work

  • 01

    Audit

    Conduct a risk assessment to identify potential security threats and vulnerabilities.

  • 02

    Plan

    Evaluate the likelihood and impact of identified risks and plan short term mitigation.

  • 03

    Design

    Design the network security architecture and create best practices procedures to reduce the recurrence of future incidents.

  • 04

    Implementation

    Deploy the security infrastructure and train the operation team.

  • 05

    Go LIVE!

    Conduct a final review of the project to ensure all objectives are met and handover to operation team.

What each phase delivers

Structured. Documented. Repeatable.

01

Audit

We begin every engagement with a structured risk assessment. We map your existing infrastructure, identify attack surfaces, and assess compliance gaps against NIS2, DORA, GDPR, and BSI IT-Grundschutz. The output is a prioritised risk register — not a generic report.

02

Plan

We translate the risk register into a remediation roadmap with clear priorities and timelines. Short-term mitigations are separated from strategic infrastructure changes. Every recommendation is costed and scoped before any implementation work begins.

03

Design

Architecture diagrams, network topology, VLAN design, firewall ruleset logic, and integration touchpoints are documented before a single package is installed. The design phase produces artefacts that survive the engagement — your team can maintain what we build. Where the change carries risk, we model your existing vs. proposed topology in an isolated sandbox (Proxmox + containerlab) and prove it works before it ever touches production — and we can show the solution running live.

04

Implementation

On-site deployment by our engineers. Infrastructure-as-code (Ansible, Terraform) means every configuration is version-controlled and reproducible. We deploy, test, and validate against the design. Your operations team is trained during this phase — not after.

05

Go LIVE!

Final review against all design objectives. Runbooks, DR procedures, and compliance evidence packages are handed over. We sign off only when monitoring is active, alerts are configured, and your team can operate the system independently.

When we leave, you don't need us

It is open source, it is documented, your team helped configure it, and you keep root. Some consultants engineer dependency on purpose — we build the opposite. If you never call us again, we did the job right.

Talk to an engineer →