Loading...

An IT upgrade can be good news for a business: faster systems, better security or a more reliable network. The tricky part is making the change without interrupting the people who rely on those systems every day.

For many major upgrades, migrations and urgent fixes, the quietest time is outside normal working hours. With careful planning, our team can do the work while the office is empty, check that everything is running properly, and aim to have systems ready before staff arrive.

That doesn’t mean every change needs to happen at night. It means we should match the timing to the likely impact and the way our business operates.

What can an upgrade cost during the working day?

A system change can briefly interrupt access to email, shared files, business applications, phones or the internet. Even if the planned work takes only a short time, staff may need to stop, wait, or find another way to serve customers.

The cost isn’t always a dramatic outage. It can be a series of small delays: a team unable to use a key application, calls that can’t be answered, or work that needs to be repeated when access returns. If a change takes longer than expected, those delays can spread across the day.

There can also be pressure on the people doing the work. An engineer troubleshooting a change while staff are waiting for access has less room to investigate calmly. An out-of-hours window can give the team space to work through the agreed checks without adding avoidable disruption.

A contrast between a busy office interrupted by IT work and a quiet after-hours upgrade

What makes after-hours work safer?

Choosing a quiet time helps, but it doesn’t make a change safe by itself. Good business IT support starts well before the work begins. We should know what’s changing, what depends on it, how we’ll test it, and what we’ll do if the result isn’t right.

A reliable IT support services partner will agree the scope, timing and expected impact with us. They’ll also identify who needs to know about the work and who can make a decision if the plan needs to change.

That preparation can include:

  • A clear plan: What will change, in what order, and who is responsible?
  • Checks before the work: Are backups available? Are the systems needed for the change ready?
  • Testing: How will we confirm that staff can use the services they need?
  • A rollback plan: If the change causes a problem, how do we return to a known working setup?
  • A firm finish time: When do we stop troubleshooting and decide whether to continue or roll back?

Microsoft’s guidance on carrying out a migration highlights the value of planning the cutover, monitoring system health and being ready to respond if problems appear. AWS also recommends planning for unsuccessful changes and preparing a way to recover through its Well-Architected guidance.

The useful lesson is simple: a change window should be controlled, not improvised.

What a good out-of-hours IT partner does

Before the work, a good partner will ask how the business runs. A quiet Friday night may sound convenient, but it may not be right if it overlaps with payroll, a customer deadline, a backup window or a team working late. The best time is the one that limits the impact on our actual operations.

They’ll then set expectations. We should know which services may be unavailable, how long the work is expected to take and how updates will be shared. Staff should have enough notice to save work or plan around any short interruption.

During the change, the engineer follows the agreed steps and checks the result as they go. If something unexpected happens, they compare it with the success criteria and the rollback plan. That helps avoid extending a change window just because everyone hopes the issue will resolve itself.

Before the agreed finish time, the partner should check that key services work as expected. That means more than seeing that a server has powered on. It means confirming the systems staff use are available, the network is behaving normally and important business tasks can be completed.

The goal is for the work to be finished before 9am, where the plan and scope allow it. If the checks show a serious issue, it may be safer to restore the previous setup than to leave the business with a change that hasn’t been properly tested.

An engineer checking a runbook, test setup and rollback plan before an upgrade

When out-of-hours support matters most

Migrations

Moving data, applications or services to a new system can involve several connected steps. A planned maintenance window can give engineers time to move the work, check that it’s complete and confirm that staff can access what they need before the business opens.

Some migrations can be designed to keep downtime low or avoid it altogether. That depends on the systems involved, the budget and the business requirements. An impartial IT partner can help us weigh those options rather than assuming that one approach suits every organisation.

Server upgrades

A server upgrade may require a restart or a change to the services it provides. If staff rely on it for files, applications or other everyday tasks, doing the work outside busy hours can reduce disruption.

Before starting, we should agree which services are affected and how they’ll be tested afterwards. The networking and server infrastructure service page explains the kind of infrastructure work Your IT Specialist supports.

Network changes

Changes to routers, firewalls, Wi-Fi or cabling can affect how people and devices connect. A small configuration mistake can have a wider effect than expected, so it’s important to make the change in a planned window and check connections afterwards.

Where possible, remote IT support can help with configuration and checks without a site visit. If the work involves physical equipment or cabling, an engineer may need to attend in person.

Emergencies

Not every urgent issue can wait until the office is empty. A serious fault may need attention as soon as possible. But if the repair involves a planned restart, replacement or wider infrastructure change, an out-of-hours window can still help limit its effect on staff and customers.

A migration, server upgrade and network change, with a sunrise signalling a ready-to-use workplace

Is out-of-hours work always the right choice?

No. A change that is low risk and easy to reverse might be suitable during the day, especially if the system has a safe way to switch back or the business can continue working. Some organisations also have evening or weekend shifts, so “after hours” needs to reflect when our staff and customers are actually active.

Working overnight also brings its own considerations. The right people need to be available, the work must be properly handed over, and the plan should include a clear stopping point. If the window is too short, it may be wiser to split the work into stages or choose another date.

The aim isn’t to avoid every interruption at any cost. It’s to make a sensible choice based on risk, business needs and the time available.

Plan the change around the business

Before booking an upgrade, we can ask a few straightforward questions:

  1. Which staff, customers or services could be affected?
  2. What is the quietest suitable time for our business?
  3. Has the work been tested, and are backups available?
  4. What checks will confirm that everything is working?
  5. What happens if the work can’t be completed as planned?
  6. Who will confirm the systems are ready before staff arrive?

Clear answers make it easier to plan well and avoid last-minute surprises. They also help us understand whether out-of-hours work is needed, or whether another approach would suit us better.

Your IT Specialist offers flexible support, including out-of-hours upgrades and emergency work, with availability across 24 hours a day for 364 days a year. Our focus is on limiting disruption and finding a practical solution, not pushing the most expensive option. To discuss a planned change or urgent work, contact our team.

When office Wi-Fi keeps dropping out, the problem usually isn't the internet connection alone. The wireless design, building, cabling, switching or connected devices may all play a part.

This matters in every type of workplace. Offices need reliable video calls and cloud applications. Warehouses need scanners and tablets to stay connected between aisles. Clinics need dependable access to records and systems. Workshops and multi-floor sites often have thick walls, machinery and difficult coverage areas.

A stronger Wi-Fi network starts with finding the real cause. Adding another access point at random rarely fixes the problem for good.

Why business Wi-Fi fails

Access points are placed for appearance

An access point may look tidy above a reception desk or inside a communications cupboard. That doesn't mean it's in the right place.

Wireless signals weaken as they travel through walls, ceilings, glass, furniture and equipment. A device hidden behind a cabinet or mounted close to metal may provide poor coverage even when its status light shows everything is working.

Access points usually work best when they're mounted high and in the open. Ceiling mounting often gives a more even signal than placing equipment under desks or in corners.

A good design considers the whole floor plan, not just where the equipment looks neat.

There aren't enough access points

One wireless router might be enough for a small home. It often isn't enough for a busy workplace.

Every laptop, phone, printer, scanner, tablet and smart device shares the available wireless capacity. As the number of devices increases, performance can fall even when the signal appears strong.

Large offices may also have meeting rooms that suddenly fill with people. A network that works well for five devices can struggle when 20 people join a video call at the same time.

The answer isn't always to increase signal strength. Sometimes we need more access points, placed in the right locations, with sensible power levels and channel settings.

Walls, metal and lifts block the signal

Building materials make a significant difference.

  • Concrete and brick walls reduce signal strength.
  • Metal racking reflects or blocks wireless signals.
  • Lift shafts can create difficult coverage areas.
  • Refrigeration, machinery and electrical equipment may add interference.
  • Multiple floors may require a different design on each level.

This is why a wireless network that works in an open-plan office may fail in a warehouse or clinic. A coverage plan must reflect the building's actual construction and how each area is used.

Common causes of poor business Wi-Fi, including walls, metal racking, interference and poorly positioned equipment

Nearby networks cause interference

In a shared office building, several businesses may be operating wireless networks close to each other. Neighbouring signals can compete for the same channels.

The 2.4 GHz band is particularly crowded. It can travel further, but it has fewer usable channels and is often affected by other devices.

Modern business Wi-Fi should make sensible use of the 5 GHz band and, where suitable, 6 GHz. Channel width and transmit power also need to be planned. More power isn't automatically better. It can create more interference and encourage devices to stay connected to a distant access point.

Devices cling to the wrong access point

A common complaint is that someone can walk across the office while their laptop or phone remains connected to an access point at the other end of the building.

The device usually decides when to move. Some devices are better at this than others. If the access points are too far apart, transmit power is too high or the wireless design isn't tuned correctly, a device may hold onto a weak connection for too long.

Better placement, sensible power settings and suitable roaming features can improve this. However, there isn't one setting that fixes every client device.

Guest traffic shares the business network

Guest Wi-Fi should not sit on the same network as staff computers, servers, printers or business devices.

If everyone shares one network, guest devices may create avoidable security and performance concerns. A busy guest network can also compete with important business traffic.

The UK Government's guidance on sharing workplace wireless networks highlights the importance of separating access for different users and purposes.

A properly designed network normally provides separate wireless services for:

  • Staff and managed company devices
  • Guests and visitors
  • Printers, scanners, cameras and other business equipment

These separate networks are often called VLANs. In simple terms, they create controlled lanes for different types of traffic. Staff can reach the systems they need, while guest devices are limited to the internet.

Consumer equipment is being asked to do a business job

Low-cost home equipment can be useful in the right setting. It may not offer the management, capacity, security and reliability that a busy business needs.

Problems often appear when several consumer routers are connected together without a clear design. Devices may switch between networks unpredictably. Security settings may differ. Firmware may not be updated consistently. There may be no useful monitoring when something fails.

Business-grade equipment isn't about buying the most expensive brand. It's about choosing hardware that matches the building, device count, applications and budget.

What actually fixes unreliable Wi-Fi?

Start with a proper wireless site survey

A site survey measures what is happening across the building instead of relying on guesswork.

It can identify:

  • Weak signal areas and dead zones
  • Interference from nearby networks
  • The effect of walls, metal and machinery
  • Areas with too many devices
  • Suitable access point locations
  • Whether 2.4 GHz, 5 GHz or 6 GHz is appropriate
  • Coverage requirements for voice, video and business applications

