Skip to content

Commissioning IT security externally — from assessment to ongoing operations

How to outsource IT security to an external provider — protection needs, audit, implementation, ongoing operations, incident preparedness, evidence.

For companies

Updated September 23, 2026

IT security isn't a single project — it's an umbrella term for very different services: a one-off security assessment, the implementation of specific protective measures, or ongoing operation of monitoring that detects attacks early. A company that requests "IT security" without making this distinction gets correspondingly different, hard-to-compare offers back. This guide helps you place your own need and formulate a request that providers can actually work with. Regulatory questions are deliberately treated here only as checkpoints — for a binding assessment of which obligations concretely apply to your company, the responsible bodies and official sources are the right place to go, not this guide.

Assessment and protection needs

Before you approach a provider, get an overview: which systems, data and processes are critical to ongoing business operations, and what would an outage or data loss actually mean in each case? Not every system has the same protection needs — an internal wiki can tolerate a short outage more easily than a system that controls production or processes customer data. You don't need to make this assessment in full technical detail yourself, but a rough prioritization helps the provider considerably in tailoring their proposal to the areas that are actually critical, instead of treating everything the same across the board. Also name any requirements customers or business partners have already raised with you, for example as part of supplier requirements, as well as existing technical constraints such as the operating systems, cloud services or firewall infrastructure already in use.

Distinguish audit, implementation and ongoing operations

An audit or security assessment (such as a penetration test or vulnerability analysis) reveals the current state and possible gaps, but doesn't fix them itself. Implementation of specific measures — such as reworked network segmentation, an access-rights concept, or a new backup strategy — usually presupposes a prior audit or at least a clear target picture. Ongoing operations — such as continuous monitoring of security-relevant events or patch management — is in turn a standing service with its own contract model, not a one-off measure. These three types of service sometimes require different specializations, and not every provider covers all three equally well. So decide in the request which of these categories you're actually looking for — or whether you deliberately want to start with an audit and plan the next steps only afterward. If what you're actually looking for is general, non-security-specific support, the guide to IT support and managed services is the better starting point.

Incident preparedness

An IT security concept that relies only on prevention stays incomplete. Clarify how you'll respond if something goes wrong: is there a documented process for a security incident, who gets informed, and how quickly can systems be restored from a backup? A backup that's never been tested is no reliable safeguard — ask a provider specifically whether and how regularly restores are tested. This kind of preparedness should still be a fixed part of every request, not an afterthought. Also ask how quickly a first point of contact is reachable in an emergency, and whether a separate emergency contact exists outside normal support hours — a security incident rarely respects business hours.

Evidence and documentation

Ask what evidence you'll receive once the project is complete: an assessment report with the vulnerabilities found and how they were fixed, documentation of the measures implemented, or proof of the provider's own existing certifications. Such documents matter not just for your own records but are often relevant to customers or insurers too. Also clarify in what form and language the documentation is delivered, and whether it remains available for follow-up questions later.

Check regulatory topics instead of assuming them

Whether and to what extent your company is affected by regulatory requirements — for example in connection with NIS2 or industry-specific rules — depends on factors like company size, industry and critical-infrastructure status, and can't be answered in general terms. For a first orientation, the BSI offers the NIS-2 self-check — an anonymous self-assessment tool that doesn't replace a legally binding assessment. Check there, or with appropriately specialized advice, whether and which concrete obligations apply to your company, before relying on a specific deadline or requirement you heard about elsewhere.

Requirements for the provider

IT security is an area where a provider's experience is particularly hard to judge from the outside. So ask specifically for references for comparable projects — not a general list of past clients, but projects with a similar system landscape or similar company size. Relevant certifications held by the provider or its staff can be an additional data point, but they don't replace a substantive review of the actual proposal. Also clarify who at the provider will actually work on your project, and whether that's the same people introduced in the first conversation. A verified business identity shows who you're dealing with — it says nothing about technical competence.

Place the offers

Summarize your protection needs, the type of service you want (audit, implementation, or ongoing operations) and the evidence you expect in a written request — the guide to writing a scope description shows what information is useful for that. Since security offers often use different pricing models, from fixed-price audits to ongoing support contracts, it's worth looking past price when comparing; the guide to comparing offers describes what else to watch for.

Checklist

  • Critical systems and data identified, rough protection needs assessed
  • Clear whether you're looking for an audit, implementation, or ongoing operations
  • Incident preparedness and backup restoration named as a topic
  • Expected evidence and documentation clarified upfront
  • Regulatory exposure checked with the BSI or specialized advice, not assumed
  • References and responsibilities at the provider concretely asked about, not just in general terms

If you want to move forward with an IT security project, you can describe it on Projektlotse — whether that's an audit, implementing specific measures, or ongoing operations. Verified IT providers in your region see the request and get in touch with questions and offers. Your company name, exact address and attachments stay confidential until you release them to individual providers. So don't name specific vulnerabilities, system names or access credentials in the request itself — save those for the conversation with a provider. Use is free during the current start phase.