At a garment factory near Famalicão, at 23:40 on the last working day of the month, the server running the ERP has been at 100% CPU for forty minutes. The administrative manager wants to close invoicing to report the SAF-T. The picking terminal in the warehouse has stopped responding. And the only person who knows how to restart the machine — the "IT guy" who also looks after the printers and the canteen Wi-Fi — is on holiday in the Algarve, with his phone on silent. This scene repeats itself in hundreds of factories across the North every month.

The thesis of this guide is simple and uncomfortable: most Portuguese industrial SMEs do not have a software problem — they have an infrastructure problem that the software will amplify. A new, modern ERP is bought to run on a foundation from 2011: a server with no redundancy, a backup that nobody has tested, a network that goes down when the second production line comes online. The ERP does not fail. It is the base beneath it that was never designed to hold up.

Let us go through the subject without brochure euphemisms. What infrastructure is, where it gives way first, what silence costs, what models exist and how to decide by company size. And, above all, what to do over the next ninety days without stopping production or spending the entire budget at once.

1. The real operational problem

Industrial IT infrastructure is not an abstract topic for the systems department. It is the difference between shipping an Inditex order on the scheduled hour or paying a late-delivery penalty. It is the dye house in the Vale do Ave that needs to trace the dyeing lot to respond to a sustainability audit from the client brand — and discovers that the data is scattered across three Excel spreadsheets and the foreman's memory.

Anyone who spends time inside these factories learns one thing quickly: the problem almost never presents itself as "the infrastructure is bad". It presents itself as scattered symptoms that nobody connects. The ERP is slow. The terminals fail. The backup takes ages. Sales cannot see stock in real time. Each symptom is treated in isolation, often with a quick fix, until one day they all arrive at once — and it is always at the worst possible moment.

Where it hurts first: the month-end close

The accounting close and the monthly SAF-T reporting are the involuntary stress test of any infrastructure. When the ERP drags because storage is a mechanical disk shared with the file server, when the nightly backup runs at the same time as invoicing, when the network saturates because the production line and administration share the same segment — that is where the fragility shows. Not on a normal day. On the worst possible day.

What makes the month-end close worse in industry is that it is not only accounting. In a subcontracted garment operation, the close intersects with the calculation of the month's production — how many pieces came out of each operation, how long each phase took, which subcontractors were invoiced. If production capture runs on the same machine as accounting and both compete for the same disk at the same hour, the outcome is predictable. The system does not fail because it is badly written. It fails because it was set to do two heavy things at once on a foundation sized for one.

There is a detail that many managers are unaware of: the slowness of the close is rarely a CPU problem. It is an I/O problem — of reading from and writing to disk. A server with a modern processor and a 2015 mechanical disk will drag in exactly the same way. Swapping storage from mechanical disk to SSD or NVMe is, very often, the intervention with the greatest impact per euro invested. It is not glamorous. But it turns a two-hour close into a twenty-minute close.

The footwear calendar does not forgive

In Felgueiras, a sample collection has between 800 and 1,200 SKUs, crossed on three axes — colour, size and last. International buyers visit twice a year (menswear in August, womenswear in February). If the sample management system and the article database are running on infrastructure that does not scale, the peak of work preceding those visits turns into a marathon of overtime and picking errors. APICCAPS has documented the complexity of the Portuguese product for years — it is that complexity the infrastructure has to support without cracking.

The SKU maths is relentless. A base sample in fifteen colours, eight sizes and three widths generates 360 combinations from a single reference. Multiply by a few hundred models and you have an article database with tens of thousands of active lines for just one collection. A generalist ERP models this as though they were independent products — and drowns. A vertical footwear ERP manages the colour-size-last matrix as a native structure, but it still needs a database that responds in milliseconds when the salesperson opens the article record with the German buyer sitting in front of him.

Seasonality counts even more in this industry. In the weeks before August and February, work concentrates to such a degree that the infrastructure goes through two or three months of normal usage compressed into fifteen days. Whoever sizes the machine for the average annual load discovers, precisely in those weeks, that the average lies. Infrastructure is designed for the peak, not for the average — and in footwear the peak is known a year in advance. There is no excuse for being caught by surprise.