A survey may include measurements before installation and testing after the network is live. For complex offices, warehouses, clinics and multi-floor sites, this can prevent expensive trial and error.

A wireless site survey measuring coverage, access point placement, cabling and network equipment across a business site

Mount access points for coverage, not decoration

Access points should be positioned based on signal requirements. They shouldn't simply be placed where they're easiest to reach or least visible.

The design should consider:

  • Ceiling height
  • Wall and partition materials
  • Racking and machinery
  • Lift shafts and stairwells
  • Meeting rooms and high-density areas
  • Outdoor or loading areas where coverage is needed
  • Future changes to the building

The correct number of access points is also important. Too few can create overloaded coverage areas. Too many can create unnecessary interference.

Check the cabling and switches

Wireless access points still depend on the physical network behind them. A Wi-Fi problem may really be a cabling or switching problem.

A faulty cable, poor termination, underpowered switch or incorrect configuration can cause:

  • An access point to restart
  • Reduced connection speeds
  • Random dropouts
  • A device to connect but receive no network access
  • Performance to vary between access points

Power over Ethernet can provide both data and power through one network cable. That helps keep ceiling-mounted equipment neat, but the switch must support the required power level.

This is where hardware installation and support matters. A proper check should include the access points, switch ports, patching, cabling routes and network cabinet.

Separate staff, guest and device traffic

Once the wireless design is right, traffic should be separated.

Staff devices may need access to internal applications. Guests normally need internet access only. Printers, scanners, cameras and other devices should have limited access to the systems they require.

This improves security and makes troubleshooting easier. If a guest device is using excessive bandwidth, it doesn't need to affect critical staff traffic. If a printer has a problem, it can be investigated within its own network area.

The separation must be configured across the access points, switches, firewall and any related services. Creating extra wireless names alone isn't enough.

Separate staff, guest and business device networks managed through access points, switching and monitoring

Plan channels and keep equipment updated

Wireless channels should be planned around the building and nearby networks. Automatic settings can help, but they shouldn't replace proper testing where the environment is busy or complex.

Firmware updates also matter. They can improve stability, fix faults and address security weaknesses. Updates should be planned so they don't interrupt working hours, particularly in clinics, warehouses and sites with out-of-hours operations.

After changes are made, the network should be tested from the places where staff actually work. A network cabinet may show everything as healthy while a warehouse scanner still loses connection at a particular aisle.

Monitor the network after go-live

A new installation isn't finished when the access points are mounted.

Monitoring can show:

  • Which access points are overloaded
  • Where devices are disconnecting
  • Whether signal levels are changing
  • Which channels are congested
  • Whether firmware is out of date
  • Whether a switch port or cable is causing trouble

It also creates a useful record. If complaints increase after a building change, new machinery or a larger workforce, we can compare the current position with earlier results.

Choose what fits the building and budget

There isn't one wireless brand that suits every business. A warehouse, dental clinic, workshop and professional office may all need different equipment and designs.

At Your IT Specialist, we take a provider-agnostic approach. We don't push a particular manufacturer because it happens to be familiar or profitable. We look at the building, usage, security needs, existing network and budget before recommending a solution.

That may involve wireless site surveying, access point installation, switching, cabling diagnostics, firewall configuration or ongoing business IT support. In some cases, the best answer may be to repair the existing network rather than replace everything.

Your IT Specialist physical infrastructure audit covering networking, Wi-Fi performance and cabling

A practical starting point

When Wi-Fi is unreliable, we can start with a simple review:

  1. Map where the problems occur.
  2. Record which devices and applications are affected.
  3. Check access point locations and mounting.
  4. Test cabling, switch ports and power.
  5. Measure wireless coverage and interference.
  6. Review guest, staff and device separation.
  7. Apply changes in a planned order.
  8. Monitor performance after the work is complete.

Reliable Wi-Fi comes from the whole network working together. With the right survey, suitable hardware, sound cabling and ongoing monitoring, wireless problems can become a controlled infrastructure issue rather than a daily interruption.

For more guidance on choosing practical, impartial support, see our business IT support guide. We can then help build a network that fits the way the business actually works.

Microsoft 365 keeps businesses running from almost anywhere. Email, documents, meetings, chat and user accounts all sit in the cloud.

That convenience can create a risky assumption: Microsoft 365 backs everything up for us.

It doesn’t, at least not in the way most businesses mean when they talk about backup.

Microsoft protects the availability and resilience of its service. We’re still responsible for protecting our data, setting retention rules and making sure we can recover after deletion, ransomware or a serious mistake.

Microsoft describes this as the shared responsibility model. Its Microsoft 365 Backup FAQ confirms that offering additional backup tools hasn’t changed that responsibility.

What Microsoft protects, and what we still need to protect

Microsoft manages the infrastructure that delivers Microsoft 365. This includes its data centres, platform security, service resilience and built-in redundancy.

That helps if a Microsoft data centre has a problem. It doesn’t necessarily help if:

  • A user deletes important email and empties their deleted items
  • A staff member overwrites a document with incorrect information
  • A compromised account deletes files or changes permissions
  • Ransomware encrypts files and synchronises those changes
  • A departing administrator removes important settings
  • We need to meet a five- or seven-year retention requirement
  • We need to restore one mailbox, folder or file from a known point in time

Microsoft 365 is designed to be highly available. It isn’t automatically a complete, independent backup of everything in our tenant.

The National Cyber Security Centre (NCSC) also recommends that organisations use backups designed to resist deletion, corruption and ransomware.

Illustration showing email, documents, Teams, OneDrive and identity data at risk in a cloud environment

What is actually at risk in Microsoft 365?

A Microsoft 365 backup plan should cover more than just email. We need to identify the data and settings that our business relies on.

Exchange Online and email

Email often contains contracts, customer information, instructions and financial records. A deleted message may remain recoverable for a limited period, but that window isn’t the same as long-term backup.

If a user deletes a message from their deleted items, recovery can become more difficult. The available recovery period depends on the mailbox configuration and Microsoft 365 features in use.

A proper backup should let us restore individual messages, folders or a complete mailbox without restoring an entire tenant.

SharePoint documents

SharePoint may hold the main working documents for a department or the whole business. Files can be deleted, overwritten or moved.

SharePoint recycle bins and version history can help with recent mistakes. They’re useful operational tools, but they’re still subject to retention settings, storage limits and the age of the content.

If a file was changed months ago, we shouldn’t assume that the version we need still exists.

OneDrive files

OneDrive is often treated as personal storage, but business-critical documents can end up there. A user might delete a folder, change hundreds of files or allow a compromised device to synchronise harmful changes.

The OneDrive sync client can make this worse. If ransomware encrypts a local folder, those encrypted files may synchronise to OneDrive. The cloud copy can then reflect the damaged state.

OneDrive recovery features may help us roll back a large number of changes, but we need to know how far back they go and whether they meet our recovery requirements.

Teams files and chat

Teams data is spread across different Microsoft 365 services.

Files shared in a Teams channel are generally stored in SharePoint. Files shared in a private or group chat are usually stored in the sender’s OneDrive. Chat and meeting information can also be associated with Exchange or other Microsoft 365 services.

This matters because protecting Teams means understanding where its content is stored. A backup plan that only covers mailboxes may not cover every Teams file or chat requirement.

Microsoft Entra ID configuration

Microsoft Entra ID, formerly Azure Active Directory, controls identities and access to Microsoft 365.

The risk isn’t limited to user data. We also need to protect or document important configuration, including:

  • User and group membership
  • Administrator roles
  • Conditional access policies
  • Multi-factor authentication settings
  • Application registrations and permissions
  • Device and access policies
  • Domain and authentication settings

Not every backup product covers Entra ID configuration in the same way. We should check the exact scope and keep a clear record of critical settings so they can be rebuilt if necessary.

Recycle bins, version history and retention aren’t the same as backup

Microsoft 365 includes several useful recovery features:

  • Exchange deleted item recovery
  • SharePoint and OneDrive recycle bins
  • File version history
  • Retention policies
  • Legal holds
  • Microsoft 365 Backup

These tools have different purposes.

Recycle bins are designed to recover recently deleted content. SharePoint and OneDrive recycle bin retention is commonly around 93 days, but settings and workload behaviour can vary.

Version history helps us undo recent changes to a document. It may not retain every version forever. Older versions can be removed because of library settings, storage limits or retention rules.

Retention policies and legal holds help preserve information for compliance. They don’t automatically create a separate, independent backup copy that’s optimised for fast restoration.

Microsoft 365 Backup now provides additional point-in-time recovery for supported workloads. It can be a useful part of a wider plan, but we still need to check its scope, retention, access controls and recovery process against our business requirements.

Comparison between short-term recycle bins and version history and a protected independent backup vault

What a proper Microsoft 365 backup should provide

For many businesses, a suitable backup should include:

Independent storage

The backup should be stored separately from the production Microsoft 365 environment. This reduces the chance that one compromised administrator account can delete both the live data and its backups.

Long-term retention

The right retention period depends on our contracts, regulations, insurance requirements and business needs. A short recovery window may be enough for a small operational mistake, but not for a dispute involving an old email or document.

Immutable or deletion-resistant copies

The NCSC’s guidance for ransomware-resistant cloud backups recommends protection against malicious editing, overwriting and deletion.

This may include immutable storage, delayed deletion, separate administration and alerts for major changes.

Granular restores

We should be able to restore what we need without replacing everything. Useful options can include:

  • One email
  • One mailbox
  • One folder
  • One SharePoint site
  • One OneDrive file
  • One Teams file
  • A complete user account

Granular recovery reduces disruption and helps us deal with small incidents quickly.

Restore testing

A backup that has never been restored is an assumption, not an assurance. We need to test that the data is present, usable and recoverable by the people responsible for it.

Four practical steps to take now

1. Check what retention we actually have

Don’t rely on licensing names or assumptions. Record:

  • Which workloads are protected
  • How often backups run
  • How long copies are retained
  • What happens after a user is deleted
  • Whether Teams files and chat are included
  • Whether Entra ID configuration is covered
  • Who can delete or change backups

This review often reveals gaps quickly.

2. Test a restore

