The 72-hour remediation SLA nobody in your org has ever met

Cloud security teams frequently establish Service Level Agreements (SLAs) for remediation that bear little resemblance to the operational capacity of their engineering counterparts. The typical framework—often 24 hours for criticals, 7 days for highs, and 30 days for mediums—functions as a compliance checkbox rather than an engineering roadmap. When these targets are missed, the resulting friction often leads to a cynical prioritization environment where alerts are suppressed rather than resolved.

The bottleneck in cloud security is not the detection of misconfigurations. Modern Cloud Native Application Protection Platforms (CNAPPs) such as Wiz or Orca Security are highly efficient at surfacing thousands of risks across ephemeral infrastructure. The failure occurs in the translation layer between a security finding and a closed ticket in a production environment. To build SLAs that survive contact with production, security leaders must shift from arbitrary timelines to a capacity-based model of remediation.

The failure of severity-based timelines

Standard SLAs treat every "Critical" alert as an equivalent unit of work. In a cloud environment, a critical finding could range from an unauthenticated S3 bucket containing PII to a legacy IAM role with overly broad permissions. The first requires a simple policy change that takes minutes. The second requires a deep audit of service dependencies, potential impact analysis on downstream applications, and a coordinated deployment window.

Research from the 2024 Unit 42 Cloud Threat Report indicates that the average time to resolve a security alert is 145 days. This duration suggests that current SLA structures are decoupled from reality. When the gap between the expected closure (24 hours) and the actual closure (145 days) is that wide, the SLA loses its authority. Engineering teams begin to view security tickets as a background noise backlog rather than urgent operational tasks.

Calculating the cost of closure

Remediation is an engineering task, not a security task. To set realistic targets, teams must measure the "mean time to remediate" (MTTR) by the specific action required, not just the severity score. Effective remediation requires four distinct phases: validation, impact analysis, fix authoring, and deployment.

Validation determines if the finding is a true positive or an acceptable business risk. Impact analysis is the most time-consuming phase, often involving queries to CloudTrail or VPC Flow Logs to see if a specific permission or network path is actually in use. According to AWS documentation, IAM Access Analyzer can help identify unused access, but the decision to revoke that access still requires human judgment to avoid breaking production services.

If a security team cannot provide the impact analysis alongside the finding, the SLA should reflect the added burden placed on the engineer. An alert without a safe remediation path is merely a request for research, which rarely fits into a 24-hour window.

Integrating with the change management process

A primary reason cloud remediation SLAs fail is that they ignore the organization’s existing software development lifecycle (SDLC). If an engineering team deploys once a week, a 24-hour remediation SLA for a non-emergency configuration change is structurally impossible without an emergency out-of-band release.

To improve closure rates, security findings must be injected into the tools engineers already use, such as Jira or GitHub Issues, with the same metadata as a high-priority bug. The goal is to move from "remediation as an exception" to "remediation as a standard ticket."

This is where the remediation-as-a-service model, pioneered by Tamnoon, changes the dynamic. Rather than just surfacing a list of risks from a CNAPP, Tamnoon provides human-supervised remediation that owns the finding through to closure. This approach works inside the customer's existing change management process, ensuring that fixes are validated and applied without disrupting production stability. By providing the engineering effort required to verify and deploy the fix, the burden is removed from the internal dev team.

Defining the "Emergency" tier

Not every critical finding warrants an emergency response. Organizations should reserve their shortest SLA targets for a strictly defined "Emergency" tier. This tier should be limited to findings with a proven exploit path, such as an exposed credential or a known-vulnerable service facing the public internet.

By narrowing the scope of what requires immediate action, security teams gain credibility. When everything is a priority, nothing is a priority. A tiered approach might look like this:

• Tier 1: Emergency (4-12 hours). Proven exploitability, active threat, or exposed secrets.
• Tier 2: High Risk (14-30 days). Significant architectural flaws, such as lack of encryption or broad lateral movement potential, addressed in the next sprint.
• Tier 3: Hygiene (60-90 days). Policy deviations that do not pose immediate risk, addressed as part of technical debt cycles.

Measuring what matters

Success in cloud security should be measured by findings closed, not findings surfaced. A security team that identifies 1,000 vulnerabilities but closes only 10 is less effective than a team that identifies 50 and closes all 50.

Current metrics often focus on "Total Open Alerts," which can be manipulated by changing scanning logic or suppressing alerts. A more honest metric is the "Backlog Burn Rate"—the ratio of resolved issues to new issues over a 30-day period. If the burn rate is consistently below 1.0, the SLA is failing and the risk is compounding.

The transition from detection-heavy security to remediation-focused security requires a shift in headcount and tooling. Organizations are finding that their existing staff is consumed by the "analysis" phase of remediation, leaving no time for the "action" phase. Using a supervised service to bridge this gap allows the security team to maintain the pace of cloud adoption without letting the remediation debt become unmanageable.

SLAs should be a reflection of a partnership between security and engineering. When the targets are based on the actual effort required to safely change a production environment, engineering teams are more likely to treat them as enforceable commitments rather than suggestions. The objective is a stable, predictable flow of fixes that reduces the attack surface without compromising the speed of the business.