Textiles and the traceability the brand demands

In the textiles of the Vale do Ave — Famalicão, Guimarães, Barcelos, Vizela — the pressure has changed in nature. It is no longer just price and deadline. Client brands, aligned with the EU Strategy for Sustainable and Circular Textiles, are beginning to demand lot traceability: which yarn this knit came from, in which bath it was dyed, with which dyes, with what water and energy consumption. This is not a marketing requirement. It is a data requirement that the infrastructure has to sustain.

A finishing plant that cannot associate each shipped roll with the dyeing lot and its respective process conditions is competing with one hand tied behind its back. Traceability requires data capture at the moment the process happens — in finishing, in printing, in garment-making — and a system that stores it in an intact and recoverable way for years. When the audit arrives, the answer has to be on a screen, not in the head of the foreman who has since retired.

The warehouse manager and the radio

There is an operational truth that software vendors rarely admit: the warehouse manager of a distribution centre in the Lousada/Paços de Ferreira corridor will fight any rollout that takes him off the radio for more than two hours. And he is right. A poorly planned infrastructure upgrade — one that forces the WMS to be stopped during shipping hours — costs more in delayed orders than the entire modernisation project saves in a year.

This is the point where many infrastructure projects derail: they are designed by someone who looks at the network diagram and ignores the operations diagram. The maintenance window is not a technical variable — it is a business variable. In a food distribution operation shipping from 06:00 to 14:00, the real intervention window may be from 15:00 to 05:00, and even then there are night-time replenishments. Whoever plans a migration without mapping the shipping calendar is planning a conflict. The good news is that virtualisation and replication now allow systems to be migrated with downtimes of minutes, not hours — provided the project is designed with that restriction from the outset.

Infrastructure does not fail when everything is calm. It fails at the month-end close, on the eve of the buyers' visit, at the Friday shipping peak. Design it for the worst day, not for the average day.

2. What exactly is IT infrastructure for industrial companies in Portugal

IT infrastructure is the set of physical and logical resources that sustain the business applications: servers, storage, network, virtualisation, operating systems, backup, cybersecurity and the support services that keep all of this standing. In an industrial context, there is an added layer that the office does not have: the shop-floor terminals, the barcode readers, the scales connected to the ERP, the machine sensors, the picking PDAs.

The distinction between office infrastructure and industrial infrastructure is deeper than it seems. An office tolerates the system being slow for five minutes — people wait, have a coffee, come back. A production line with time capture does not tolerate it. If the terminal does not record the operation at the moment it happens, either the operator stops and waits (production is lost) or carries on and the record is lost (traceability is lost). Industrial infrastructure lives under the tyranny of real time in a way the back office does not know.

The seven layers that matter

A factory does not need to know every layer of an enterprise datacentre. It needs to master seven decisions:

  • Compute — where the ERP and applications run: physical server, virtualised cluster, private or public cloud.
  • Storage — the difference between a mechanical disk and SSD/NVMe is the difference between a two-hour month-end close or a twenty-minute one.
  • Network — the backbone that links office, production and warehouse; the most underestimated single point of failure.
  • Continuity — backup, replication and the recovery plan that almost nobody tests until they need it.
  • Security — perimeter, segmentation, identity management and ransomware protection.
  • Shop floor — the operational layer (terminals, industrial IoT, production capture) that distinguishes industrial infrastructure from office infrastructure.
  • Support and governance — who maintains this, with what SLA, with what documentation.

Each layer has its typical breaking point. In compute, it is the lack of redundancy — a single server that, when it dies, takes everything with it. In storage, it is the slow disk and the space that runs out without warning. In the network, it is the €100 switch bought ten years ago that aggregates critical traffic. In continuity, it is the backup that runs but was never restored. In security, it is remote access without multi-factor authentication. On the shop floor, it is the Wi-Fi that does not reach the back of the warehouse. In support, it is dependence on a single person. Knowing these points is half the way to fixing them.

A brief history of the server in the basement