Restore a sample email, file and mailbox to a safe location. Check how long the process takes and whether permissions, metadata and file versions are preserved.

A test also shows whether the process is clear during a stressful incident.

3. Document who can restore what

Write down the people and accounts that can manage backups. Use separate administrator accounts, multi-factor authentication and least-privilege access where possible.

We should also plan for the situation where normal Microsoft 365 accounts are unavailable.

4. Set a retention policy

Choose retention periods based on real business requirements. Keep important records for as long as we need them, but avoid keeping everything indefinitely without a clear reason.

Review the policy after major changes, such as a new compliance requirement, merger or application rollout.

IT professional testing a restore of a file and mailbox from a secure cloud backup

Getting Microsoft 365 backup right

Microsoft 365 is a strong platform, but cloud hosting doesn’t remove the need for data protection. It changes how we manage it.

A sensible approach combines Microsoft’s built-in recovery tools with suitable backup, secure identity controls, monitoring and regular restore tests.

At Your IT Specialist, we provide provider-agnostic advice. We can help review Microsoft 365 protection, software configuration and recovery arrangements without pushing a particular vendor.

Our cyber-security services include Microsoft 365 security hardening, vulnerability assessments, patching, access controls, cloud backup and retention reviews, and logs analysis.

We can also support software installation, cloud application management and wider IT changes as part of a practical long-term plan.

The useful question isn’t simply, “Is Microsoft 365 backed up?”

It’s: “If important data disappeared today, could we restore the right information quickly, securely and completely?”

A short review and a tested restore can give us a much clearer answer.

A new starter should be productive on their first day. A leaver should lose access on their last.

That sounds straightforward. In practice, many businesses have a clear process for issuing a laptop but no reliable process for removing access. A former employee may still have access to email, Microsoft 365, cloud applications, VPNs, shared passwords or building systems.

Leavers retaining access is one of the most common and most dangerous gaps we see in business IT support.

The answer isn't a complicated policy document. It's a repeatable joiner, mover and leaver process. This checklist covers the key steps.

Why onboarding and offboarding need the same attention

Onboarding is about giving people the access they need to work.

Offboarding is about removing that access before it creates a problem.

Both processes affect:

  • Business data
  • Customer and employee information
  • Company devices
  • Software licences
  • Email and shared files
  • Phone systems
  • Physical security
  • Audit records

The NCSC recommends formal identity and access management, including a process for joiners, movers and leavers. The ICO also expects organisations to control access to personal data and remove access when staff leave or change roles. Its access control guidance is a useful reference for UK businesses.

The practical principle is simple: give access based on the role, then remove or change it when the role ends.

Before a new starter arrives

Good onboarding starts before day one. Last-minute setup creates avoidable delays and often leads to shortcuts.

Starter checklist

  • Confirm the employee's full name, start date, job title, department and manager.
  • Confirm whether they'll work in the office, remotely or across multiple sites.
  • Identify the systems and data needed for the role.
  • Order the laptop, monitor, headset, phone and other equipment.
  • Check that required software licences are available.
  • Create a role-based access profile.
  • Prepare the email address and user account.
  • Set up MFA before the first login.
  • Prepare access to shared drives, cloud storage and collaboration tools.
  • Set up the desk, Wi-Fi and phone or VoIP extension.
  • Prepare security and acceptable-use guidance.
  • Agree who will approve access requests.
  • Record the planned setup in a ticket or onboarding form.

The access profile should be based on the job, not copied from another employee. Copying a colleague's permissions can give a new starter access to systems they don't need.

This is the principle of least privilege: we provide enough access to do the job, but no more than necessary.

It also makes future changes easier. When someone moves from sales to finance, we can remove the old role and apply the new one instead of trying to find every permission manually.

Secure IT onboarding checklist with laptop, email, MFA, role-based access and VoIP setup

Day one: give access safely

The first login is an important security moment. It shouldn't be treated as a quick handover of a laptop and password.

Day-one checklist

  • Give the starter their device and accessories.
  • Confirm the device is encrypted and protected.
  • Check that operating system updates are installed.
  • Confirm antivirus or endpoint protection is active.
  • Guide the user through their first login.
  • Make sure they change any temporary password.
  • Enrol their MFA device or authenticator app.
  • Set up a backup MFA method where appropriate.
  • Confirm email and calendar access.
  • Confirm access to the correct shared folders and drives.
  • Check access to role-specific applications.
  • Confirm VPN access if remote work requires it.
  • Test the phone, extension, voicemail and call routing.
  • Add the employee to the correct distribution lists and Teams channels.
  • Explain how to contact the IT helpdesk.
  • Explain how to report suspicious messages or lost devices.
  • Confirm that security and acceptable-use policies have been read.

MFA should be enabled from the start, not added later. The NCSC recommends MFA for corporate online services, particularly email, cloud systems and administrative accounts. The NCSC MFA guidance explains the main controls.

We should also check what the starter can't access. Excessive access is a risk, even when it was granted with good intentions.

The first week: check the setup

A new employee may not know which access is necessary until they start doing the work. A short follow-up prevents small issues from becoming permanent permissions.

First-week review

  • Ask whether the user can access all required systems.
  • Remove any access that isn't needed.
  • Confirm MFA is working correctly.
  • Check that the device is receiving updates.
  • Confirm security training is complete.
  • Review access to customer, finance, HR or other sensitive data.
  • Confirm shared mailbox and calendar access.
  • Check distribution lists and team channels.
  • Record any changes made.
  • Set a date for a later access review.

This review is particularly important for contractors, temporary staff and employees who work across departments.

When someone changes role

Internal moves are often missed because the person doesn't technically leave the business. Their risk can still change significantly.

A move from one department to another may require:

  • Removing old shared-drive permissions
  • Removing access to previous customer or financial data
  • Changing application roles
  • Reassigning approval rights
  • Updating email groups and distribution lists
  • Changing their phone extension or call routing
  • Reviewing admin access
  • Issuing a new device or software licence

Treat a role change as a smaller offboarding and onboarding event. The old access should be removed before the new access is added where possible.

Offboarding: the access must end immediately

Offboarding needs a clear trigger. HR or a manager should tell the person responsible for IT when the leaving date is confirmed.

The process should record:

  • Employee name
  • Last working date and time
  • Whether the departure is planned or immediate
  • Manager responsible
  • Systems and applications used
  • Devices issued
  • Shared passwords known
  • Physical access held
  • Data and mailbox ownership
  • Person approving completion

For a planned departure, access should be removed at the agreed time on the last working day. For an immediate departure, it should happen at once.

Don't wait until the next morning. A former employee may still have active sessions, saved passwords, mobile access or valid tokens.

Account and access revocation checklist

At the agreed time:

  • Disable the main user account.
  • Revoke active Microsoft 365 or cloud sessions.
  • Remove VPN and remote-access permissions.
  • Disable email access.
  • Remove access to Microsoft 365, Google Workspace or other cloud platforms.
  • Remove access to CRM, finance, HR and project systems.
  • Remove access to file-sharing services and customer portals.
  • Remove administrator and elevated permissions.
  • Remove the user from distribution lists, Teams channels and shared mailboxes.
  • Disable remote-control tools.
  • Remove registered MFA devices and authentication methods.
  • Review temporary accounts created for projects.
  • Change shared passwords the person knew.
  • Rotate shared keys, tokens or access codes where needed.
  • Remove access to social media and other business accounts.
  • Remove door access, alarm codes, keys and entry cards.

Disabling the main email account is not enough. Many applications use separate accounts or saved sessions. A proper offboarding process follows the full list of systems.

Secure employee offboarding with revoked cloud access, returned devices, file transfer and audit records

Recover and protect company equipment

The physical device can contain locally stored files, saved browser sessions and authentication tokens.

Equipment checklist

  • Recover laptops, desktops, tablets and phones.
  • Recover security keys, access cards and tokens.
  • Recover monitors, headsets and other company equipment.
  • Confirm whether any equipment is at home or with a third party.
  • Remove company data from approved personal devices.
  • Lock or wipe lost equipment remotely where possible.
  • Back up required business data.
  • Securely wipe devices before reassigning them.
  • Record the condition and location of each asset.

If a device can't be recovered, treat it as a security issue. Revoke its access, change relevant passwords and check whether remote wipe is available.

Transfer files, email and responsibilities

Deleting an account without checking ownership can create a second problem: important business information may disappear with it.

Before closing the account:

  • Transfer ownership of important files.
  • Move shared documents into the correct business location.
  • Transfer ownership of calendars and meeting records.
  • Review OneDrive, SharePoint or other cloud storage.
  • Decide whether the mailbox needs a short-term handover.
  • Set a suitable automatic reply if required.
  • Avoid forwarding mail indefinitely.
  • Transfer customer, supplier and project records.
  • Reassign approval tasks and workflows.
  • Record who now owns each key responsibility.

Mailbox and file retention should follow business needs, contractual requirements and data protection policies. We should keep what the business needs, but avoid retaining personal data without a clear reason.

Don't forget phones, doors and call routing

IT offboarding isn't limited to computers.

Check:

  • VoIP extension and direct-dial number
  • Hunt groups and call queues
  • Voicemail access
  • Mobile phone and SIM
  • Shared phone-system accounts
  • Door access and alarm codes
  • CCTV or access-control accounts
  • Office keys and entry cards
  • Meeting-room and booking systems

Our telecom support service covers VoIP, SIP, PBX systems, call routing and the network behind them. This matters when a leaver's number needs to be reassigned or customer calls need to reach another member of the team.

Keep a record for audit

A completed checklist is useful evidence that the process was followed.

Record:

  • Who requested the offboarding
  • When access was removed
  • Which systems were checked
  • Which devices were recovered
  • Where files and mailboxes were transferred
  • Which licences were cancelled or reassigned
  • Which passwords or codes were changed
  • Who approved completion
  • Any outstanding actions

Keep the record with the employee's HR or IT documentation, with access limited to authorised staff.

A quarterly review can also identify old accounts, unused licences, inactive shared mailboxes and excessive permissions.

Repeatable joiner, mover and leaver workflow linking HR, identity, devices, cloud applications and audit logs

How managed IT services can help

A checklist is a good starting point. The real benefit comes from making it repeatable.

