Governance
Change governance
Every enterprise has approval rules. Few can show that the rules were enforced on the last hundred changes to production, because the policy is held in a document, execution happens in pipelines, and nothing keeps the two aligned. OpsChain binds the approval policy to the path where the change runs. Quorum is enforced, self-approval is excluded, windows are honoured, and the evidence is generated as part of the change.
The governed change lifecycle
A governed change cannot start by accident. It is held before anything runs, released by named approvers and admitted by a window.
Propose
A person or a pipeline submits the change with its change category and the external change record it implements. Your ITSM change request stays attached to the change end to end.
Hold
The change is held in pending approval before anything starts. Nothing is queued, no runner is reserved and no step is partly executed. The pending state is shown in every list.
Approve
Each matching policy contributes a checklist line. Quorum counts distinct identities, self-approval is refused, and strict lines name their own approver groups.
Admit
Approval does not start the change. The change starts only inside a window that admits it. If it is refused, the refusal names the next scheduled window when one exists.
Prove
On completion the evidence is assembled: who requested the change, who approved it, the fingerprinted content they approved, the window it ran in and the result. The evidence can be exported as a submission packet.
Policy set by the change manager, enforced by the platform
Authors can request approval within their own automation on the base platform. Governance adds approval imposed on the estate by the change manager, which no author can bypass.
Approval as policy on the path
The change manager binds a policy to an estate path, such as production, a subsidiary or a system. Every matching change is gated, whoever wrote it. No workflow is edited and no author can bypass the policy in code.
Quorum with self-approval excluded
Checklists enforce quorum per line and count distinct identities. The requester cannot approve their own change. The platform refuses the attempt and records it.
Impacted-asset-owner approval
A policy can require the declared owner of every impacted asset to approve. Every owner must approve; there is no quota. A change whose target has no declared owner is refused at creation, so a covered change can never proceed without an approver.
Change windows with audited overrides
The window record is the change plan. It admits the workflows and actions you planned and refuses everything else. Overrides are explicit, permission-checked and audited.
Audited break-glass
A single discretionary lever for emergencies. It is named, requires a reason and is permission-checked. Each use is recorded as a warning in the audit stream and sent to your notification channels at the moment it is used.
Fingerprinted submissions and masked exports
Approvers approve the exact content of the change. A changed input changes the fingerprint, and a retry goes through approval again. The submission export is masked and fingerprint-stamped, and is generated from the records that governed the change.
Step-up before the most sensitive changes
For the operations you designate, the platform requires step-up authentication before the change can be proposed. This check comes before any approval gate.
One audited history
Every approval, rejection, override and grant is recorded on the same hash-chained, tamper-evident history that covers everything else in your estate.
Integration with your CAB and ITSM tools
Your change process stays where it is. OpsChain adds the enforcement. Every governed change carries a typed reference to the external change record it implements, so the change request your CAB raised in Jira Service Management or ServiceNow stays attached from proposal to evidence export. Approvers see the reference on the checklist. Auditors see it in the submission packet.
Pending approvals are shown consistently in the web console, the command line and notifications to your channels. The request is visibly waiting on a named person wherever your team works.
The questions your auditors ask
Who approved this change? Named identities are recorded against each checklist line, quorum is recorded, and self-approval is excluded by the platform.
Was it what they approved? The approval is bound to the fingerprinted content: target, action, version and inputs. A retry or an altered input goes through approval again.
Did it run in its window? The admitting window is on the record. Work outside a window was refused, and any override is an audited event.
What about emergencies? Break-glass releases are recorded as warning events with a mandatory reason. There is one lever, it is named, and every use is audited.
Can you hand us the evidence? Yes. A masked, fingerprint-stamped submission export is available for each change, generated from the authoritative records.
OpsChain supports the evidence you take to CPS 230/234, SOCI and TSSR discussions. It enforces the controls and produces the governed history that your compliance evidence is built from.
Change governance by role
For the CAB owner
OpsChain does not replace your change process. It enforces that process where the change runs. An approval becomes a gate held by the platform instead of a ticket state that execution can drift away from. Your CAB keeps its cadence and its ITSM tool. Every governed change carries its change request reference end to end, and the submission packet is generated automatically.
For the compliance lead
Every production change is approved by the right people, executed as approved, run inside its window and supported by evidence that can be handed over. Each of these controls is enforced by the platform. The history is hash-chained and tamper-evident, exports are masked, and the enforcement is stated precisely: self-approval is excluded and quorum is counted across distinct identities.
For the platform team
Governance applies only to the paths your change manager designates. Non-production environments run without added gates. A pending change holds no infrastructure. The emergency path is part of the design: break-glass is fast, named and audited, so teams have no reason to build an unofficial route around the process.
A governed change in a live demo
In twenty minutes we show a policy imposed on production, a change held before it starts, a self-approval refused, a window that admits the planned work and refuses the rest, an audited break-glass release, and the evidence export at the end.