For two decades, the Portuguese industrial SME ran everything on a physical server in the basement or in a poorly ventilated room next to accounting. It worked — until it stopped working. Virtualisation (VMware, Hyper-V, Proxmox) came along to allow several machines to be consolidated onto a single piece of hardware and to recover more quickly from failures. The cloud came next, but it did not replace everything: the factory has latencies, local integrations and connections to physical equipment that do not always sit well with a datacentre 1,500 km away. The model that won out in Portuguese industry is the hybrid — and we explain why in section 4.

It is worth understanding what virtualisation really changed, because many factories still run systems as though we were in 2008. Before, each application required its own physical server: one for the ERP, one for email, one for files, one for the database. Four machines, four points of failure, four power supplies consuming energy. With virtualisation, those four machines become four virtual machines inside one or two redundant physical hosts. If a host fails, the virtual machines start up on the other in minutes. It is the difference between a day stopped waiting for parts and an interruption nobody even notices.

The cloud added a second revolution: the ability not to own the hardware at all. But industry has learned, at its own cost, that not everything should go up to the cloud. A production capture system that talks to shop-floor terminals gains nothing from running in a distant datacentre — on the contrary, it gains latency and dependence on the fibre. What the cloud gains you is backup, disaster recovery, and office applications that everyone accesses from anywhere. Hence the hybrid: each workload where it makes sense.

Terms you will find in any proposal

RTO (Recovery Time Objective) and RPO (Recovery Point Objective) — how long the operation can be stopped and how much data it can lose. SLA — the vendor's availability and response commitment. High availability — architecture with no single point of failure. These three concepts decide more projects than any hardware brand. If a vendor does not talk about RTO/RPO in the very first meeting, they are selling you boxes, not continuity.

It is worth translating these acronyms into factory language, because that is where they gain weight. RTO is the answer to the question: "if the server dies at 09:00 on Monday, what time do we go back to invoicing and shipping?". RPO is the answer to: "when we recover, from what moment is the data — from last night, from an hour ago, from five minutes ago?". A factory that backs up once a day has, at best, an RPO of 24 hours: in the event of disaster, it loses an entire day of production records, orders and invoices. For many operations, that is unacceptable — and the solution (more frequent replication) exists and is not expensive.

ConceptQuestion it answersTypical "bad" valueTypical "good" value
RTOHow long stopped until recovery?Several days (waiting for hardware)Minutes to a few hours
RPOHow much data do we lose?24h (single daily backup)Minutes (continuous replication)
SLAWhat availability and response does the vendor guarantee?"Best efforts", no contractContracted availability and response times
High availabilityWhat happens if a component fails?Everything stops (single point of failure)Continues on another node, no stoppage

3. The landscape in Portugal today

Portugal has a dense industrial fabric in the North and Centre — textiles and clothing in the Vale do Ave, footwear in Felgueiras and S. João da Madeira, moulds in Marinha Grande, ceramics in Aveiro. It is a fabric of family SMEs, many with tight margins and a critical dependence on systems that were rarely designed for the current scale.

This profile has a direct consequence on how infrastructure decisions are made. The decisions concentrate in a trio: CEO, CFO and the IT lead. The CEO thinks about growth and business continuity. The CFO thinks about CAPEX versus OPEX and cost predictability. And the IT lead — often a self-taught person with fifteen years of deep business knowledge and no formal training — thinks about not being woken at 3 a.m. Any infrastructure proposal that does not speak these three languages at the same time dies in the meeting room.

The threat is no longer hypothetical

In 2024, CERT.PT recorded 2,758 cybersecurity incidents in Portugal, a 36% increase over 2023, and around 78% occurred in private entities (Source: CNCS, 2024). It is not a problem of "big Lisbon companies". Verizon's 2025 DBIR report is even clearer about who gets hit: in small and medium-sized enterprises, ransomware was present in 88% of the breaches analysed, against 39% in large organisations. The industrial SME is the disproportionate target — precisely because it has valuable data and weak defences.

The reason SMEs are a preferred target is no mystery at all. Attackers do not hand-pick — they automate. They sweep the internet looking for exposed systems, open remote access ports, unpatched servers. An industrial SME with a remote access server without multi-factor authentication is exactly the kind of door the automated sweeps find every day. And unlike a large company with a dedicated security team, the SME often only discovers the intrusion when the files are already encrypted and the ransom demand appears on the screen.

