Cloud Security Posture Remediation for a Healthcare-Adjacent SaaS

A SaaS platform operating in a healthcare-adjacent industry where customer trust and regulatory posture were existential rather than aspirational. The platform had grown its AWS footprint organically over several years; its security posture had grown accordingly — meaning unevenly.

A routine security scan against the platform's AWS footprint had returned a large volume of findings — high-severity, medium-severity, and informational — without prioritization the engineering team could act on. The team had three engineers with security ownership; the finding volume was beyond what three engineers could triage manually within any reasonable timeframe.

The leadership needed two things: a triage framework that would surface what genuinely required immediate action, and a remediation engagement that would close the high-severity findings without consuming the team's full capacity for months.

A two-phase engagement combining triage methodology with remediation execution.

Phase one — triage — Findings were classified along three dimensions: actual exposure (was the issue genuinely reachable in the platform's threat model), data sensitivity (did the issue affect resources holding customer data), and remediation cost (what would it take to fix). The classification produced a prioritized backlog where the top items were the ones that genuinely mattered, not the ones with the highest severity score in the scan output.

Phase two — remediation — The high-priority items were addressed in sprints alongside the platform's normal engineering work:

• ◇IAM policies were rationalized; over-privileged roles were scoped to least privilege
• ◇S3 buckets with public access configured (intentionally or accidentally) were reviewed; intentional public access was preserved with explicit policy, accidental public access was closed
• ◇Security group rules were audited; rules permitting access from anywhere were reviewed and tightened
• ◇Secrets that had been committed to repositories or configuration were rotated and moved to a managed secret store
• ◇Logging and audit configuration was extended to cover the gaps the audit had identified

Phase three — operational practice — The team adopted Infrastructure-as-Code patterns that made security configuration declarative, with policy-as-code checks running in the deployment pipeline. New resources couldn't be provisioned without meeting the security baseline; the team's previous reactive remediation pattern was replaced with prevention.

The platform exited the engagement with a substantially improved security posture against its threat model, the high-severity findings closed, and operational practices in place that prevented the previous accumulation pattern from recurring. The team's security ownership shifted from reactive triage to declarative baseline enforcement.

The work was as much methodology as it was technical execution. The triage framework was the leverage point; remediation was the execution of what triage prioritized.