This case study composites patterns from three mid-market retail engagements where the underlying problem was the same: a backlog of security audit findings that had accumulated over multiple audit cycles, where the security and engineering teams disagreed about prioritization, and where executive sponsorship for the work was missing. The composite isn’t any one specific client; the patterns are drawn from real engagements where the resolution approach worked. Specific details have been adjusted to maintain client confidentiality.
The pattern matters because audit backlog is common in mid-market retail. The security team flags issues, engineering pushes back on prioritization, executives don’t see the issues until they become incidents, and the backlog grows audit cycle by audit cycle until something forces resolution. The forcing event is usually a breach, a major audit finding that affects business operations, or a strategic transaction (M&A, capital raise, major customer requirement) that requires clean security posture.
This is how the resolution played out for a representative client and what produced the durable outcome.
The Starting State
The retailer was running Adobe Commerce as their primary eCommerce platform, with $80M in online revenue and a substantial B2B operation alongside consumer sales. The security team had been documenting audit findings across the previous 14 months. The backlog included 47 items across categories, PCI DSS scope issues, authentication weaknesses, dependency vulnerabilities, configuration drift, missing controls around third-party access, and gaps in incident response readiness.
The engineering team’s position was that most of the findings were lower priority than the feature work driving revenue growth. The security team’s position was that the cumulative risk was untenable and individual findings shouldn’t be evaluated in isolation. The executive sponsor was nominally supportive of security but in practice approved roadmap that didn’t include the backlog work.
The forcing event was a major B2B customer’s vendor security requirement update that demanded specific PCI DSS attestation and SOC 2 readiness within six months. The CFO escalated the situation and asked for a resolution plan that would clear the backlog without derailing the business.
The Engagement Structure
The engagement that resolved this started with a re-prioritization exercise that involved all three stakeholders, security, engineering, and the executive sponsor. The exercise wasn’t a debate about which findings were valid; the security team’s findings were all valid. The exercise was about sequencing the work in a way that managed risk while maintaining business velocity.
The re-prioritization used three dimensions to sort findings. First, regulatory and contractual exposure, findings tied to PCI DSS, customer contractual requirements, or other binding obligations went to the top regardless of internal opinion. Second, exploitability and impact, findings that could be directly exploited to access cardholder data, customer PII, or business operations ranked above findings that required chained conditions to exploit. Third, remediation cost relative to risk, findings with high impact and low remediation cost ranked above findings that would consume substantial engineering time.
The sorted list looked different from both the security team’s original priority and the engineering team’s deprioritized version. Some findings the security team considered critical turned out to be lower priority once exploitability was assessed. Some findings the engineering team considered minor turned out to be regulatory blockers that had to be resolved regardless of complexity.
Bemeir’s enterprise eCommerce practice led the prioritization exercise and the subsequent remediation work, with security team review of each remediation as it completed. The structure produced an actual ordered backlog instead of a contested list.
The First Sprint: Regulatory and Contractual
The first sprint addressed the items tied directly to the PCI DSS attestation and the B2B customer’s requirements. This work was non-negotiable; without it, the customer contract was at risk and the PCI compliance posture was insufficient.
Specific items included tightening checkout architecture to maintain SAQ A scope rather than SAQ D scope (the existing implementation had drifted into wider scope through incremental changes), implementing payment page integrity monitoring required under PCI DSS 4.0, restricting third-party JavaScript loaded on payment pages, and documenting the segmentation between cardholder-data-handling components and the rest of the platform.
The work took six weeks of focused engineering attention. The PCI assessor confirmed SAQ A scope after the work, the customer contract proceeded on schedule, and the foundational compliance posture was restored.
The Second Sprint: High-Impact Vulnerabilities
The second sprint addressed vulnerabilities with realistic exploit paths and meaningful impact. The list included a subset of the dependency vulnerabilities (specifically the ones in components that handled untrusted input on internet-facing paths), authentication weaknesses in the customer-facing portal (multi-factor authentication enforcement, session management, password policy alignment with NIST guidance), and access control gaps in administrative interfaces.
The dependency work involved upgrading or patching the affected components, with regression testing on each upgrade to validate compatibility. The work surfaced two cases where the upgrade required additional code changes because of API breaks between versions, which is exactly why dependency upgrades tend to backlog in mid-market environments, they aren’t always mechanical.
The authentication work involved implementing TOTP-based MFA for customer accounts with substantial value (B2B accounts and consumer accounts above a transaction threshold), tightening session management to align with current industry guidance, and updating password policy to NIST 800-63B recommendations (which involve more permissive password requirements alongside stronger compromise detection, the modern guidance is different from older complexity requirements).
The access control work involved auditing administrative role definitions, removing access that wasn’t needed for current job functions, implementing approval workflows for high-privilege actions, and adding audit logging for administrative changes.
The sprint took eight weeks. The security team’s risk register dropped substantially after the sprint completed.
The Third Sprint: Foundational Controls
The third sprint addressed foundational controls that had been deferred. The list included formalizing the incident response procedure with named roles and tested escalation paths, implementing centralized logging with appropriate retention, deploying file integrity monitoring on critical components, configuring vulnerability scanning integrated with the development workflow, and establishing a vendor risk management process for third-party integrations.
The work was less glamorous than the prior sprints and harder to justify to leadership in terms of immediate risk reduction. But it produced the operational foundation that made ongoing security posture sustainable rather than dependent on one-time projects.
The incident response work specifically involved tabletop exercises that surfaced gaps in the existing plan. The plan documented escalation paths, but several of the named contacts had left the company or changed roles. The exercises identified the gaps and updated the plan to reflect current reality.
The sprint took six weeks. By the end of week 20 of the engagement, the original 47-item backlog was down to 8 items, all of which were either accepted risks documented appropriately or items deferred to subsequent quarters with documented timing.
The Operational Discipline That Stuck
The remediation work was visible. The operational discipline that produced durable outcomes was less visible but arguably more important.
A monthly security review process was established with security, engineering, and executive participation. The process reviewed new findings, validated remediation status on previous findings, and adjusted prioritization based on emerging risk. The process gave security visibility into engineering work and engineering visibility into security priorities, which substantially reduced the disagreements that had previously paralyzed action.
A vulnerability management workflow was integrated into the engineering process. New dependency vulnerabilities surfaced through automated scanning, prioritized through the same framework used in the engagement, and assigned to development sprints rather than accumulating in a separate backlog.
A documented exception process was established for cases where a finding couldn’t be remediated within standard timing. The exception process required executive approval, documented business justification, and compensating controls. The process meant exceptions were visible and intentional rather than invisible and accidental.
Quarterly penetration testing was established with rotating focus areas to maintain ongoing validation of the security posture. The testing produced findings that fed into the monthly review process, which kept the security work continuously refreshed rather than letting it drift back into backlog.
| Sprint | Focus | Duration | Impact |
|---|---|---|---|
| Sprint 1 | Regulatory and contractual (PCI DSS, B2B requirements) | 6 weeks | Customer contract proceeded; PCI scope restored to SAQ A |
| Sprint 2 | High-impact exploitable vulnerabilities | 8 weeks | Risk register dropped substantially; MFA deployed; admin access tightened |
| Sprint 3 | Foundational controls (incident response, logging, vulnerability mgmt) | 6 weeks | Operational foundation for ongoing security posture |
| Ongoing | Monthly security review, vulnerability workflow, quarterly pentest | Continuous | Backlog drift prevented; security maintained as operational discipline |
What Made This Work
The remediation worked because the structure produced agreement rather than conflict between stakeholders. The re-prioritization exercise gave engineering a defensible framework for sequencing rather than an opaque list from security. It gave security confidence that the prioritization reflected actual risk rather than engineering convenience. It gave the executive sponsor visibility into the work in business terms (regulatory exposure, customer contract risk, operational readiness) rather than technical terms.
The remediation also worked because the execution included security team review at each step. Engineering completed the work and security validated that the work actually addressed the finding. Without this validation, remediation tends to be self-reported and audit findings come back as “still open” in subsequent audits.
The operational discipline that stuck worked because it was integrated into existing processes rather than created as separate processes. The monthly security review used the existing engineering cadence. The vulnerability workflow used the existing development tooling. The exception process used the existing change management. Adding security to processes the teams already used produced adoption that creating new processes wouldn’t have.
Bemeir’s mid-market engagement model treats security remediation as a structured engagement that produces operational discipline, not as a one-time project that delivers a fixed scope. The pattern works because security posture is inherently continuous, the backlog will re-accumulate if the discipline isn’t there, and the structured engagement is meant to install the discipline.
Implications for Other Mid-Market Retailers
The patterns from this engagement apply broadly to mid-market retailers facing similar backlogs. The implications worth noting:
The conflict between security and engineering usually resolves through better prioritization, not through louder advocacy. The frameworks that work involve regulatory and contractual exposure, exploitability and impact, and remediation cost relative to risk. Getting all three perspectives explicit in the prioritization shifts the conversation productively.
Forcing events accelerate backlog resolution. Customer contractual requirements, M&A diligence, or major audit findings produce executive sponsorship that ordinary security advocacy doesn’t. Retailers who anticipate forcing events can use them as opportunities to clear backlog rather than scrambling reactively.
Operational discipline matters more than one-time remediation. The retailer who clears the backlog without building the operational process to prevent re-accumulation will be back in the same position within 12–18 months. The retailer who builds the process during remediation maintains the gains durably.
External expertise is often the difference between a stalled internal conversation and forward progress. A partner with experience across multiple comparable remediations can move the conversation past the prioritization debate that internal teams have been stuck on. The cost of the engagement typically pays back through faster resolution and durable operational improvement. Useful references for the structured approach include the PCI Security Standards Council guidance documents and the NIST 800-53 security control catalog.