The cost of doing nothing

IBM's 2024 report set the global average cost of a data breach at a record USD 4.88 million, 10% more than in 2023. For a Portuguese SME that number seems to be from another planet — but the relevant maths is not the global average cost. It is the cost of being five days without invoicing, without shipping, without responding to customers who are already threatening to switch supplier. A garment operation subcontracted to an international parent company that does not ship on time does not lose an order: it loses the relationship.

Do the maths at your own scale. A factory that invoices, say, a certain amount per working day, and that is stopped for five days, loses five times that amount in revenue — but that is the least of it. It loses the contractual deadlines with brands that have penalty clauses. It loses the trust of a buyer who now has to explain to their own supply chain why the Portuguese order did not arrive. And it earns a reputation as a risky supplier that takes years to erase. The ransomware that encrypts the server does not destroy only data. It destroys the competitive position the factory built over decades.

The question is not "will we be attacked?". It is "when we are, how long are we stopped and how much of it can we recover?". If you do not know the answer in hours and in number of days of data, you do not have infrastructure — you have luck.

The scarcity of those who know how to do this

There is a structural problem behind all of this: the global deficit of cybersecurity professionals reached around 4.76 million people in 2024, 19% more than in 2023 (Source: ISC2, 2024). Translated to the Portuguese ground: the industrial SME cannot hire or retain a senior systems engineer while competing with salaries from Lisbon or abroad. That is why the factory's "IT guy" accumulates functions that should belong to three people — and why the partner-managed infrastructure model makes increasing sense for those with fewer than 100 employees.

The problem is worsened by geography. A systems engineer with ten years of experience now has, a click away, remote offers from foreign companies paying in euros of another order of magnitude. The factory in Felgueiras or Barcelos competes not with the neighbour, but with the entire European market. Retaining that talent internally is expensive and fragile — if the person leaves, all the knowledge leaves with them. Outsourcing the competence to a partner who spreads it across several clients is, for many SMEs, the only economically viable way to have access to senior competence without paying for it full-time.

The funding exists — but it has its own rhythm

Portugal has funding instruments that cover part of these investments: PRR, PT2030, COMPETE 2030 and Norte 2030 have lines for digitalisation and digital transition of SMEs. In practice, what is approved most easily are projects with clear and measurable objectives — modernisation of production systems, cybersecurity, digitalisation of processes. What gets stuck are vague applications, poorly grounded in the technical reports, or that do not demonstrate the operational impact of the investment.

The lesson from those who have been through several application cycles is simple: the funding should not drive the technical decision. The technical decision should drive the application. Designing an architecture just because a call is open is the fastest way to end up with underused hardware the factory did not need. First decide what the operation requires. Then look for the instrument that funds that decision. Never the other way round.

4. The implementation models

There are four models that a Portuguese industrial SME really considers. They are not religions. They are trade-offs of cost, control, risk and available competences.

Traditional on-premise

Everything runs on the company's own servers, on its premises. Maximum control, minimal latency to the production equipment, and the monthly bill is predictable. In exchange: the capital invested in hardware is tied up, redundancy is expensive (everything has to be bought twice over) and the responsibility to maintain, update and protect it is internal. It makes sense for factories with a strong dependence on local integrations and a capable technical team.

On-premise carries a hidden cost that rarely enters the initial reckoning: the hardware lifecycle. A server has a useful life of five to seven years. At the end of that time, the manufacturer's support ends, parts become expensive and scarce, and the risk of failure shoots up. Many factories today run critical systems on hardware that has already passed that boundary — not because they decided to, but because "it's working" and nobody wanted to touch it. It works until the day it does not, and on that day it turns out there is no replacement part and the new machine takes weeks to arrive and configure.

Public cloud

Servers rented from a hyperscaler (Azure, AWS, Google). Instant scale, no initial investment in hardware, redundancy included in the service. The trade-offs: the bill grows with consumption and can surprise you, latency to shop-floor equipment can be a problem, and dependence on the internet connection becomes critical. A fibre cut in the industrial zone leaves the factory without an ERP.