Managed IT services can help us:

  • Build joiner, mover and leaver workflows
  • Create role-based access profiles
  • Enforce MFA
  • Review permissions
  • Manage devices and software licences
  • Secure Microsoft 365 and cloud applications
  • Revoke access remotely
  • Support password and credential changes
  • Maintain audit records
  • Provide practical security advice

Our cyber-security services include identity and access controls, MFA, role-based access, endpoint protection, vulnerability reviews and secure onboarding and offboarding processes.

We can also provide remote support when a starter needs access set up quickly or a leaver must be locked out outside normal working hours. Where the process needs a wider review, our provider-agnostic IT consulting approach focuses on practical improvements rather than unnecessary upgrades.

The uncomfortable question

If someone left your business today, could we confirm within minutes that they no longer have access to:

  • Email and Microsoft 365?
  • VPN and remote tools?
  • CRM and finance systems?
  • Shared passwords?
  • Cloud files?
  • Phone systems?
  • Door access and alarm codes?
  • Personal devices used for work?

If the answer isn't clear, the process needs attention.

A documented checklist won't prevent every incident. It will make the right action quicker, more consistent and easier to verify. That is a good next step for any business handling staff changes and sensitive information.

If we need help reviewing or improving the process, contact Your IT Specialist for practical business IT support.

IT support can look like a cost line when everything is working. An outage shows the other side of the calculation.

When systems stop, staff may be unable to work, customers may be unable to contact us, sales can be missed and invoices may be delayed. The first hour is rarely the full cost, either. Recovery work often continues after systems come back online.

Published estimates vary widely. Some UK estimates place small-business downtime at roughly £800 to £1,200 per hour, while larger or more dependent businesses can lose much more. The right figure for our business depends on how many people and processes rely on IT.

The useful question isn't, “What does IT support cost?”

It's, “What does one hour without it cost us?”

What happens during an hour of downtime?

The impact usually falls into several areas.

1. Staff remain on the payroll

If staff can't access email, business applications, files or phones, we may still pay them for an hour when little work gets done.

This is easy to calculate:

Number of affected staff × fully loaded hourly cost × proportion of lost time

The fully loaded hourly cost should include salary, employer costs and other employment overheads. It doesn't need to be exact. A sensible estimate is more useful than ignoring the cost altogether.

For example, if 20 employees cost the business an average of £25 per hour, a full hour of lost productivity costs:

20 × £25 = £500

This doesn't mean every employee is completely unproductive. Some may continue working offline. Others may be affected only briefly. We can adjust the calculation by using a percentage.

If 20 employees lose 75% of an hour:

20 × £25 × 0.75 = £375

2. Sales and enquiries can disappear

Revenue loss is often more difficult to see than staff cost.

An outage might stop:

  • Online orders
  • Card payments
  • Booking systems
  • Customer enquiries
  • Sales demonstrations
  • Calls to the business
  • Access to a customer relationship system
  • Work that needs to be submitted through a client portal

A business generating £4,000 during an eight-hour working day has an average revenue rate of £500 per hour. That doesn't mean every hour produces £500. Sales may be concentrated around certain times. Still, it provides a useful starting point.

Average revenue per trading hour × proportion of revenue affected

If 60% of that hourly revenue depends on the unavailable system:

£500 × 0.60 = £300

The lost amount may be higher if customers abandon a purchase or move to a competitor. It may be lower if orders can be recovered later. We should use a realistic estimate rather than assuming every missed opportunity becomes a permanent loss.

3. The work doesn't always restart immediately

A system may be restored after 60 minutes, but normal work may take much longer to resume.

Staff may need to:

  • Re-enter information
  • Reconcile orders
  • Return missed calls
  • Re-send emails
  • Recreate documents
  • Rebook appointments
  • Explain delays to customers
  • Catch up on a backlog

This creates a second cost: recovery time.

If 10 employees each spend another 30 minutes catching up, at a fully loaded cost of £25 per hour, that adds:

10 × £25 × 0.5 = £125

This is why we should measure the total disruption, not just the time shown on the outage message.

Flat vector illustration showing a calculator, pound symbols, staff icons and a revenue chart used to estimate downtime costs

A simple way to estimate our cost

We can create a practical estimate with five figures:

  1. Number of affected staff
  2. Average hourly employment cost
  3. Average revenue per trading hour
  4. Percentage of staff and revenue affected
  5. Expected recovery time after service returns

A simple calculation looks like this:

Staff cost + lost revenue + recovery cost + additional costs = estimated downtime cost

Let's use a straightforward example.

Example: a 30-person business

Assume:

  • 30 employees are affected
  • Average fully loaded staff cost is £24 per hour
  • Average revenue is £400 per trading hour
  • 80% of staff are unable to work
  • 75% of revenue-generating activity is affected
  • Recovery takes another 30 minutes for 15 employees
  • The business pays £200 for emergency technical support

Staff productivity

30 × £24 × 0.80 = £576

Lost revenue

£400 × 0.75 = £300

Recovery time

15 × £24 × 0.5 = £180

Emergency support

£200

Estimated total

£576 + £300 + £180 + £200 = £1,256

This estimate doesn't include missed service levels, customer churn or reputational damage. It also doesn't assume a serious cyber incident or hardware replacement.

For this business, one hour offline could reasonably create more than £1,200 of immediate cost.

We can use the same method with our own figures. It takes only a few minutes and gives us a more useful basis for IT decisions.

The costs that are harder to measure

Some effects don't appear on an invoice straight away.

Missed service levels

If we have contractual response or delivery commitments, downtime may cause:

  • Service credits
  • Refunds
  • Missed deadlines
  • Contract penalties
  • Additional account-management work

The amount depends on each agreement. We should check whether our important contracts include uptime or response commitments and include a reasonable allowance in our business continuity planning.

Delayed invoicing and cashflow

If finance systems are unavailable at month-end, invoices may be delayed. That can affect when customers pay us.

A short outage might not change the final invoice total, but it can move the payment date. For businesses managing tight cashflow, that delay matters.

Customer confidence

Customers may accept an occasional technical issue when communication is clear and recovery is quick. Repeated outages are different.

They can create questions about whether we are reliable, organised and safe to work with. In sectors where customers depend on timely service, one visible failure may influence future buying decisions.

Overtime and additional work

Teams may need to work later to catch up. We may also need specialist help, replacement equipment or temporary systems.

The cost of recovery can exceed the cost of the original outage, particularly when backups haven't been tested or nobody is sure how systems should be restored.

Flat illustration showing an offline server and connected business impacts including delayed invoices, customer messages and service commitments

Prevention usually costs less than recovery

We can't prevent every incident. We can reduce how often problems happen, how long they last and how far they spread.

A sensible business IT support plan should include the following.

Proactive monitoring

Monitoring can identify failing disks, full storage, unavailable services, unusual activity and network problems before they become a full outage.

This gives us a chance to fix issues during a planned window rather than during a busy trading period.

Tested backups

A backup that has never been restored is an assumption, not a plan.

Backups should be checked regularly. We should know:

  • What is being backed up
  • How often backups run
  • Where copies are stored
  • How long restoration takes
  • Who is responsible for recovery

Testing also helps identify whether a backup is complete or only appears to be working.

Planned out-of-hours maintenance

Some work can't be completed without interrupting a service. Upgrades, migrations and infrastructure changes are safer when scheduled outside normal working hours.

Our out-of-hours support service helps businesses plan this work around their operating needs. It also provides a response when an issue happens outside the usual working day.

The goal isn't to avoid every maintenance window. It's to choose the least disruptive one.

Remote IT support that starts quickly

Waiting for an engineer to travel to site can add hours to an outage. Many issues can be investigated and resolved remotely, including problems with desktops, servers, virtual machines, networks and cloud applications.

Remote IT support can begin as soon as the problem is reported. That may reduce both the outage time and the need for an emergency site visit.

On-site support still has a place when hardware needs replacing or physical work is required. Remote support simply gives us another, often faster, option.

Flat vector illustration showing proactive monitoring, tested backups, remote support and an out-of-hours maintenance window protecting business systems

IT support is a business continuity decision

The right support arrangement doesn't need to be the most expensive option. It needs to match the cost and risk of an outage.

For some businesses, business-hours support is enough. Others rely on systems that operate evenings, weekends or across multiple time zones. A one-size-fits-all package may not reflect the real business need.

We can start by calculating our own hourly exposure, then ask:

  • Which systems would stop work if they failed?
  • How quickly could we restore them?
  • Who would respond outside working hours?
  • Which issues can be fixed remotely?
  • When were our backups last tested?
  • How long would recovery and catch-up take?

A provider-agnostic managed IT services review can help us answer those questions without starting with a particular vendor or product.

The aim isn't to spend more on IT for its own sake. It's to reduce avoidable downtime, recover faster and protect the work that keeps the business moving.

When we know that one hour offline could cost £1,000, £5,000 or more, reliable IT support stops looking like a fixed overhead. It becomes a practical investment in productivity, revenue and customer confidence.

Find out more about impartial IT support from Your IT Specialist.

Signing an IT support contract should make life easier. It should give us clear support, predictable costs and confidence that problems will be handled properly.

But contracts can be full of vague terms. “Unlimited support”, “24/7 monitoring” and “priority response” can sound reassuring without explaining what they really mean.

The answer is simple: we need to read the detail behind the headline.

This guide explains what’s commonly included in business IT support agreements, what often costs extra, and which terms deserve closer attention.

What is an IT support contract?

An IT support contract is an agreement between a business and an IT provider. It sets out the services provided, the price, support hours, service standards and responsibilities of both sides.

Some agreements cover basic helpdesk support. Others provide wider managed IT services, including monitoring, security, maintenance and strategic advice.

The important point is that no two contracts are exactly the same. We shouldn't assume a service is included just because it’s commonly offered elsewhere.

A useful contract should clearly answer:

  • What systems, users and locations are covered?
  • When can we contact the support team?
  • How quickly will they respond?
  • What work is included in the monthly fee?
  • What will cost extra?
  • How can either side end the agreement?
  • What happens to our data, licences and equipment when it ends?

What’s normally included?

Every provider structures its packages differently. However, most business IT support contracts include some combination of the following.

Helpdesk support

This is the day-to-day support service. It may cover issues such as:

  • Password and account problems
  • Email and application faults
  • Printer and device issues
  • Access problems
  • Basic troubleshooting
  • User setup and routine requests

