What we do

We help organisations make security-led decisions about technology, process, and governance — before the spend, before the procurement, and before the incident.

Most providers in our market sell you something and then tell you why you needed it. We do the work in the other order. We look at the decision in front of you, the data and processes it touches, and the risks it changes — and then we tell you what we think. Sometimes the answer is what you expected. Sometimes it is not. Sometimes it is “do nothing right now, here is why.” We are paid for the answer, not for the sale that follows.

When organisations need this

The advisory conversation usually starts with a specific decision the client is about to make:

A technology change is being considered — a new firewall, a move to the cloud, a backup overhaul, a vendor switch, an AI deployment. The client wants security-led input before the procurement is signed.

A regulatory or contractual obligation has surfaced — POPIA, FSCA Joint Standard 2, an insurer requirement, a TISAX request from a customer — and the client needs to work out what it actually means for their organisation.

An internal review or audit has flagged gaps, and the client needs to decide what to address, in what order, and at what depth.

A growth event is approaching — a new office, an acquisition, a major customer, a regulatory crossover — and the client recognises that the current arrangement will not scale.

Something has gone wrong, or nearly gone wrong, and the client is asking how to think differently about the next decision. This is the most expensive entry point. We would rather help before that conversation than after it.

If your situation does not look like one of these, we may not be the right call yet. Advisory is a service for clients who have a specific question worth answering. If you are exploring whether information security matters at all, that is a different conversation — happy to have it, but it is not advisory work in the usual sense.

How we approach the work

We do not have a single methodology for advisory engagements. The right approach depends on the question. But the disciplines underneath are consistent.

We start with the question, not the technology. Most clients arrive describing a solution: “we want to move to Cloudflare,” “we are evaluating Fortinet versus Sophos,” “we need to know if Copilot is safe for us.” The first work is almost always to step back from the proposed solution to the underlying decision — what is being protected, what is being changed, what trade-offs are being made. Sometimes the original solution holds up. Sometimes the real question turns out to be different.

We work with what is in front of us. Real systems, real data flows, real organisational context. We do not produce strategy documents that sit on shelves. The work is grounded in the specifics of your environment — what you actually run, what you actually need to protect, who is actually involved. Advisory disconnected from operational reality is theatre.

We bring frameworks where they help, not where they decorate. ISO 27001, NIST CSF, CIS Controls, TISAX, POPIA, the FSCA Joint Standards — these frameworks exist because they encode hard-won thinking. We use them when they sharpen the decision. We do not put a framework on a slide just because frameworks are reassuring.

We say what we think. This is the part most clients eventually find most valuable. We are not selling an outcome. If we think a vendor is right, we say so. If we think a project is wrong, we say so. If we do not know, we say so. The work is worth more when it is honest.

What you get

The deliverable depends on the engagement. Some common ones:

A written assessment of a specific decision — what we think, what we considered, what trade-offs are involved, what we recommend, and what would change our mind.

A technology roadmap covering a defined timeframe (typically twelve to twenty-four months) — sequenced, costed at the right level of fidelity, anchored against business priorities and risks.

A security architecture review of an existing or proposed environment — what is in place, where the gaps are, what should change, and in what order.

A vendor or technology evaluation — structured comparison against criteria the client cares about, with our actual recommendation.

A regulatory impact analysis — what a specific obligation (POPIA, TISAX, FSCA, an insurance requirement, a customer contract) actually requires of you, in plain language, with an action list.

A pre-implementation review for a project that is already in flight — independent eyes on what is being built, before it goes into production.

For all of these, the report exists to be used, not filed. We follow up to make sure it lands, that decisions get made, and that the recommendations turn into work — either by us, by the client, or by another provider the client chooses.

A note on independence and offensive testing

WR360 is a defensive security practice. We monitor, detect, harden, and respond. We do not perform penetration testing, red team exercises, or other offensive security services.

This is a deliberate position, and an important one for advisory work. Offensive testing is most useful when it is done by an independent party — not by the team that designed and operates the controls being tested. When advisory work surfaces the need for pen testing, vulnerability assessment at audit grade, or red team work, we arrange it through trusted independent partners. The result is more defensible than a single provider doing both, and aligns with what regulators, insurers, and assurance frameworks like ISO 27001 expect.

If you arrive expecting us to test your defences, we will tell you why we do not — and help you find someone who will, with the right scope and the right report.

Who this is for