The bill surprise is a real and underestimated risk. The public cloud charges per consumption — compute, storage, outbound data traffic. A poorly sized migration, or an application that generates a lot of traffic, can turn an estimated bill into something much heavier. And dependence on the internet is the Achilles heel in an industrial context: many industrial zones in the North have no fibre redundancy, and an excavator that cuts the cable on the road leaves the entire factory without access to its own systems. Whoever chooses public cloud for critical workloads needs a second internet connection, from a different operator, and that rarely enters the initial calculation.

Private cloud / managed datacentre

The infrastructure runs in a partner's datacentre, dedicated to the company, with a contracted SLA. It combines the predictability of on-premise with the resilience of a professional datacentre (redundant power, cooling, physical security, multiple connections). It is the model that solves the problem of the small internal team — the competence is on the vendor's side.

What a professional datacentre offers and a factory's technical room almost never has: power with a generator and UPS that ride out a mains failure without an interruption, cooling sized to run 24 hours a day without overheating, fire detection and suppression, physical access control, and multiple internet connections from different operators. Replicating this in a factory would cost a fortune and require continuous maintenance. Renting the space and the SLA in a datacentre — such as the one INFOS operates — spreads that cost across many clients and makes it accessible to an SME.

Hybrid

What most Portuguese factories end up adopting: critical low-latency systems stay close to production, backup and disaster recovery go to the cloud or datacentre, and office applications move as makes sense. It is pragmatic and it is defensible.

A well-designed hybrid solves the central dilemma of industrial infrastructure: the systems that talk to the shop floor need to be close, and the systems that guarantee continuity need to be far away. The production capture of KORA Productivity runs locally, next to the terminals, with minimal latency. The backup copy of that data replicates to a distant datacentre, protected from a fire or flood on the premises. The office applications and the B2B portal that customers access can live in the cloud, always available. Each piece in its optimal place.

CriterionOn-premisePublic cloudPrivate / managed cloudHybrid
Initial investmentHigh (CAPEX)Low (OPEX)Low/medium (OPEX)Medium
Latency to shop floorMinimalVariable / riskGoodOptimisable
Resilience / redundancyExpensive to obtainIncludedIncluded (SLA)Good
Dependence on internal teamHighMediumLowMedium
Cost predictabilityHighLow (consumption)HighMedium
Risk on internet outageLowCriticalMediumMitigable

There is no right model in the abstract. There is the right model for your production latency, your internal team and your tolerance for being stopped. Whoever sells you "cloud always" or "on-premise always" is selling you their own convenience.

5. How to assess whether your company needs to intervene

Intervention on infrastructure rarely begins from conviction. It begins from a scare — a server that died, an attack that got through, a month-end close that did not close. The goal is to decide before the scare. This diagnosis gives you the basis.

Signs that the foundation is giving way

  • The ERP becomes predictably slow at the same moments (the close, shipping peaks, mass entry of orders).
  • The backup exists but nobody remembers the last time it was successfully restored in a test.
  • Only one person knows how to restart the systems and that person takes holidays like everyone else.
  • The production network and the office network are the same, with no segmentation.
  • The shop-floor terminals run on a Wi-Fi that drops when the second line comes online.
  • You cannot say, in hours, how long it would take to restore the operation after a total failure.
  • The hardware of the critical servers has already passed five years and has no active support contract.
  • There are applications running on operating systems out of manufacturer support.

If you ticked three or more of these points, you do not have an "if" question — you have a "when" question. Each of these signs is, on its own, a manageable risk. Together, they make up an infrastructure that is asking to fail at the worst moment. The good news is that almost all of them have a relatively quick and cheap fix — the hard part is deciding to look before the problem decides for you.

