Patch Management
Patch management is the controlled process by which software fixes (patches) for a system are systematically recorded, assessed, tested and deployed. In an ERP context, patch management keeps the application secure, stable and up to date without jeopardising ongoing operations.
Patch management is the structured process by which software fixes – known as patches – for an IT system are provided, checked and installed in a controlled way. A patch is a small software update that fixes a bug, closes a security vulnerability or adjusts the behaviour of a program. Patch management ensures that these fixes are not applied arbitrarily and one by one, but according to a traceable procedure: record, assess, test, distribute and document. The goal is a system that stays secure, stable and low on errors over the long term.
In an ERP context, patch management carries particular weight because the ERP system runs a company’s central, business-critical data foundation – from orders and stock through invoices to accounting. An unpatched system with a known vulnerability is a gateway for attacks; a patch applied without control can, in the worst case, block processes or corrupt data. Good patch management balances both: it keeps the system current and protected without jeopardising ongoing operations through rushed changes.
At a glance
- Patch management = structured process for recording, testing and deploying software fixes
- A patch closes security vulnerabilities, fixes bugs or adjusts behaviour
- Core steps: inventory, assessment/prioritisation, testing, rollout, documentation
- Security-critical: unpatched vulnerabilities are a primary gateway for attacks
- With cloud/SaaS ERP the provider handles patching – governed by SLA and maintenance windows
How patch management works: the process
Patch management runs as a recurring cycle. It starts with inventory: you have to know which systems, applications and version levels are actually in use, because only known components can be updated in a targeted way. Available patches are then recorded – from vendor notices, security advisories (such as CVE reports) and update channels. Each patch is assessed and prioritised: a patch that closes an actively exploited vulnerability takes precedence over a cosmetic fix.
Before going into production, a patch should be tested – ideally in a separate test or staging environment that mirrors the production environment. Only once it has been verified that the patch does not break any function and is compatible with customisations and interfaces does the rollout to production follow, often within a defined maintenance window. The final step is documentation: which patch was applied, when, by whom and with what result? This audit trail is indispensable for audits and troubleshooting.
Patch, hotfix, update and release update
The terms overlap but mean different things. A patch is a small, targeted fix. A hotfix is a particularly urgent patch that resolves an acute disruption outside the regular cycle. An update bundles several fixes and minor improvements. A larger release update, by contrast, lifts the system to a new functional version and, alongside bug fixes, brings new features – it is more extensive, riskier and requires more testing and planning effort than a simple patch.
Why patch management is security-critical
The most important driver for patch management is security. As soon as a vendor discloses a vulnerability and provides a patch, the gap is also known to attackers – the time between disclosure and deployment becomes a window of risk. Many successful attacks and ransomware incidents exploit exactly these long-known but unpatched vulnerabilities. Disciplined patch management shortens this window and is therefore one of the most effective and, at the same time, cheapest security measures there is.
Alongside security, stability matters. Patches fix bugs that can lead to crashes, incorrect calculations or data inconsistencies – especially in an ERP, where a calculation error directly affects stock, prices or postings. At the same time, a current version level is often a prerequisite for support: many providers offer warranty and help only for maintained, supported versions. Anyone who puts off patches too long loses not just protection but also entitlement to support, and runs into an expensive backlog of bundled upgrades.
Patch management in the ERP system
Patching an ERP is more demanding than a single application, because the system rarely stands in isolation. It depends on databases, interfaces to shops and marketplaces, on DATEV or payment integrations, and often on company-specific customisation. A patch that corrects the standard software can clash with such customisations or interfaces. That is why the testing phase in a production-like environment is especially important here – as is a robust fallback plan (rollback) and a current backup, in order to return quickly to the previous state after a failed patch.
How much a company has to do itself depends heavily on the operating model. With an on-premise ERP or self-hosting, the entire cycle – planning, testing, deploying, rollback – is the company’s own responsibility. With a cloud ERP in the SaaS model, the provider handles patching of infrastructure and application centrally; updates usually run automatically in defined maintenance windows, governed by the availability SLA. The customer thereby gives up control over the timing but gains relief and a permanently current state without in-house patching effort.
Distinction: patch management vs. change management
Both processes govern changes to IT systems, but differ in focus. Patch management specialises in one particular type of change – the deployment of software fixes and security updates. Change management is the overarching framework for all planned changes to systems and processes, from new functions through configuration adjustments to patches. In many organisations, patch management is therefore a specialised sub-process within change management that, because of its security-critical nature, has its own – often faster – rules for urgent cases.
Patch management, compliance and DACH specifics
Running current systems is, in the DACH region, not merely prudence but touches on legal obligations. The GDPR requires appropriate technical measures to protect personal data – a known-vulnerable, unpatched system contradicts this and, in the event of damage, can be treated as a breach of the duty of care. For tax-relevant ERP data, the GoBD additionally require availability, immutability and traceability; complete documentation of applied patches is therefore part of sound procedural documentation.
In regulated or certified environments, patch management is explicitly required: security standards such as ISO 27001 and the BSI’s IT-Grundschutz prescribe a defined, documented approach to vulnerabilities and updates. Evidence for auditors, cyber insurers or as part of a certification also relies on a verifiable patching procedure. Anyone who records, tests and logs patches in a traceable way thus meets not only technical but increasingly also contractual and legal requirements.
Principles for robust patch management
Sound patch management combines speed with reliability. Security-critical patches should be deployed promptly to keep the window of risk small; functional updates, by contrast, may be tested thoroughly. Risk-based prioritisation has proven effective: the severity of a vulnerability and the criticality of the affected system determine how quickly you react. This is complemented by fixed maintenance windows in which changes are made with as little operational disruption as possible.
Three safeguards are indispensable: a current backup before every major patch, a tested rollback path for the failure case, and complete logging. For ERP systems it is advisable never to push a patch into production untested and to deliberately steer automated update behaviour rather than leave it to chance. That way the system stays current and protected without a well-meant fix slowing operations down.
Example
Example: critical security patch at a mid-sized company
A mid-sized retail business runs its ERP on its own hosting. On a Tuesday the vendor reports a critical vulnerability in a component of the application and provides a patch; in parallel, the BSI warns that the vulnerability is already being actively exploited. Instead of applying the patch in a panic, the IT lead follows the established procedure: they classify the vulnerability as highly critical, take a current backup and first deploy the patch to the staging environment.
There it turns out that a custom interface to the online shop has to be adjusted so that it works with the corrected version. After this adjustment and a brief functional test, the patch is put into production that same evening in a maintenance window and documented. The window of risk stays limited to a few hours, the shop keeps running without data loss – and in the cyber insurer’s audit report the prompt, structured handling of the vulnerability can be documented in full.
Frequently asked questions
Matching ERP systems
Related services
Questions about Patch Management in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.