NIS2 cybersecurity: how to audit industrial IT suppliers

Article 21 of NIS2 requires you to manage supply chain risk. In practice, this means that your textile factory answers to the authority for what the supplier hosting your MULTI ERP does — or fails to do — in terms of security. But how does the IT lead of a 90-person company audit the datacentre that sells it cloud, the integrator that maintains its MES, and the manufacturer of its shop-floor terminals? This article resolves this in technical detail: which clauses to require, which evidence to collect, which thresholds to set, and where auditing fails in real life.

The thesis, first and foremost: most IT supplier audits in Portuguese industrial SMEs fail not for lack of rigour, but because they audit the wrong company. Energy is spent demanding ISO 27001 from the cloud supplier — who already has it — and the small local integrator with permanent remote access to the ERP, sharing a password between three technicians, is ignored. Risk lives in the smallest link, not the biggest. And that link almost never appears on the Excel sheet of the NIS2 dossier.

There is a second reason, less comfortable to admit. In many industrial SMEs in the North, auditing IT suppliers does not even exist as a process — it exists as a reaction. Someone got a fright, ransomware hit a client in the same cluster, and suddenly there is a meeting where it is decided to "ask suppliers for their certificates". They are requested, PDFs arrive, they are filed, and the matter is considered closed. Six months later, no one remembers where the dossier is, and the integrator's technician still logs into the production server with the same generic account as ever. NIS2 came to force that one-off fright to be turned into a recurring, auditable process that can be defended before the competent authority. That is what this text is about.

It is worth being precise about who is within scope. NIS2 covers essential and important entities above certain thresholds — typically medium-sized enterprises and above, in sectors defined in the annex to the directive. Many small clothing manufacturers and footwear factories are not directly within scope. But they are in the supply chain of those who are: a fashion multinational, a food distributor, an automotive component manufacturer. And Article 21 pushes the obligation down the chain. Whoever subcontracts to Inditex, Decathlon or Lacoste will receive, sooner or later, a security questionnaire from the parent company. Being prepared to answer it is no longer optional.

1: Recommended architecture of the audit process

Auditing suppliers is not an annual event — it is a pipeline. Design it in four layers, from classification to continuous monitoring, because a one-off audit ages within weeks. Each layer has its own objective and produces a concrete artefact: an inventory, an evidence dossier, a technical report, an alert flow. If a layer produces nothing fileable, you did not do it — you had a conversation.

Order matters. You do not do documentary due diligence before classifying, because you do not know who to require what from. You do not do technical verification before reading the documents, because you waste time testing what the paperwork had already ruled out. And you do not set up continuous monitoring before knowing who the Tier A suppliers are, because you spend SIEM budget watching whoever prints labels. The sequence protects the budget the SME does not have.

Layer 1 — Supplier inventory and classification

You cannot audit what you do not list. The first mistake is not having a canonical register of IT suppliers with their actual level of access to systems and data. Build it with five minimum attributes per supplier: type of service, data it accesses, privilege level (read / write / administrative), access mode (VPN, RDP, agent, API) and criticality to production continuity.

Classify each supplier into one of three tiers. Tier A: administrative access to systems that, if they go down, stop the line (ERP, MES, firewall, datacentre). Tier B: access to data but without the privilege to stop production (BI, payroll, document management). Tier C: no access to critical systems (consumables, desktop hardware). The depth of the audit scales with the tier — auditing a Tier C supplier with the same questionnaire as a Tier A one is wasting the budget you do not have.

In real life, the surprise of Layer 1 is almost always the same: the list turns out larger than the IT lead expected. In a medium-sized textile factory in the Vale do Ave, a serious inventory usually reveals between fifteen and thirty entities with access to some system — the ERP supplier, the cloud supplier, the BI supplier, the automation integrator for the looms, the technician for the time-and-attendance system, the CCTV company that turns out to be on the same network segment, the supplier of the warehouse scale software, the accounting firm that pulls files from the ERP. Half of them were on no register at all. That is the immediate value of the layer: making visible the real attack surface, not the imagined one.

