Secure and resilient IT infrastructure for businesses
A modern business IT infrastructure has to do more than simply work. It must keep services running when a component fails, limit the impact of an attack, protect data and allow a recovery you can actually verify. That is why servers, network, security, backup and cloud are designed together, as parts of a single system.
- Architecture and dependencies
- Security by design
- Backup and disaster recovery
- Proportionate resilience
- Performance
- resources sized for real workloads, not imagined ones
- Security
- identities, network and systems protected by design
- Continuity
- critical services stay available when a component fails
- Recoverability
- data and services can be restored, and you have verified it
- Scalability
- you grow by adding, not by rebuilding
- Manageability
- documented, monitored, upgradable
- Governance
- responsibilities, risks and decisions are clear
Seven properties of the same system: improving one at the expense of the others does not make the infrastructure stronger.
01 The starting point
The IT complexity of a small or mid-sized business has little to do with headcount
A company of twenty people can depend on IT more than one of two hundred. What matters is how much work stops when IT stops.
Today a small or medium-sized business runs on a management system or ERP, a database, Microsoft 365, often an e-commerce site or web applications, shared files, remote access and VPNs, perhaps several offices and cloud services from different vendors. Each of these has its own dependencies, and many are critical to the day's revenue.
That is why the right question is not "how many servers does a company like ours need", but "which services cannot stop, for how long, and with how much data loss". This is how a business IT infrastructure is sized: from the services, not from the org chart.
What really drives complexity
- Business dependence on IT
- Criticality of services
- Users and devices
- Workloads and applications
- Number of sites
- Data volume and growth
- Tolerance for data loss (RPO)
- Acceptable recovery time (RTO)
- Exposure to cyber risk
- Remote access and third parties
- Integrations between systems
- Regulatory and contractual obligations
- Dependencies on cloud services
02 From separate parts to one system
An IT infrastructure is not a list of products
The most common way to build the IT of a small business is by successive purchases: a server when needed, a firewall after an incident, a backup when someone asks for it. Each piece may be good. The whole rarely is.
Fragmented approach
- Servers
- Firewall
- Backup
- Antivirus
Bought and managed separately, often from different vendors. No one is accountable for how they behave together when something goes wrong.
System integration approach
- Business services
- Applications
- Identity
- Endpoints
- Network
- Security
- Compute
- Virtualization
- Storage
- Data
- Backup
- Disaster recovery
- Cloud
- Monitoring
- Processes
Designed as a single system: every component is chosen knowing what it depends on, what depends on it and what happens if it stops.
03 What an IT infrastructure is today
IT infrastructure does not mean "servers"
A business IT infrastructure is the set of layers that carry a service from the company's need all the way down to data that is saved and recoverable. Each layer supports the one above it.
- Businessthe processes and services the company must deliver
- Userspeople, roles, offices, remote work
- Identityaccounts, authentication, privileges
- EndpointsPCs, laptops, mobile devices
- NetworkLAN, Wi-Fi, site-to-site links, VPN
- Securityperimeter, segmentation, controls
- Compute and virtualizationphysical servers, hypervisors, virtual machines
- Storagedisks, NAS, SAN, where the data lives
- Applicationsmanagement system, ERP, email, e-commerce, databases
- Datathe one thing you cannot buy again if it is lost
- Backupseparate, recoverable copies of the data
- Disaster recoveryhow systems are brought back into service
Cutting across every layer
- Monitoring
- Logs
- Security
- Governance
- Management
04 Why you need a system integrator
Specialization is necessary, but no technology lives alone
The ten misconceptions we meet most often share the same root: a property that belongs to the system is attributed to a single component.
High-availability cluster≠recoverable data
A cluster keeps the service up if a node fails, but it does not protect the data: a deletion, a mistake or ransomware encryption acts on the only copy, or is replicated to the other nodes. Without separate backups, lost data stays lost.
Backup≠verified restore
A backup is only as good as its last successful restore. Until someone has tested it, it is an assumption.
Firewall≠protected identities
The firewall filters traffic, but it cannot tell whether someone logging in with valid credentials is who they claim to be. You need MFA and privilege management.
High availability≠disaster recovery
High availability covers the failure of a component at the same site. Disaster recovery covers the loss of the site, of the data or of the whole environment.
RAID≠backup
RAID tolerates the failure of one or more disks. It does not protect against deletions, logical corruption, ransomware or controller failure.
Snapshot≠backup
A snapshot usually lives on the same storage as the data: if the storage fails or is compromised, you lose both.
Replication≠backup
Replication copies changes, including the wrong ones. It becomes protection only if it keeps restore points over time, separate from production.
Cloud≠no responsibility
The cloud provider manages its own part. Configurations, identities, data and their backups remain largely the customer's responsibility.
Cybersecurity≠a product
Security is a set of controls over identity, network, systems, data and processes. A single product covers only part of it.
Compliance≠an installed technology
Regulatory obligations concern governance, processes and accountability. Technology supports their implementation; it does not replace it.
Often the problem is not a lack of technology. It is a lack of integration: good components that nobody designed to work together.
05 The role of IT consulting
Technology is chosen afterwards, not first
Consulting is the bridge between the needs of the business and the technical architecture. Its job is to define what is needed before deciding what to build it with.
From requirements to evolution
- Business requirements
- Assessment of the existing environment
- Asset inventory
- Dependency map
- Risk analysis
- Capacity and growth
- Security requirements
- Continuity requirements
- RPO and RTO per service
- Architecture
- Technology selection
- Integration
- Monitoring
- Evolution
When a project starts from the product ("we need a new server", "let's move to the cloud"), the architecture ends up adapting to that choice instead of the other way round. When it starts from requirements, the same decision can turn out right, wrong or simply premature, and you know it before you spend.
In the sequence above, technology selection comes at the eleventh step. Before it come the services to protect, the dependencies between systems, the risks, the expected growth and the downtime the business can sustain. This information tells you whether you need two servers or a cluster, a local backup or an off-site copy as well, a new firewall or a better-segmented network.
This is the work we do in IT consulting and IT infrastructure design: this page explains the overall picture, while the dedicated pages go into the services in detail.
06 The components of the infrastructure
Twelve components, one architecture
For each component: what it does, what it depends on and which risk it manages. This view shows why none of them can be designed on its own.
Compute
- Function
- Provides CPU and memory to services.
- Depends on
- Power, cooling, storage, network.
- Risk it manages
- Slowdowns and outages caused by insufficient resources or faulty hardware.
Virtualization
- Function
- Separates services into virtual machines and makes them movable.
- Depends on
- Compute, storage (shared or replicated), management network.
- Risk it manages
- A failure or an update that takes several services down together.
Network
- Function
- Connects users, offices, servers and external services.
- Depends on
- Devices, cabling, Internet links.
- Risk it manages
- Services that are intact but unreachable; the spread of an attack.
Identity
- Function
- Determines who can access what.
- Depends on
- Directory, MFA, onboarding and offboarding processes.
- Risk it manages
- Access with stolen credentials, excessive privileges.
Security
- Function
- Prevents, detects and contains attacks.
- Depends on
- Segmented network, identity, updates, logs.
- Risk it manages
- Compromise and lateral movement between systems.
Storage
- Function
- Holds data and virtual machine disks.
- Depends on
- Disks, controllers, storage network.
- Risk it manages
- Loss or slowness of data for every service that uses it.
Backup
- Function
- Keeps separate, recoverable copies.
- Depends on
- Separate storage, network, protected credentials.
- Risk it manages
- Permanent data loss after failures, errors or ransomware.
Disaster recovery
- Function
- Brings systems back into service after a serious event.
- Depends on
- Off-site backups or replicas, procedures, tests.
- Risk it manages
- Prolonged downtime after the loss of a site or of the environment.
Monitoring
- Function
- Makes the state of the system observable.
- Depends on
- Metrics, logs, thresholds, someone who receives the alerts.
- Risk it manages
- Problems discovered by users instead of by technicians.
Cloud
- Function
- Extends the infrastructure with external services.
- Depends on
- Connectivity, identity, contracts and configurations.
- Risk it manages
- Vendor dependence, ungoverned data and configurations.
Applications
- Function
- Deliver everyday work: management system, email, e-commerce.
- Depends on
- Every layer below.
- Risk it manages
- This is where users see the outage, whatever the cause.
Governance
- Function
- Assigns responsibilities, priorities and decisions.
- Depends on
- Documentation, inventory, processes.
- Risk it manages
- Improvised interventions, unseen risks, nobody deciding.
07 The dependency chain
A business service is a chain: it breaks at the weakest link
The user sees "the management system is down". Underneath there are at least ten levels, and the failure of just one is enough to stop the service even if all the others work.
- Business serviceissuing an order, invoicing
- Applicationthe management system
- Databasewhere the application writes
- Virtual machinethe system hosting the database
- Hypervisorthe server running the VMs
- Storagethe VM disks
- Networkswitches, VLANs, internal firewall
- Identity and securitywho can access, and from where
- Backup and DRhow you go back
- Monitoringwho notices, and when
Example scenario
The server is on, but the business is at a standstill
The shared storage reaches its space limit. The hypervisor is running, the virtual machines show as on, the network responds. But the database can no longer write, the management system throws errors and orders stop.
No component is "broken" in the classic sense. The problem is that nobody had linked data growth to storage capacity and to an alert that would fire before the blockage. It is an integration error, not a technology one.
Thinking like a system integrator means starting from the service and walking down the chain, asking for each link what can stop it, who notices and how it is restored.
08 Reference architecture
A conceptual example of a resilient architecture
It is not a model to copy: it is a diagram to show how the components connect. Every company builds a version proportionate to its own services and risks.
Perimeter and segmentation
The firewall separates the company from the Internet, but it is internal segmentation that stops the compromise of one PC from reaching servers and backups.
Cluster and storage
Multiple nodes make it possible to move virtual machines during failures and maintenance. If the storage is shared (SAN or NAS) and is not itself redundant, it remains a single point of failure under all the nodes; with distributed or replicated storage, such as Ceph, the data sits on several nodes but you need a dedicated network and correct sizing. In no case does it replace backup.
Multi-tier backup
The local copy serves quick restores, the off-site copy covers the loss of the premises, and the isolated or immutable copy covers cases where an attacker also reaches the backups.
Disaster recovery
The DR environment can be a second site, a cloud infrastructure or a rebuild procedure: what matters is that it is documented, sized and tested.
09 Virtualization and Proxmox
Virtualization organizes workloads; it does not protect them on its own
It is the layer that makes a modern infrastructure manageable. For this very reason it must be designed together with storage, network and backup.
Virtualizing means running several logical servers on the same hardware, each isolated from the others. The benefit is not only consolidation: it is being able to treat a server as an object that you create, move, clone and restore.
- Consolidation. Less physical hardware for the same number of services, with resources assigned according to real load.
- Isolation. Each role in its own virtual machine: the peak or failure of one service does not drag down the others.
- Provisioning. A new server is prepared in minutes from a template, not in days.
- Clusters and high availability. With multiple nodes and shared or replicated storage, VMs are automatically restarted on another node if one fails.
- Maintenance. With shared or replicated storage you update one node at a time by migrating VMs, normally without stopping services.
- Migration and growth. You add capacity or change hardware without reinstalling services.
Where we use Proxmox VE
Proxmox VE is an open source virtualization platform that we use in client projects when it fits the requirements, and on our own infrastructure: Hector Cluster, the infrastructure that runs TN Solutions' Hector services (Hector AI, Hector LIS, Hector Biz), is built on Linux environments virtualized with Proxmox behind a pfSense perimeter.
It is not always the right choice. Where VMware licenses are already in place, in-house skills are well established or applications have specific certification requirements, the evaluation may point elsewhere. The comparison should be made on cost, features, skills and migration path, not on the label.
10 Open source in business
Open source or proprietary: decide on the architecture, not on the label
Mature open source technologies have a concrete role in business infrastructures. Not because they are always better or always cheaper, but because in many cases they offer a good balance of control, interoperability and total cost.
Interoperability
Open standards and documented formats make integration with the rest of the infrastructure easier.
Control
Configuration and behavior can be inspected: you know what you are running.
Licensing
No usage license fee, but professional support is often subscription-based (for Proxmox VE, per CPU socket).
Vendor lock-in
Less dependence on the commercial choices of a single vendor, as long as data and procedures also remain portable.
Supportability
You need someone who can run it in production: in-house staff, a vendor or the community are not equivalent.
Skills
License savings turn into cost if the skills to configure and maintain it are missing.
Lifecycle
Versions, updates and end of support must be planned like for any product.
TCO
Total cost includes licenses, hardware, skills, maintenance, downtime and the exit from the platform.
Open source technologies we use and document
- Proxmox VEvirtualization and clustering
- Linuxservers and application services
- pfSensefirewall and segmentation
- HAProxyload balancing and TLS termination
- MariaDB and Galeradatabase and synchronous replication
- Redisin-memory cache and sessions
- Elasticsearchsearch engine
- Dockercontainerized application services
Technology should be chosen according to architecture, requirements and TCO, not the open source or proprietary label. In the same infrastructures we also use Windows Server, VMware, WatchGuard and Synology, when they are the best answer.
11 Applications and Microsoft 365
Applications are the last link, and they often live in the cloud
Email, documents, collaboration and identity increasingly run on Microsoft 365. That doesn't take them out of the infrastructure: it makes them part of it, with the same questions about security, recoverability and governance.
A Microsoft 365 tenant depends on user identities, on the devices people sign in from, on the network and on the domain's DNS records. In turn it carries the company's email, files and communication. It is a component of the architecture like any other, and it should be designed with the same criteria.
The typical mistakes are the ones described above: a tenant with no MFA on admin accounts, an email migration that forgets DNS and shared mailboxes, a file server copied into SharePoint with all its clutter, licenses chosen without knowing which controls are needed, data left to the recycle bin as if it were a backup.
- Exchange Online email and calendars: identity, DNS, security and migration are designed together.
- SharePoint, OneDrive and Teams content and collaboration: information architecture and permissions first, migration second.
- Entra ID and Intune identity, Conditional Access and devices: the new perimeter.
- Licensing the right plan depends on roles, devices and required security controls, not on price.
- Backup retention and the recycle bin are not an independent backup of tenant data.
12 Cybersecurity by design
Security and infrastructure are not designed separately
A flat network, a backup reachable with domain credentials or an exposed management panel cannot be fixed with one more product: they are architectural choices.
Segmentation
Separate networks for users, servers, management, guests and backup, with explicit rules between zones.
Firewall and VPN
Controlled perimeter and remote access only through encrypted, authenticated channels.
MFA
Multi-factor authentication at least for remote access, email and administrative accounts.
Least privilege
Each account has only the permissions it needs, and elevated privileges are kept separate from everyday use.
Hardening
Unneeded services switched off, secure configurations, management interfaces not reachable from untrusted networks.
Patch management
Planned updates for systems, firmware and applications, prioritizing actively exploited vulnerabilities.
EDR
Detection and response on endpoints and servers, where the risk justifies it.
Logging and monitoring
Events collected and retained to understand what happened and to notice it in time.
Vulnerability management
Periodic checks, from vulnerability assessment to penetration testing when needed.
Administrative access
Dedicated workstations and paths for management, backup credentials distinct from domain credentials.
Every control depends on the others: MFA protects identities, segmentation limits the damage if an identity is compromised anyway, logs make it possible to reconstruct what happened and isolated backups make it possible to restart.
13 NIS2 as an example
Why NIS2 talks about continuity and backup, not just security
The NIS2 Directive is a good example of how risk, security and continuity are now treated together.
Directive (EU) 2022/2555, transposed in Italy by Legislative Decree No. 138 of 4 September 2024, requires essential and important entities within its scope to adopt proportionate risk-management measures that go beyond technical protection (Article 21): they include business continuity, with backup management, disaster recovery and crisis management, incident handling, supply chain security and assessment of the effectiveness of the measures. Management bodies approve the measures and are accountable for them (Article 20).
Not all small and medium-sized businesses fall within the scope of NIS2: applicability depends on sector, size and other criteria set by the law, and must be checked case by case. But the list of measures is useful to anyone, because it describes the areas a resilient infrastructure must cover.
No technology makes a company compliant on its own. A well-designed infrastructure supports the implementation of the measures; compliance remains the responsibility of the organization, which builds it with processes, documentation and governance. We support our clients on the technical side.
Areas that NIS2 brings together
- Risk analysis and security policies
- Incident handling
- Business continuity, backup and disaster recovery
- Supply chain security
- Vulnerability management
- Access control and asset management
- Assessment of the effectiveness of measures
- Cryptography and multi-factor authentication
- Cyber hygiene, training and accountability of management bodies
Primary sources
Technical content for information purposes, not legal advice. To establish whether and how NIS2 applies to your organization, refer to the official sources and to a legal advisor.
14 Backup, disaster recovery and continuity
From saved data to restored service
Backup, disaster recovery and business continuity are three different levels of the same question: what happens, and how quickly do you restart, if something is lost.
- Productionthe data and services in use
- Backupcopies at defined intervals
- Separationon systems and credentials different from production
- Off-sitea copy far from the main site
- Isolation or immutabilitya copy that an attacker, even with compromised credentials, cannot delete or modify for the duration of the retention period
- Restore testingproof that the copies work
- Disaster recoverythe procedure to bring systems back into service
- Business continuityhow the company keeps working in the meantime
- RPO · Recovery Point Objective
- The maximum amount of data the company accepts to lose, expressed as time. With a single nightly backup, the RPO you can actually achieve is up to 24 hours: you go back to the previous night's data.
- RTO · Recovery Time Objective
- The maximum time within which a service must be available again after an interruption. It depends on where the copies are, how large they are and how ready the procedure is.
- Backup
- A copy of the data, separate from production, from which a previous state can be restored.
- Disaster recovery
- The set of infrastructure and procedures to bring systems back into service after an event that makes the main environment unusable.
- Business continuity
- The organization's ability to continue essential activities during and after a disruption, including IT but not only IT.
| Technology or process | What it protects | What it does not protect | Role in the architecture |
|---|---|---|---|
| RAID | The failure of one or more disks, depending on the level | Deletions, corruption, ransomware, controller or server failure | Storage availability |
| Snapshot | A quick return to a previous state, for example before an update | Failure or compromise of the storage it resides on | Operational tool, not an independent copy |
| Replication | Availability of an up-to-date copy on another system | Errors, deletions and encryption, which are replicated; it protects against these only if it keeps restore points separate from production | Lower RTO and a basis for high availability or DR |
| Backup | Recovery of data to a point in time | Service downtime during the restore; data loss after the last copy | Data recoverability |
| Off-site backup | Loss of the premises: fire, theft, flooding | An attack that also reaches the remote copy with the same credentials | Geographic protection |
| Immutable or isolated backup | Deletion or encryption of backups by an attacker | Data produced after the last copy; a backup already compromised at the source (encrypted data or dormant malware copied); a restore that was never tested | Last barrier against backup deletion |
| High availability | The failure of a component: node, power supply, link | Logical errors, ransomware, loss of the site | Service continuity, normally at the same site (stretched multi-site clusters are a separate case) |
| Disaster recovery | Loss of the main environment | A plan that was never tested; data after the last copy or replica (RPO); downtime during the restore | Restoring services within the defined RTO |
| Business continuity | Continuity of the company's essential activities | It does not replace any of the technical levels | Organizational framework that coordinates them |
A backup strategy has operational value only when restore is verifiable: that is why restore tests are a step of the architecture, not an optional activity.
15 Three levels of criticality
There is no single right infrastructure for every business
The scenarios below show how choices change as criticality grows. They do not depend on company size: a small business can sit at the third level, a large one at the first.
Standard services
A few hours of downtime is an inconvenience, not serious damage. Data changes little over the course of the day.
Business-critical services
The management system, production or sales stop when IT stops. Every hour of downtime and every piece of lost data has a measurable cost.
High criticality or specific requirements
Services that cannot stop, regulated data, strict contractual or regulatory obligations.
| Aspect | Standard services | Business-critical services | High criticality or specific requirements |
|---|---|---|---|
| Redundancy | Critical components made redundant (disks, power) | Redundant servers and network on critical services | Extended redundancy, including across sites |
| High availability | Usually not necessary | Clusters on critical services | Clusters and services designed for failover |
| Backup | Local and off-site | More frequent, with an isolated or immutable copy | Multiple tiers, defined retention, isolated copies |
| RPO / RTO | Defined, even if broad | Defined per service and verified | Tight, contractual and tested |
| Monitoring | Status of systems and backups | Metrics, thresholds and alerts with escalation | Continuous monitoring with on-call coverage |
| Security controls | Firewall, MFA, updates, antivirus or EDR | Segmentation, EDR, centralized logs | Extended controls, periodic checks and testing |
| Disaster recovery | Documented rebuild procedure | DR plan with a recovery environment | DR site or environment ready and tested |
| Testing | Spot-check restores | Scheduled restore tests | Periodic DR exercises |
| Documentation | Inventory and network diagram | Plus operating and recovery procedures | Plus roles, responsibilities and a test log |
| SLA | Standard response times | Guaranteed times on critical services | Tight SLAs and extended coverage |
Indicative values to show the logic, not universal requirements: RPO, RTO and SLA are defined service by service during the assessment.
16 What happens without integration
Nine problems that arise between one component and the next
None of these cases requires the wrong technology. The right technology put together without a plan is enough.
Virtualization without capacity planning
VMs are added one at a time until storage or memory saturate and slow down every service at once.
Backup without restore testing
On the day it is needed, you find the copies are incomplete, unreadable or take days to come back online.
Cybersecurity without an inventory
You cannot protect what you do not know you have: the forgotten server is the one without updates.
Firewall without segmentation
The perimeter holds, but once inside, an attacker reaches servers and backups from the user network.
Cloud without governance
Services activated by different departments, accounts without MFA, data outside any company backup.
High availability without disaster recovery
The cluster survives the failure of a node, but ransomware or a fire hits all the nodes together.
Monitoring without escalation
The alert fires, lands in a mailbox nobody reads, and a customer reports the problem.
Fast application on slow storage
The new management system is high-performing on paper, but the database and storage are still those of five years ago.
Unprotected privileged accounts
A single administrator credential, without MFA, also used for email: it is the key to everything.
Often the problem is not the absence of technology. It is the absence of integration.
17 The role of the system integrator
What a system integrator actually does
The value does not lie in knowing how to install one more product, but in designing and governing the way all the products work together.
- Understands the business service before the technology
- Identifies dependencies between systems, applications and vendors
- Spots single points of failure
- Assesses risk and turns it into priorities
- Defines security and continuity requirements, RPO and RTO
- Designs the architecture
- Selects technologies suited to the requirements
- Integrates the components and verifies how the whole works
- Considers security, recoverability, capacity and performance in the same project
- Defines monitoring and escalation
- Plans the lifecycle: updates, renewals, decommissioning
What it does not mean. A system integrator does not have to build every technology in-house. It can coordinate vendors, cloud services and specialists: what it cannot delegate is responsibility for how the whole behaves.
Initpc: an e-commerce site that is an infrastructure
For Initpc, whose technical partner we have been since 2006, we run an e-commerce site with over 280,000 products in the catalog and more than one million images.
We do not mention it to tell a client story, but because it shows the thesis of this page well: a single business service, selling online, requires expertise in virtualization, Linux, networking, security, databases, caching, search, storage, backup, monitoring and software, designed to work together.
The design criterion documented in the case study is clear: for each layer we asked what happens if it stops. Only the HAProxy entry point and the MariaDB database really shut the shop down, and monitoring and recovery procedures concentrate on those; the other layers are designed to degrade rather than block sales.
All technical information comes from the published case study. We do not report uptime, RPO or RTO figures that the case study does not state.
The skills a single service required
- VirtualizationProxmox VE on Ubuntu Server, one VM per role
- Entry pointHAProxy for load balancing and TLS termination
- CacheVarnish for pages, Redis for objects and sessions
- DataMariaDB on a dedicated VM, with its own backups
- SearchElasticsearch in Docker
- PerimeterpfSense and network segmentation
- MonitoringHector LIS for intrusions and traffic
- Storage and backupmedia on separate storage, VM images, database dumps
- Softwareintegration with the management system and warehouse synchronization
- AIHector AI for product pages
19 The method
From analysis to continuous improvement
These are the phases we follow in infrastructure projects, from consulting to management: consistent with the approach of IT systems design, from requirements analysis to testing and go-live, with backups, access controls, updates and active monitoring.
Analysis
Business requirements, inventory, dependencies, risks and current situation, service by service.
Design
Architecture, RPO and RTO per service, security, capacity and technology selection.
Integration
Phased implementation, migration of services and testing of the whole, not of the individual pieces.
Protection
Security controls, multi-tier backups and disaster recovery procedures.
Monitoring
Metrics, alerts and escalation to whoever intervenes.
Verification
Restore tests and periodic checks: what is not tested is not considered working.
Improvement
Updates, risk review and evolution of the architecture with the business.
20 What a resilient infrastructure costs
The factors that determine the cost
There is no per-user or per-server price that makes sense in the abstract. There are factors that, combined, determine the investment and the running cost.
Size
- Users and devices
- Sites to connect
- Servers, VMs and workloads
- Data volume and growth
Continuity
- Criticality of services
- Required RPO and RTO
- High availability
- Backup retention
- Off-site copy and disaster recovery
Security and rules
- Security requirements
- Regulatory and contractual obligations
- Periodic checks and testing
Management
- Monitoring
- SLAs and response times
- On-call coverage
- Lifecycle and renewals
Why two similar small businesses can spend very differently. Two companies with thirty employees: the first mostly uses cloud services and can tolerate half a day of downtime; the second produces on an in-house management system, has two offices and loses revenue every hour of outage. Same headcount, different requirements for RPO, RTO, redundancy and monitoring: different infrastructures, and different costs.
21 Checklist
Twenty questions to assess your IT infrastructure
A practical check, without scores: every "no" or "I don't know" answer is a point to look into.
Knowledge
- Is there an up-to-date inventory of assets and services?
- Is there an up-to-date network diagram?
- Are the dependencies between critical services documented?
- Is it clear who is responsible for what, including among vendors?
Security
- Is the network segmented?
- Do updates follow a planned process?
- Do administrators use MFA?
- Are privileges assigned on a need basis and reviewed?
- Are logs collected and retained?
Recoverability
- Are backups stored on systems separate from production?
- Is there an off-site copy?
- Is there an isolated or immutable copy where needed?
- Are restores tested periodically?
- Are RPO and RTO defined for every critical service?
Continuity and management
- Is there high availability where it is needed, and only there?
- Is there a written disaster recovery plan?
- Do alerts have an escalation path?
- Is the operational documentation up to date?
- Are there periodic tests of the whole?
- Is the lifecycle of hardware and software planned?
The checklist does not replace an assessment: it helps you understand where to start.
Not isolated services: parts of the same architecture
- IT consulting
- understands business, requirements, risks and constraints
- Architecture
- defines how the components must work together
- System integration
- integrates technologies and systems
- Cybersecurity
- protects identity, network, systems and data
- Virtualization
- organizes workloads and makes them manageable
- Networking
- connects and segments
- Storage
- supports data and workloads
- Backup
- protects the recoverability of data
- Disaster recovery
- plans the restoration of services
- Business continuity
- protects the continuity of work
- Monitoring
- makes the system observable
- Cloud
- extends the architecture when appropriate
- Open source
- offers technologies to use when consistent with requirements and TCO
- NIS2
- shows why risk, security, continuity and governance must be addressed together
Technologies are tools. Architecture is the value. Consulting establishes what is needed, system integration makes the parts work together, and IT resilience lets the system support the business even when something goes wrong.
22 · Infrastructure assessment
Request an IT infrastructure assessment
We start from your services and from how you work today. The result is a clear picture of risks, priorities and proportionate actions, not a quote for products.
What it may include
- Current architecture
- Dependencies between services
- Single points of failure
- Virtualization
- Network
- Cybersecurity
- Backup and recoverability
- Monitoring
- Capacity
- RPO and RTO
- Scalability
- Lifecycle
The scope of the assessment is agreed at the start, based on the size and criticality of the environment.