Client wants vulnerability management compliant with BSI rules — what do we actually need to set up in Germany?

Smaller teams often hear BSI and instantly get overwhelmed by hundreds of pages of IT-Grundschutz documentation. Most of the time, the client doesn't actually mean full certification; they just need operational proof they can present during an audit. If the contract doesn't explicitly require an ISO 27001 or formal BSI certificate, proceed by delivering a documented process and scan reports without burning through your budget.

To streamline things technically, integrate continuous open-source dependency scanners alongside host-level vulnerability scanners. Hooking up a webhook that pushes new CVE findings straight into your ticketing system will save your sysadmin from keeping manual spreadsheets. BSI auditors typically look for unscanned shadow servers, so make sure every subdomain host is covered under your scope.

On a similar public sector project, we licensed a vulnerability scanner for 2,200 EUR annually. Setting up the system took us 3 weeks. Our sysadmin spends 2 hours every Monday reviewing BSI and CERT bulletins, and 6 hours a month generating reports. Thanks to this routine, we cleared our last two client audits with zero findings.

The quickest things you can do starting tomorrow: 1) Put together a clean spreadsheet listing your servers and libraries. 2) Subscribe to the free CERT-Bund email newsletter. 3) Draft a two-page Security Policy specifying patch timelines and have it signed off internally. When the client comes for an audit, that document is the first thing they'll ask to see.

We faced the exact same requirement in a healthcare software tender in Munich. During the first audit, they asked us, "How long did it take you to patch that critical kernel vulnerability that came out last month, and where's the log?" We had pushed the patch to prod in 4 hours, but we got flagged because we hadn't opened a ticket and logged the timestamps. The whole secret really boils down to proper record-keeping.

Does your client explicitly reference BSI IT-Grundschutz building block OPS.1.1.3 (Patch- und Änderungsmanagement) in the specs? If that module is mandated you need to link your change management process directly to patch approvals.

went through something similar, add automated vuln scanning bots to your git repo. have them scan libraries on every build. tbh even just a flowchart showing you never push code to prod without a green light in staging is enough to satisfy the client.

Because your client is affiliated with the public sector, they are required to guarantee BSI compliance in their subcontractor agreements. The documentation you prepare should include a RACI matrix, an emergency patching procedure, and a commitment to annual external audits. It is essential that these documents are officially approved by company leadership.

We need to make a distinction here. Your time to detect an issue directly determines its cost.

That's all, sorry if I went on too long.

How did you solve this? The real issue isn't the number, but what it's based on.

Sorry, but this doesn't apply in every case. Most incidents start with a leaked password, not a vulnerability.

Good luck with that.

I've been dealing with this for a long time. Everyone rushing into bsi vulnerability management gets stuck at the same point.

I'd appreciate it if you shared the outcome. Start with a small trial; don't commit to everything at once.

Just leaving this note, it might be useful.

Following.

There's a part I don't understand. An automated scan report is not the same as a penetration test.

Good luck with that.

Exactly like that. Solutions that work at a small scale collapse when you grow; I learned this late.

If you post the result here, it will help others too.

The discussion got scattered, let me summarize. If it's your first time, start small; scaling comes later.

The answer varies greatly by industry; there is no one-size-fits-all rule. Hope this helps.

You're right. I mean hasty decisions become decisions you have to fix six months later.

An automated scan report is not the same as a penetration test. anyway if you post the result here it will help others too.