Step by step of the infrastructure diagnosis

  1. Inventory what you have. List all the servers, the age of the hardware, the operating systems and the versions. A Windows Server out of support is an open door and a compliance risk. This survey takes two days and almost always reveals an unpleasant surprise.
  2. Measure the real RTO and RPO. Ask the question seriously: if the main server dies now, how many hours until we are invoicing again, and how many hours of data do we lose? If nobody knows, you have identified your first problem.
  3. Test the backup for real. Do not trust the software's green report. Restore a file, a database, a virtual machine in an isolated environment. A backup that was never restored is a hypothesis, not a guarantee.
  4. Map the single points of failure. Walk the chain: if this switch, this server, this connection goes down — what stops? Mark each point where a single failure interrupts the operation. Those are your priority targets.
  5. Assess segmentation and access. Does production talk to accounting on the same network? How many people have administrator access? Is there multi-factor authentication on remote access? Each wrong answer is a quick fix with high impact.
  6. Cross-reference with the business calendar. Overlay the risks onto the real calendar — month-end close, buyer visits, campaigns. A vulnerability that coincides with the annual peak is worth ten that fall in the dead season.

This exercise does not need an external consultant to start. It needs two afternoons and honesty. When you want to go deeper, systems engineering aligned to strategy is the logical next step.

Translating the diagnosis into priorities

The diagnosis produces a list of problems. The hard part is ordering them. The rule that works on the ground: prioritise first by the crossing of probability of failure with impact on the operation. A backup that was never tested has a high probability of failing when needed and maximum impact — it goes to the top. An old switch at a secondary point of the network can wait. This simple matrix avoids the classic mistake of spending the budget on the most visible problem instead of the most dangerous one.

Typical problemProbability of failureImpact on operationPriority
Backup never restoredHighMaximumImmediate
Remote access without MFAHighHighImmediate
Single server without redundancyMediumMaximumHigh
Non-segmented networkMediumHighHigh
Hardware out of supportMediumHighMedium
Weak Wi-Fi in the warehouseHighMediumMedium

6. What to choose and why — decision by company size

The company's size and the complexity of the operation decide almost everything. It is not the sector — it is the number of employees, the number of critical systems and the existence (or not) of an internal technical team.

Up to 50 employees

They rarely have a dedicated systems team. The "IT guy" accumulates functions. Here, the managed datacentre or private cloud with SLA model solves the structural problem: the competence you cannot hire, you rent from the partner. The most common mistake at this scale is buying an expensive server and leaving it without a support contract — when it fails, you discover that nobody has a contractual responsibility to restore it.

At this scale, the absolute priority is continuity with contracted responsibility. It does not matter how many features the system has if, when it stops, there is nobody obliged to restore it within a defined timeframe. The question to ask any vendor is direct: "if this dies on a Friday afternoon, who answers and in how long?". If the answer is "we'll see what can be done", look for another vendor. A factory with fewer than 50 people does not survive days stopped waiting for goodwill.

50 to 150 employees

They already have one or two internal technicians — usually self-taught heroes with fifteen years of business knowledge and zero formal training. These people are the company's most undervalued asset and its biggest single point of failure. The hybrid model makes sense: the internal technician manages the day-to-day and the operation; the external partner guarantees continuity, security and architecture. The right relationship between the two is where projects live or die.

The mistake in this band is treating the internal technician and the external partner as competitors. They are not. The internal technician knows the business in a way no external partner ever will — knows that the dyeing line cannot stop on Thursdays because that is when the big lot comes in, knows that salesperson X needs the report on Mondays. The external partner brings the architecture, security and continuity competence the factory cannot hire full-time. Together, they cover what neither covers alone. Separating them or setting them to compete is wasting both. It is also at this size that it makes sense to consolidate management information in a BI such as Qlik Sense, so that decisions no longer depend on manual reports.

Above 150 employees

Complexity that justifies formal architecture, separate development/test/production environments, and possibly a larger-scale low-code ERP such as QAD Adaptive ERP when the processes are very specific. At this size, infrastructure ceases to be support and becomes a competitive advantage — or a drag.

Above 150 employees, accumulated technical debt becomes the main enemy. Years of one-off decisions — a server here, an integration there, a legacy system nobody wanted to replace — make up a web that is difficult to manage and even harder to protect. At this scale, the value of a formal architecture, with separate development, test and production environments, ceases to be a luxury and becomes a condition of sanity. Testing a change directly in production, as is done in small factories, becomes an unacceptable risk when five thousand users depend on the system.

