Managed technology services
Day-to-day operation of the systems a business runs on: endpoints, identity, network and backup, plus the monitoring that catches problems before anyone files a ticket.
Focus
Technology services, done unglamorously well.
The group's first operating company works in managed and co-managed IT, for organisations that need their systems to simply keep working. That is the whole job.
Operating areas
Four areas of work
Co-managed IT
Working alongside an existing internal team rather than replacing it. The in-house staff keep ownership; we take the load they do not have capacity to carry.
Security and continuity
Mail authentication, patch discipline, least-privilege access, tested restores. The unglamorous work that decides whether an incident is an afternoon or a quarter.
Systems and web
Practical build work: internal tooling and integrations, plus fast, maintainable websites that a business can actually keep current.
Co-managed IT
Where the line sits
Co-managed arrangements fail when nobody wrote down who owns what. This is the division we start from.
Fig. 1
Service design, written ahead of the entity that will run it
Direction and priorities
The internal team keeps
Budget, vendor choice, the call on what the business needs next.
Held jointly
An agreed plan for the year, revisited when reality disagrees with it.
We carry
Honest advice on what each option costs to run, not just to buy.
Day-to-day requests
The internal team keeps
Whatever they want to keep. The internal team stays the face of IT if that is what works.
Held jointly
A single queue, so nothing is fixed twice or dropped twice.
We carry
The overflow, the after-hours, and the tickets nobody has time for.
Identity and access
The internal team keeps
The decision of who should have access to what.
Held jointly
Joiner and leaver handling, done against a checklist rather than from memory.
We carry
Enforcement: least privilege and MFA coverage, reviewed periodically for the exceptions.
Patching and updates
The internal team keeps
The maintenance windows the business can tolerate.
Held jointly
An exceptions list, with the reason each entry is on it.
We carry
The schedule itself, and the follow-up on whatever failed to apply.
Backup and recovery
The internal team keeps
Deciding what the business cannot afford to lose.
Held jointly
Recovery objectives, in writing, agreed before they are needed.
We carry
Running the backups, and proving by restoring that they work.
When something breaks
The internal team keeps
Declaring what it means for the business, and who needs to know.
Held jointly
The first hour runs to an agreed sequence – Fig. 2 – settled before it is ever needed.
We carry
Detection and the technical response, then the written account afterwards.
Documentation
The internal team keeps
Institutional knowledge: why things are the way they are.
Held jointly
One system of record, kept current by whoever touched it last.
We carry
Writing down every change we make, without being asked.
Incident response
The first hour, as designed
Most of what determines how bad an incident gets is decided before anyone knows how bad it is. This is the sequence the operating company is being built to run.
Fig. 2
Service design, written ahead of the entity that will run it
-
Confirm
Establish that something is actually wrong
A real incident is separated from a stale alert or a bad dashboard before anything is restarted on a hunch. Most first reports are right that something is wrong, and wrong about what.
-
Scope
Work out what it touches
One user or every user; one system or everything downstream of it. Scope decides everything that follows. It gets settled before any fix is attempted.
-
Contain
Stop it spreading before curing it
If it looks like compromise, isolation comes before diagnosis. An isolated machine can be examined at leisure; a credential in active use somewhere else cannot.
-
Communicate
Tell the people affected what is known
A short, honest note beats silence: what is affected, what is not, and when the next update comes. It goes out before the fix is found, not after.
-
Restore
Bring service back the boring way
Known-good state first: fail over, roll back, restore. The clever root-cause hunt can wait. Locked-out staff cannot.
-
Record
Write down what happened while it is still true
Timestamps, actions taken, what was believed at the time. Memory rewrites itself within a day; the record is what makes the review afterwards worth holding.
Verification
What gets checked, and how often
Monitoring says when something breaks. Verification says whether the safety nets would hold if it did. The difference is a calendar, and this is the one the operating company is being built around.
Fig. 3
Service design, written ahead of the entity that will run it
Daily
every working day
- Backup jobs: ran to completion and wrote what they were supposed to write.
- Overnight alerts: each one read and dispositioned, not merely received.
- Endpoint protection: reporting in from every machine that should be.
Weekly
- Patch status: what applied, what failed, what is now overdue.
- Access changes: reviewed against who actually joined, left, or changed roles.
- The ticket queue: nothing ageing quietly at the bottom.
- One real file from one real backup, restored and opened.
Monthly
- A larger restore: a mailbox or a server brought back from backup and checked.
- Mail authentication: SPF, DKIM, and DMARC still aligned and still enforced.
- Firewall and remote-access rules: read top to bottom for anything nobody remembers adding.
- The renewal horizon: anything coming due inside ninety days, certificates and domains included.
- Alert rules: reviewed against the month's false alarms, and tuned.
Quarterly
- Access review, with names attached: every administrative right justified to someone senior, or removed.
- A full recovery exercise: a system rebuilt from backup, timed, with the gaps written down.
- Documentation audit: could a competent stranger run this environment from what is written down.
- The incident sequence in Fig. 2, rehearsed while nothing is wrong – the only time rehearsal is cheap.
Who it suits
Organisations that have outgrown improvisation
Small and mid-sized organisations where technology has become load-bearing but there is no team dedicated to keeping it that way, or where a capable internal team is carrying more than it can sustain.
Co-managed work in particular is built for the second case, where the internal team keeps ownership and context while the routine load and the after-hours exposure come to us.
Operating companies are being established now.
Names, agreements, and contact details will be published here as each entity is formed and able to take enquiries.