IT Governance

cyber essentials failure reasons how to avoid a shield five panels plinth

Cyber Essentials Failure Reasons: Proven Fixes to Avoid

Cyber Essentials failure is rarely caused by a sophisticated security gap. It is caused by an end-of-life laptop nobody logged, a cloud service quietly left outside the scope statement, or a director who has been reading email from an administrator account for four years. This guide works through the reasons organisations actually fail against version 3.3 of the Requirements for IT Infrastructure: scope boundaries that exclude what they cannot, unsupported software as an automatic fail, the 14-day patching deadline and its CVSS trigger, administrator account separation, mandatory MFA on cloud services, home working and BYOD traps, undocumented firewall rules, and the five Cyber Essentials Plus test cases where paper answers meet a live scan. It closes with a 60-day readiness plan and what to do inside the two-working-day correction window if a result has already come back non-compliant.

Read more
cyber essentials for suppliers contract clauses a shield with keyhole plinth

Cyber Essentials for Suppliers: Proven Safe Contract Terms

Most organisations ask for Cyber Essentials during the tender and never mention it again, which leaves the requirement sitting in a questionnaire with no expiry date, no evidence obligation and no consequence attached. This guide shows how to write it into the contract instead: which suppliers belong in scope and at what level, model clause wording for the certification obligation, how to define scope so a certificate for somewhere else cannot satisfy it, what evidence to demand and how to verify it against the register, how the obligation flows down to subcontractors, what happens when certification lapses mid-term, and a proportionate remedy ladder that runs from a rectification plan to termination without ending a workable relationship.

Read more
software handover checklist changing development partners a vault door ajar plinth

Software Handover Checklist: Essential Guide to Avoid Risk

Changing development partners is the moment your leverage is highest and your knowledge is thinnest. This software handover checklist covers everything that has to transfer before the outgoing supplier’s last billable day: repositories and full commit history, build and deployment pipelines, infrastructure accounts, domains and certificates, secrets and credentials, third-party licences, architecture and runbook documentation, test suites, and the data your users depend on. It sets out realistic timelines and costs for a structured transition, the acceptance tests that prove the handover actually worked, the contract clauses that make all of it enforceable, and the mistakes that turn a routine supplier change into a rewrite.

Read more
in-house developers - in house developers vs software agency vs freelancers a three hexagonal pillars plinth

In-House Developers vs Agency vs Freelancer: Proven Best Fit

In-house developers, a software agency and freelancers are not three prices for the same thing — they are three different products, sold in three different units, carrying three different kinds of risk. This guide normalises all three to a comparable annual cost for the 2026 UK market, sets out the on-costs that make a salary roughly 1.5 times its headline figure, and compares the routes on speed to first release, delivery risk, control, knowledge retention and intellectual property. It includes a weighted scoring method you can run in twenty minutes, the hybrid core-plus-capacity model most UK companies end up with, the IR35 and copyright traps that catch contractor engagements, and the hiring mistakes that make the in-house route the least reversible of the three.

Read more
software development company questions to ask a magnifier over three cubes

Software Development Company: 30 Essential Risk Questions

Software development company pitches converge fast: by the third meeting everyone is agile, everyone has a dedicated senior team, and every quote sits within twenty per cent of the others. The differences that decide whether your project ships only surface when you ask specific, verifiable questions. This guide gives you thirty of them, grouped into the seven areas where engagements actually break down — team and continuity, delivery process and evidence, price and change control, code ownership and exit rights, security and data protection, support after launch, and reference checking — with UK day-rate bands by supplier type, a scoring method that weights the things which predict outcomes, the contract clauses worth holding out for, and the red flags that should end a shortlist.

Read more
rescue failing software development project a cracked sphere held by ring

Failing Software Development Project: Best Proven Rescue

Software projects rarely fail in a single moment. They drift — a sprint slips, integration is deferred, a status report stays amber for eleven weeks — until the gap between reported progress and real progress can no longer be closed inside the original budget. Most of those projects are still recoverable, and for far less than the cost of starting again. This guide covers the practical rescue: the four failure signatures that separate a struggling project from a genuinely failing one, a ten-day audit that produces defensible numbers instead of percentage-complete fiction, the five root cause families and how to tell which two you have, the four rescue options with UK cost bands, the governance changes that stop a rescued project relapsing, and the three signals that mean you should stop and salvage instead.

Read more
legacy system modernisation rehost refactor rebuild replace a monolithic block on plinth

Legacy System Modernisation: Proven Guide to Avoid Risk

The four routes out of a legacy system are well known — rehost, refactor, rebuild or replace — and the wrong one gets chosen more often than not, usually because the decision is made on temperament rather than evidence. This guide works through what modernisation actually means, the four options in detail with the conditions each one suits, a six-factor scoring model that turns preference into a defensible ranking, what each route costs in money and elapsed time, how to sequence delivery with the strangler fig pattern so the business keeps running, and the failure patterns that sink modernisation programmes.

Read more
technical debt audit measure cost prioritise repairs a magnifying lens on plinth

Technical Debt Audit: Essential Guide to Avoid Costly Risk

Every development team knows its codebase has problems. Far fewer can say what those problems cost per month, which of them is compounding, and which single item deserves the remediation capacity anybody will realistically approve this quarter. This guide covers the full exercise: what a technical debt audit measures and deliberately ignores, the six categories of debt to inventory, the five passes that make up the audit, four methods for costing what you find, the delivery metrics that survive a board meeting, and how to rank repairs by cost of delay rather than by whichever module irritates the loudest engineer.

Read more
cyber security and resilience bill a glossy shield ringed by network nodes

Cyber Security and Resilience Bill: Essential Risk Guide

The Cyber Security and Resilience Bill brings managed service providers, data centres and designated critical suppliers into cyber regulation for the first time. Even businesses that are never regulated directly will feel it, because their IT supplier acquires a regulator, a 24-hour incident reporting clock and turnover-based fines. This guide covers where the Bill has reached in Parliament, the four-part managed service provider test, the customer notification duty most buyers miss, the two penalty bands, and the five questions worth putting to your provider before your next renewal.

Read more
CHAT