Reliability, Security & Lifecycle Management

What is copied, where the copy lives, and how long it takes to be working again.

• What is backed up, where - an inventory per system: servers and virtual machines, databases, file shares, Microsoft 365 mail and files, network and firewall configurations - with the copy kept somewhere the original can't take it down with it.
• Microsoft 365 is not backed up by default - retention and the recycle bin protect against a deleted e-mail; they do nothing when an account is compromised, when a sync pulls ransomware-encrypted files into the cloud, or when a departed user's license is removed. We add a tenant-level backup where the data warrants it.
• Recovery objectives in plain words - for each system we agree how long it may be down and how much data may be lost, and the backup schedule and redundancy follow from those two numbers.
• Tooling - Azure Backup for Azure resources, Proxmox Backup Server for Proxmox clusters, Veeam for VMware and mixed estates, and a tenant-level backup for Microsoft 365; chosen by what you run.
• Restore tests - scheduled and recorded: a full server or a mailbox brought back in a scratch environment, timed, compared with the objective, and the procedure corrected where it fell short.
• Disaster recovery runbooks - the order of restoration, who does what, where the passwords are, and how to reach the vendors - kept somewhere that survives the disaster it describes.

A backup on the same storage, the same credentials, or the same site as the original is a copy. Ransomware encrypts both in the same night.

Nothing we deliver under an SLA runs unmonitored.

• Our own monitoring, included - every system we deliver under an SLA is under our watch from the first day in production: availability, errors, resource use, job results, and certificate expiry, with alerts routed to the engineer on duty.
• Your stack, if you have one - that watch is built on what you already run and already pay for, and we add our own only where nothing is in place: a system under an SLA has to be observed and acted on from alerts and data, not guesses. We work with Azure Monitor on Azure, CloudWatch on AWS, Grafana or Zabbix for metrics, Graylog or an Elastic stack for logs, Splunk or Datadog where you already pay for them. Logs and events from switches, routers, firewalls, and hypervisors go to the same place as everything else.
• What gets watched - availability from outside, resource exhaustion and certificate expiry from inside, backup job results, failed sign-ins and privilege changes, and the checks that matter to your business: the nightly job finished, the order flow works. We also check that the result makes sense: a job that succeeds with empty or impossible output is the failure you won't spot yourself.
• Alerts that mean something - thresholds set per system so an alert is a call to action; anything that fires without needing action gets tuned or removed.
• Who responds and how fast - response and resolution targets by severity, written into the SLA.
• How long logs are kept - long enough to investigate an incident noticed weeks later, short enough to satisfy personal-data retention rules; both durations agreed in advance.

An alert channel nobody reads is worse than no monitoring, because everyone believes someone is watching.

Everything you run has an end-of-support date - the switch, the hypervisor, the database, the Windows version, the framework under your application, the certificate on your domain, the domain itself. We keep the list and act on it before the date does.

• Patch cadence - operating systems, hypervisors, firmware, network devices, and Microsoft 365 apps on a schedule, with maintenance windows agreed and the emergency path for a critical vulnerability defined in advance.
• End-of-support tracking - hardware, software, licenses, and support contracts in one inventory, with the renewal or replacement decision made months ahead so it can be budgeted.
• Domains and certificates - inventoried, renewed automatically where the system allows it and watched where it doesn't. An expired certificate takes down a system with nothing else wrong with it.
• Upgrades rehearsed - major version changes to hypervisors, databases, and frameworks run in a scratch environment first, with the rollback tested and the deprecations listed before production is touched. The dependency practice for the applications we build is described under Application and Systems Engineering.
• Dependencies you don't control - someone else's API, a data source, an integration with a customer's system, a device on the shop floor: they go into the same inventory as everything else, and when one stops working it is our monitoring that finds it, not your phone call. And on the vendor's side, usually nobody announces an end-of-support date or the change itself in advance.
• Vulnerability management - advisories for the products in your inventory tracked, exposure assessed against your actual configuration rather than the headline severity, and fixes scheduled by real risk.

"If it isn't broken, don't touch it" works right up to the day the one thing nobody patched takes everything else down with it.

For organizations that work in Microsoft 365, the tenant is the workplace: identity, mail, files, meetings, and devices in one place. Most of the ones we take over have not been touched since the day they were switched on. The practice around identity, devices, and access is the same whoever provides the workplace; this section is written around Microsoft because there we can name the specific tools.

