Approve each change for the exact revision, and keep the record of what ran.
A customer or an auditor samples one change and asks who approved it, and what exactly they approved. A change is a plan, and a plan is an ordered list of steps against named hosts. It is previewed on each host, approved for one revision and run, and nothing can be edited in between without voiding the approval.
The approval covers the revision that runs. Edit the plan and it is void.
The approver must hold access to the environment, and the environment comes from the hosts the plan targets. A run in a protected environment waits until that person decides.
Patch nginx across prod
Upgrade nginx to 1.25.3@alex → AIDry-run passedApproval requiredAudit
- Revision
- Covers revision 7 only.
- Targets
- web-01, web-02, web-03 in prod, derived from the targets
- Approver
- Must hold access to prod
See what each host will do before anyone approves.
The dry run connects to every target and reports per host. The approver reads what would change on web-02 and not a summary of the plan.
Dry run #4f2a, revision 7
| Host | Changes | Destructive | Time |
|---|---|---|---|
| web-01 | 4 | 0 | 810 ms |
| web-02, diff shown | 4 | 0 | 790 ms |
| web-03 | 4 | 0 | 840 ms |
| Total | 12 | 0 | |
| Since the last run | +2 | 0 | |
| ssl_session_tickets added | |||
Diffweb-02
--- a/etc/nginx/nginx.conf+++ b/etc/nginx/nginx.conf@@ -1,7 +1,7 @@user www-data;−worker_processes 4;+worker_processes auto;pid /run/nginx.pid;@@ -31,6 +31,7 @@ssl_prefer_server_ciphers on;− ssl_protocols TLSv1.2;+ ssl_protocols TLSv1.3;+ ssl_session_tickets off;
The chain from request to outcome, kept for the auditor who samples it.
The record keeps who asked, what drafted the plan (the model is named when the AI composer did), the dry run, who approved and what happened. It is the fourth record on the evidence page.
Change record /Patch nginx across prod, run #4f2a
@alex → AIDry-run passedApproved by @danaAudited · #4f2a
- Origin
- Drafted by the AI composer for @alex
- Targets
- web-01, web-02, web-03 in prod
- Dry run
- 3 hosts, 12 changes, 0 destructive
- Approved
- Dana Okafor at 14:32:07, for revision 7 only
- Outcome
- Completed on 3 hosts, 4 steps
The requirement it answersRegulation (EU) 2024/2690, point 6.4.2
“documented and ... tested and assessed in view of the potential impact before being implemented”
The point asks for documented, tested and assessed changes. The approval, bound to the revision that runs, is what Opafra adds on top.
Approve a plan once, run it many times as a standard change.
A routine job does not need a new approval request every time it runs. Approve the plan once, put it in the catalogue as a standard change, and run it whenever the job comes round. Each run is still recorded.
- Approved once, for one revision
- The approval covers an exact revision, as for any change. Edit the plan and it leaves the catalogue until it is approved again.
- Run many times, each run recorded
- Every run of a standard change writes its own record: who ran it, on which hosts, which approved revision ran and what happened.
- Lower risk, and the history shows it
- A change that has run before under an approval is lower risk than a new one, and the earlier runs are on the record for the change board that rates it.
When production is down, run now. Approve and review it afterwards.
Waiting for an approver is the wrong cost in an incident. The emergency path lets a person with access to the environment run the plan now, and it is recorded as an emergency change so that nothing about it is hidden.
- Run now, with a reason
- The person states why it cannot wait, the run starts at once, and the audit log writes it as it writes any run.
- Independent approval and review afterwards, within a set window
- A second person, not the one who ran it, approves and reviews the change after the fact, within the window your organization sets, and the review is signed on the record.
- Recorded as an emergency change
- The record says it was an emergency change, who ran it, who reviewed it afterwards and when, so a sample of emergency changes is a list and not a search.
The changes that repeat need a record every time they run.
A scheduled run goes through the same approval gate as a manual one.
- Patching, with the reason a server was skipped
- A scheduled patch plan shows a preview for each host, runs after approval, and asks for a reason on any host it leaves out. Per host, the record reads patched, or skipped with the reason, with the run and the approver.
- Certificate renewal
- A scheduled plan checks expiry on every domain, renews what is due, installs the certificate and reloads the service that holds it. Each renewal is a run: which hosts, which certificate, and the result.
- Configuration changes
- Edit a file or a template on many servers at once. Each host shows its diff before anything changes, and every revision is kept.
Remediate against CIS and STIG baselines, with the exceptions on the record.
Remediation runs as plans, so each fix is previewed on each host, approved for its revision and recorded like any other change. A control you decide not to remediate is an exception, and the exception is recorded too.
- Remediation as plans
- Write the fix for a control as a plan, preview it on every host, approve it and run it. The run records the result per host. The benchmark itself stays yours.
- A recorded exceptions list
- Each exception names the host and the control, with the reason it was left and the person who approved leaving it. The list is what a reviewer asks to see next to the runs.
Answer the change question with a record.
Tell us how changes reach your servers today and who has to approve them. You get a demo and your price in writing within one business day, with no call.