What we do
We design, build, and operate the technology environments our clients run on. Networks, servers, virtualisation, identity, end-user computing, databases, and the supporting infrastructure that holds them together. The work is broad on purpose — most clients need the components to be operated as one stack, not as separately-managed silos.
Operations is where the information security model meets the daily reality of running a business. The ISMS sets the controls and the framework; operations applies them, day after day, change after change. We do the work properly, we document what we do, and we operate by service management disciplines that hold up under audit.
When organisations need this
Most clients come to operations work for one of a few reasons:
They have outgrown their current arrangement. The internal team that has been holding things together is stretched, the vendor stack has accumulated, and the environment has drifted from anything resembling a deliberate design. They want someone to take the operational responsibility, properly.
They have decided that operations should be done by a practice rather than improvised. They have lived through enough incidents, near-misses, or audit findings to know that “we will get to it” is not an operational discipline, and they want to engage a partner who treats operations as a discipline.
They have just made an architectural decision — through their own thinking, through advisory work, or through an external requirement — and they need someone to deliver and then operate the resulting environment. They want the design and the operation to be coherent rather than handed off between disconnected providers.
They are an existing client of ours, and a new domain has opened up — a new office, a new platform, a new requirement. The relationship extends naturally because we already know the environment.
How we approach the work
Operations work runs continuously, but the underlying disciplines are deliberate. A few principles shape how we operate environments.
Service management is not optional. We operate by ITIL v4 service management — change management, incident management, problem management, request fulfilment, and configuration management — across all engagements. This is what “documented disciplines” actually means in operational practice. Every change is risk-assessed. Every incident is recorded. Every request is tracked. Every configuration is documented.
Document everything, before and after. Before a change: what is changing, why, what could go wrong, what the rollback looks like. During: what is actually happening. After: what was changed, what the environment looks like now, what was learned. The documentation is not a paperwork exercise — it is what makes the next change safer, faster, and reviewable.
Risk-assess before action, not after. Significant changes get a documented risk assessment. Smaller changes follow a documented standard procedure. Workarounds are not the destination — if a workaround is necessary in the moment, it is recorded as a known issue with a planned resolution, not as the new normal.
Operate inside the security model, not alongside it. Hardening, patching, identity hygiene, change control, evidence trails — these are not separate “security” activities done as an afterthought. They are how operations is run. The Information Security Management practice sets the framework; operations applies it.
Adapt the technology to the client. We work with the stack the client has, not the stack we would prefer to sell. Where a stack genuinely needs to change, we say so and explain why — through advisory work, separately. Operations does not exist to push procurement.
What we cover
We organise operations work around capability domains rather than vendor lines. Each domain is operated as part of the broader environment, not as an isolated service.
Network. LAN, WAN, wireless, segmentation, routing, firewalls, VLANs, trunks, and the disciplines around them — change control, configuration backups, capacity planning, and lifecycle. We work with the leading network and firewall platforms, including platforms we do not resell. The right fit for a client’s environment is rarely the one we have a margin on.
Servers and virtualisation. Physical and virtual server infrastructure, on-premises and hosted. We work with the leading virtualisation platforms — including platforms we do not resell — and with the operating systems and supporting services that run on them. We have a long-running preference for open source where it makes sense, balanced against the operational realities of supportability and the specific assurance requirements clients face.
Identity and access. Active Directory, modern identity (Entra ID and equivalents), federation, single sign-on, conditional access, privileged access. Identity is one of the highest-leverage operational domains — most security incidents trace back to identity compromise — and it is operated with the seriousness that warrants.
End-user computing. Workstations, laptops, mobile devices, the software estate, the user experience. We treat workstations as cattle, not pets — the device is a component, not an object of personal attachment. If a device fails, the user is on a replacement quickly. The user’s ability to work is what we protect; the specific device they happen to have today is replaceable. This framing matters because it changes what “support” means: less about coddling individual machines, more about ensuring that any machine can take over for any other.
Databases. We work with the major relational platforms — Microsoft SQL, PostgreSQL, MySQL — on planning, availability, backup, integration, and the operational disciplines around them. We are not database administrators. Where deeper DBA work is needed, we work alongside specialists or recommend them.
Cloud and hosted infrastructure. Public cloud services and hosted infrastructure are part of the operational stack, not a separate category. We manage the relationships with hosted infrastructure providers, including budget colocation arrangements where genuinely appropriate. The choice of where workloads run is an architectural conversation, handled through advisory work; once decided, operations runs them.
Connectivity and voice. We manage the relationships and integration with connectivity providers and hosted voice providers across South Africa. We do not provide connectivity or voice services directly — these involve specialised infrastructure better delivered by partners — but we own the integration into the client environment and the operational responsibility for keeping it working.
A note on offensive testing
Operations work involves hardening, patching, configuration management, and incident response — but not penetration testing or red team work. WR360 is a defensive security practice. When operations work surfaces the need for offensive testing, vulnerability assessment at audit grade, or red team exercises, we arrange it through trusted independent partners. The reasoning is on the Monitoring and Response page in full.
What you get
A technology environment that is operated by a practice. Specifically:
A documented current-state baseline — what is running, where it lives, how it is configured, and who is responsible. This is the foundation. Without it, operational decisions are guesses.
A change management discipline — risk-assessed changes, documented before and after, with evidence trails that survive scrutiny.
An incident and request management discipline — incidents recorded and worked, requests fulfilled within agreed timeframes, with reporting that means something.
Hardening and patching as continuous activities, not occasional projects. Configuration aligned to the security framework. Identity hygiene as a standing discipline.
A service desk relationship — a defined route for the client team to get work done, with the standards we apply on our own organisation applied to theirs.
Operational reporting on what was done, what was learned, and what is coming next.
For clients on a managed-operations engagement, this is the ongoing deliverable — month after month, year after year. The environment is operated, not just managed.
Who this is for
SME and mid-market organisations that want a single, accountable technical partner for the operational domain — not a service desk that closes tickets quickly and walks away, and not a procurement vehicle dressed up as an MSP.
It works for organisations that have outgrown an internal-only model — where the existing team is too stretched to maintain the disciplines, or where specialised depth is missing in particular domains.
It works for organisations that have an internal IT manager or function and want a partner that supplements rather than replaces them. We work with internal teams, not over them. Where they are strongest, we step back. Where they are stretched, we step forward.
It works for organisations where the cost of getting operations wrong — through downtime, data loss, audit findings, or security incidents — is meaningfully higher than the cost of operating the environment properly.
It works less well for organisations that want the cheapest hourly rate for break-fix work. The service desk relationship is real, but it is part of an operational practice, not a body shop.
How we work with you
Operations engagements typically run as ongoing managed-services relationships, structured around an agreed scope of the environment, an agreed service level, and a documented set of disciplines. The commercial shape varies — block-purchase hours, monthly retainer, mixed arrangements — and is described on the Engagement Models page.
The relationship runs continuously, but the work is structured. Standing operational disciplines (monitoring, patching, change reviews, configuration management) run on documented schedules. Project work (deployments, migrations, upgrades) is scoped and delivered as discrete engagements within the broader relationship. Advisory conversations come up naturally — we are there, we see the environment, we can be asked.
Where projects are large enough or specialised enough to warrant their own engagement structure, we scope them separately. Otherwise the work folds into the operating relationship.
What it looks like in practice
We apply the same operational disciplines to ourselves that we recommend to clients. WR360’s own infrastructure — service desk, monitoring, documentation, communication, time tracking, and the rest — is operated by the same ITIL v4 disciplines and the same documentation hierarchy we deploy with clients. We use this stack daily. We know where its rough edges are. We do not recommend operational disciplines we have not lived inside ourselves.
This is also what makes our open-source posture credible. We run open-source operating systems, hypervisors, monitoring, documentation, and service management tools — not because open source is ideologically preferable, but because we have lived with the operational realities and we know what works at this scale. For clients with specific assurance requirements (TISAX, regulated environments, supplier audits), we are equally fluent in supported commercial alternatives. The choice is the client’s; the operational discipline is the same either way.
A few honest things to know
Operations work is the practice area where the “they don’t know we do this” problem hits hardest. Most clients arrive thinking of us as the network and hardware people, because that is the most visible part of the operational footprint. The rest of operations — the service management discipline, the identity work, the database planning, the documentation rigour — is less visible, and clients sometimes engage other providers for it without realising we already do it. If you are an existing client and you are not sure whether something falls inside our operational scope, please ask. The list above is comprehensive, and even where something is at the edge of it, we will tell you honestly whether we are the right people to do the work.
Operations work also takes time to settle into. The first few months of a new operations engagement are often a handover and stabilisation period — understanding the environment, documenting the current state, finding the gaps that previous arrangements left behind, and building the operational rhythm. We are deliberate about this; rushing the early phase produces fragile operations later.
We will not implement workarounds and call them solutions. Some clients arrive with environments that have accumulated workarounds for years. Part of the operational engagement, sometimes, is unwinding them — properly, with risk assessment and change control, into something defensible. This sometimes takes longer than clients expect. The alternative is to leave the workarounds in place and be the next provider who tolerates them; that is not the practice.
We do not write software, and we do not provide DBA-level database administration. Where these are needed, we work alongside specialists or recommend them. We are clear about this scope rather than improvising.
What this connects to
Operations does not stand alone. It is one face of the practice.
The Information Security Management System practice is what operations runs against. The ISMS sets the controls and the framework; operations applies them. The two reinforce each other.
Advisory and Architecture is where operational decisions are shaped before they are committed to. Most operational work that lasts has had advisory thinking applied to it first.
Continuity and Recovery is one of the operational outcomes. Backup, archiving, and recovery are operated as part of the broader environment, not as a separate service.
Monitoring and Response is the visibility layer that tells operations whether the environment is healthy. Monitoring data informs operational priorities; incidents detected by monitoring are worked through the operational disciplines.
Procurement is downstream of operational and architectural decisions. Once we know what is being run, procurement is how the technology, licensing, and supplier arrangements come into the practice.
Operations work compounds when the practice is engaged as a whole. Most clients start with operations alone and grow the relationship from there.
Want to talk?
The fastest way to start is a conversation. Tell us about the environment you are running, what is working, what is not, and what is making you look for a different operational arrangement. We will read it carefully and reply.