SizeRecommended modelPriority no. 1Biggest risk
<50 employeesManaged datacentre / private cloudContinuity and contractual supportDependence on one person
50–150 employeesHybridSecurity and segmentationIrreplaceable internal hero
>150 employeesHybrid with formal architectureScalability and governanceAccumulated technical debt

Regardless of size, the decision benefits from a solution architecture designed before buying hardware. Buying boxes before designing the architecture is the most expensive way to get it wrong.

The company's size does not decide whether it needs good infrastructure — it decides who should manage it. A 40-person factory needs the same resilience as a 400-person one; it just cannot pay for an internal team to guarantee it.

7. Regulatory framework and applicable compliance

Infrastructure in Portugal does not live in a legal vacuum. There are obligations that decide part of the technical choices — and ignoring them costs fines and, worse, credibility with customers who audit suppliers.

Invoicing and reporting to the AT

DL 28/2019 and Ordinance 195/2020 set the rules for electronic invoicing, ATCUD and monthly SAF-T reporting. In practice, this requires software certified by the Tax Authority and infrastructure that guarantees the integrity and availability of the tax data. A server that loses the database on the 30th is not just an IT problem — it is a tax non-compliance.

The infrastructure dimension of this obligation is frequently ignored. Software certification is a necessary condition, but not a sufficient one. What use is certified software if the database storing the tax documents has no intact and recoverable backup? The AT requires that the records exist, are complete and can be reported. A data loss that prevents the timely reporting of the SAF-T is a tax problem, with the consequences that entails. Tax compliance, at bottom, is also a requirement of infrastructure continuity.

NIS2 — the change many still ignore

The NIS2 Directive (Directive (EU) 2022/2555), transposed in Portugal by Decree-Law No. 65/2025, extends cybersecurity obligations to medium and large companies in 18 critical sectors, including industry. For many industrial SMEs that never considered themselves "critical infrastructure", this changes the game: they now have to manage security risks, notify incidents and hold top management accountable. Compliance with NIS2 begins exactly with the infrastructure diagnosis we described in section 5.

One point of NIS2 that catches many managers by surprise: responsibility falls on top management, not on the IT department. The CEO and the board can be directly held accountable for the lack of cybersecurity risk management measures. This takes security out of the "IT guy's" corner and places it in the boardroom. And there is a second, equally important point: NIS2 extends the obligations to the supply chain. A covered company has to assess the security of its suppliers — which means that, even if your factory is not directly covered, you may come to have to demonstrate security in order to continue supplying a customer who is.

GDPR, ISO 27001 and the supply chain

The GDPR and Law 58/2019 impose the protection of personal data — and a factory manages data of workers, customers and suppliers. The international brands that subcontract garment-making and footwear increasingly audit suppliers on information security. Having (or working with a partner who has) ISO 27001 certification and GDPR compliance has ceased to be a luxury and become a condition of access to certain customers.

The management of worker data deserves special attention in industry, where attendance, shift and payroll systems concentrate sensitive personal data of dozens or hundreds of people. A people management solution such as pplPortal has to handle that data in compliance with the GDPR from the architecture stage — not as a later patch. And when those solutions incorporate predictive AI for turnover or absenteeism, one more regulatory layer comes into play that is best anticipated.

Regulatory compliance seems like a cost until the day an international customer asks for the security report of your IT supplier. On that day, it is the difference between keeping the contract or losing it.

eIDAS, qualified signature and AI

The eIDAS regulation underpins the qualified digital signature, increasingly used in contracts and official documents — and integrable into document management workflows. And for those beginning to use artificial intelligence in the operation, the AI Act (EU Regulation 2024/1689) introduces a risk classification that is best documented early. What to record before the AI Act tightens is described in our guide on AI governance in industrial SMEs.

Law 93/2021 — the whistleblowing channel the infrastructure has to support

Companies with 50 or more employees are required, by Law 93/2021, to have an internal whistleblowing channel that guarantees the confidentiality of the whistleblower. This has an infrastructure dimension that goes unnoticed: the channel has to be secure, the data has to be protected, and access has to be controlled and logged. A poorly implemented solution, on a shared system without access segmentation, violates precisely the confidentiality the law requires it to guarantee. Once again, the legal obligation translates into a concrete technical requirement.

