{
 "slug": "servicenow-ticket-manipulation-preventing-unauthorized-admin-elevation",
 "topic_id": "TOPIC-033",
 "cluster": "Privileged Identity & Help-Desk Takeover",
 "tier": "Tier B",
 "title": "When the approval record is a row in the approver's own database",
 "summary": "IT service management platforms store approvals as database rows. Rows can be written by an API, altered by an administrator, and produced by an integration nobody is watching.",
 "lede": "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.",
 "date": "2024-12-17",
 "category": "Developer",
 "author_id": "solene-beaumont-adjei",
 "tags": [
  "ITSM",
  "change control",
  "approvals",
  "audit evidence",
  "insider threat",
  "ServiceNow"
 ],
 "image_title": "Approval Record Database Row",
 "schema": "Article",
 "key_takeaways": [
  "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."
 ],
 "body": [
  {
   "type": "h2",
   "text": "Who can write an approval"
  },
  {
   "type": "diagram",
   "kind": "flow",
   "alt": "Seven ways an approval state gets set, and how many are inventoried",
   "caption": "Ask an administrator to enumerate these. The list is consistently longer than the organisation assumes.",
   "nodes": [
    {
     "label": "Human clicks Approve",
     "note": "inventoried"
    },
    {
     "label": "Platform admin writes the field",
     "note": "rarely",
     "bad": true
    },
    {
     "label": "Integration service account",
     "note": "sometimes",
     "bad": true
    },
    {
     "label": "Business rule or workflow",
     "note": "rarely — and they accumulate",
     "bad": true
    },
    {
     "label": "REST call, import set, delegation rule",
     "note": "almost never",
     "bad": true
    }
   ]
  },
  {
   "type": "p",
   "html": "Ask an ITSM administrator to enumerate everything that can set an approval state to approved. The list is consistently longer than the organisation assumes."
  },
  {
   "type": "table",
   "head": [
    "Write path",
    "Typically inventoried?"
   ],
   "rows": [
    [
     "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"
    ]
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Three realistic failure modes"
  },
  {
   "type": "ol",
   "items": [
    "<strong style=\"font-weight:600\">Direct state change.</strong> Someone with table write access sets the approval, or alters the approver field after the fact. The change proceeds with a clean record.",
    "<strong style=\"font-weight:600\">Integration abuse.</strong> 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.",
    "<strong style=\"font-weight:600\">Payload drift.</strong> 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."
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "What the signature has to cover"
  },
  {
   "type": "p",
   "html": "Not the ticket. The change."
  },
  {
   "type": "code",
   "text": "# Weak — signs a reference. The referent can move.\nsign({ \"ticket\": \"CHG0048219\", \"decision\": \"approved\" })\n\n# Strong — signs the change itself.\nsign({\n  \"ticket\":      \"CHG0048219\",\n  \"repository\":  \"platform/payments\",\n  \"commit\":      \"a3f91c8e2b7d4056891fa2c73e1b9d40\",\n  \"environment\": \"production\",\n  \"migrations\":  [\"2026_04_06_add_index\", \"2026_04_06_backfill\"],\n  \"window\":      \"2026-04-08T02:00Z/04:00Z\",\n  \"approver\":    \"s.beaumont@example.com\"\n})\n# digest recomputed and compared at deploy time"
  },
  {
   "type": "p",
   "html": "With 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."
  },
  {
   "type": "h2",
   "text": "Keeping the platform, changing the evidence"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "table",
   "head": [
    "Element",
    "Stays in the platform",
    "Moves to the receipt"
   ],
   "rows": [
    [
     "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"
    ]
   ]
  },
  {
   "type": "h2",
   "text": "What an auditor gets"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Which changes warrant it"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "ul",
   "items": [
    "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"
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Three failure modes, and the quiet one"
  },
  {
   "type": "table",
   "caption": "How approval records fail",
   "head": [
    "Mode",
    "What it looks like afterwards"
   ],
   "rows": [
    [
     "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"
    ],
    [
     "<strong style=\"font-weight:600\">Payload drift</strong>",
     "<strong style=\"font-weight:600\">An accurate record of a ticket, and a change that differs from it</strong>"
    ]
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“We can lock down write access to the approval table.”</strong> Partly. Administrators, integrations and automation all need write access for legitimate reasons, and the list grows. Locking it down helps and produces no evidence."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“This means replacing our ITSM platform.”</strong> 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."
  }
 ],
 "faq": [
  {
   "q": "Can't we lock down write access to the approval table?",
   "a": "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."
  },
  {
   "q": "Does this replace the ITSM platform?",
   "a": "No. Routing, scheduling and reporting stay. Only the approval artefact changes — a signature over the rendered change, stored on the ticket."
  },
  {
   "q": "What is payload drift?",
   "a": "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."
  },
  {
   "q": "Should every change require a signature?",
   "a": "No. Reserve it for production deployments in audit scope, access changes, network boundary changes, retention configuration and emergency changes."
  },
  {
   "q": "Which changes warrant a signature?",
   "a": "Production deployments in audit scope, access changes, network boundary changes, retention configuration and emergency changes."
  }
 ],
 "sources": [
  {
   "t": "AICPA Trust Services Criteria (SOC 2)",
   "u": "https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022"
  },
  {
   "t": "ITIL 4 change enablement practice",
   "u": "https://www.axelos.com/certifications/itil-service-management"
  },
  {
   "t": "FTC — business guidance on marketplaces and consumer protection",
   "u": "https://www.ftc.gov/business-guidance"
  },
  {
   "t": "RFC 8785 — JSON Canonicalization Scheme",
   "u": "https://www.rfc-editor.org/rfc/rfc8785"
  },
  {
   "t": "ISO/IEC 20000-1 — service management system requirements",
   "u": "https://www.iso.org/standard/70636.html"
  }
 ],
 "related": [
  {
   "slug": "soc-2-common-criteria-6-8-replacing-slack",
   "title": "Replacing Slack screenshots with cryptographic proof",
   "category": "Developer"
  },
  {
   "slug": "privileged-access-management-pam-under-attack-gating-just",
   "title": "Gating just-in-time escalation",
   "category": "Developer"
  },
  {
   "slug": "github-copilot-pr-approval-soc2-supply-chain-risk",
   "title": "When an AI approves the pull request",
   "category": "AEO"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Approval%20Record%20Database%20Row/1200_630/blog.jpg",
 "wordcount": 937,
 "url": "/blog/servicenow-ticket-manipulation-preventing-unauthorized-admin-elevation.html",
 "reading_time": "4 min read",
 "seo_title": "When the approval record is a database row",
 "meta_description": "ITSM platforms store approvals as database rows. Rows can be written by an API, altered by an administrator, or set by an integration.",
 "hub": {
  "slug": "topics/privileged-identity",
  "title": "Privileged identity and account recovery"
 },
 "answer": "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.",
 "answer_q": "Who can write an approval into your ITSM platform?",
 "entities": [
  {
   "name": "ServiceNow",
   "type": "Organization",
   "url": "https://www.servicenow.com/",
   "primary": true
  }
 ],
 "glossary": [
  {
   "term": "Approval state",
   "def": "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."
  },
  {
   "term": "Payload drift",
   "def": "The gap between the change described in the ticket and the change that executed."
  },
  {
   "term": "Emergency change",
   "def": "The path that exists to bypass controls under time pressure — therefore the path an insider uses and the one auditors examine hardest."
  }
 ],
 "checklist": {
  "title": "Making the approval artefact testable",
  "id": "testable",
  "desc": "Five steps inside your existing platform.",
  "steps": [
   {
    "name": "Enumerate every write path to the approval state.",
    "text": "Including import sets and delegation rules. Write the list down."
   },
   {
    "name": "Sign the change, not the ticket reference.",
    "text": "Repository, commit, environment, migrations, window — not just the ticket number."
   },
   {
    "name": "Store the receipt on the ticket.",
    "text": "So workflow and evidence stay together."
   },
   {
    "name": "Verify at the deployment gate.",
    "text": "Recompute the digest and refuse on mismatch, rather than reading the state field."
   },
   {
    "name": "Scope it to changes that matter.",
    "text": "Production deployments in audit scope, access changes, network boundary changes, retention configuration and emergency changes."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "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.",
  "href": "../docs.html",
  "label": "See change-control receipts"
 }
}