The contract should explain how we raise requests. This might be by email, telephone, support portal or a combination of these.

It should also state whether support is unlimited or subject to fair-use limits. “Unlimited” doesn't always mean that every type of work is unlimited.

Remote support

Remote support allows an engineer to investigate and resolve many issues without visiting the office. This can include support for:

  • Windows and Linux desktops
  • Windows and Linux servers
  • Virtual machines
  • Network infrastructure
  • Cloud applications
  • User accounts and permissions

Remote support can often resolve problems quickly and keep costs under control. Your IT Specialist prioritises remote support, while site visits can be arranged where they’re genuinely needed.

Monitoring and maintenance

A managed IT services contract may include monitoring of servers, networks, devices and key services.

Monitoring can help identify:

  • Systems that are running out of storage
  • Devices that have stopped reporting
  • Network or connectivity problems
  • Hardware warnings
  • Failed services
  • Performance issues

The contract should explain what the provider monitors and what happens when an alert appears. Monitoring alone isn't enough if nobody reviews the alerts or takes action.

Patching and updates

Patching means applying updates to operating systems and supported software. This helps fix known faults and reduce security risks.

Ask whether patching is:

  • Included in the monthly fee
  • Automatic or manually approved
  • Completed during business hours or out of hours
  • Tested before being applied
  • Available for all devices or only selected systems

Patching can sometimes require planned downtime. A good provider should explain how this is managed.

Security support

Security services may include firewall management, antivirus or endpoint protection, vulnerability checks, log reviews and advice on security policies.

However, security is often split across different packages. One contract may include antivirus but exclude firewall management or security assessments.

We should ask for the exact tools and services included. We should also confirm who is responsible for responding to security alerts.

Reporting and regular reviews

Some contracts include regular reports or service review meetings. These can show:

  • Support requests and response performance
  • Patching status
  • Security alerts
  • Backup status
  • Outstanding risks
  • Recommended improvements

This gives us a useful view of what we’re paying for. If the contract promises proactive support but provides no meaningful reporting, it’s worth asking how that support is measured.

What’s often excluded or charged extra?

The exclusions are just as important as the inclusions.

Site visits

Site visits are often charged separately, particularly where the contract focuses on remote support. Additional costs may include:

  • Engineer time
  • Travel
  • Parking
  • Accommodation
  • Emergency call-out fees

The agreement should explain when a site visit is included and how extra costs are calculated.

Hardware and licences

The monthly support fee usually doesn't include the cost of:

  • Laptops and desktop computers
  • Servers
  • Firewalls and network equipment
  • Replacement parts
  • Software licences
  • Cloud subscriptions
  • Internet or telephone services

Ask whether the provider buys equipment on our behalf, whether a margin is added, and who owns the equipment once it’s purchased.

Provider-agnostic advice matters here. The best solution isn't always the most expensive one. It should fit our needs, budget and future plans.

Project work

Routine support and project work are different.

Projects might include:

  • Office moves
  • Server replacements
  • Large software upgrades
  • Microsoft 365 migrations
  • New network installations
  • Data migrations
  • New application development
  • Major security improvements

These are often quoted separately. That isn't a problem, provided the contract makes the boundary clear.

Out-of-hours work

A contract covering weekday support may not include evenings, weekends or bank holidays. Emergency work outside those hours may have a different rate.

If our business operates outside standard hours, we should check:

  • Which hours are included?
  • Is an emergency number available?
  • Who answers the call?
  • Is the service genuinely staffed or simply monitored?
  • Are response targets different outside normal hours?

Out-of-hours support can be useful for upgrades and emergency work because it reduces disruption to staff.

Stopwatch and repair checklist representing response time and fix time in an IT support agreement

Response time is not fix time

This is one of the most important distinctions in an IT support contract.

Response time is how long the provider takes to acknowledge or begin working on a request.

Fix time, sometimes called resolution time, is how long it takes to solve the problem or provide a workable alternative.

A contract may promise a 30-minute response without promising a fix within 30 minutes. That can be reasonable, particularly for complex faults, but we need to understand the difference.

Look for separate targets for different priorities:

Priority Example What to check
Critical A major outage affecting the business Response target, escalation process and workaround target
High Several users can't access an important system Response target and expected progress updates
Normal One user has an application problem Standard response and resolution approach
Low Routine request or advice Expected timescale and communication method

We should also ask what pauses the clock. For example, does the target stop while the provider waits for information, a supplier or access to the affected device?

Clear definitions prevent disappointment later.

Per-user or per-device pricing?

IT support contracts commonly charge per user, per device or through a hybrid model.

Per-user pricing

A per-user model charges for each supported employee. It can be easier to budget when people use several devices.

But we should check whether the price includes:

  • Laptops and desktops
  • Mobile devices
  • Home-working equipment
  • Microsoft 365 administration
  • Shared accounts
  • Servers and network equipment

Per-device pricing

A per-device model charges for each managed laptop, server, workstation or network device.

This may work well where we have many devices but fewer users. It can become less predictable if equipment increases over time.

Questions to ask

Whichever model is used, the contract should explain:

  • What counts as a user or device
  • How new users and devices are added
  • What happens when staff or devices are removed
  • Whether inactive devices still attract a charge
  • Whether servers, firewalls and network equipment are priced separately

Comparison of per-user and per-device IT support pricing models

Contract length, renewals and price increases

Check the commercial terms before focusing on the service list.

Important points include:

  • Minimum contract length
  • Notice period
  • Renewal date
  • Auto-renewal wording
  • Annual price increases
  • Early termination charges
  • Payment terms
  • Charges for work outside the agreement

A 12-month term isn't automatically unreasonable. A provider may need time to understand and improve an environment. The concern is a long commitment that we didn't fully understand.

If the contract renews automatically, add the notice date to our calendar. Missing it could extend the agreement for another term.

Price reviews should also be clear. The contract should state when prices can change, how much notice we’ll receive and whether increases are fixed or linked to an index.

Exit clauses and ownership

We should read the exit section before signing, not when we’re already trying to leave.

The agreement should explain:

  • How much notice we must give
  • Whether we can leave for convenience
  • What happens if the provider repeatedly misses service targets
  • Whether there are early termination fees
  • How outstanding invoices are handled
  • What help is available during handover

We should also confirm who owns:

  • Business data
  • Backup data
  • Documentation
  • Network diagrams
  • Administrator accounts
  • Domains
  • Cloud subscriptions
  • Hardware
  • Software licences

A good handover should include the information needed to keep the business running. This may include passwords, configuration details, asset lists and backup access.

Open IT support contract folder with keys, secure data icons and an orderly provider handover

Questions worth asking before we sign

A provider should be comfortable answering awkward questions. We can ask:

  1. Exactly which users, devices and locations are covered?
  2. What isn't included in the monthly price?
  3. What does “unlimited support” mean in practice?
  4. Is support remote, on-site or both?
  5. What are the response and fix targets?
  6. What happens outside normal support hours?
  7. Are projects charged separately?
  8. Who owns our data, hardware and licences?
  9. How does the contract renew?
  10. What does the handover process look like if we leave?

If the answers aren't clear, the contract isn't ready to sign.

The right contract should make things clearer

An IT support contract isn't just paperwork. It sets expectations for the working relationship.

The best agreements are specific about services, costs, responsibilities and exit arrangements. They don't rely on vague promises or pressure us into buying more than we need.

At Your IT Specialist, we provide provider-agnostic and impartial advice. We focus on practical solutions, remote support where possible and long-term relationships rather than expensive recommendations for their own sake.

If we're reviewing an agreement, contact us for an honest conversation. A second view can help us spot unclear terms before they become expensive problems.

Quantum computing still sounds like a distant concern. For UK businesses, it isn't something we can leave until 2034.

The National Cyber Security Centre (NCSC) has set clear milestones for moving to post-quantum cryptography (PQC):

  • By 2028: complete discovery and create an initial migration plan.
  • By 2031: migrate the highest-priority systems.
  • By 2035: complete migration across systems, services and products.

The NCSC says this work should start now. The reason is simple: much of the public-key encryption used today is expected to be vulnerable to sufficiently powerful quantum computers.

The often-cited 95% figure describes the estimated share of current encryption that depends on quantum-vulnerable public-key methods. It isn't an official NCSC statistic, and it doesn't mean every password hash or piece of symmetric encryption will suddenly fail. However, it highlights the scale of the change ahead.

For many small and mid-sized businesses, the first challenge is more basic: we don't yet have a clear record of where encryption is being used.

What is post-quantum cryptography?

Encryption turns readable information into a protected form. Only someone with the right key can read it.

Most modern businesses use encryption for:

  • Websites and customer portals
  • Email and file transfers
  • Virtual private networks
  • Cloud applications
  • Remote access
  • Digital certificates
  • Software updates
  • Secure connections between servers
  • Data stored on laptops, servers and backup systems

Some of this protection relies on mathematical problems that are difficult for today's computers to solve. A sufficiently advanced quantum computer could solve some of those problems much faster.

Post-quantum cryptography uses different mathematical methods designed to remain secure against both traditional and quantum computers.

In practical terms, PQC isn't a new app that we download. It will become part of operating systems, browsers, cloud platforms, firewalls, VPNs, certificates, applications and hardware.

The transition will take years because these systems need to work together. Some will be updated by suppliers. Others, especially custom applications and older infrastructure, may need direct planning and replacement.

The risk has already started: “harvest now, decrypt later”

Quantum computers capable of breaking current public-key encryption aren't available today. That doesn't mean the risk begins in the future.

An attacker can collect encrypted information now and store it. If the information is still valuable in ten or twenty years, it may be decrypted when quantum technology becomes powerful enough.

This is known as “harvest now, decrypt later.”

Encrypted business data being stored today while a future quantum computer prepares to decrypt it

This matters most when data needs to remain private for a long time, such as:

  • Intellectual property
  • Product designs and research
  • Financial information
  • Personal and medical records
  • Legal documents
  • Long-term business agreements
  • Customer and supplier data
  • Sensitive communications

A business might complete its migration in 2035 but still face a problem if an attacker has already copied sensitive encrypted data.

That is why the NCSC's first milestone is discovery and planning, rather than waiting until new quantum-safe systems are widely available.

The NCSC timeline in practical terms

