OCI Security Checklist for Go Live

The moment before a workload goes live is the cheapest time to find a security gap and the last quiet moment you will have for a while. Once it is in production, every change carries risk, every fix needs a change window, and the open bucket or the over privileged role that was trivial to correct in staging becomes a careful production operation. A structured go live security review catches those gaps while they are still cheap to fix. This guide is a practical checklist, organised by the layers that matter, that you can run against any workload before it goes live on OCI. It is deliberately concrete, because a checklist that is too abstract gets nodded through without anyone really checking.

The value of a checklist is that it makes the review systematic rather than dependent on whoever happens to be in the room remembering to ask. Security gaps are rarely missed because they are hard to spot. They are missed because nobody looked, and a checklist is simply the discipline of looking at every layer every time, so the same thing is never quietly forgotten twice.

Identity and access

Start with who can do what, because identity is the foundation everything else rests on. Confirm that access follows least privilege, that there are no broad administrator grants handed out for convenience, that multi factor authentication is enforced for anyone with meaningful access, and that the access is governed through your central identity rather than a parallel set of local accounts. This is the discipline from our IAM policies guide and our identity federation guide, applied as a checkpoint rather than an aspiration. A workload that goes live with a flat admin role shared widely has already lost the argument before it starts.

The go live checklist

Network exposure

The second layer is what is reachable from where. Confirm that nothing is exposed to the public internet that should not be, that databases and other sensitive services sit behind private endpoints, and that the network security groups are scoped to the minimum connectivity each component needs rather than left broad. This applies our NSGs versus security lists guide as a gate, and it is one of the highest value checks because internet exposure is the most directly exploitable category of mistake. A test rule that opened a port and was never closed is exactly the kind of thing this review exists to catch.

Check the access path to your hosts too. Management access should go through the bastion service covered in our bastion service guide rather than through open ports on the hosts themselves, so that access is brokered, time limited, and audited rather than a permanent property of the network.

Data protection

The third layer is the data itself. Confirm that encryption is on, which on OCI it generally is by default, that you have made a deliberate decision about whether to manage your own keys through the vault, and that sensitive data stores are not reachable from the public internet. Our data encryption guide and our vault and key management guide cover the detail. The go live check is to confirm that the decisions were made deliberately rather than left at whatever the default happened to be, because a default that was never reviewed is a decision nobody actually made.

Detection and guardrails

The fourth layer is whether you will know if something goes wrong after go live. Confirm that Cloud Guard is running across the relevant compartments, covered in our Cloud Guard guide, and that audit logging is enabled and retained, covered in our audit logging guide. These are what give you visibility once the workload is live and changing. Where you can, put a security zone in place too, covered in our security zones guide, so that the baseline you are checking now is enforced automatically going forward rather than relying on the next person remembering to run the same checklist.

Running the review

Run the review as a gate, not a formality. The point is that a workload does not go live until each item has genuinely been checked and signed off, because a checklist that is rubber stamped without real inspection gives you the false comfort of a review without the protection of one. The recovery check at the end ties into our incident response guide, because a workload going live should already have tested backups, not backups that are configured and assumed to work.

Bringing it together

A structured go live security review catches the gaps that are cheap to fix before launch and expensive to fix after. Work through the layers, identity and least privilege, network exposure and access paths, data protection and key strategy, detection through Cloud Guard and audit logging, guardrails through security zones, and tested backups for recovery, and treat the review as a gate rather than a formality. Done that way it is one of the highest value security activities you can run, because it is systematic, it is timed for when fixes are cheapest, and it never relies on someone remembering to look. The full model is in our complete security guide, and we run go live reviews for clients through our OCI security service.