A detail that distinguishes a useful inventory from a decorative one: record the access mode with technical honesty. "VPN" is not a sufficient answer. What matters is knowing whether it is a permanent site-to-site VPN, an on-demand user VPN, or — the worst case, more common than admitted — a TeamViewer or AnyDesk installed on the server and always on. The risk difference between these modes is of orders of magnitude. Unsupervised permanent access is what keeps security managers awake.

If your IT supplier inventory fits in the IT lead's head from memory, it is not an inventory — it is a favourites list. Risk lives precisely in the access points no one remembers.

Layer 2 — Documentary due diligence

Collect evidence, not promises. A valid ISO 27001 certificate is worth more than any questionnaire answer, because an independent third party verified it. For Tier A suppliers, require: a valid ISO 27001 certificate (with scope annex — the devil lives in the scope), a SOC 2 Type II report where it exists, a patch management policy, an incident response plan with a notification SLA, and evidence of disaster recovery testing in the last year.

An ISO 27001 certificate whose scope covers only "consultancy services" and not "datacentre operation" is a certificate that covers nothing of what interests you. Always read the scope annex.

Beyond ISO 27001, there are related standards that matter depending on the service. ISO 27017 extends controls to the cloud, and ISO 27018 covers the protection of personal data in cloud environments. If your supplier hosts employee data — and it does, if it runs payroll or the pplPortal —, the existence of these certifications tells you more about real maturity than a handful of questionnaire answers. Do not require everything from everyone; require what is proportionate to the specific data the supplier touches.

The questionnaire has its place, but know its limits. A security questionnaire is a self-declaration. It serves for Tier B and C suppliers, and serves as triage for Tier A before requesting evidence. It does not serve as proof. When a Tier A supplier answers "yes" to "is MFA enforced on all administrative accounts?", that answer is an assertion that Layer 3 will verify — not an established fact. Treat the questionnaire as hypothesis, not conclusion.

Establish documentary rejection criteria right from the outset, in writing. A Tier A supplier that cannot present an incident response plan, nor evidence of a single restore test in the last year, nor a patch management policy, is not a supplier to improve — it is a supplier to replace or to contain with compensating controls on your side. Due diligence only has value if it can produce a "no".

Layer 3 — Technical verification

Documents lie elegantly. For Tier A, technically validate what the paperwork asserts: an on-site backup restore test, a review of accounts with remote access, verification that MFA is really active (and not merely "available"), and a vulnerability scan of the exposed perimeter. This layer is what distinguishes a serious audit from a filing exercise.

The most revealing technical verification is also the most uncomfortable to request: watch a real restore. Not the report of a restore — the restore. Schedule with the datacentre supplier a window in which it restores a copy of your ERP in an isolated environment, and time it. That is the moment when the paper RTO meets reality. We have seen "4-hour" restores turn out to be 18-hour restores once you counted the time to locate the correct copy, decompress it, remount the database and validate integrity. That true figure is the only one that matters to your continuity plan.

Reviewing remote access accounts is usually equally productive. Request the full list of accounts the supplier uses to access your systems, with the date of last use. Compare it with the list of technicians currently employed by that supplier. The difference between the two lists — active accounts of people who have already left — is one of the most reliable indicators of the supplier's real security posture. A company that manages its access well does not leave orphaned accounts hanging on a client's server.

As for the perimeter vulnerability scan, keep it within what is legal and contracted. Do not run aggressive scans against third-party infrastructure without written authorisation — that exposes you. What you can and should do is verify the exposed surface of the service that directly affects you: unnecessarily open ports, outdated services visible from outside, expired TLS certificates. It is hygiene verification, not penetration testing.

Layer 4 — Continuous monitoring

Between audits, the supplier changes staff, subcontractors and posture. Monitor continuously whatever you can automate: alerts for out-of-window remote access, quarterly review of privileged accounts, and a contractual clause for incident notification within a defined deadline. NIS2 does not forgive "we didn't know".

The key phrase of this layer is "automate what you can". A 90-person industrial SME does not have a 24/7 SOC, and pretending it does is building a process no one will maintain. Realism dictates choosing two or three high-value signals and automating them well, rather than setting up a dashboard with forty metrics no one looks at. The highest-return signals are usually three: supplier remote access outside the agreed window, creation of a new privileged account, and failure of a scheduled backup. These three, well alerted to the IT lead's mobile phone, cover most of the scenarios that matter.

