An outside IT provider runs your servers? The responsibility remains with you
A network of outpatient clinics, a dozen or so sites, and an in-house IT team of one person who looks after computers and printers. The servers running patient registration and medical records are maintained by an outside company, the same one for years, and nobody has any complaints. When someone asked, in the context of KSC, how the company manages vulnerabilities, the answer was simple: we have a company that takes care of it.
Then someone asked how the clinics knew the provider was doing it. Silence. Not because the provider had neglected anything. Simply nobody on the clinics' side had ever checked, because they did not know how.
In the third part of the KSC series I look at how to oversee a company you have entrusted with running your servers.
A note before we start: I am not a lawyer and this is not legal advice.
What the law says
The NIS2 Directive, implemented in Poland by the amended National Cybersecurity System Act (KSC), places oversight of cybersecurity risk-management measures on the management bodies in Article 20(1). Article 21(2)(d) lists among those measures supply chain security, including the relationships with direct suppliers and service providers. Article 21(3) adds that the overall quality of suppliers' cybersecurity practices must be taken into account. Point (f) adds assessing the effectiveness of the measures.
The official FAQ to the KSC Act confirms that tasks can be entrusted to others, but this does not release the head of the entity from responsibility. I wrote about this in more detail in the article on outsourcing. Here I deal with one practical consequence: since the responsibility stays with you, you have to ensure effective oversight of the outsourced work. You can hand the technical checking to a competent person, but someone on your side must know what is checked and how.
Where the gap is
In most such relationships, the only source of information about the servers is the provider itself. It scans, it patches, it writes the report, if it writes one at all. The client gets what the provider considers important, in the form the provider chose.
This is not an accusation against providers. Most do solid work. The problem is structural: when the same party does the work and is the only one assessing it, the client has nothing to compare that assessment with. In an audit, "the provider assured us" is not evidence of oversight.
There are also three things that most often get lost in practice.
Risk decisions are made on the provider's side. The administrator decides an update cannot be done before the end of the quarter because the registration system does not support it. The decision may be reasonable, but its consequences fall on the clinics, and outsourcing the work does not take responsibility away from their head. Someone on the clinics' side should approve it, knowing what they are approving.
The history stays with the provider. If you ever change companies, the record of the last few years may leave with them, and those are exactly the years an auditor will ask about.
The report says what the provider wants to say. That need not be dishonest. It is enough that the report describes work done ("140 updates installed") rather than the state ("how many vulnerabilities are overdue").
How to close it without damaging the relationship
Agree in the contract what the report must contain. Not the number of tasks performed, but state indicators: the share of vulnerabilities fixed on time, the list of overdue items, time to fix, the list of servers covered and not covered by scanning, the date of the last scan of each. Plus the remediation deadlines binding the provider, written in the contract or in your policy. I described these indicators in the previous part.
Risk decisions are approved by someone on your side. The provider can propose postponing an update, with a justification and a review date. The approval comes from the person on your side who is responsible for it. Write this rule into the contract.
The data must be yours. Access to the scan and decision history during the contract and its handover after the contract ends. It is simplest if the data sits from the start in a place you can access independently of the provider.
Keep your own list of the access you have given the provider. Administrator accounts, SSH keys, VPN, the hosting panel, backups: who on your side holds that list, and can they close that access without the provider's help? If the only person able to revoke the provider's access is the provider, what you have is trust, not oversight. The point is not to take anything away today. The point is that on the day you change providers, or the provider has an incident of its own, you do not start by asking where the passwords are. This question was suggested to me under the first episode by an administrator at a company that maintains servers for its clients. He admitted it can be uncomfortable for the provider, but once it is answered both sides know where they stand.
The report should reach you straight from the data. The strongest form of oversight is one where the indicators are calculated from scan results rather than copied into a table by someone. Then both sides look at the same numbers and nobody has to take anyone's word for it. Such a report checks the part of the provider's work that is visible in the scan. It does not replace assessing the provider's practices or evidence of its other obligations, and you still check whether the scan covers all servers and is current.
One conversation about numbers per quarter. Not about how much was done, but about what is overdue and why. If the cause is a lack of maintenance windows or an old application, that is a matter for your decision, not a complaint against the provider.
These rules help the provider too. A report calculated from data shows its work better than a table, and what is stuck because of your own decisions is plain to see.
Where Secvalis helps, and where it does not
The Secvalis account can belong to your company, with the provider given access in it under the technical role. One user can belong to several accounts, with a separate role in each, so a company serving several clients works in each client's own account. For that role you can narrow access to the machines of selected projects. The owner or an administrator invites people to the account, and only the owner can remove a user from it. A provider with the technical role cannot invite or remove anyone. After removal, access ends at the next session refresh rather than in the same second. This applies to Secvalis itself: it holds no list of access to your servers, so that list has to be kept separately.
Management report delivery settings, including recipients, can only be changed by the account owner or administrator. The technical role can read them but not change them. The report can reach you on a schedule, and its indicators are calculated from scan results: a vulnerability counts as removed when it disappears from the next full scan, not when someone clicks "fixed". The mean time to fix excludes, among other things, items already present when tracking began.
A risk acceptance requires a justification, a risk owner, a review date and information on safeguards. The technical role can submit a request, which the account owner or administrator approves. The audit log records such decisions and can be exported. If you want to give an auditor a view, there is a separate read-only role for that.
Secvalis does not replace the contract with the provider, the provider assessment or the wider area of supply chain security. It will not check whether the provider properly protects its own systems and its access to yours. It covers Linux servers and the images of containers running on them, so if the provider also maintains Windows workstations or the network, that part needs its own report. If you give the provider the administrator role, it will be able to change the report settings, so consider who gets which role.
You can see how this works in practice in the public demo: the management report, the risk decision register and the audit log of a fictitious company, with no registration.
In the next part I switch to the administrator's side: what to do when the list has 800 items and there is one person to deal with them.
Sources
Weekly CVE digest
One email a week with newly published vulnerabilities worth knowing about. No account needed.
This digest covers new vulnerabilities in general, not your servers. If you want to know which of them actually run in your infrastructure, that is what Secvalis does: it scans your machines and reports only what concerns them.