OUR DISCIPLINES
Cybersecurity
in South Africa.
Security in most businesses touch every system and owns almost none of them, it slows things down for good reasons that are hard to prove, and it has to be credible with both the engineering team and the board at the same time.
This is how cybersecurity really works in South Africa: security engineering, architecture and governance, in businesses where trust is the product and the cost of losing it is not recoverable. The roles, the market, and what it takes to get the hire right, whether you’re building the team or building your own career.
A LOOK AT THE MARKET
The cybersecurity
market in South Africa.
Security demand in South Africa is not really set by South African businesses. It is set by the people who audit them, the clients who buy from them, and whoever is having a go at them this month. That is why security budgets tend to hold up in a year when everything else is being trimmed. It’s also why these roles almost always have a deadline sitting behind them: an audit, a client review, a remediation commitment somebody has already made in writing.
The regulatory bar moved recently and it moved properly. Joint Standard 2 of 2024, in force since 1 June 2025, applies to far more of the financial sector than most people expected, not just the big banks and insurers, but retirement funds, collective investment scheme managers, certain FSPs and the businesses running systems and data on their behalf. The board carries the accountability, controls and recovery have to be tested and shown to have been tested, and material incidents go to the regulator inside 24 hours. Put POPIA enforcement that has genuinely sharpened next to that, plus the Cybercrimes Act and PCI DSS for anyone near card data, and a large share of South African businesses are now hiring against an obligation rather than an ambition.
Where that demand sits is a local question too. Technology employment in this country is typically concentrated in a handful of industries: banking, insurance, telecoms, retail and mining and security hiring follows the same approach. Johannesburg is financial services, insurers and the mining houses, while Cape Town is product businesses, payments and a growing number of people employed offshore from a flat in Sea Point. The manufacturing and logistics belt is why operational technology security matters here in a way it does not in a purely software economy, because a good deal of this country’s value is still created by machinery that was never designed to be on a network. And if you sell into any of those sectors, their third-party risk process is now a real gate. Deals stall in a security questionnaire rather than in a pricing conversation, and the person who gets you through it is a security hire. That is what trust being the product actually means.
Then there is the money side, which nobody writes about and everybody in a security team lives with. Security tooling is priced in dollars and your budget is in rands. The practical result is that a security budget here buys noticeably less than the number suggests. As a result, South African businesses consolidate onto the Microsoft stack harder than most markets do, because Sentinel and Defender arrive inside a licence they are already paying for, which is why Microsoft security skills turn up on a disproportionate share of local job specs.
The premium sits with people who can get more out of fewer tools, which is a different skill from knowing a lot of products.
Supply has not moved to meet any of this, the senior security population here is small, far smaller than the business analysis or software engineering pools, and it is no longer priced locally. A good cloud security engineer in Cape Town can work for a business in London or Amsterdam without leaving their house, and plenty already do. When you lose a senior security candidate in this market, you usually lose them to a currency rather than to the company down the road.
One last thing worth knowing before you start reading CVs. Very few security people in South Africa came in through a security degree, because that pipeline barely existed until recently. Most arrived sideways, out of infrastructure, networking, systems administration or a service desk, and picked the discipline up through vendor certifications and whatever their employer happened to run.
A large share of the capability also sits inside consultancies, MSSPs and vendors rather than inside businesses. Those people are well trained and have seen a lot of environments, which counts for something. Fewer of them have owned a risk in production, been on standby over a long weekend, or had to face a board the morning after. Both are useful, but be aware that they are not the same hire, and the CV will not tell you which one you are looking at.
THE TITLE
What 'Cybersecurity' in a job title actually means.
The title tells you what somebody defends, and almost nothing about how well. “Cyber Security Specialist” is used for a person who tunes a firewall, runs an identity platform for forty thousand users, reviews code for injection flaws, writes policy, and who spends their week producing evidence packs for an auditor. Those people do not share a skill set and in some cases they don’t even share a vocabulary.
So the first question to ask is which layer the person actually owns: is it identity, cloud, application, network, endpoint, data, or the governance wrapper around all of it? That single question cuts a security CV down to something readable, and it’s the question most hiring processes skip because the title implies it has already been answered.
The second question is the one that separates this market, and is worth being blunt about. There is a meaningful difference between someone who operates a security tool and someone who understands the system the tool is watching.
A tool operator can tell you what the console flagged, what the severity rating says and what the vendor recommends. They are useful, they are employable, and there are a lot of them, because the vendor certification path is the most accessible route into this discipline and the market has trained thousands of people down it.
An engineer can tell you whether the flag matters. They know how this application authenticates, where the data actually sits, which of those alerts is a known artefact of the way your integration was built, and what would genuinely happen if the control failed. That judgement is what you are paying for, and it cannot be certified.
Certifications will not draw the line for you. CISSP, CISM, OSCP, the cloud security certifications and the rest are worth having, and a candidate who has invested in them is usually serious about the discipline. What they tell you is that somebody has been taught a body of knowledge and passed an exam on it. They don’t tell you that the person has ever had to apply it to a system nobody documented, under pressure, with the business asking when it will be back up.
If you’re hiring, write the spec around the layer the person will own and the decision they will be trusted to make. If you’re deciding your own next move, be honest about which of the two jobs you have been doing as it will all become visible within the tech testing stage.
THE ROLES
The roles, and what each one involves.
Every role here is defined by what it is responsible for when something goes wrong, and where in the lifecycle it gets involved. Tooling matters more in this discipline than in most, and it changes faster, but the tool is the smaller half of the hire.
What travels between businesses is the understanding of the system underneath it.
Application and product security engineer
Works with engineering teams to find and remove weaknesses in the software the business builds and ships, rather than in the infrastructure it runs on. The role that matters most in a product business, and the hardest to fill, because it needs genuine software engineering ability alongside security knowledge.
Common tools: secure code review, SAST and DAST tooling, dependency and supply chain scanning, threat modelling, API security testing, and enough fluency in the team’s language to submit the fix rather than log the ticket.
Chief Information Security Officer, Head of Information Security
Owns the security posture of the business and answers for it to the board, the regulator and, increasingly, the customer. The job is roughly a third technical judgement, a third commercial argument and a third organisational politics, and candidates who are strong at only the first tend to struggle. Under Joint Standard 2 the board carries the accountability, which changes what this person spends their time on.
Common tools: risk quantification and reporting, security strategy and roadmap, budget and vendor management, board and regulator engagement, incident command, and control framework ownership.
Cloud security engineer
Secures the environments the business actually runs in, which in this market usually means AWS or Azure, sometimes both after an acquisition. The role where the gap between certified and experienced is widest, because the certification covers the services and the job is about how those services were wired together by people under deadline pressure three years ago.
Common tools: AWS or Azure native security services, infrastructure as code and policy as code, CSPM and workload protection, network and identity design in cloud, container and Kubernetes security, and logging architecture.
Detection and response engineer, SOC analyst
Watches what is happening across the estate, decides what is worth acting on, and acts. The tier structure is real here: tier one triages, tier two investigates, tier three engineers the detections that stop tier one drowning. Often shift based, which makes retention a design problem rather than a hiring problem.
Common tools: SIEM platforms such as Sentinel, Splunk or Elastic, EDR and XDR, detection engineering and rule writing, MITRE ATT&CK mapping, threat hunting, and SOAR and automation.
DevSecOps engineer
Builds security into the pipeline so that controls run automatically rather than as a gate somebody has to remember. Sits between engineering and security and is judged on whether engineers stop routing around the process, which means the job is as much about developer experience as it is about controls.
Common tools: CI/CD pipeline security, secrets management, IaC scanning, container image hardening, automated compliance checks, and platform engineering practice.
Governance, risk and compliance specialist
Turns an obligation into something the business can demonstrate: control design, policy, evidence, audit response and regulatory reporting. Undervalued by technical teams and indispensable in regulated environments, because a control that works but cannot be evidenced does not exist as far as an auditor is concerned.
Common tools: ISO 27001, NIST CSF, PCI DSS, POPIA and Joint Standard control mapping, risk registers and treatment plans, third-party and vendor risk assessment, audit and evidence management.
Identity and access management engineer
Owns who can reach what, which is where a large share of real incidents now run. Chronically undersupplied in South Africa and consistently underpriced relative to the damage a weak identity estate does, partly because the work looks administrative from the outside and is architectural in practice.
Common tools: Entra ID or Okta, privileged access management, SSO and federation, MFA and conditional access design, joiner mover leaver automation, and access review and certification.
Incident response and digital forensics specialist
Handles the thing everyone hopes not to need: containment, investigation, evidence preservation, root cause and the honest account afterwards. Scarce as a permanent hire in all but the largest businesses, which is why most organisations hold this capability on retainer and pay for it when the day comes.
Common tools: forensic imaging and analysis, memory and endpoint forensics, log and timeline reconstruction, malware triage, evidence handling to an admissible standard, and post-incident reporting.
Offensive security specialist, penetration tester
Attacks the business on purpose, under agreement, to find what an actual attacker would find first. The best ones do not stop at the finding. They explain the business consequence and stay involved long enough for the fix to be real, which is the difference between a report and an improvement.
Common tools: web, mobile, network and cloud penetration testing, red team and adversary simulation, Burp Suite, Cobalt Strike or equivalent, exploit development, and reporting written for the people who have to act on it.
Operational technology and industrial control security specialist
Secures the systems that run physical processes: plant, mining operations, utilities, manufacturing, logistics. A different discipline from IT security in practice, because availability outranks confidentiality, the equipment is old, and patching something can stop production. A small, expensive and genuinely scarce population in South Africa, and a serious one given the sectors that make up this economy.
Common tools: ICS and SCADA protocols, IEC 62443, network segmentation and zoning, passive monitoring, safety instrumented system awareness, and OT asset inventory.
Security architect
Designs how security works across the estate rather than inside one system, and decides what gets built, bought, changed or retired. The level at which somebody needs enough standing to say that a proposed design is not acceptable, and enough credibility with engineering that the answer holds.
Common tools: reference architecture and security patterns, zero trust and segmentation design, threat modelling at system level, control selection and rationalisation, cloud and hybrid architecture, and technical standards ownership.
Threat intelligence analyst
Works out which threats are actually relevant to this business, in this sector, in this country, and turns that into something the detection and response teams can use. Valuable when it changes what the business defends. Decorative when it produces a weekly report nobody actions, and the interview should establish which one the candidate has been doing.
Common tools: intelligence collection and analysis, MITRE ATT&CK and adversary profiling, sector and regional threat tracking, IOC and TTP management, and intelligence reporting for technical and executive audiences.
Other disciplines we recruit in
AI & Machine Learning · Software engineering · DevOps and cloud engineering · Fintech · Project and programme management and more
IF YOU'RE HIRING
Hiring for a job where the standard is set by
someone else.
The instinct in this discipline is to hire against a list: certifications, tools, frameworks, years. It is the most defensible looking shortlist you will ever produce and it is close to useless, because everything on that list is available to anyone willing to study, and none of it tells you how the person behaves when the business pushes back.
That is the thing worth testing, because it is the daily reality of the job. Security hires spend a surprising amount of their time telling people with more authority than them that something cannot go ahead in its current form. Everything else is method.
Where we have seen hiring go well is when the interview is built around real incidents and real friction. Some thought starters:
- Ask about an incident they were personally involved in. What did they know, what did they get wrong, and what would they do differently.
- Discuss a time they told the business no, and what happened after that. Then ask for a time they said yes to something they were uncomfortable with, and how they reduced the risk instead of blocking it.
- Understand what they’ve had to remove, a security estate accumulates controls, and very few people have ever taken one away on purpose.
- Ask them to explain a system they protected, not a tool they used. If the explanation stays at the level of the console, you have your answer.
- Ask how they decided what not to fix. Every security function runs out of budget before it runs out of findings, and the prioritising is the skill.
The key is to listen for whether the answers contain systems, people and consequences, or only frameworks. Then look for the two core capabilities that separate the top of this market.
Systems understanding. The ability to reason about how the thing actually works, rather than about what the security product says about it. Candidates who can script, read code, read logs at volume and follow an architecture diagram are worth materially more than candidates who cannot, and in South Africa that remains a minority within the discipline.
The commercial argument. Security produces conclusions that cost money and slow things down. A security professional who cannot express a risk in terms an executive can weigh against other risks will be politely ignored, and a security function that is ignored is indistinguishable from one you do not have.
One practical warning on job specs. A large proportion of South African security vacancies are written as a stack of certifications and product names, which reliably attracts the population that collects certifications and product names, and screens out nobody. If the role exists because you failed a client security review, or because Joint Standard readiness is now a board item, or because your identity estate has grown past what anyone can manually control, say so. The people you want will read that and recognise a problem they have already solved.
WHY LEVELS MATTER
Understanding seniority.
Here is a top line view of what each level looks like in practice, whether you are writing a brief or working out where you sit.
-
A junior security analyst works inside a process somebody else designed: triaging alerts, running scans, chasing remediation, gathering evidence for an audit. The thing to hire for at this level is curiosity about how systems work rather than familiarity with the tooling. The good ones want to know why the alert fired, not just how to close it, and they are visibly uncomfortable marking something resolved that they do not understand.
-
A mid-level security engineer or analyst owns a control or a domain end to end: running the identity platform, maintaining the detection rules, managing the vulnerability programme, handling the third-party assessments. Usually the level at which somebody starts noticing that the control as configured and the control as intended are different things, and starts fixing it rather than reporting it.
-
A senior security engineer or architect is trusted with the work nobody can fully specify: the legacy environment with no owner, the cloud estate assembled by four teams with different standards, the regulatory requirement that has to become an actual technical control. Seniors here are measured by what they designed that held, and by whether engineering teams treat them as a help or an obstacle.
-
A lead or principal carries the judgement calls where security meets the commercial decision: what the business will accept, what it will spend, what it will stop doing, and which findings genuinely matter against everything else competing for the same budget. At this level the work is as much about persuasion and prioritisation as it is about architecture.
-
A Head of Information Security or CISO owns the posture and answers for it externally, to the board, the regulator, the auditor and the customer. The technical grounding still has to be real, because a CISO who cannot interrogate their own team's advice is dependent on it. What changes is that the job is now to make risk legible to people who do not work in technology, and to hold a position when it is commercially inconvenient.
Where the money is, and where it isn't
What lifts pay in this discipline is not the certification stack, it is scale and exposure. Securing a small estate and securing a large, messy, regulated one are different jobs, and the market prices the second one properly because far fewer people have done it.
Four kinds of experience move it most
- Cloud at real scale. Not a certification, and not a lab. A production environment with real workloads, real identity sprawl and a history of decisions nobody wrote down.
- Identity. The layer most incidents now travel through, and the one businesses are most likely to have underinvested in. People who have genuinely rebuilt an identity estate are rare and know it.
- Application security with engineering credibility. Someone engineers will listen to because they can write the fix, not only find the flaw. This is the scarcest combination in the local market.
- Real incidents. Having been inside a serious incident, in a role that carried responsibility, is worth more than any qualification. It is also the one thing candidates cannot manufacture, and it shows within two questions.
Underneath all of that, the fundamentals still carry. Scripting to automate rather than repeat, networking to know what should be talking to what, understanding of how software is built and deployed to propose a control that a team can actually adopt, rather than one they will quietly route around.
The ‘unicorn’ profile in this market is the person who can reduce the number of controls. Security functions accumulate tooling, policy and process, and almost nobody has the combination of technical confidence and organisational standing to remove something and be right. That person saves a business more money than any product ever will.
What the package is really worth
Security salary packages in South Africa is set by a wider market than the local one, and any benchmark that ignores that will be wrong every time. The strongest cloud, application and identity people are visible to employers in the UK, Europe and the Middle East, and can often be employed by them without relocating. That is the real comparator for a senior offer, and businesses that benchmark only against local peers lose candidates and never learn why.
Beyond the number, three things shape what the package is worth.
- The first is the estate. An engineer’s future earning power depends heavily on what they got to work on, so access to a large, modern, complicated environment is a genuine part of the offer, and candidates who understand this negotiate for it.
- The second is on call and shift. Detection and response work carries a load that does not show up in the annual figure, and businesses that price it honestly, through shift allowances, standby pay and recovery time, retain people that businesses which treat it as goodwill do not.
- The third is standing. Whether security reports into the business or sits three levels down under IT changes the job, the frustration level and, within a couple of years, what the person is worth. Ask about the reporting line early. It tells you more about how seriously the business takes this than the budget does.
THE COST
Contract vs Permanent.
The contract market for security specialists in South Africa is smaller than it is for engineering or business analysis, but it has grown quickly, largely because the regulatory deadlines that drive this work arrive with a deadline the business needs to comply to.
The work that suits contract is clear enough. Joint Standard or PCI readiness programmes, a cloud migration’s security workstream, a post incident rebuild, an identity platform implementation, a penetration testing cycle, an interim security lead while a permanent search runs. Real scope, a real end date, and a depth of experience that a business cannot justify carrying permanently. Paying a day rate for somebody who has taken three businesses through the same remediation usually costs less than a permanent hire learning it on yours.
Where we would draw the line is standing rather than cost. Security decisions frequently require somebody to refuse a business unit, and refusing carries weight in proportion to how permanent and how senior the person doing it is. A contractor can design the control, write the policy and build the evidence pack. They rarely have the internal relationships to hold a position against a determined executive, and they will not be there when the risk they flagged eventually lands.
There is a practical consideration too. Security roles usually need privileged access, background vetting and, in financial services, a documented view of who holds what. That is not a reason to avoid contracting, but it is a reason to plan it rather than treat security like any other resource line.
So it is usually a mix. Contract the programme, keep the ownership permanent, and make sure a permanent person is close enough to the work to inherit the reasoning behind the design rather than just the configuration. Where you need a permanent security leader and cannot afford to wait, an interim while the search runs is a sound answer, and a better one than appointing quickly at that level.
For the professional, contract in security builds exposure faster than almost any permanent route, because you see how several businesses have solved the same problem badly. What you give up is the chance to own something long enough to see whether your design survived contact with the organisation, and the internal trust that gets you into the conversations where the real decisions are made. That is a real give and take, and worth making on purpose.
Cybersecurity salaries
in South Africa.
FOR CONTRACTOR ROLES
Seniority
Indicative hourly rate
> Junior security analyst
R650 – R750
> Mid-level security engineer or analyst
R850 – R950
> Senior engineer or architect
R1000 – R1100
> Lead or Principal security architect
R1100 – R1300
> Interim Head of Information Security or CISO
R1300 – R1500
FOR PERMANENT ROLES
Seniority
Annual cost to company
> Junior security analyst
R700K – R800K
> Mid-level security engineer or analyst
R800K – R950K
> Senior security engineer or achitect
R1.1M – R1.4M
> Lead or Principal security architect
R1.5M – R1.7M
> Head of Information Security or CISO
R1.7M – R2.2M
Figures are drawn from Acuity’s own placements across the South African market and are indicative ranges, not quotes. Actual pay and rates vary with specific skills, sector, location and how in-demand a role is at the time. Contractor rates are excluding VAT. Last reviewed: September 2026
IF YOU'RE BUILDING A CAREER
Nobody builds a career on alerts they've closed
The certification path is the most visible route into this discipline and the least differentiating one, because everybody who is serious is already on it. Two analysts can spend four years in the same SOC and come out worth very different money, because one of them learned the tool and the other learned the environment. You will however find out in an interview where the questions go one layer past the console.
So the useful question about a role is not which platform the business runs, it is what you would be allowed to touch. Ask whether you would engineer detections or only triage them. Who would own the identity estate and whether you would ever get near it. Understand what happens when security says no, because the answer tells you whether this function has standing or exists to produce evidence for an audit.
Two things are worth building deliberately. Go deep in one layer, identity, cloud, application or OT, rather than collecting surface familiarity across all of them, because depth is what the scarce, well paid roles are actually asking for. Get as close as you legitimately can to a real incident, in whatever role you are allowed to hold. Nothing in this discipline compounds faster, and it is the one part of a security CV that cannot be studied for.
At Acuity we take the time to understand where you’re trying to get to, not just what’s already on your CV, and we only put you forward for roles that move you that way. You stay in control the whole way through, and we’d rather point you at the right role than hurry you into the nearest one.
COMMON QUESTIONS
Cybersecurity questions, answered.
FOR BUSINESSES LOOKING TO LEAD, BUILD & SCALE
How do I tell a strong security hire from a well-certified one?
Ask them to explain a system they protected rather than a tool they used. A strong hire will describe how the thing worked, where the real exposure was and what they chose not to fix. A well-certified one will describe the product, the framework and the methodology. Both interviews sound competent, but only one of them tells you the person can reason about your environment.
Do we need a CISO or a security engineer?
Get an understanding of whether the problem you need solved is based around decisions or controls. If nobody in the business can say what your risk position is, what you are spending on it and what you are accepting, that is a leadership gap. If you know the answers and the controls simply are not built, hiring a CISO to fix it is expensive and slow. Businesses often appoint a leader when what they needed first was two engineers.
What does Joint Standard 2 of 2024 mean for our hiring?
It moved accountability to the board and put real requirements around testing, resilience, third-party oversight and 24-hour incident notification. Practically, it creates demand for governance capability that can evidence controls, and engineering capability that can build the ones being evidenced. Businesses that hire only the first end up with well-documented gaps.
We failed a client security review. What do we actually need?
Usually less than you fear and sooner than you would like. Most failed reviews come down to identity, logging, patching discipline and the absence of documented process rather than exotic threats. A short piece of specialist contract capability to close the findings, and a permanent owner so it does not drift back, is the common shape of the answer.
Should our security lead report into IT?
It is workable at small scale and becomes a problem as you grow, because IT and security are optimising for different things and the same person cannot hold both positions with equal conviction. The reporting line is also one of the first things senior candidates ask about, so it affects who you can attract as much as how the function performs.
Can we outsource this instead of hiring?
Partly, and for detection and response, out of hours cover and incident response retainers it often makes sense. What does not outsource well is ownership. A managed service can tell you what happened. It cannot decide what your business is willing to accept, argue for budget, or say no to a commercial decision, and those are the parts that determine your actual posture.
How long should we expect a senior security search to take?
Longer than an equivalent engineering search, because the population is smaller and the strongest people are usually not looking. It is also a market where counter-offers and offshore offers are common late in the process, so building a proper shortlist rather than moving on the first available candidate is the faster route in practice.
FOR PROFESSIONALS EXPLORING
I have the certifications. Why am I not getting senior roles?
Senior roles are looking for evidence that you have owned something in production, been through a real incident, or made a decision with consequences attached. If your experience is assessment and advisory work, the gap is exposure rather than knowledge, and it is usually closed by moving to a role that lets you build and run rather than review.
Is it better to work in-house or for a consultancy or MSSP?
Consultancies build breadth quickly and are a strong start, because you see many environments in a short time. In-house builds the depth that senior roles are priced on: owning a control, living with your own design, and being there when it is tested. A lot of strong careers in this market do the first for three or four years and then move to the second on purpose.
Which specialisation is worth committing to?
Identity, cloud security and application security are where local demand consistently outstrips supply, and OT security is scarce enough to be worth considering if you are near mining, energy, utilities or manufacturing. The general advice holds across all of them: depth in one layer beats familiarity with several.
Should I consider a remote international role?
It is a genuine option in this discipline and the money is usually better. What you should consider is what you get to own. Remote contract work for an overseas business can leave you further from the decisions than a local role would, and the experience that raises your value over time is ownership rather than rate. Worth deciding deliberately rather than by default.