The quarterly review of privileged accounts does not need an expensive tool — it needs discipline and a calendar reminder. Four times a year, someone pulls the list of supplier accounts, confirms with each supplier which ones are still needed, and deactivates the rest. It is tedious half-hour work that avoids the classic scenario: the technician who left eight months ago and still has an active VPN.

2: Parameters, metrics and thresholds

An audit without numbers is opinion. Set concrete thresholds and make them the criterion for accepting or rejecting the supplier. The values below are defensible for a typical Portuguese industrial SME — adjust them to your criticality, but adjust in writing.

Two market figures to calibrate the urgency. In 2024 CERT.PT recorded 2,758 cybersecurity incidents in Portugal — 36% more than in 2023 — and around 78% occurred in private entities (CNCS, 2024). And in SMEs, ransomware was present in 88% of the breaches analysed, against 39% in large organisations (Verizon DBIR, 2025). The preferred target is not the multinational with a 24/7 SOC — it is the clothing manufacturer in Famalicão whose IT supplier has used the same password since 2019.

How to calibrate the thresholds to your reality

The values in the table are a starting point, not dogma. Calibration is done by looking at two things: the cost of one hour of production downtime and the tolerance window of your most demanding client. A footwear factory in full swing of sample campaigns for the August buyers does not have the same tolerance for downtime as the same factory in a slack period. The RTO you negotiate with the datacentre supplier should reflect the worst moment of your calendar, not the average over the year.

RPO deserves special attention in a production industry. An RPO of 24 hours means that, in an incident, you can lose up to a whole day of records. In a clothing manufacturer that captures production in real time via shop-floor terminals, that is potentially hundreds of sewing operations to recover manually — who did what, how many pieces, on which manufacturing order. The cost of rebuilding that day by hand, against the cost of a more frequent backup, usually settles the discussion in favour of a short RPO. Do that calculation before accepting the standard RPO the supplier offers.

If your cloud supplier cannot tell you how long it takes to restore the ERP after ransomware, its RTO is "I don't know" — and "I don't know" does not pass a NIS2 audit.

The patching window and the conflict with production

The threshold of patching critical vulnerabilities within seven days is defensible in an IT environment. In an OT environment — the controllers and terminals on the shop floor — that deadline collides with the reality that you do not restart a PLC in the middle of a shift. The conflict is real and the answer is not to pretend it does not exist. The answer is to separate the two domains in the policy: IT follows the aggressive window; OT follows a longer window, offset by network segmentation that isolates vulnerable OT systems until they are patched. Segmentation is the control that buys time for the patch that can only wait for scheduled downtime.

3: Practical configuration

The audit produces technical requirements that have to live in the configuration, not in the PDF. Three illustrative examples of what to require and validate.

Restricting remote access by window and origin

The integrator that maintains your ERP does not need RDP open 24/7 to the entire internet. Limit it by origin IP and by time window, and enforce VPN with MFA. Illustrative example of a firewall rule for a Tier A supplier's access:

# IT supplier access rule — illustrative
Allows RDP to the ERP server ONLY from the integrator's VPN
and only during the maintenance window (Mon-Fri, 08-20h)
allow proto tcp \
     src 10.44.12.0/29         # supplier's VPN subnet (named)
     dst 192.168.30.10         # MULTI ERP server
     port 3389 \
     schedule "mon-fri 08:00-20:00" \
     require-mfa yes \
     log all                   # mandatory logging for NIS2 evidence
Everything else to this destination: denied and logged
deny  proto tcp dst 192.168.30.10 port 3389 log all

The rule illustrates two principles that matter more than the specific syntax. First, access is granted from a known, named origin — not from the entire internet. Second, anything not explicitly permitted is denied and logged. That log all at the end is not decorative: it is the evidence that shows the authority, on the day of an inspection or an incident, that supplier access was controlled and monitored. Without logging, there is no way to prove the control existed.

