Resilience is often described as a feeling. Leaders feel confident that systems are secure, backups are working and the business could continue after a serious incident.
That confidence is useful. Evidence is better.
For UK SMEs, resilience should be demonstrable through a connected programme of governance, technical controls, tested recovery, dependable business systems and disciplined technology spending. ISO 27001, Cyber Essentials, Disaster Recovery and Dynamics 365 should not be treated as separate projects competing for attention. They should reinforce one another.
That requires more than a certificate, a backup report or a new ERP system. It requires an IT strategy led from the top, the role of the Fractal IT Director, with technical execution following a clear business case.
Compliance should produce evidence, not paperwork
Cyber Essentials is a practical baseline for defending against common cyber threats. The National Cyber Security Centre identifies five core technical controls:
- Firewalls
- Secure configuration
- Security update management
- User access control
- Malware protection
The NCSC Cyber Essentials overview makes the distinction clear: Cyber Essentials helps organisations protect against common attacks, while Cyber Essentials Plus adds independent technical testing.
ISO 27001 operates at a different level. It is a risk-based management system covering information security governance, risk treatment, supplier management, incident response, business continuity and continual improvement.
For an SME, the practical relationship is straightforward:
- Cyber Essentials establishes a defensible technical baseline.
- ISO 27001 provides the management framework around information security and risk.
- Disaster Recovery demonstrates how the business will respond when prevention is not enough.
- Business systems such as Dynamics 365 Business Central need to be included in the scope, risk assessment and recovery plan.
The mistake is to treat compliance as a document production exercise. Policies that nobody follows are simply very formal fiction.
A stronger approach creates an evidence trail. That might include:
- A current asset and service register
- Owners for critical systems and information
- Access reviews with dates, decisions and approvals
- Patch and configuration records
- Supplier due diligence
- Incident logs and lessons learned
- Backup success and restoration records
- Recovery test plans and results
- Management review actions
- Evidence that corrective actions were closed
The value is not limited to an audit. The same evidence helps directors answer customer due diligence questions, support cyber insurance applications and understand whether technology controls are working in practice.
The evidence pack should mirror the risk
Evidence is most useful when it reflects business risk rather than merely collecting whatever a platform happens to report.
Start with a Business Impact Analysis. Identify the processes that would materially affect revenue, customer service, regulatory obligations or cash flow if they stopped. Then map the supporting systems and dependencies.
For a finance-led SME, that may include:
- Dynamics 365 Business Central
- Banking and payment integrations
- Microsoft 365 identities and email
- Warehouse or stock systems
- Customer and supplier data
- Network Solutions and remote access
- Voice and Connectivity
- Critical third-party services
Each important process should have a named owner, an agreed tolerance for disruption and a recovery priority.
This is where Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) become useful.
- RTO: how quickly the service needs to be available.
- RPO: how much recent data the organisation can afford to lose.
These targets should influence architecture and spending. A system requiring rapid recovery should not quietly depend on an untested manual process or a single administrator’s memory.
Disaster Recovery must be tested at several levels
A Disaster Recovery plan is not proven because it exists in SharePoint. It is proven when people can execute it, systems can be restored and the results are measured.
A pragmatic testing cadence for a UK SME could include:
| Activity | Suggested cadence | Evidence produced |
|---|---|---|
| Backup restoration test | Quarterly | Restore log, integrity check and sign-off |
| Access and administrator review | Quarterly | Review record, exceptions and approvals |
| Tabletop exercise | Quarterly | Scenario notes, decisions and actions |
| Patch and configuration review | Monthly, with quarterly reporting | Compliance report and remediation plan |
| Service-level recovery test | Twice yearly | RTO/RPO results and test report |
| Cyber incident exercise | Annually | Incident timeline, communications and lessons learned |
| Management review of resilience programme | At least annually | Decisions, risks and improvement actions |
This is not a universal certification rulebook. It is a sensible operating rhythm that gives leaders regular assurance without turning every month into an emergency exercise.
The important detail is to test the dependencies, not just the headline application. Restoring a database is not the same as restoring the ability to invoice, pay suppliers, ship goods or answer customers.
A useful recovery test should record:
- What scenario was tested
- Which systems and teams were involved
- The planned RTO and RPO
- The actual recovery time and data position
- Any manual workarounds required
- Decisions made during the exercise
- Failures, gaps and owners
- A target date for remediation
- Retesting evidence after the fix
That final point matters. A failed test is not automatically a failure of the programme. An unrecorded failure that nobody corrects is.
Dynamics 365 readiness is a resilience question
Dynamics 365 Business Central is not simply an accounting application. It can support finance, sales, purchasing, inventory, warehousing, distribution, service management and reporting. The Microsoft Dynamics 365 page describes its role as a cloud ERP platform that connects business operations with Microsoft 365 tools and real-time reporting.
That breadth makes implementation readiness a governance and continuity issue.
Before configuration begins, an SME should be able to explain:
- Which processes Business Central will replace or improve
- Which data is authoritative
- Which integrations are business-critical
- Who owns master data
- Which roles require privileged access
- What the cutover fallback would be
- How the business would operate during an outage
- What evidence is needed for financial control and audit
A Dynamics 365 Jump Start should therefore begin with decision-making, not screens. The first phase should establish scope, process priorities, data quality, reporting requirements, integration dependencies and acceptance criteria.
Implementation readiness can also expose hidden resilience weaknesses. For example:
- Unclear approval routes may become access-control risks.
- Poor customer or supplier data may undermine reporting.
- Unmapped integrations may create recovery blind spots.
- Manual spreadsheets may reveal an undocumented dependency.
- Inconsistent user roles may create excessive privilege.
- Weak change control may make future audits painful.
A consultancy-first approach keeps the ERP programme aligned with the wider IT strategy. Traditional Managed IT Services, Helpdesk Support, Cloud Solutions, Network Solutions and Voice and Connectivity can then be added as execution capabilities around that strategy. Useful bolt-ons, not substitutes for it.
Legacy platforms still need a place in the model
Not every SME is starting from a clean cloud estate. Some rely on established IBM i or Power Systems platforms supporting finance, manufacturing, distribution or specialist operational workloads.
These environments deserve a risk-led treatment rather than a fashionable migration slogan. An IBM i platform may be highly resilient, but its supporting knowledge, interfaces, backup process, privileged access and recovery documentation still need attention.
Where IBM i, Power Systems or AS/400 management and support is involved, IBM i Management should be considered a specialised technical consultancy niche within the wider resilience programme.
The key questions are familiar:
- Is the platform included in the asset register?
- Is its business criticality understood?
- Are interfaces documented?
- Are restores tested?
- Are privileged accounts reviewed?
- Can the organisation recover if its most experienced administrator is unavailable?
- Does the Disaster Recovery plan cover the surrounding business process?
A resilient estate is not defined by whether a system is old or new. It is defined by whether its risks are understood and its recovery can be demonstrated.
Technology Expense Management makes resilience affordable
Security and continuity programmes often fail commercially before they fail technically. The business sees rising subscription costs, overlapping tools, duplicate connectivity and consultancy invoices, then asks a reasonable question: what is this programme returning?
Technology Expense Management provides the answer.
It creates a disciplined view of technology expenditure across:
- SaaS and cloud subscriptions
- User licences
- Telecoms and mobile services
- Network circuits
- Hardware estates
- Support contracts
- Backup and security services
- ERP-related costs
- Supplier commitments and renewal dates
The objective is not to cut indiscriminately. It is to align spend with business risk.
An expensive service may be justified if it supports a critical RTO. An apparently cheap licence may be wasteful if it is unused, duplicated or no longer aligned with the operating model.
A useful expense review should connect each cost to:
- A business owner
- A business process
- A security or continuity requirement
- A measurable usage pattern
- A renewal or exit decision
That turns cost reduction into programme funding. Savings from unused licences, billing errors, redundant services and poorly negotiated renewals can help fund security remediation, recovery testing or Dynamics 365 improvements.
The Technology Expense Management service page highlights the importance of auditing telecoms, cloud, SaaS and supplier invoices rather than accepting them as fixed overheads.
Build a resilience story the board can understand
A credible resilience programme should allow directors to answer five questions:
- What are our most important business processes?
- What could prevent them from operating?
- Which controls reduce that risk?
- Have we tested recovery in realistic conditions?
- Are we spending proportionately on the outcomes we need?
ISO 27001, Cyber Essentials, Disaster Recovery and Dynamics 365 become far more valuable when they answer those questions together.
The role of the Fractal IT Director is to keep the whole pattern visible: governance at the centre, infrastructure around it, business systems connected to it and specialist execution brought in where required. That may include Managed IT Services, Helpdesk Support, Cloud Solutions, Network Solutions or Voice and Connectivity. The services matter, but they should serve the strategy.
Resilience you can prove is not a badge collection. It is an evidence-led IT estate in which security controls, recovery capability, core systems and Technology Expense Management reinforce one another.
That is how compliance becomes operational confidence, and how the programme begins to pay for itself.
Join The Discussion