While reviewing a cloud provider's risk management program, a customer finds that the provider accepts certain risks, such as extended patching windows for some platform components, that exceed the customer's own risk appetite for a regulated workload. What should the customer do?

Assessing a provider's risk management program means understanding its controls, methodologies, policies, risk profile and appetite, then comparing them with the customer's own tolerance for the workload in question. Where the provider accepts risks the customer would not, such as longer patching windows, the residual risk falls on the customer and must be treated deliberately: negotiating contract commitments or service levels, applying compensating controls in the customer's layer such as segmentation or additional monitoring, choosing a different service tier or provider or formally accepting the risk with appropriate approval. Adopting the provider's appetite surrenders the customer's governance and misreads shared responsibility; the provider manages its own risks, not every risk of hosted workloads. Treating certification as making the provider's decisions binding is wrong; certifications show that a management system exists, not that its risk choices suit every customer. Transferring accountability through an SLA is impossible; contracts and insurance can shift financial impact, but accountability for regulated data remains with the customer. Exam caveat: risk appetite is set by the customer's leadership and documented, so the comparison needs that baseline. Operational check: confirm the gap, chosen treatment, owner and approval are recorded in the risk register and reviewed periodically.