Patch and Vulnerability Management Services
Reduce exposure without introducing uncontrolled change.
A governed patching and vulnerability-remediation service built around risk, testing, maintenance windows and evidence.
Based in Boksburg and supporting organisations across Gauteng: IT support in Johannesburg and IT support on the East Rand.
Discuss this managed service →Defined scope. Clear ownership. Visible service.
A governed patching and vulnerability-remediation service built around risk, testing, maintenance windows and evidence. Namandla Consultants begins with discovery, agrees responsibilities and measures the service against operational outcomes.
What the service can cover.
Coverage baseline
Confirm in-scope systems, supported versions, ownership and current patch posture.
Risk prioritisation
Prioritise critical vulnerabilities and high-impact systems using business context.
Patch planning
Define maintenance windows, dependencies, exclusions, rollback and communication.
Controlled deployment
Test and deploy approved updates through repeatable procedures.
Exception management
Record failed, deferred or incompatible updates with accountable remediation plans.
Compliance reporting
Provide clear evidence of coverage, success, exceptions and outstanding exposure.
Controlled from onboarding to improvement.
Why these are two disciplines, not one
Patching is an activity. Vulnerability management is a decision process. Treating them as the same thing is why organisations patch diligently and remain exposed.
Patching applies updates on a schedule. It handles the vulnerabilities the vendor has fixed and released.
Vulnerability management identifies what is exposed and decides what to do about it. That includes vulnerabilities with no patch available, misconfigurations that no patch addresses, software that is past end of support, and the exposures you have accepted deliberately and need to record.
An environment that is fully patched still has vulnerabilities. Default credentials on a network appliance, a legacy protocol enabled, an internet-facing management interface, an unsupported operating system running a machine tool. None of those are patch problems and all of them are vulnerability management problems.
The gap that catches most organisations
Third-party applications. Windows Update covers Microsoft. It does not cover Chrome, Firefox, Adobe Reader, Java, 7-Zip, Zoom, Notepad++, PDF tools, database clients or the fifty other applications on a typical estate.
Third-party software is where a large share of practical exposure sits, and it is the part most patch programmes never touch, because the Microsoft patching looks complete and produces a compliance figure that appears reassuring.
Patch management
The ring structure
Deploying every patch everywhere immediately breaks things. Deferring everything leaves systems months behind. The structure that resolves this is rings.
| Ring | Population | Deferral | Purpose |
|---|---|---|---|
| Pilot | IT staff and volunteer users, 5 to 10 percent | 0 days | Catch obvious breakage before it reaches anyone who matters |
| Broad | General user population | 7 days | The bulk of the estate, after the pilot has run clean |
| Critical | Executive, finance, specialist workstations, production-adjacent | 14 to 21 days | Machines where an unexpected reboot or a broken application has real cost |
| Servers | Server estate, by function | Scheduled window with rollback plan | Sequenced by dependency, never all at once |
Quality updates and feature updates are deferred separately. They carry very different risk. A monthly quality update is low risk and should move quickly. A Windows feature update changes far more and warrants a longer soak and explicit testing.
Out-of-band patches bypass the rings. Where a vulnerability is being actively exploited and a patch exists, it goes out on an emergency change with the pilot ring compressed to hours rather than days. That path has to exist and be documented before you need it.
Server patching specifics
Servers are not endpoints and the same schedule does not apply.
Sequence by dependency
Domain controllers one at a time, never together. Database before application tier. Cluster nodes rolled, not parallel.
Snapshot or backup before, verified after
A restore point that has not been verified is a hope rather than a rollback plan.
Verify the service, not the server
A server that boots is not a service that works. Post-patch verification checks that the application answers, the scheduled job runs and the integration completes.
Maintenance windows agreed in advance and published
Patching that surprises people generates incidents that are not incidents.
What breaks and how to keep it small
The realistic failure modes are a narrow set: a driver update that breaks specific hardware, a .NET or runtime update that breaks a legacy line-of-business application, a security update that changes default behaviour on a protocol, and a feature update that resets a configuration.
The pilot ring catches most of this. The rest is caught by knowing which applications are fragile and testing those specifically, which is a list that gets built over the first six months and is worth its weight afterwards.
Vulnerability management
Scanning
Authenticated scanning logs into the system and inspects installed software, versions, configuration and patch state. It gives an accurate picture.
Unauthenticated scanning probes from outside and sees what an unauthenticated party would see. It gives a different and also useful picture, particularly on internet-facing assets.
Both have a place. Authenticated internal scanning tells you what is actually there. External scanning tells you what is exposed. Running only one gives you half the position, and running only external scanning is the more common gap.
Coverage is the first problem, not scanning frequency. A scan of the assets you know about misses the assets you do not. Reconciling the scan inventory against the asset register, the DHCP leases and the network discovery routinely finds systems nobody knew were running.
Prioritisation, which is the whole discipline
A scan of a mid-market environment produces thousands of findings. Working through them by severity alone is neither possible nor useful.
CVSS gives a base severity score from 0 to 10. It describes how bad a vulnerability would be if exploited. It says nothing about whether anyone is exploiting it.
EPSS estimates the probability that a vulnerability will be exploited in the next thirty days. It is a far better prioritisation signal than CVSS alone, because a large majority of published vulnerabilities are never exploited at all.
Known exploited catalogues list vulnerabilities with confirmed active exploitation. Anything on one of these is a different category of urgency regardless of its CVSS score.
Asset context is the multiplier your scanner does not have. A CVSS 9.8 on an isolated test box matters less than a CVSS 6.5 on the internet-facing system holding personal information.
The workable prioritisation is: confirmed active exploitation first, then high EPSS on exposed or sensitive assets, then high CVSS on exposed or sensitive assets, then everything else on the standard patch cycle.
Remediation targets
Set them, publish them and report against them.
| Category | Target |
|---|---|
| Confirmed active exploitation, internet-facing | 48 hours or documented compensating control |
| Critical, internet-facing or sensitive asset | 7 days |
| Critical, internal | 14 days |
| High | 30 days |
| Medium | 90 days or next scheduled cycle |
| Low | Risk-accepted or next cycle |
The exception process
Some things cannot be patched. A machine tool controller running an unsupported operating system because the vendor certified it that way. An application that breaks on a required runtime version. A system in a change freeze.
Pretending otherwise produces a register full of findings that never close and a programme nobody believes in. The honest handling is an exception record with the reason, a compensating control, an owner and a review date.
Compensating controls that actually work: network segmentation isolating the system, removing internet access, application allowlisting, restricting access to named accounts, and increased monitoring on that specific asset.
Compensating controls that do not: “it is behind the firewall” and “nobody knows it is there”.
What Namandla delivers
Assessment. Current patch compliance across operating systems and third-party applications, current vulnerability position from an authenticated scan, and asset coverage reconciliation.
Patch programme design and operation. Ring structure, deferral policy, maintenance windows, rollback procedures, emergency patch path and third-party application patching alongside operating system patching.
Vulnerability scanning on a defined cycle, authenticated internally and unauthenticated externally, with coverage reconciled against the asset register.
Risk-ranked remediation using exploitation likelihood and asset context rather than raw CVSS, worked against the published targets.
Exception management with compensating controls, owners and review dates.
Evidence and reporting. Monthly compliance by ring and by asset class, vulnerabilities closed and opened, remediation performance against target, and the exception register. Written for an audit or a customer security questionnaire, because that is what it usually gets used for.
Microsoft-native delivery where the licensing supports it. Intune, Windows Autopatch and Defender Vulnerability Management are included in subscriptions many organisations already hold. We use what you have before proposing anything additional.
Remote delivery nationally. Onsite in Gauteng where a project needs it.
Common questions about Patch & Vulnerability Management
What is the difference between patch management and vulnerability management?
Patch management applies updates on a schedule. Vulnerability management identifies what is exposed and decides what to fix first, including exposures that no patch addresses.
A fully patched environment still has vulnerabilities: misconfigurations, default credentials, legacy protocols, unsupported software and deliberate exceptions. Patching is one remediation route among several. Vulnerability management is the process that decides which route applies and produces the evidence that a decision was made.
How often should we patch?
Our default baseline follows the monthly vendor release cycle, with an out-of-band path for vulnerabilities under active exploitation. A typical ring design starts with a pilot group, moves to the broad estate after validation, and schedules critical systems and servers against their operational risk and maintenance windows.
Faster is not automatically better. Deploying everything on release day means the estate finds vendor defects before the vendor does. The ring structure exists so that the pilot group absorbs that risk on your terms rather than the whole organisation absorbing it by accident.
What about third-party applications like Chrome and Adobe?
They need patching as much as the operating system does and they are the most commonly missed part of a patch programme. Windows Update does not cover them.
Third-party application patching needs its own tooling and its own inventory. This is worth checking specifically if you believe your patching is under control, because a compliance report showing ninety-eight percent frequently means ninety-eight percent of Microsoft updates and nothing at all for the other fifty applications on the estate.
How do you decide what to fix first?
Confirmed active exploitation first, then high exploitation probability on exposed or sensitive assets, then high severity on exposed or sensitive assets, then everything else on the standard cycle.
Severity score alone is a poor prioritiser. The large majority of published vulnerabilities are never exploited, and a critical score on an isolated internal system matters less than a moderate one on an internet-facing server holding personal information. Exploitation likelihood combined with asset context is what makes a remediation queue workable.
What if a system cannot be patched?
It gets an exception record with the reason, a compensating control, a named owner and a review date. Common cases are vendor-certified machine controllers, applications that break on required runtime versions and systems in change freeze.
The compensating controls that hold are network segmentation, removal of internet access, application allowlisting, restricted named-account access and increased monitoring on that asset. “It is behind the firewall” is not a compensating control, and an exception without a review date becomes permanent by default.
Will patching break our systems?
Occasionally, which is why the ring structure exists. The pilot ring absorbs the risk on a small population before anything reaches the general estate, and server patching runs with a verified restore point and a rollback plan.
The realistic failure modes are a narrow set: driver updates on specific hardware, runtime updates breaking legacy applications, security updates changing protocol defaults and feature updates resetting configuration. Knowing which of your applications are fragile is a list that builds over the first six months and it makes the programme substantially smoother afterwards.
How often should we scan for vulnerabilities?
Monthly authenticated internal scanning as a baseline, weekly or continuous on internet-facing assets, and an unscheduled scan after any significant change.
Frequency matters less than coverage. A weekly scan of the assets you know about is worth less than a monthly scan that has been reconciled against your asset register, your DHCP leases and network discovery. The systems nobody knew were running are consistently among the most exposed.
Is vulnerability scanning the same as penetration testing?
No. Scanning is automated, broad and frequent, and it identifies known vulnerabilities. Penetration testing is manual, targeted and periodic, and it finds what a skilled attacker could chain together, including logic flaws no scanner detects.
They are complements. Scanning is the standing hygiene process. Testing is the periodic check on whether the hygiene is working. Testing an environment that has never been scanned wastes most of the test on findings a scan would have given you for a fraction of the cost, so the sensible order is scan first, remediate, then test.
Do we need extra tooling for this?
Often not. Intune, Windows Autopatch and Defender Vulnerability Management are included in subscription tiers many organisations already hold, and third-party patching capability is available within them.
We assess what your licensing already includes before proposing anything additional. In most mid-market tenants the capability is present and unconfigured, which means the cost of getting started is the configuration work rather than a new product. Where a genuine gap exists we will say so and quote it separately.
What reporting do we get?
Monthly patch compliance by ring and asset class, vulnerabilities opened and closed, remediation performance against the published targets, and the current exception register with owners and review dates.
The reporting is written to be usable as evidence. Customer security questionnaires, insurance applications and audits all ask for patch compliance and vulnerability remediation evidence, and assembling it retrospectively is considerably harder than producing it monthly as a by-product.
How long does it take to get compliant?
Three to six months to reach a stable position on a typical mid-market estate. The first month is assessment and tooling, the second and third are the initial remediation backlog, and the cycle stabilises after that.
The initial backlog is the slow part. An environment that has never had structured patching will have hundreds of findings, and clearing them takes sequencing and change windows rather than effort. Setting a realistic target and reporting progress against it works considerably better than aiming for full compliance in month one and abandoning the programme in month three.
When is a formal programme more than you need?
On a small estate of cloud-managed devices with automatic updates enabled and no on-premises servers, automatic patching plus an annual external scan covers most realistic exposure.
The formal apparatus earns its cost where you have servers, legacy applications, third-party software at scale, or an obligation to evidence your position to a customer, insurer or regulator. If none of those apply, turn on automatic updates, run an external scan once a year and spend the difference elsewhere. We will tell you when that is where you sit.