Adobe Commerce Security Patching as a Service: SLAs That Make Sense

Adobe Commerce security patches arrive on a predictable quarterly cadence, with occasional out-of-band releases for urgent vulnerabilities. The work of applying them is unglamorous and high-stakes. A patch that fixes a known exploit also has the potential to break custom modules, regress integrations, or introduce subtle behavior changes that customers notice immediately. The merchants who get patching right have either invested in a serious in-house DevOps capability or contracted with an agency that runs patching as a structured service. The merchants who get patching wrong have either skipped patches and accumulated security debt or applied patches without testing and triggered production incidents.

This piece walks through what a credible Adobe Commerce security patching SLA looks like, the response times, the testing scope, the rollback procedures, and the coverage that actually protects production. It is written for engineering leaders and operations directors evaluating maintenance partners. The patterns below come from Bemeir’s maintenance practice and from the patching-related rescue work we have done after other agencies treated patching as a checkbox.

Why a Real SLA Matters

Without an SLA, patching becomes ad-hoc. The agency applies patches when they have time. The merchant assumes the patches are being applied. Both sides default to optimistic assumptions, and the gap between assumption and reality is where security incidents happen. A real SLA is a written commitment with specific response times, specific scope, and specific exclusions. It forces both sides to be explicit about what coverage looks like.

The SLA is also a procurement document. When the security team or the compliance team asks “what’s your patching posture,” the SLA is the document they need to see. PCI DSS, SOC 2, and most other compliance frameworks require evidence that security patches are applied within defined windows, and an SLA is what produces that evidence.

The Tiers of Patch Urgency

Adobe Commerce patches fall into urgency tiers. The SLA should respond to each differently.

Critical / Out-of-band: Adobe releases an emergency patch for an active exploit (the most notable recent example being the SUPEE-style historical incidents, and more recently the CVE-2022-24086 vulnerability and its successors). Response window should be under 48 hours from release.

High-severity quarterly: Adobe’s regular Patch Tuesday release contains high-severity fixes. Response window should be 7-14 days from release.

Medium-severity quarterly: Lower-severity fixes in the same release. Response window can extend to 30 days from release.

Low-severity and informational: Bundled with the next normal patch cycle, no expedited response required.

A credible SLA differentiates between these tiers. An SLA that promises “all patches applied within 30 days” is not differentiating, and it leaves critical vulnerabilities exposed for too long.

What the SLA Should Include

A complete patching SLA covers these dimensions:

• Patch tiering and response time per tier
• Testing scope per tier (smoke tests, regression tests, integration tests, performance tests)
• Staging environment policy (every patch tested in staging before production, with documented exceptions for emergencies)
• Rollback procedure (every patch deployment includes a documented rollback path)
• Communication policy (when the merchant is notified, what they’re notified about, who is the contact)
• Post-deployment validation (what’s checked after the patch is live)
• Exclusion handling (patches that cannot be applied due to custom code conflicts; how these are documented and remediated)

Each of these dimensions has nuance, and the SLA should be explicit rather than gestural.

Testing Scope: The Unglamorous Detail That Matters

The biggest variation in patching service quality is testing scope. A “patch applied” that has not been tested is a patch deployment, not a patch service. The testing scope should be calibrated to the patch’s risk profile.

For critical and high-severity patches: full regression testing including checkout, account, search, and PDP flows; smoke tests on the top 50 customer journeys; integration tests on payment, shipping, and tax; performance regression check against the previous baseline.

For medium-severity patches: smoke tests on the top 20 customer journeys; integration tests on payment and tax; performance regression check.

For low-severity patches: smoke tests on critical paths; visual regression check.

The testing should be automated wherever possible. Manual QA for every patch is too expensive to be sustainable, and automated tests catch a wider class of regressions reliably. Adobe Commerce’s Magento Functional Testing Framework (MFTF) is the official testing tool, and any serious patching service should be running MFTF tests as part of the patch validation.

Staging First, Always

Production patching without staging validation is malpractice. The SLA must require that every patch is applied to a staging environment that mirrors production (same Adobe Commerce version, same extensions, same data shape if not the full data), tested against the documented scope, and only promoted to production after the testing passes.

