Your change board gains authority. It does not lose any.
If someone has sent you this page, the question you are about to ask is whether a security vendor is now in your deploy path. The answer is no, and this page exists to show the work rather than assert it.
Churchill does not approve anything, cannot approve anything, and adds no step that WestGate controls. What it does is make your existing approval the only path that works. Today an approved release is the way changes are supposed to happen. After Churchill it is the way they can happen.
Asked in your words. Answered without hedging.
Is a security vendor now in my deploy path?
No. There is no WestGate approval step, and we cannot sign a baseline.
Does my CI/CD change?
No. It produces artifacts exactly as it does today.
Who picks the approvers?
You do. Your pool, any size, minimum two to approve.
Can anyone outside my board block a release?
No. Only members you designated.
Will it slow the application?
No. Approved operations run at native speed.
Can you push an update to my hosts?
No. Your quorum approves every baseline, or nothing runs.
Does a refusal take my workload down?
No. The operation stops; the application keeps running.
How hard is it to get off?
Removal is straightforward, and the uninstall guide ships with the trial.
Every one of these is expanded, with the mechanism, in the Technical FAQ. Nothing above is softened there.
Exactly what changes, and what does not.
- Your build pipeline, unchanged. Churchill captures the approved application when your board signs off, not at every build.
- Your release cadence, as long as governance approval already exists at each release.
- Your existing kernel security modules. SELinux, AppArmor, and kernel lockdown all stay registered and are all still consulted.
- Your identity and access tooling. Churchill verifies what executes, not who is asking.
- Your SIEM and SOAR. Churchill emits structured events in standard formats.
- Your rollback capability. A prior signed snapshot is a change request like any other.
- An approved release becomes the only path that executes. Unapproved change is refused before it takes effect.
- Approval requires signed receipts from a minimum of two of your approvers, and any one of them can deny.
- Approval keys live on your approvers' own machines, outside Churchill, and cannot be forged or hidden.
- Adoption of a new baseline restarts the protected application. This applies to rolling forward and rolling back alike.
- Every attempt, allowed or refused, lands on a hash-chained record in dual custody.
You need a change Churchill has not approved. Here is the whole path.
Written out in full because this is the sequence you will judge us on, and because you should know the constraints before you agree to anything, not after.
What this is: a governed maintenance event that produces a signed change and a protected application on the other side. What it is not: a way to hot-patch a running settlement broker. If your continuity plan needs the second thing, plan the change as a maintenance window.
Reasons to say yes, in your terms rather than ours.
Not the security argument. The five things that change for the team that owns the hosts.
Refusals happen without an analyst and without a ticket. There is no new console to staff, no alert stream to triage, and no on-call rotation added to your team.
Change approval already exists on paper. This makes it the only path, so drift, undocumented hotfixes, and 'someone fixed it Friday' stop being a category of problem you inherit.
The approved state is continuously verified rather than scanned after the fact, so hosts do not silently diverge from the baseline you signed off on between audits.
You set the pool and it has no cap. Any two of your approvers can clear an emergency, not two specific ones, so adding backups makes you more available rather than more fragile.
When someone needs proof of what ran and who approved it, the record already exists, dated and signed. Nobody spends a week exporting tickets for a compliance deadline.
Reasons to say no, from us.
You will find these eventually. Better that you find them here, in week one, than in a pilot in week nine.
No formal change board required. You name the pool and it can be anyone: a CTO, a CISO, a CIO, release managers, senior engineers. Two of them have to sign every change, never one, and any single member can veto. What does not work is a workload where changes and hot patches go out on the fly with nobody on your side signing off, because then there is no approval for Churchill to enforce.
Adopting a baseline restarts the protected application. If a given workload cannot tolerate a short restart on a governed schedule, say so early.
There is no off switch and no scheduled window that opens itself. A person opens every hold, and every hold is on the record.
Full-strength refusal at the kernel boundary needs 5.7 or higher. Below that, refusals degrade to detection and response by the sentinels, which you should weigh before committing a RHEL 8 estate.
Put it on a host you own and try to break your own pipeline with it.
A host you choose. Run your real release process against it and see what it refuses. That is a better evaluation than any conversation with us.