Note the time window. The supplier accesses during maintenance hours, not at three in the morning on a Sunday. Any attempt to access outside the window is, in itself, an alert — either it is a technician working outside what was agreed (to correct, by talking to them), or it is a compromised credential being used by an attacker (to investigate, urgently). The window turns each anomalous access into an actionable signal.

Verifying MFA is active (not merely available)

"We have MFA" and "MFA is enforced on all accounts" are different statements. Audit the enforcement, not the availability. In a directory query, confirm that there are no exempt privileged accounts:

# Check administrative accounts WITHOUT enforced MFA (illustrative)
PowerShell / Microsoft Entra — run during the audit
Get-MgUser -Filter "accountEnabled eq true" -All |
  Where-Object { $_.AssignedRoles -match "Admin" } |
  ForEach-Object {
    $mfa = Get-MgUserAuthenticationMethod -UserId $_.Id
    if (-not $mfa) {
      Write-Output "NO MFA: $($_.UserPrincipalName)"  # audit failure
    }
  }

The distinction between "available" and "enforced" is the difference between theoretical security and real security. Many organisations enable MFA as an option and then never make it mandatory, leaving administrative accounts authenticating with just a password "because it's convenient for the technician who logs in in a hurry". Those accounts are exactly the ones an attacker looks for. Programmatic verification during the audit produces an objective list of exceptions — and each exception is a failure to correct before signing off the report.

Contractual notification clause (technical draft)

The notification SLA has to be in the contract, not in the email of good intentions. Illustrative draft:

Clause X — Security incident notification
The Supplier undertakes to notify the Client of any
security incident that affects, or may affect, the
Client's systems or data within a maximum of 24 hours
of detection, by written channel and by telephone contact
to the Client's security manager.
The notification shall include: nature of the incident, affected
systems, potentially compromised data and containment
measures in progress.
Non-compliance constitutes grounds for contract termination.

The final sentence of the draft is the one that gives teeth to the rest. A notification obligation without a contractual consequence is a polite request. By making non-compliance grounds for termination, the IT lead gains real leverage in the negotiation with a supplier that would otherwise treat notification as optional. Note too the deadline aligned with your own obligation: NIS2 imposes tight reporting deadlines on the operator towards the authorities, and you only meet them if the supplier warns you in time. The 24-hour deadline in the clause is, at bottom, the condition for you yourself to comply with the law.

Activity logging as a contractual obligation

Add a log retention clause to the draft. The supplier that accesses your systems must keep access logs for a defined period — six months is a reasonable minimum — and make them available on request in the event of an incident. Without this clause, you discover at the worst moment that the supplier did not keep the records that would prove what happened. Evidence that does not exist cannot be recovered after the fact.

4: Integrations and dependencies

Supplier auditing does not live in isolation — it feeds and is fed by other systems. Map the dependencies before starting, otherwise you discover halfway through that you do not have the data you need.

The detail that slips through: if your ERP runs in the cloud, the cloud supplier's RTO and your backup's RPO have to be coherent with your own continuity plan. There is no point having a restore objective of 4 hours if the supplier's contract says "best effort". For those sizing the source infrastructure, it is worth reviewing what to consider in the network infrastructure for cloud ERP in a factory. And if you have an OT environment — controllers, production-capture terminals with MQTT, IIoT sensors — auditing the automation supplier follows the same logic, but with the particularities of patch and vulnerability management in an OT environment, where you cannot simply restart a PLC in the middle of a shift.

The identity link: the IdP as a single point of control

If you have a centralised identity provider, use it as the enforcement point for supplier access rules. Instead of managing supplier accounts scattered across each system, concentrate them in the IdP, apply mandatory MFA and access review there, and let the systems trust the central authentication. This centralisation is not just convenience — it is the difference between revoking access in one place and having to hunt it down across twelve systems when a technician leaves the supplier. A well-configured IdP turns access revocation into a one-click operation.

Coherence between your DR and the supplier's

There is a coherence trap that only appears under testing. Your disaster recovery plan assumes a 4-hour RTO for the ERP. But the ERP runs in the supplier's datacentre, whose contract promises "best effort". On paper, the two figures never meet — until the day of the incident, when you discover that your plan depended on a commitment the supplier never made. The audit serves precisely to force this meeting before the incident: either the supplier commits to a contractual RTO coherent with your plan, or your plan is written on sand.