The NCSC's guidance on timelines for migration to post-quantum cryptography is mainly aimed at larger organisations, critical national infrastructure and businesses with bespoke IT.

However, the direction is relevant to organisations of every size.

By 2028: understand what we have

The first milestone is not to replace every firewall, laptop or application.

It is to:

  1. Define our migration goals.
  2. Identify where cryptography is used.
  3. Record which systems depend on it.
  4. Identify long-lived or sensitive data.
  5. Understand supplier dependencies.
  6. Create an initial migration plan.

For a smaller business, this may be a focused review rather than a large transformation programme. Many standard systems will eventually be updated by their suppliers.

Custom software, older servers, specialist equipment and privately managed networks may need more attention.

By 2031: protect the most important systems

The second milestone is to migrate the highest-priority services.

This means focusing first on systems that:

  • Protect valuable or long-lived information
  • Support essential business operations
  • Connect directly to customers or suppliers
  • Depend on older hardware or software
  • Use custom encryption or certificates
  • Would be difficult to replace quickly

By this point, businesses should also have a more detailed route to full migration by 2035.

By 2035: complete the migration

The final milestone is to complete migration across all in-scope systems, services and products.

There may be difficult exceptions, particularly for older equipment or specialist operational technology. Even so, the NCSC expects organisations to work towards the 2035 target.

This is a long-term technology change. It should be planned alongside normal hardware replacements, software upgrades, cloud projects and security improvements.

The simple first step: create a cryptographic inventory

Most businesses have an asset list. Fewer have a clear record of how those assets use encryption.

A cryptographic inventory is a practical map of the technology that protects business information.

It doesn't need to begin as a complex technical document. We can start with a spreadsheet that records:

  • System or application name
  • Supplier and product version
  • Where it is hosted
  • What data it protects
  • Whether it connects to external services
  • Certificates and renewal dates
  • VPN and remote access dependencies
  • Hardware or software replacement cycle
  • Supplier plans for PQC support
  • Business importance
  • Recommended next action

We should look at more than laptops and servers. The NCSC recommends considering:

  • Cloud services
  • Firewalls and VPNs
  • Routers and switches
  • Websites and customer portals
  • Mobile devices
  • Backup platforms
  • Virtual machines
  • Custom applications
  • Software libraries
  • Digital certificates
  • Hardware security devices
  • Internet-connected equipment
  • Remote access tools

A practical cryptographic inventory mapping laptops, servers, VPNs, cloud applications and certificates

The goal isn't to document every technical detail on day one. The goal is to understand where the important systems are and which ones need deeper investigation.

This inventory also supports better everyday security. It can reveal unsupported software, expired certificates, unknown suppliers and systems that no one is actively managing.

What UK SMEs should do now

A sensible starting plan can be straightforward.

1. Identify long-lived data

Ask which information would still be sensitive in ten or twenty years.

This data should receive early attention, even if it isn't the easiest system to change.

2. Ask suppliers about their plans

Cloud providers, software suppliers, firewall vendors and application developers should have a roadmap for quantum-safe updates.

We should ask:

  • Will the product support PQC?
  • When will updates be available?
  • Will existing hardware support them?
  • Will licences or configuration changes be needed?
  • What happens to older versions?
  • Will the change affect performance or compatibility?

3. Record custom and older systems

Standard cloud platforms may be updated by their suppliers. Custom applications and older systems are less predictable.

These should be marked clearly in the inventory, along with their replacement or upgrade options.

4. Build flexibility into new projects

New systems should avoid designs that make future encryption changes difficult.

Where possible, we should choose platforms that support cryptographic agility. In plain English, this means we can change the encryption method without rebuilding the entire system.

5. Align upgrades with normal business planning

We don't need to replace working systems unnecessarily. Instead, we can consider PQC readiness when:

  • Renewing a firewall
  • Replacing servers
  • Selecting a new cloud application
  • Developing custom software
  • Refreshing network equipment
  • Updating remote access
  • Reviewing backup systems

Three connected stages showing discovery, priority migration and complete post-quantum migration

Where IT support fits

Post-quantum preparation sits within wider security and IT planning. It shouldn't be treated as a separate product sale.

At Your IT Specialist, we can help businesses build a clearer view of their systems and risks through:

  • IT infrastructure reviews
  • Firewall and network support
  • Patching and update management
  • Vulnerability assessments
  • Logs and security monitoring
  • Hardware and software lifecycle planning
  • Cloud application support
  • Custom application advice
  • Remote support for servers, desktops and networks
  • Out-of-hours upgrades and emergency work

Our approach is provider-agnostic. We don't recommend a particular vendor simply because it is familiar or commercially convenient. We look at the current environment, business priorities, supplier support and long-term cost.

That matters with PQC because no single product will solve the whole problem. Different systems will move at different speeds. Some may be updated by suppliers. Others may need re-platforming, replacement or retirement.

Our provider-agnostic IT support guide explains how impartial advice can help businesses make technology decisions without unnecessary sales pressure.

The main takeaway

The NCSC's 2035 target may feel distant, but the planning deadline is much closer.

By 2028, UK businesses should understand where encryption is used, which systems matter most and what suppliers plan to do.

For many SMEs, the right first step isn't buying new quantum-safe technology. It is creating a useful inventory and identifying the information that must remain protected for the longest time.

From there, we can plan upgrades alongside normal IT maintenance and security work.

A clear inventory today gives us better choices tomorrow. It also reduces the risk of rushing into expensive changes when suppliers, customers or regulators start asking difficult questions.

For an impartial review of your IT environment, contact Your IT Specialist. We can help identify practical next steps without pushing unnecessary replacements.

Further reading

Most businesses add software one subscription at a time.

A sales team needs a CRM. A project team chooses a task manager. Finance adds an expense platform. Someone starts a free trial and forgets to cancel it. A new employee receives another licence, even though an existing one was available.

Each decision seems reasonable. Over time, the result can be expensive and difficult to manage.

This is SaaS sprawl: a growing collection of cloud applications, licences and subscriptions without a clear owner or review process.

Recent research suggests that many businesses use only around half of the software licences they pay for. UK firms also face billions of pounds in excess software spending, although estimates vary between studies. The message is consistent: unused licences, duplicate tools and forgotten renewals create avoidable waste.

The good news is that we don't need to replace everything. With a structured review, we can usually reduce costs, improve control and make daily work simpler.

Here are five practical steps to get started.

1. Audit what we actually pay for

We can't reduce waste if we don't know where it is.

The first step is to create a complete list of every business application and subscription. This should include more than the software approved by IT. Some tools may be paid for through:

  • Company credit cards
  • Expense claims
  • Direct debits
  • Department budgets
  • Personal accounts later reimbursed by the business
  • App stores and online marketplaces
  • Free trials that changed into paid plans

Finance records are a useful starting point. We should then compare them with information from identity systems, email accounts, device management tools and application administrator portals.

Business software subscription audit with a central register and checklist

For each application, record:

Information Why it matters
Application name Shows what the tool is used for
Business owner Gives someone responsibility for its value
Supplier and plan Helps us understand the contract
Monthly or annual cost Shows the real financial impact
Number of paid licences Identifies the potential saving
Active users Highlights unused seats
Renewal date Prevents unwanted renewals
Data stored Supports sensible security decisions
Integrations Shows what could be affected by cancellation

We should also look for applications that perform similar jobs. For example, we might find two project management tools, several file-sharing platforms or multiple systems collecting customer information.

A simple spreadsheet is enough for a small business. Larger organisations may benefit from a software asset management platform or a managed IT services partner.

The goal isn't to create paperwork for its own sake. It is to build a clear view of what we own, what we use and what we need to review.

2. Consolidate overlapping tools

Once we have an inventory, we can group applications by purpose.

For example:

  • Customer relationship management
  • File storage and document sharing
  • Team communication
  • Video meetings
  • Project management
  • Accounting and expenses
  • Marketing
  • Password management
  • Cyber security
  • Human resources

We can then ask a straightforward question:

Are we paying for several tools that solve the same problem?

Overlap is often hidden by department boundaries. Sales may use one task manager while operations uses another. Marketing may use a separate file-sharing service, even though the business already has suitable storage in its main productivity platform.

Consolidation doesn't mean forcing every team into the same tool without considering how they work. It means choosing a sensible standard where the features are suitable.

Duplicate business applications being consolidated into one streamlined platform

For each group of overlapping tools, we can decide to:

  • Keep the application with the strongest adoption and best fit
  • Combine two tools where one platform covers both needs
  • Downgrade a plan where advanced features aren't being used
  • Replace a costly or difficult tool with a better option
  • Retire software that no longer has a clear purpose

We should check integrations before cancelling anything. A tool may appear lightly used but still support an important workflow or connect to another system.

This is where impartial IT consulting can help. An independent review should focus on what works best for the business, not on selling a particular vendor or platform. Sometimes the right answer is to consolidate. Sometimes it is to keep a specialist tool because replacing it would create more cost and disruption.

3. Remove unused licences and control renewals

Unused licences are often the quickest source of savings.

For each application, compare the number of paid seats with recent activity. Depending on the tool, useful measures may include:

  • Last login
  • Number of active users
  • Recent file activity
  • Recent projects or transactions
  • Use of premium features
  • Whether the employee still works for the business

We should avoid removing access based on login data alone. Some applications are used monthly, quarterly or only during specific projects. A quick check with the application owner can prevent an important account from being removed.

However, licences belonging to former employees should be disabled promptly. The same applies to abandoned trials, duplicate accounts and users who no longer need premium access.

Before each renewal, review:

  1. How many licences are paid for?
  2. How many are active?
  3. Which features are being used?
  4. Could a lower plan meet the same need?
  5. Is the application still supporting a current business process?
  6. Can the supplier offer more suitable terms?

Renewal dates should be recorded in a shared calendar with reminders at least 60 and 30 days beforehand. This gives us time to negotiate, downgrade or cancel before an automatic renewal takes place.

The saving from one unused seat may be small. Across ten or twenty applications, the total can become significant.

4. Centralise software procurement

SaaS sprawl often returns when every department can buy software independently.

We don't need a slow approval process. We do need one clear route for new applications.

