When the approval record is a row in the approver's own database
An auditor asks for evidence that a change was approved. The evidence is a state field in a ticketing table. Whoever can write to that table can produce the evidence, and the list of who can is longer than anyone expects.
Who can write an approval into your ITSM platform?
More parties than anyone assumes. In ServiceNow and comparable platforms an approval is a row, and rows can be set by a human clicking approve, a platform administrator, an integration service account, a business rule, a REST call, an import set or a delegation rule. Every path produces an identical record.
- An approval stored as application state is an assertion by the application, not evidence about a person.
- The write paths into that state — platform admins, integration accounts, workflow automation, direct API — are numerous and usually uninventoried.
- Attaching a signature over the rendered change to the ticket makes the record verifiable independently of the platform holding it.
Part of Privileged identity and account recovery
Who can write an approval
Ask an ITSM administrator to enumerate everything that can set an approval state to approved. The list is consistently longer than the organisation assumes.
| Write path | Typically inventoried? |
|---|---|
| A human clicking Approve in the interface | Yes |
| Platform administrators with table-level write access | Rarely |
| Integration service accounts (CI/CD, monitoring, chatops) | Sometimes |
| Workflow automation and business rules | Rarely — and they accumulate |
| Direct REST API calls with a valid token | Rarely |
| Import sets and bulk data loads | Almost never |
| Delegation and out-of-office auto-approval rules | Almost never |
Every row produces a record indistinguishable from the first. The audit log will show which account made the write, and the account is not the same thing as the person.
Three realistic failure modes
- Direct state change. Someone with table write access sets the approval, or alters the approver field after the fact. The change proceeds with a clean record.
- Integration abuse. A service account exists to update tickets from a pipeline. Its token is broadly scoped because narrowing it was fiddly, and it can approve as easily as comment.
- Payload drift. The ticket described change A. The change that executed was A plus something added afterwards. The approval record is accurate about the ticket and wrong about the change.
The third is the most common and the least discussed, because nothing is compromised. The process simply does not bind the approval to the artefact.
What the signature has to cover
Not the ticket. The change.
# Weak — signs a reference. The referent can move.
sign({ "ticket": "CHG0048219", "decision": "approved" })
# Strong — signs the change itself.
sign({
"ticket": "CHG0048219",
"repository": "platform/payments",
"commit": "a3f91c8e2b7d4056891fa2c73e1b9d40",
"environment": "production",
"migrations": ["2026_04_06_add_index", "2026_04_06_backfill"],
"window": "2026-04-08T02:00Z/04:00Z",
"approver": "[email protected]"
})
# digest recomputed and compared at deploy timeWith the commit in the signed statement, a change that drifts after approval produces a digest mismatch at the gate. The deploy stops rather than proceeding under an approval that covered something else.
Keeping the platform, changing the evidence
None of this argues for replacing the ITSM platform. Workflow, routing, CAB scheduling and reporting are what it is for, and it does them well.
The change is narrow: the approval step captures a signature over the rendered change, the receipt is stored on the ticket, and the deployment gate verifies the receipt rather than reading the state field.
| Element | Stays in the platform | Moves to the receipt |
|---|---|---|
| Routing and assignment | Yes | — |
| CAB scheduling and calendars | Yes | — |
| Reporting and metrics | Yes | — |
| The fact of approval | Displayed | Attested |
| What was approved | Described | Bound |
| Who approved it | Recorded as an account | Signed by a person |
What an auditor gets
A file. It contains the canonical change, the signature, the approver's credential identifier and the verification state of their authenticator. It checks against a published key with no call to the ITSM platform.
This matters because it changes the audit question from "do we trust this platform's integrity controls" to "does this signature verify". The first is an assessment; the second is arithmetic.
Which changes warrant it
Not all of them. A standard pre-approved change to rotate a log level does not need a signature, and requiring one would produce reflexive approval — the exact behaviour that makes approvals worthless.
- Production deployments to systems in audit scope
- Access and permission changes, especially self-service elevation
- Firewall and network boundary changes
- Anything touching data retention, backups or encryption configuration
- Emergency changes, where the process is weakest and the stakes are highest
The last bullet deserves emphasis. Emergency change paths exist precisely to bypass controls under time pressure, which makes them the path an insider uses and the one auditors examine hardest.
Three failure modes, and the quiet one
| Mode | What it looks like afterwards |
|---|---|
| Direct state change | A clean record, set by someone with table write access |
| Integration abuse | A broadly scoped service token that can approve as easily as comment |
| Payload drift | An accurate record of a ticket, and a change that differs from it |
The third is the most common and least discussed, because nothing is compromised. The ticket described change A; the change that executed was A plus something added afterwards. The approval is accurate about the ticket and wrong about the change.
Objections and honest limits
“We can lock down write access to the approval table.” Partly. Administrators, integrations and automation all need write access for legitimate reasons, and the list grows. Locking it down helps and produces no evidence.
“This means replacing our ITSM platform.” It does not. Routing, CAB scheduling, calendars and reporting stay exactly where they are. Only the approval artefact changes — a signature over the rendered change, stored on the ticket.
Making the approval artefact testable
- Enumerate every write path to the approval state. Including import sets and delegation rules. Write the list down.
- Sign the change, not the ticket reference. Repository, commit, environment, migrations, window — not just the ticket number.
- Store the receipt on the ticket. So workflow and evidence stay together.
- Verify at the deployment gate. Recompute the digest and refuse on mismatch, rather than reading the state field.
- Scope it to changes that matter. Production deployments in audit scope, access changes, network boundary changes, retention configuration and emergency changes.
Terms used here
- Approval state
- A field on a change record. Whoever can write the field can produce the approval, and the audit log shows an account rather than a person.
- Payload drift
- The gap between the change described in the ticket and the change that executed.
- Emergency change
- The path that exists to bypass controls under time pressure — therefore the path an insider uses and the one auditors examine hardest.
Frequently asked questions
Can't we lock down write access to the approval table? Partly. Platform administrators, integrations and automation all need write access for legitimate reasons, and the list grows over time. Locking it down helps and does not produce evidence.
Does this replace the ITSM platform? No. Routing, scheduling and reporting stay. Only the approval artefact changes — a signature over the rendered change, stored on the ticket.
What is payload drift? The approval covered the change described in the ticket; the change that executed differed. Nothing is compromised — the approval simply was not bound to the artefact.
Should every change require a signature? No. Reserve it for production deployments in audit scope, access changes, network boundary changes, retention configuration and emergency changes.
Which changes warrant a signature? Production deployments in audit scope, access changes, network boundary changes, retention configuration and emergency changes.
Where this fits in Manav
Manav's receipt sits on the ticket as an attachment and verifies against a published key. The deployment gate checks the signature and recomputes the commit digest, so a change that drifted after approval stops instead of shipping.