5: Operational pitfalls

What we see recurring in Portuguese factories and distributors — and how to resolve it.

Pitfall 1 — The integrator's shared password. Three technicians from the supplier access the ERP with the same "support" account. When there is an incident, no one knows who logged in. Solution: require named accounts per technician, enforce it contractually and validate it in the log. If the supplier resists, that is a sign — not of inconvenience, but of security maturity.

Pitfall 2 — Auditing the big one, ignoring the small one. The whole dossier is devoted to the certified hyperscaler and the local technician with TeamViewer always connected to the production server is forgotten. Solution: the risk tier governs the depth, not the supplier's size.

Pitfall 3 — A certificate without reading the scope. An ISO 27001 is accepted whose scope does not cover the contracted service. Solution: read the scope annex and confirm that it includes the specific operation that affects you.

Pitfall 4 — RTO on paper, never tested. The contract promises restoration in 4 hours but there has never been a real test. On the day of the incident it emerges that the restore takes 19 hours. Solution: require evidence of a restore test in the last 12 months — watch one, if it is Tier A.

Pitfall 5 — Remote access that no one revokes. The technician who left the supplier eight months ago still has an active VPN. Solution: quarterly review of supplier accounts and a clause for notification of changes in staff with access.

Pitfall 6 — Invisible sub-subcontracting. Your cloud supplier subcontracts support to a third-party company it did not audit. The chain has three links and you only see the first. Solution: require by contract the disclosure of subcontractors with access to data, and the right to audit or reject them.

Pitfall 7 — Frozen NIS2 dossier. The audit is done once, filed, and the obligation is deemed met. Six months later it is out of date. Solution: treat the audit as a recurring process, with a minimum annual review for Tier A and whenever the service changes shape.

Pitfall 8 — The questionnaire no one verifies. A fifty-question questionnaire is sent out, the supplier answers "yes" to all of them, the PDF is filed and the supplier is considered audited. Solution: for Tier A, no questionnaire answer is worth anything without evidence. Choose three or four critical answers — MFA, backup, notification, named accounts — and verify them technically. An unverified "yes" is worse than no answer, because it gives a false sense of control.

Pitfall 9 — The shop-floor shortcut. The audit is impeccable on paper, but the warehouse supervisor gives the server password to the technician "to be quicker" because the line is stopped and the month-end is pressing. Solution: technical security has to be accompanied by training of those on the ground. If the named process is slower than the shortcut, the shortcut always wins. Design legitimate access to be fast — a well-configured VPN with MFA logs in within seconds — so no one has any incentive to bypass it.

The warehouse supervisor does not go to the NIS2 meeting, but it is he who, on a Thursday afternoon, gives the server password to the technician "to be quicker". The security of the chain dies at the shortcut, not in the document.

6: Final technical decision

No hedging: the level of audit you set up depends on your size and on the criticality of what you subcontract. This matrix gives you the direct choice.

The rule that does not change in any tier: named accounts, enforced MFA and contracted incident notification. These three are the non-negotiable minimum, regardless of size. Everything else scales with risk. In 2024 the global average cost of a data breach reached 4.88 million dollars, 10% more than the previous year (IBM, 2024) — and the slice an industrial SME does not survive is not the fine, it is the production downtime during the month-end. Those who combine this audit with zero trust on OT networks and technical controls at factory level stop reacting and start preventing.

Priority in the first year: three actions before everything else

If reading this matrix has left you feeling it is a lot to do at once, focus on what delivers the greatest immediate return. First, do the inventory — without it, none of the rest makes sense, and it already exposes the real attack surface. Second, eliminate shared supplier passwords, starting with the Tier A ones; it is the highest-impact control per unit of effort. Third, put the incident notification clause into all Tier A contracts, taking advantage of the next renewal. These three actions, completed within six months, move most of the risk. The full pipeline is built on top of them.

What the authority will want to see