ObligationLegal basisInfrastructure requirement it imposes
Invoicing and SAF-TDL 28/2019, Ordinance 195/2020Certified software + integrity and availability of tax data
CybersecurityNIS2, DL 65/2025Risk management, incident notification, supply chain security
Data protectionGDPR, Law 58/2019Security and access control for personal data
Whistleblowing channelLaw 93/2021Confidential system and controlled access (≥50 employees)
Digital signatureeIDASQualified signature integrable into document workflow
Use of AIEU Regulation 2024/1689Risk classification and documentation of AI systems

8. How INFOS approaches this

We have worked for more than three decades inside Portuguese factories — textiles, clothing, footwear, distribution, retail, metal and plastic. That teaches one thing generalist vendors do not have: industrial infrastructure cannot be separated from the applications it runs. A vertical MULTI ERP and the real-time production capture of KORA Productivity impose concrete requirements of latency, availability and integration with shop-floor equipment. Designing the infrastructure without knowing these applications is designing blind.

Our approach starts from the business, not from the hardware. First we understand the operational calendar — when the peak is, when the close is, when the buyers arrive. Then we design the architecture that holds up on the worst day, with managed datacentre, cybersecurity and continuity options that adjust to the company's size and internal team. And we connect the decision layer through

Frequently asked questions

What is industrial IT infrastructure?

Industrial IT infrastructure is the set of servers, storage, network and systems that support a factory's operations. It is not an abstract topic — it is the difference between shipping an order on the scheduled hour or paying a late-delivery penalty. It includes everything from the server running the ERP to the network that links the picking terminals.

Why is the month-end close so critical for infrastructure?

The accounting close and SAF-T reporting are an involuntary stress test. When the ERP, nightly backup and invoicing run simultaneously, fragile infrastructure collapses. In industry, the close also intersects with production calculation — how many pieces came out, how long each phase took. Everything competes for the same disk at the same hour.

What is the real cause of slowness at the month-end close?

It is rarely a CPU problem. It is an I/O problem — reading from and writing to disk. A server with a modern processor and a 2015 mechanical disk drags in the same way. Swapping storage to SSD or NVMe is often the intervention with the greatest impact per euro invested, turning a two-hour close into a twenty-minute one.

How does the footwear industry cope with demand peaks?

A sample collection has between 800 and 1,200 SKUs crossed by colour, size and last. Buyers visit twice a year (August and February). The infrastructure goes through two or three months of usage compressed into fifteen days. It is designed for the peak, not for the average — and in footwear the peak is known a year in advance.

What do international brands demand in terms of traceability?

Client brands are beginning to demand lot traceability: which yarn the knit came from, in which bath it was dyed, with which dyes, water and energy consumption. This is not a marketing requirement — it is a data requirement that the infrastructure has to sustain. The pressure has changed in nature: it is no longer just price and deadline.

How does a deficient infrastructure problem manifest itself?

Rarely as "the infrastructure is bad". It presents itself as scattered symptoms: slow ERP, terminals that fail, delayed backup, stock not visible in real time. Each symptom is treated in isolation with quick fixes, until one day they all arrive at once — always at the worst possible moment.

What is the most common mistake when implementing an ERP?

A new, modern ERP is bought to run on a foundation from 2011: a server with no redundancy, an untested backup, a network that goes down when the second production line comes online. The ERP does not fail. It is the base beneath it that was never designed to hold up. The problem is not software — it is infrastructure that the software will amplify.

Sources

  • Decree-Law No. 133/2020, of 25 December — Regime for the Communication of Invoicing Data (SAF-T PT)
  • Directive (EU) 2022/2555 (NIS2) — Security of Network and Information Systems
  • ISO/IEC 27001:2022 Standard — Information Security Management Systems
  • EU Strategy for Sustainable and Circular Textiles — European Commission, 2022
  • APICCAPS — Portuguese Association of Footwear, Components and Raw Materials Manufacturers