The before-and-after report is the deliverable

Security work has a reputation problem inside enterprises: it is easy to spend and hard to show. A programme sponsor signs off a security workstream, months pass, settings change, and at the end someone is asked "so what did we get?" and answers with a slide.

We prefer to answer with two reports.

The pair

The CIS OCI Foundations Benchmark is the published, vendor-neutral baseline for an Oracle Cloud Infrastructure tenancy. Oracle maintains an open-source compliance script that checks a tenancy against it and produces a report: which recommendations pass, which fail, and where. It runs read-only. Your own administrator can run it.

Every engagement we lead runs that script twice. Once in the first week, before anything is touched. Once at the end, after remediation. Same script, same tenancy, same scope. The first report is the baseline. The second is the result. The difference between them is the engagement.

Two reports from the same instrument, weeks apart, are worth more than any deck about what was done in between.

What the first run is for

The "before" report does three jobs at once.

It sets the scope. A benchmark report is a list of specific failures against specific recommendations, each with a compartment, a resource and a rule number. That list is far more useful for agreeing what an engagement will fix than a statement of work written from assumptions. Items that will not be fixed are named as such, with the reason, and that is a decision your sponsor can sign.

It starts the findings register. We number findings from the first week, F-01 onward, and the benchmark supplies most of the early entries. By the time the second run happens the register is the change log of the engagement.

It calibrates everyone. A tenancy that has grown over several years always has drift between what the architecture documents describe and what the compliance script sees. Seeing that gap in a report, rather than hearing about it in a meeting, moves the conversation from opinion to evidence on day three instead of week six.

What the second run is for

The "after" report is the evidence you keep. It answers the auditor's question and the sponsor's question with the same document. It also sets the operating baseline for whoever runs the tenancy next: the recommendations that now pass are the ones the team must keep passing, and the recommendations that were consciously accepted are documented as accepted rather than forgotten.

We attach both reports to the build document, side by side, with a short table of what changed and why. The table is usually one page.

Who runs the script

Your administrator does, with our run guide and, the first time, with us on a call. We do not ask for elevated access to a tenancy in order to measure it. A practice whose recommendations are built on least privilege should not want the keys, and the audit trail is cleaner when the tooling runs under an account your organisation already governs. We supply the link to the published source rather than a copy, so your security team reviews what is actually run.

The script's home has moved over the years and the Terraform that once accompanied it has been retired in favour of Oracle's newer landing-zone modules. We tell teams that before they hit the banner, because the banner reads as more alarming than it is. The compliance script itself is current and certified against the present benchmark version.

The cost of skipping it

Engagements that skip the baseline end with claims. Engagements that skip the second run end with hope. Both are avoidable for the price of two read-only script runs and one page of comparison, which is why the pair is not optional in our method. It is the first thing we set up and the last thing we hand over.