Monthly patches applied directly to running production servers in the organization's IaaS environment have repeatedly broken applications, and teams now delay patching for months. Which process best balances security and stability?

Effective patch management treats patches as changes: they are evaluated for relevance and severity, tested in a staging environment that mirrors production, and deployed in a controlled way with the ability to back out. In the cloud a common pattern is to patch a golden image, validate it, and replace running instances in staged waves, starting with a canary group, with a documented rollback to the previous image. This preserves both security and stability. Abandoning patching in favour of network controls leaves known vulnerabilities in place; security groups and a WAF reduce exposure for some attack paths but cannot address local, authenticated or non-HTTP exploitation. Waiting for active exploitation inside the organization means patching only after compromise, which inverts the purpose of vulnerability management. Fully automatic, untested patching of every production server at once removes the delay but reproduces the outages that caused the backlog, with no staged exposure or rollback. Exam caveat: in IaaS the customer patches guest operating systems and applications; in PaaS and SaaS the provider patches the platform, and the customer's role shifts to tracking provider notices and testing compatibility. Operational check: confirm that patch compliance is reported per server, that critical patches meet the defined remediation timeframe, and that each rollout records the image version deployed and the rollback tested.