An information security policy for an ICT service provider describes, in plain language and in writing, how your organization handles access, equipment and the people who work on these on your behalf. For an ICT service provider, this revolves around three main things: how you manage customer systems remotely, who has access to those systems, and what you arrange with subcontractors who take on part of the work. Without that document in writing, there is often a way of working, but not something you can show if someone asks you about it.
And they do ask. A client who themselves falls under the duty of care of the NIS2 Directive must assess their suppliers — and an ICT service provider often ranks high on that list, precisely because they have access to systems of multiple customers at the same time. The security questionnaire that follows rarely asks for a thick policy document. It asks for a short, recognizable answer to a few recurring questions. That answer comes faster if the policy is already in writing, rather than having to formulate it anew for each questionnaire.
Objective and scope: what the policy covers and who it applies to
The first component is simple but often overlooked: who this policy applies to, and what it does not cover. For an ICT service provider, this usually means a clear distinction between your own internal systems and the customer systems you manage or work in. A reader — or a customer requesting the policy — should be able to see in a paragraph whether it concerns your own office automation, the infrastructure you manage for customers, or both. Without that distinction, every subsequent section is difficult to assess.
Remote management: what you specifically set out
If you manage customer systems remotely, the policy should name how those connections are established, which tools are used for this and who is allowed to start them. This is not about a technical manual, but about the procedures that a client recognizes: is work done via a fixed, controlled access route or can any employee log in at any time, is a session logged, and what happens if a device used for remote work is lost or replaced. Supervisors and clients look at this component mainly for clarity: is there a line in the policy that matches what actually happens in practice.
Access to customer systems: arrangements that stand out in a questionnaire
Access to customer systems is a different matter than remote management, even though they often overlap in practice. The policy preferably describes here who within your organization gets access to which customer environment, based on which role, and how that access is revoked if someone changes position or leaves the company. Many security questionnaires from clients ask exactly this: not whether you have a password policy, but whether access is linked to a role and reviewed periodically. Anyone who already has this in writing does not need to invent the answer at the moment the questionnaire arrives.
Subcontractors: who sees what, and who is accountable for it
The third component that is often missing at an ICT service provider is the position of subcontractors. If you work with an external party for, say, hosting, part of the helpdesk, or specialized management, the policy should specify what agreements apply: does that party get access to customer systems, and if so, under what conditions, and who within your organization is the point of contact if something goes wrong with that subcontractor. A client reviewing your policy often wants to see precisely this — not because working with subcontractors is a problem, but because unclear arrangements about it are.
Who establishes the policy, and when it is reviewed
A final component that is often overlooked is ownership: who within the organization established the policy, and when it was last reviewed. At a small business, that is often the director themselves; at a slightly larger organization, it may be a designated responsible person. More important than the title is that there is one name and a date attached, so that a client or supervisor can see that the document was not drawn up and then forgotten.
Which components exactly are expected depends on the sector in which you operate and on the client asking the question. the knowledge base with topics by situation provides an overview for each situation of what belongs with it. If you first want to know whether your organization is affected by the NIS2 Directive through the supply chain, then an indication based on a few questions will help you get that clear. Many questions that customers ask about this come up again in the questions other ICT service providers have also asked, and whoever wants to know what those answers are based on can read that back via the explanation of our sources and methodology.
If you do not yet have a picture of where your organization stands, start with the free NIS2 check. That provides an indication and a next step within a few minutes, without requiring an account.