What should organisations do when ASPM findings are not being remediated?

Why This Matters for Security Teams

ASPM only creates value when findings drive action. If issues remain open without ownership, they become a reporting layer that documents risk but does not reduce it. Security teams often assume visibility is enough, yet unmanaged findings can mask recurring exposure across application code, cloud configuration, secrets handling, and CI/CD pipelines. That is especially true where ASPM aggregates many scanners and the same defect appears in multiple places.

The practical failure is not usually a lack of findings. It is a lack of decision-making. Teams need a clear path from detection to remediation, accepted risk, or formal exception. Without that, backlog growth erodes developer trust and security reports are treated as noise. NIST SP 800-53 Rev. 5 Security and Privacy Controls is a useful reference point because it ties governance to operational control ownership, not just assessment activity.

In practice, many security teams encounter repeat exposure only after a production incident, a failed audit, or a customer escalation has already occurred, rather than through intentional remediation discipline.

How It Works in Practice

The remediation process should start with triage, not with a generic queue. Findings need to be classified by severity, exploitability, asset criticality, and business context so that teams can decide whether to fix, mitigate, or formally accept the risk. ASPM works best when each finding is mapped to a named owner, a target SLA, and the workflow that will close it. That workflow may be a ticketing system, pull-request approval, change-management gate, or an exception register.

Best practice is to connect ASPM to the same operational systems that already govern delivery. For example, build-time blockers can stop merges for critical issues, while lower-risk findings can flow into sprint planning. Current guidance suggests that exception handling should include expiry dates, compensating controls, and re-review. The NIST Cybersecurity Framework provides a practical way to align these activities with governance, identification, protection, detection, and recovery outcomes.

• Assign one accountable owner per finding or grouped defect class.
• Use severity plus business context to set remediation deadlines.
• Link high-risk findings to release gates so unresolved issues block deployment.
• Track exceptions separately so accepted risk does not disappear into the backlog.
• Measure aging, recurrence, and closure quality, not only open issue counts.

Where teams want control evidence, OWASP ASVS can help translate findings into verifiable security requirements for applications. These controls tend to break down when ownership is split across security, platform, and product teams because no single group can approve remediation priority or accept the residual risk.

Common Variations and Edge Cases

Tighter remediation controls often increase delivery overhead, requiring organisations to balance faster risk reduction against developer throughput. That tradeoff becomes visible in fast-moving product teams, regulated environments, and organisations with many inherited findings from legacy tooling. There is no universal standard for ASPM SLA design yet, so guidance should be adapted to the maturity of the engineering organisation and the risk profile of the applications.

One common edge case is noisy findings that never reach a human decision because they are duplicates, low confidence, or irrelevant to the deployed configuration. In those environments, the answer is not stricter escalation alone. It is better deduplication, tuning of detection rules, and suppression with documented justification. Another edge case is third-party or outsourced development, where remediation depends on contract terms and change windows rather than direct internal control.

For workflow design, the CISA Known Exploited Vulnerabilities Catalog is useful when ASPM findings map to actively exploited issues and leadership needs a prioritisation signal. If exceptions are overused or never expire, the process stops being a control and becomes a parking lot for unresolved risk.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?