When the inspection comes — and for entities within scope, it comes —, what distinguishes a prepared company from one caught off guard is not the number of controls, it is the existence of filed and dated evidence. An up-to-date supplier inventory. A due diligence dossier per Tier A supplier. Remote access logs. Restore test reports. Minutes of quarterly access reviews. The internal audit does not just produce security; it produces documented proof that security was managed. That proof is what answers the authority.

7: How INFOS implements it

As a vertical software supplier for industry, INFOS is, for its clients, a Tier A supplier — and we know what that implies. The MULTI ERP and the KORA Productivity shop-floor modules operate with named access, activity logging for evidence and integration with monitoring solutions, and our cybersecurity area supports the technical assessment of the supply chain and the verification of restores in the datacentre. We do not sell you a certificate to file — we help build the process that withstands the first serious audit and the first real incident.

In practice, when a textile or footwear factory asks us for support with the NIS2 dossier, we start with what concerns us directly: how our access to the ERP is controlled, what records we produce, what RTO and RPO are realistic for the architecture we built together. A Tier A supplier that cannot answer these questions about itself has no authority to help anyone audit others. We prefer to come to the conversation with our own answers already in order.

In the end, auditing IT suppliers under NIS2 is less about paperwork and more about an uncomfortable question: if your integrator were compromised tonight, at what time tomorrow would your line be producing again? If you do not have the answer in hours and in writing, the audit has not yet begun.

Sources

• Directive (EU) 2022/2555 (NIS2) — Official Journal of the European Union; transposed in Portugal by Decree-Law No. 65/2025 (Diário da República).
• CNCS — National Cybersecurity Centre / CERT.PT, 2024 incident report (2,758 incidents, +36% compared to 2023; ~78% in private entities).
• IBM — Cost of a Data Breach Report 2024 (global average cost of 4.88 million dollars).
• Verizon — Data Breach Investigations Report (DBIR) 2025 (ransomware in 88% of breaches in SMEs).
• ISO/IEC 27001 — Information security management systems (certification requirements).
• ISO/IEC 27017 and ISO/IEC 27018 — security controls and protection of personal data in cloud environments.

Frequently asked questions

What is Article 21 of NIS2 and how does it affect me?

Article 21 requires you to manage supply chain risk. This means that your company answers to the authority for what your IT suppliers do — or fail to do — in terms of security. If the supplier hosting your ERP suffers an incident, you are responsible before the regulator.

How do I classify my IT suppliers?

Divide them into three tiers. Tier A: administrative access to critical systems (ERP, MES, firewall). Tier B: access to data without the privilege to stop production (BI, payroll). Tier C: no access to critical systems (consumables, hardware). The depth of the audit scales with the tier — do not spend the same effort on all of them.

What is the most common mistake in supplier audits?

Auditing the wrong company. Energy is spent demanding ISO 27001 from the large cloud supplier — who already has it — and the small local integrator with permanent remote access to the ERP using a shared password is ignored. Risk lives in the smallest link, not the biggest.

What should I record in the supplier inventory?

Record five attributes per supplier: type of service, data it accesses, privilege level (read/write/administrative), access mode (VPN, RDP, agent, API) and criticality to production. Be honest about the access mode — "VPN" is not sufficient; differentiate between permanent site-to-site, on-demand user, or unsupervised permanent access.

I am a small SME — does NIS2 apply to me?

Many small factories are not directly within scope. But if you subcontract to multinationals (Inditex, Decathlon, Lacoste) or distributors, you are in the supply chain of those who are. Article 21 pushes the obligation down. You will receive security questionnaires — being prepared is no longer optional.

How should I structure the audit process?

Design a pipeline in four layers: inventory and classification, documentary due diligence, technical verification and continuous monitoring. Order matters — you do not do due diligence before classifying, because you do not know who to require what from. Each layer produces a fileable artefact: inventory, dossier, report, alerts.

What is the difference between a one-off audit and a defensible process?

A one-off audit is a reaction — someone got a fright, certificates are requested, PDFs are filed, the matter is closed. Six months later, no one remembers the dossier. NIS2 requires this to be turned into a recurring, auditable process that can be defended before the competent authority, with evidence and traceability.