Advisory works best for organisations that have specific decisions to make and want considered input before committing. It works particularly well for owner-led businesses where the decision-maker is in the room — we can have the real conversation rather than working through layers of intermediaries.

It works for organisations that have an internal IT or compliance team and need independent, framework-aware input alongside their internal view. We do not replace internal teams; we supplement them.

It works for organisations that have been bitten before by a vendor that sold them a solution before understanding their problem.

It works less well for organisations that have already decided what they want and are looking for someone to validate the decision. We will give the honest read, not the comfortable one. That is sometimes uncomfortable. Clients who want comfortable should know that up front.

It does not work for organisations that want fast answers without context. Real advisory work takes time — to understand the situation, to consider the options, to test the conclusion. If the timeline is “by end of next week,” the engagement may not be the right fit.

How we work with you

Advisory engagements are usually scoped around a specific question or set of questions. The shape varies:

A short, focused engagement — a few days to a few weeks — to assess a specific decision and produce a recommendation.

A longer roadmap engagement — typically four to eight weeks — to look at a broader programme and produce a sequenced plan.

An ongoing advisory relationship — usually an agreed monthly or quarterly cadence — for clients who want a steady security-led perspective on decisions as they arise. This is sometimes called a virtual CISO arrangement, though we do not use that title; it is closer to a senior advisor on call.

We bill advisory work on time-and-materials terms with an agreed estimate up front. For clients who consume advisory time regularly, the engagement model can also work as part of a broader retainer alongside other practice areas.

The work is collaborative. We do not produce reports in a vacuum. We work alongside you, with your team, with your existing providers where appropriate. The end product is yours — your decisions, your roadmap, your architecture. We do the thinking with you, not at you.

What it looks like in practice

A few concrete examples of advisory questions we have worked through with clients:

A manufacturing client preparing for a TISAX assessment needed to understand what AL2 actually required, where their current arrangements fell short, and what sequence of work would close the gaps without disrupting production. The advisory work produced a phased roadmap, a clear scope decision, and a costed estimate — before any implementation work began.

A financial services client was being told by multiple vendors that they needed an EDR product. The real advisory question was different: did they have the operational capacity to use one effectively, and if not, was monitoring-as-a-service a better starting point? The recommendation was the latter, with EDR planned for a later phase.

An owner-led business was considering a major Microsoft 365 expansion including Copilot. The advisory work mapped what data Copilot would have access to, what governance was missing, and what controls needed to be in place before deployment was safe. The deployment proceeded — six months later than originally planned, after the right foundations were in.

We do not name clients on this page. The patterns matter; the names do not. If you want to talk to specific clients about their experience, we can arrange that under appropriate terms.

A few honest things to know

Advisory work is most valuable when the client engages with it. We can produce the best report in the world; if the recommendations are not acted on, the engagement was wasted. We will tell you when we think this is happening.

We will sometimes recommend work we cannot do ourselves — independent penetration testers (which is the correct arrangement, not a workaround), specialist regulatory firms, development houses for custom software architecture. The advice is not shaped by what we sell.

We will sometimes recommend doing nothing. “The current arrangement is adequate for now, here is what would change that judgement, let’s revisit in twelve months” is a legitimate outcome of advisory work. It is sometimes the best outcome.

If you ask a question we are not the right people to answer, we will tell you and point you toward someone who is. The advisory category is wide; we are deliberate about where we operate within it. Topics like detailed software architecture, custom development decisions, or specific marketing technology are outside our practice — we will say so rather than improvise.

What this connects to

Advisory work often surfaces the need for the rest of the practice:

The Information Security Management System practice is where many advisory engagements lead — once a client decides they need a managed discipline, the ISMS is how it gets built and operated.

Technology Operations is often where advisory recommendations land. We can advise on a network change; we also operate networks, so we can deliver what we recommend if you want us to.

Continuity and Recovery is one of the most common advisory entry points — a client asks whether their backup arrangement is sufficient. The advisory work produces an honest answer; the operational work follows if needed.

AI and Automation is an emerging advisory topic in its own right. For depth on AI-specific advisory — agentic systems, governance, security implications, automation design — see the AI and Automation page.

Procurement is downstream of advisory. Once a decision is made, procurement is how the technology, licensing, and supplier arrangements come into the practice.

Want to talk?

The fastest way to start is to tell us about the decision you are weighing. What you are considering, what you are weighing it against, and what is making the call hard. We will read it carefully and reply with what we think a useful conversation would look like.