The exception is true emergency situations where a vulnerability is being actively exploited and the rollout is happening across the entire eCommerce industry simultaneously. Even in those cases, the rollback procedure must be tested and documented before the production deployment.

For stores on Adobe Commerce Cloud, the staging environment is provided by the platform. For self-hosted Adobe Commerce stores, the maintenance partner is responsible for ensuring staging exists and is current.

Rollback Procedure

Every patch deployment includes a rollback path. The SLA should document what the rollback looks like:

• The database backup taken immediately before the deployment
• The file system backup or the deployment image
• The infrastructure state required to restore service
• The runbook for executing the rollback
• The expected time to rollback under normal conditions

A rollback that takes 12 hours to execute is not a rollback. It’s a recovery. The SLA should aim for rollbacks executable in under 30 minutes.

Communication Policy

The merchant needs to know when patches are being applied, what they cover, and what’s expected to change. The communication should include:

• A scheduled patch window communicated at least 48 hours in advance for high-severity patches
• A pre-deployment notification with the patch summary, the test results from staging, and the expected impact
• A real-time notification when deployment starts and completes
• A post-deployment validation report confirming production health
• A monthly summary of all patches applied during the month

Communication should land in writing in a system the merchant uses (Slack, Teams, email), not buried in a ticket nobody checks.

Bemeir’s Adobe Commerce maintenance practice treats communication as part of the deliverable, because the merchant who doesn’t know what just happened has effectively not received the service even if the work was done. The same pattern applies to Shopware and BigCommerce maintenance engagements.

Custom Module Conflict Handling

Some patches conflict with custom modules, and the conflict has to be resolved before the patch can be applied. The SLA should specify:

• How conflicts are detected (composer dependency resolution, file-level checks, runtime testing)
• How conflicts are remediated (custom module update, vendor patch request, or temporary workaround)
• The maximum delay tolerated before remediation
• Escalation if the conflict cannot be resolved within the response window

Stores running heavy custom code accumulate patch debt because each patch introduces conflicts that take time to resolve. The SLA should reckon with this, a store with 30 custom modules will need more remediation budget than a store with 3.

Compliance Mapping

The patching SLA should map explicitly to compliance requirements. PCI DSS 4.0 requires patching of critical vulnerabilities within 30 days. SOC 2 requires documented patch management with measurable response times. GDPR doesn’t specify patch windows but does require “appropriate security measures,” which in practice means timely patching.

A good SLA includes a compliance attestation section that the merchant can hand to auditors. The PCI Security Standards Council documentation is the reference for PCI requirements, and the AICPA SOC framework covers SOC 2 expectations.

Adobe Commerce Cloud vs Self-Hosted Nuances

Stores on Adobe Commerce Cloud have a specific relationship with patching: Adobe applies platform-level patches automatically, but application-level patches still require the merchant’s involvement. The SLA needs to differentiate which patches are platform-managed and which are merchant-managed.

Self-hosted Adobe Commerce stores have full responsibility for both layers. The SLA needs to cover platform patches (PHP, MySQL, Redis, OpenSearch) as well as Adobe Commerce application patches.

Adobe’s Commerce Cloud documentation covers the platform-managed boundary clearly, and the SLA should align with that boundary.

The Annual Patching Audit

Once a year, the patching SLA should be audited end-to-end. The audit reviews:

• Every patch released during the year and the response time achieved
• Every test cycle and any test failures
• Every production incident traced to patching
• Every rollback executed
• Every custom module conflict and its remediation

The audit produces a written report that becomes part of the compliance documentation. It also surfaces SLA improvements for the following year, patches consistently missed on a particular tier, custom modules that keep producing conflicts, integrations that need more thorough testing.

The merchants who go through this audit annually have a patching posture that holds up under scrutiny. The ones who don’t have the audit have a patching posture that holds up until it doesn’t, at which point the incident postmortem becomes the audit. The annual audit is the cheaper option.

For independent benchmarks on security patching norms across eCommerce, Sansec’s eCommerce security threat reports and OWASP’s eCommerce security guidance provide industry context that can inform internal SLAs. The SLA you sign with your maintenance partner is one of the highest-leverage security decisions you’ll make for the store, and it deserves the same scrutiny as any other security control.