• Tenant design and cleanup - roles and groups that mirror how the organization actually works; inherited tenants audited account by account and group by group, with delete, archive, or keep decided jointly.
• Mail - Exchange Online configured through PowerShell rather than click by click: shared mailboxes, transport rules, retention, and sender authentication so your mail is delivered and your domain can't be used to impersonate you.
• Teams and SharePoint - sites and teams that follow the group structure; sharing defaults decided rather than left open; migrations from Google Workspace or from a file server included.
• Devices - laptops and phones enrolled in Intune: encryption enforced, updates managed, a lost device wiped remotely, a new one set up without an engineer touching it.
• Data protection - Purview sensitivity labels and data-loss prevention for the content that must not leave the organization; retention set on purpose for each kind of data.
• Sign-in policies - multi-factor authentication for everyone, Conditional Access that blocks sign-ins from places your people never are, separate administrator accounts, and Defender for Business where the license includes it.
• Licensing by fit - Business Premium covers most organizations under 300 seats; E3 or E5 when a feature you'll actually use requires it, and we'll name the feature.

In a tenant where everyone is a global administrator, one phished password owns everything.

Segmentation and network device hardening are covered under Networking & Enterprise Connectivity; host hardening and exposure under Cloud & Platform Engineering; access control and audit inside applications under Application and Systems Engineering. This block is the standard we apply across all of them, and the habit of keeping it applied.

• One configuration standard - a written baseline per system type: tenant, server, workstation, network device, applied at build and checked on a schedule, so drift is found by us before anyone else finds it.
• Endpoint protection - Defender for Business, or the endpoint product you already license, deployed and actually reporting, with its alerts routed into the same on-call practice as everything else.
• Management access - management consoles reachable only from a separate network or over a VPN, and where you have no hardware of your own, the cloud provider's consoles behind a separate account with multi-factor authentication; default and local accounts disabled.
• Incident readiness - who to call, what to isolate first, how to preserve evidence, and when the 72-hour breach notification clock under RODO starts - written down before it's needed.

Baselines drift the moment someone needs an exception "just for today". The exception needs an expiry date.

Everything we build ships with documentation. This block is what happens after: what we do when we're the ones operating it, and what you get if we're not.

• Taking over an estate - from a previous provider or a departed administrator: access recovered and re-issued, passwords rotated, the inventory rebuilt, and the previous provider's access removed with written confirmation.
• As-built documentation - topology, inventory, configurations, where the credentials live, and a runbook per routine task, kept current as part of every change rather than as a project at the end.
• Change records - what was changed, by whom, when, and why, with the way back - so an incident three months later can be traced to the change that caused it.
• Incident handling - severities defined in the contract, response and resolution targets per severity, updates at a set cadence while it's open, and a written post-incident note with the cause and the fix - including when the cause was us.
• Staff adoption and training - new tools introduced with sessions for the people who'll use them and short written guides. A system people can't use gets worked around, and the workaround is where the data leaks.
• Handover - when you take it in-house or to another provider, you get the full documentation set, the code repositories, administrator rights transferred to you, and our access removed on a date you set, with written confirmation.

A support contract that doesn't specify severities and response times is a promise to answer the phone, and nothing more.

We're engineers, not lawyers: we implement and document the technical and organizational measures your obligations require, and we work with your legal advisor or data protection officer on the rest.

• RODO / GDPR - an inventory of which systems hold personal data and why, access limited to the people who need it, encryption in transit and at rest, retention that deletes on schedule, logging that shows who accessed what, and the incident procedure above. Personal data protected inside the data model itself is covered under Data Platforms & Automation.
• NIS2 - where it applies to you: the risk analysis, the incident-reporting readiness, the supplier register, and the continuity plan prepared on the technical side, so the obligations are met by systems and procedures that exist.
• Insurer and customer questionnaires - the security questionnaire from a cyber-insurer or a large customer answered from documentation that exists, with the gaps it reveals turned into a plan with dates.
• What we don't offer - penetration testing, ISO 27001 or SOC 2 audits, and certifications. We prepare the environment and its documentation so that the tester or auditor you bring in finds it in order, and we fix what they find.

In an audit, a policy that describes controls your systems don't enforce counts against you.