A simple procurement policy can ask for:

  • The business problem the application will solve
  • The expected number of users
  • The full cost, including setup and renewal charges
  • Whether an existing approved tool can do the same job
  • What business data the application will access
  • Who will own the application
  • How access will be removed when someone leaves
  • What happens to the data if the contract ends

The request should then be reviewed by the right people. This may include the department owner, finance and IT. Security input is important where the application handles customer details, financial information, confidential documents or employee records.

Central procurement also gives us better visibility when negotiating. Instead of several departments buying separate plans from the same supplier, we may be able to combine requirements and secure clearer terms.

A central register should be updated whenever a tool is approved, changed, renewed or cancelled. This creates a reliable record and reduces the chance of forgotten subscriptions.

This approach supports good data governance as well. We can see which suppliers hold business information, who has access and how applications connect to one another.

5. Set regular review cycles

A one-off clean-up is useful, but it won't stop sprawl returning.

Business needs change. Teams start new projects, employees move roles and software providers change their pricing. A tool that was useful last year may no longer be the right choice.

We should schedule a review at least once every quarter. For smaller businesses, a six-monthly review may be enough to begin with.

Each review should cover:

  • New subscriptions added since the last review
  • Licence use and user numbers
  • Upcoming renewals
  • Duplicate applications
  • Security and access settings
  • Data stored with each supplier
  • Applications no longer owned by a current employee
  • Changes in business requirements

Quarterly SaaS governance review with security, procurement and renewal controls

It helps to assign two types of owner:

  • A business owner who understands the application’s purpose
  • An IT or finance owner who tracks access, cost and renewal details

This shared responsibility avoids a common problem: everyone assumes someone else is checking the subscription.

We can also set a few simple rules:

  • No software purchase without an identified owner
  • No shared accounts where individual accounts are available
  • Access removed promptly when someone leaves
  • New applications checked against the existing software list
  • Renewal decisions made before the contract date
  • Unapproved tools reported without blame, so they can be assessed properly

The aim is control, not restriction. Staff should have a clear way to request the tools they need. When the process is simple and responsive, there is less reason to work around it.

How IT support can help

SaaS sprawl sits between finance, operations, security and technology. That can make it difficult to manage internally.

An IT support for business partner can help us:

  • Build a software and licence inventory
  • Review active users and application access
  • Identify duplicate or unsuitable tools
  • Improve account joiner and leaver processes
  • Check integrations and data flows
  • Plan safe cancellations and migrations
  • Create a practical procurement policy
  • Set up regular reviews and renewal reminders

The right advice should be proportionate to the business. We may only need a focused audit and a simple register. Larger organisations may need ongoing licence management as part of their wider IT support services.

At Your IT Specialist, our approach is provider-agnostic. We don't recommend a product simply because it is familiar or more expensive. We look at the current setup, the business goals and the likely long-term cost.

Take back control before the next renewal

SaaS sprawl rarely appears in one large decision. It builds through small purchases, unused accounts and automatic renewals.

We can start with one department or one software category. List what we pay for, check what is being used and review the next renewal date. From there, we can remove waste and build a process that keeps the software estate manageable.

Reducing the number of applications can lower costs, simplify support and improve data control. A focused review now can also make future growth easier.

For impartial help reviewing your software subscriptions and wider technology setup, explore our IT consulting and support services or read our guide to choosing managed IT services without getting oversold.

Further reading

Cyber insurance can help a business recover after a serious incident. It may cover costs such as investigation, legal support, data recovery and business interruption.

However, insurance isn't a replacement for good security. In 2026, insurers are asking more detailed questions before providing cover or renewing a policy. They want evidence that the main risks are being managed.

For UK SMEs, this means cyber insurance is now closely linked to day-to-day IT management.

The exact questions vary between insurers and policies. Still, five areas appear regularly:

  1. Multi-factor authentication
  2. Patching and software updates
  3. Antivirus and endpoint protection
  4. Tested and protected backups
  5. Access control and security logging

Let's look at what insurers are checking and how we can prepare.

Why cyber insurance applications are becoming more detailed

Cyber attacks can create significant costs for a business. A ransomware incident, for example, may stop staff working, affect customer services and make important data unavailable.

Insurers need to understand how likely these events are and how severe the impact could be. They also need confidence that a business is taking reasonable steps to reduce the risk.

This is why application forms now ask about specific controls rather than general questions such as, “Do you have antivirus?”

We may be asked:

  • Which systems use multi-factor authentication?
  • How quickly are serious security updates installed?
  • Are all laptops, desktops and servers protected?
  • When was the last backup restore test?
  • Who has administrator access?
  • Are important security events recorded and reviewed?

The answers need to be accurate. If a policy states that a control is in place when it isn't, this may affect a future claim.

The National Cyber Security Centre’s cyber insurance guidance recommends reviewing both our security measures and the policy wording before taking out cover.

Visual checklist showing MFA, updates, endpoint protection, backups and access logs

1. Multi-factor authentication everywhere

Passwords alone are no longer enough for important accounts.

Multi-factor authentication, or MFA, asks users to confirm their identity in a second way. This could be through an authenticator app, security key or another approved method.

Insurers commonly expect MFA for:

  • Email accounts
  • Microsoft 365, Google Workspace and other cloud services
  • VPNs and remote access tools
  • Administrator accounts
  • Financial and business-critical applications
  • Remote desktop access

The phrase “everywhere” needs careful attention. Enabling MFA for one cloud service isn't the same as enforcing it across the business.

How to prepare

Start by listing every system that staff use to access business data. Then confirm that MFA is enabled and enforced, rather than simply offered as an optional setting.

Administrator accounts deserve particular attention. They should always use MFA and shouldn't be used for ordinary email or web browsing.

We should also review old accounts, shared logins and accounts belonging to former employees. Removing unnecessary accounts reduces the number of ways an attacker could gain access.

Our cyber security services can help with MFA, conditional access, privileged access and account reviews across common cloud platforms.

2. A clear patching routine

Security updates fix weaknesses in operating systems, applications, network equipment and other technology.

Leaving systems unpatched gives attackers more time to exploit known problems. Insurers therefore want to see a repeatable patching process, not occasional updates when someone remembers.

Many application forms ask whether critical or high-risk updates are installed within a defined period. Fourteen days is a common benchmark, although internet-facing systems may need faster action.

A good patching routine should cover:

  • Windows and Linux computers
  • Servers and virtual machines
  • Firewalls and network equipment
  • Business applications
  • Cloud-connected devices
  • Printers, phones and other connected equipment
  • Firmware where relevant

How to prepare

We need a current list of the technology we own or manage. Without an accurate list, it's difficult to know whether every system has been updated.

Next, define:

  • Who checks for updates
  • Which updates are urgent
  • How quickly they should be installed
  • How changes are tested
  • What happens if an update fails
  • How completion is recorded

Keep patch reports and exception records. If an update can't be installed immediately because it could interrupt a critical service, record the reason and the temporary protection in place.

Regular vulnerability assessments can also help identify devices or software that have been missed. This gives us a clearer view before an insurer asks for it.

3. Antivirus and endpoint protection

Traditional antivirus still has a role, but insurers increasingly expect business-grade endpoint protection across all supported devices.

Endpoint protection should cover laptops, desktops and servers. It should also be centrally managed, kept up to date and able to raise an alert when something unusual happens.

Insurers may want to know:

  • Whether every endpoint is protected
  • Whether servers are included
  • Who receives security alerts
  • How alerts are investigated
  • Whether protection can isolate an infected device
  • Whether devices outside the office are covered

A single unprotected laptop can create a serious gap, particularly when staff work remotely.

How to prepare

Use a central management console where possible. This gives us a reliable view of covered devices, outdated agents and active alerts.

We should also check for:

  • Devices that haven't connected recently
  • Unmanaged personal computers
  • Unsupported operating systems
  • Disabled security software
  • Servers missing endpoint protection
  • Alerts that have been ignored or closed without review

Endpoint protection works best alongside secure email, firewall rules, regular patching and staff awareness. No single product can remove every risk.

Your IT Specialist provides antivirus and EDR deployment, patch management and remote monitoring without tying recommendations to one vendor.

4. Backups that can be restored

A backup is only useful if we can restore it.

Insurers are looking closely at ransomware recovery. They may ask whether backups are separate from the main network, protected from deletion and tested regularly.

A backup stored on the same network as the live systems may be affected by the same attack. A cloud snapshot may also be insufficient if an attacker can access or delete it.

A stronger approach includes:

  • Regular automated backups
  • A separate offline or immutable copy
  • Protection for backup administrator accounts
  • Monitoring for failed backups
  • A defined retention period
  • Regular restore tests

The right testing interval depends on the business. Testing at least annually is useful, while critical systems may need testing every 90 days or after major changes.

Protected backup database separated from the main network with a restore arrow and test calendar

How to prepare

Choose an important file, application or server and perform a controlled restore. Record:

  • What was restored
  • When the test happened
  • How long it took
  • Whether the data was complete
  • Any problems found
  • What was changed afterwards

We should test more than whether a job reports “successful”. A backup can complete correctly while still failing to restore a working system.

The NCSC's guidance on offline backups provides further advice for reducing the impact of ransomware.

5. Access control and useful logging

This final check combines two related questions:

  1. Who can access our systems?
  2. Can we see what happened if something goes wrong?

Most staff don't need administrator rights. Giving people more access than they need increases the possible impact of a stolen account.

Insurers may ask about:

  • The number of administrator accounts
  • Separate everyday and admin accounts
  • User access reviews
  • Leavers and joiners
  • Shared accounts
  • Access to financial and customer data
  • MFA for privileged accounts

Logging is also important. We should be able to review events such as:

  • Successful and failed sign-ins
  • Changes to administrator accounts
  • MFA changes
  • Security alerts
  • Backup failures
  • Firewall activity
  • Unusual access to important systems

We don't need to collect every possible log without a plan. The aim is to record the events that help us spot an attack and understand what happened.

How to prepare

Create a simple access review process. Review privileged accounts regularly and remove access that is no longer needed.

Then decide:

  • Which events must be recorded
  • How long logs should be kept
  • Who reviews important alerts
  • How suspected incidents are escalated
  • Where evidence is stored

Organised security evidence dashboard showing access logs, endpoint alerts, patch status and firewall activity

Evidence is increasingly important. Useful records may include MFA settings, patch reports, endpoint dashboards, backup test results, access reviews and incident notes.

Don't forget firewalls and Cyber Essentials

The five checks above are central to many insurance applications, but they aren't the whole security picture.

A properly configured firewall, secure settings, device encryption, malware protection and user access controls all support a stronger application.

The UK government's Cyber Essentials scheme provides a recognised baseline for protecting against common online threats. It may also support insurance discussions and demonstrate our approach to customers and suppliers.

Certification doesn't guarantee cover. We still need to read the policy carefully and answer the insurer's questions accurately.

How to keep premiums reasonable

There are no guaranteed savings, but good security can improve our position when comparing policies.

Before renewal, we can:

  1. Review the insurer's questions early.
  2. Check every answer against current systems.
  3. Close gaps before completing the application.
  4. Keep evidence in one secure location.
  5. Tell the broker about Cyber Essentials certification.
  6. Check that the policy covers our main risks.
  7. Confirm any required security controls after a claim.
  8. Review changes to systems, suppliers and remote working.

We should also check exclusions. Some policies may treat business email compromise, unsupported software or poor backup practices differently. A broker can explain the financial terms, while an IT specialist can help verify the technical answers.

A practical pre-application checklist

Before requesting a quote, let's confirm:

  • MFA is enforced for email, remote access, cloud services and administrators.
  • Critical security updates are installed within our defined timeframe.
  • All supported endpoints and servers have active protection.
  • Backups include a separate offline or immutable copy.
  • Important data has been restored successfully in a recent test.
  • Administrator access is limited and reviewed.
  • Security events are logged and checked.
  • Firewalls are configured and maintained.
  • Evidence is available for each answer.
  • The policy covers the incidents that matter to our business.

If any answer is unclear, it's better to investigate it before submitting the application.

How Your IT Specialist can help

Cyber insurance requirements are easier to manage when they form part of normal IT support rather than a last-minute exercise.

Your IT Specialist provides impartial, provider-agnostic advice for businesses of all sizes. We can help with:

  • Firewall installation and support
  • MFA and access control
  • Antivirus and endpoint protection
  • Patch management
  • Vulnerability assessments
  • Security log analysis
  • Network and cloud security reviews
  • Backup and recovery checks
  • Practical security policies

We can also provide remote support or complete planned work outside normal hours where changes could affect staff.

Our goal is simple: build security controls that work for the business, keep clear records and improve resilience over time.

Contact Your IT Specialist to review your current position before applying for or renewing cyber insurance.

This article provides general information and isn't insurance, legal or financial advice. Policy requirements differ, so we should confirm the details with a qualified broker and the insurer.

Most businesses have backups. Fewer can prove they’ll work when needed.

A backup job showing “successful” only tells us that a copy was created. It doesn’t confirm that the copy is complete, usable, secure or quick to restore.

That distinction matters. Data may become unavailable after ransomware, accidental deletion, hardware failure, a failed update or a cloud service problem. When it does, we need more than a reassuring status message. We need a tested route back to normal working.

The National Cyber Security Centre (NCSC) recommends regular backups and regular restore testing. The Information Commissioner’s Office (ICO) also expects organisations to test recovery arrangements and keep them fit for purpose.

Here are seven questions every business should ask.

1. Do we know exactly where our backups are stored?

“Somewhere in the cloud” isn’t a recovery plan.

We should be able to identify where each backup is held, which systems it covers and how we access it. This may include:

  • A local backup appliance or server
  • An off-site cloud backup service
  • External storage
  • Virtual machine snapshots
  • Backups for individual applications
  • Copies held by a third-party provider

We also need to know whether the backup is in the same building, network or cloud account as the live data. If a fire, flood, power problem or ransomware attack affects the main environment, a nearby or connected backup may be affected too.

A simple backup register can help. For each system, record:

  • What data is protected
  • Where the backup is stored
  • How often it runs
  • How long copies are retained
  • Who can access it
  • How it can be restored

This gives business leaders a clear view instead of relying on assumptions. Our business IT support team can help review this information across servers, desktops, networks and cloud services.

2. Who owns the backup and recovery process?

A backup can fail quietly if nobody is responsible for checking it.

Ownership doesn’t have to sit with one internal IT employee. It may sit with a managed IT services provider, an internal team or a shared arrangement. What matters is that responsibilities are clear.

We should know:

  • Who receives alerts when a backup fails
  • Who checks backup reports
  • Who approves changes to backup policies
  • Who can start a restore
  • Who decides which systems return first
  • Who contacts suppliers or insurers during a major incident
  • Who is accountable if a restore fails

It’s also sensible to avoid dependence on one person. If the only person who knows the backup password is unavailable, recovery may be delayed when every minute matters.

Access should be protected with strong passwords, multi-factor authentication and limited permissions. People who need to restore data may not need permission to delete every backup. Separating these roles reduces risk.

A reliable IT helpdesk should support this process, not simply wait for someone to report a problem.

Separated local, off-site and immutable backup locations protected by a shield

3. When was the last time we tested a real restore?

This is the uncomfortable question.

If we’ve never restored a file, mailbox, application or server from backup, we don’t yet know whether the backup works. We only know that a backup task ran.

A sensible testing programme should include different levels of recovery:

  1. A small file restore to confirm everyday recovery works.
  2. A folder or mailbox restore to check user data.
  3. A critical application restore to confirm important business information is usable.
  4. A server or virtual machine restore to test a wider failure.
  5. A recovery exercise to check what happens during a serious incident.

The restored data should be checked by someone who uses it. Technical completion isn’t enough. A finance user should confirm that financial records open correctly. A department manager should confirm that documents and workflows are available.

The NCSC recommends checking that backups can be restored, not just that they exist. A test from two years ago is useful history, but it doesn’t prove that today’s environment is recoverable.

We should repeat tests after major changes, such as a new server, application, cloud service or backup platform.

4. How quickly can we restore, and how much data could we lose?

A working restore may still be too slow for the business.

We need to set realistic recovery expectations for important systems:

  • How soon must email be available?
  • How quickly must finance systems return?
  • How long can staff work without shared files?
  • Which systems can be restored later?
  • How much recent data can we afford to lose?

These decisions are often described using two simple measures:

  • Recovery Time Objective (RTO): how quickly a system needs to return.
  • Recovery Point Objective (RPO): how much recent data we could lose.

For example, a business may decide that its finance system must return within four hours, while losing up to one hour of recent data is acceptable. That decision affects backup frequency, storage and recovery design.

During a restore test, we should record the time from starting the process to confirming that the system is usable. We should then compare the result with the agreed target.

If the business expects recovery within four hours but the last test took two days, the backup may be technically valid but operationally unsuitable. That gives us a clear improvement to make.

Laptop showing a restore process beside a clock, server and continuity checklist

5. Are our backups off-site, separated and protected from ransomware?

Keeping a second copy in the same place as the first isn’t enough.

A resilient approach keeps at least one copy away from the main environment. It should also be protected from unauthorised changes or deletion.

Depending on the business, this may involve:

  • Off-site storage
  • A separate cloud account
  • A separate network
  • Offline backup media
  • Immutable backup copies
  • Version history and delayed deletion
  • Restricted administrator access

An immutable backup is designed so that it can’t be changed or deleted during its protected retention period. This can help if an attacker gains access to the main network or an administrator account.

The NCSC’s ransomware-resistant backup guidance recommends designing backups to withstand destructive actions, retain earlier versions and support safe recovery.

We should also ask whether backup administration uses separate credentials. If the same account controls both live systems and backups, one compromised password may create a much larger problem.

No backup design removes every risk. The aim is to ensure that one incident can’t remove every recovery option.

6. Do our backups cover cloud applications?

Cloud services are not automatically the same as cloud backups.

Microsoft 365, Google Workspace, online accounting platforms, CRM systems and other SaaS applications may have retention or recovery features. These can be useful, but they may not provide the level of protection or control we expect.

We should check:

  • Which cloud services are included
  • Which data types are covered
  • How long deleted data is retained
  • Whether earlier versions can be restored
  • Whether individual mailboxes, files or records can be recovered
  • Whether configuration and user information are protected
  • Where backup copies are stored
  • Who controls the backup account

For Microsoft 365, for example, we shouldn’t assume that email, SharePoint, Teams, OneDrive, user accounts and settings all have identical recovery options.

The right question isn’t “Is Microsoft 365 backed up?” It’s “Can we restore the specific information the business needs, at the point in time we need it?”

A review of cloud applications should form part of wider managed IT services, especially when new applications are added without a central review.

Cloud email, documents, collaboration and CRM data flowing into a secure backup system

7. Is the recovery process documented and regularly reviewed?

Recovery is harder when everyone is under pressure.

A short, clear recovery document gives the team something practical to follow. It should include:

  • The systems covered
  • The order in which systems should return
  • Backup locations
  • Access instructions
  • Restore steps
  • Supplier contact details
  • Internal decision-makers
  • RTO and RPO targets
  • Data validation checks
  • Escalation steps
  • The date of the last successful test

The document should be stored somewhere available during an outage. If it only exists on the file server that is unavailable, it won’t help much.

After each test, record what happened:

  • What was restored
  • When it was tested
  • How long it took
  • Who checked the result
  • What went wrong
  • What needs to change

The process should be reviewed after major IT changes and at regular intervals. A recovery plan that matched the business three years ago may no longer cover its current systems.

Open recovery playbook with numbered steps, ownership icon and successful test mark

Move from assumed recovery to proven recovery

Backups are important, but recoverability is the real measure.

If we can’t say where our backups are, who owns them, whether they’ve been tested, how quickly they can restore, whether they’re protected from ransomware, what cloud data they cover and where the recovery steps are documented, we have an assurance gap.

That gap is fixable.

Start with one critical system. Check its backup, run a restore test and record the result. Then work through the rest of the environment. This approach is more useful than buying another tool without checking whether the current one works.

Your IT Specialist provides impartial IT support, backup reviews and recovery guidance for businesses using Windows, Linux, virtualisation, networks and cloud applications.

We’ll ask the questions that are easy to postpone, then help turn the answers into a practical recovery plan.

Because the best time to discover a backup problem is during a controlled test : not during a business-critical outage.

Sources and further guidance

Style Switcher

Header Style
Pre Define Colors

Custom Colors
Layout