{
 "slug": "sponsor-accountability",
 "topic_id": "TOPIC-219",
 "cluster": "Enterprise IGA, Access Certification & Identity Lifecycle",
 "tier": "Tier A",
 "title": "Contractors have no HR record: the identity lifecycle nobody owns",
 "summary": "Employees are created and terminated by HR events. Contractors, vendors, auditors and partners are created by a ticket and terminated by someone remembering, and their identities routinely outlive their engagements by months.",
 "lede": "Every identity lifecycle automation in the enterprise is anchored to an HR event. Between fifteen and forty percent of the identities in a large estate belong to people the HR system has never heard of, and for them the lifecycle is a ticket and a hope.",
 "date": "2025-01-12",
 "category": "Compliance",
 "author_id": "whit-calloway",
 "tags": [
  "non-employee identity",
  "contractor access",
  "JML",
  "identity lifecycle",
  "third party risk",
  "sponsorship"
 ],
 "image_title": "Sponsor Accountability",
 "schema": "Article",
 "key_takeaways": [
  "Lifecycle automation depends on an authoritative source. Non-employees have none, so the sponsoring manager is a free-text field and the end date is optimistic.",
  "Renewal by signature inverts the failure mode: authority lapses unless someone affirmatively extends it.",
  "Count your non-employee identities before anything else — the number is usually a surprise and it is what funds the work."
 ],
 "body": [
  {
   "type": "h2",
   "text": "What I learned from a licence audit"
  },
  {
   "type": "diagram",
   "kind": "compare",
   "alt": "Two lifecycles, one of them automated",
   "caption": [],
   "nodes": "The difference is not policy. It is whether a system event exists at all.",
   "left": {
    "title": "Employee",
    "items": [
     "Created by an HR record",
     "Role changes flow through",
     "Termination is an HR event",
     "Deprovisioning is automatic"
    ]
   },
   "right": {
    "title": "Contractor",
    "items": [
     "Created by a ticket",
     "Role changes by another ticket",
     "Termination is a memory",
     "Deprovisioning is a hope"
    ]
   }
  },
  {
   "type": "p",
   "html": "We were reconciling software licences and found six hundred accounts we could not attribute to anyone. Not orphaned employee accounts — those we knew how to find. These were contractors, auditors, partner engineers, agency designers, and a category the spreadsheet called <em>external</em>."
  },
  {
   "type": "p",
   "html": "We had been paying for the licences, which is how we noticed. What we had not noticed was that a meaningful fraction still had working access to systems those people had no current business reason to enter."
  },
  {
   "type": "p",
   "html": "Nobody had done anything wrong. There was simply no event, anywhere in our systems, that corresponded to a contractor's engagement ending."
  },
  {
   "type": "h2",
   "text": "Why the lifecycle works for employees"
  },
  {
   "type": "p",
   "html": "An employee's identity lifecycle is driven by HR events: hire, transfer, promotion, leave, termination. The HRIS is authoritative, the events are structured, and joiner-mover-leaver automation subscribes to them."
  },
  {
   "type": "p",
   "html": "That architecture is genuinely good, and it is why employee offboarding works reasonably well in most enterprises. It also explains precisely why non-employee offboarding does not: the subscription has nothing to subscribe to."
  },
  {
   "type": "h2",
   "text": "The population, counted"
  },
  {
   "type": "table",
   "head": [
    "Population",
    "Authoritative source",
    "Termination event exists?"
   ],
   "rows": [
    [
     "Employees",
     "HRIS",
     "Yes"
    ],
    [
     "Contingent workers via a managed service provider",
     "VMS, sometimes",
     "Sometimes, if integrated"
    ],
    [
     "Direct contractors",
     "A ticket",
     "No"
    ],
    [
     "Vendor support engineers",
     "A contract",
     "No"
    ],
    [
     "Auditors and assessors",
     "An engagement letter",
     "No"
    ],
    [
     "Partner staff on joint projects",
     "An email thread",
     "No"
    ],
    [
     "Interns and temporary staff",
     "Varies",
     "Frequently no"
    ]
   ]
  },
  {
   "type": "p",
   "html": "Rows three through seven are where the residual access accumulates, and in most enterprises they collectively outnumber row two."
  },
  {
   "type": "h2",
   "text": "Why hard end dates do not work"
  },
  {
   "type": "p",
   "html": "The obvious answer is to require an end date at provisioning and expire automatically. Most organisations have tried it."
  },
  {
   "type": "p",
   "html": "What happens is that the end date is set optimistically, the engagement runs long, the contractor loses access mid-project, someone escalates, and the service desk extends it — by a year, to avoid the same interruption. Within two cycles the end date is a formality."
  },
  {
   "type": "p",
   "html": "The failure is not the date. It is that extension is easier than renewal, and it requires no one to reconsider anything."
  },
  {
   "type": "h2",
   "text": "Sponsor accountability"
  },
  {
   "type": "p",
   "html": "Make issuance and renewal a signed act by a named sponsor."
  },
  {
   "type": "code",
   "text": "{\n  \"type\": \"manav-stmt/1\",\n  \"action\": \"non_employee_identity_issued\",\n  \"subject\": \"[name, organisation]\",\n  \"purpose\": \"[engagement, project reference]\",\n  \"scope\": \"[systems and access levels]\",\n  \"notAfter\": \"[date — 90 days maximum]\",\n  \"sponsor\": \"[named employee, credential assertion]\",\n  \"renewal_requires\": \"fresh_signature\"\n}"
  },
  {
   "type": "p",
   "html": "The last line is the mechanism. Renewal is not a date edit performed by a service desk agent; it is a new signature by the sponsor, who must therefore re-form an opinion about whether the access is still needed."
  },
  {
   "type": "h2",
   "text": "Ninety days, not a year"
  },
  {
   "type": "p",
   "html": "The interval matters more than it appears. Ninety days means a typical six-month engagement requires one renewal — enough to catch engagements that ended early, few enough not to become noise."
  },
  {
   "type": "p",
   "html": "A twelve-month interval recreates the original problem at a slower cadence, and twelve months is what organisations choose when they optimise for sponsor convenience rather than for the control's purpose."
  },
  {
   "type": "h2",
   "text": "What to count first"
  },
  {
   "type": "ol",
   "items": [
    "Identities in your directory with no corresponding HRIS record. That is the population.",
    "Of those, how many have authenticated in the last 30 days, 90 days, and never.",
    "Of those, how many have a populated sponsor field, and how many of those sponsors are current employees.",
    "Licence cost attached to the population, which is the number that makes this a finance conversation rather than a security one."
   ]
  },
  {
   "type": "p",
   "html": "Step four is the one I would run first, because it is what got our audit funded. The security argument was correct and the licence bill was persuasive."
  },
  {
   "type": "h2",
   "text": "The sponsor model"
  },
  {
   "type": "p",
   "html": "The fix is not a new system but a named accountable person per non-employee identity, with an expiry by default. If the sponsor leaves, the identity is flagged rather than orphaned, and renewal is an affirmative act rather than an omission."
  },
  {
   "type": "table",
   "caption": "Four properties of a sponsored identity",
   "head": [
    "Property",
    "Effect"
   ],
   "rows": [
    [
     "A named sponsor, not a team",
     "Teams do not remember; people do"
    ],
    [
     "Expiry by default",
     "Persistence requires a decision"
    ],
    [
     "Sponsor departure triggers review",
     "The most common orphaning cause"
    ],
    [
     "<strong style=\"font-weight:600\">Renewal is a signed act</strong>",
     "<strong style=\"font-weight:600\">Someone owns the continued access</strong>"
    ]
   ]
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Our access reviews catch orphaned accounts.”</strong> Quarterly at best, and a review asks a manager about an account whose purpose they may not know. Expiry by default catches it without anyone reviewing anything."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Contractors need long-lived access.”</strong> Many do, and renewing every ninety days is a signature rather than a re-onboarding. The cost is proportionate to the risk of an indefinite grant."
  }
 ],
 "faq": [
  {
   "q": "What about contingent workers managed through a VMS?",
   "a": "If the VMS is integrated as an authoritative source, they behave like employees for lifecycle purposes. The problem is everyone outside that integration."
  },
  {
   "q": "Will sponsors accept quarterly renewal?",
   "a": "A signature takes seconds. The friction is receiving the request, which is a notification design problem rather than a burden problem."
  },
  {
   "q": "What happens when a sponsor leaves?",
   "a": "Their sponsored identities surface immediately as needing a new sponsor, which is the correct outcome and is currently invisible."
  },
  {
   "q": "Is ninety days too aggressive?",
   "a": "For a six-month engagement it is one renewal. Longer intervals restore the problem; shorter ones become noise. Ninety is a defensible default, not a rule."
  },
  {
   "q": "Why do contractor accounts outlive contracts?",
   "a": "Because deprovisioning depends on someone remembering, and there is no system event equivalent to an HR termination."
  },
  {
   "q": "Why a named sponsor rather than a team?",
   "a": "Teams do not remember. A named person can be asked, and their departure is a detectable trigger."
  },
  {
   "q": "Is expiry by default disruptive?",
   "a": "Renewal is a signature, not a re-onboarding. The cost is proportionate to the risk of an indefinite grant."
  }
 ],
 "sources": [
  {
   "t": "2026 research on residual access among departing and non-employee populations."
  },
  {
   "t": "Verizon Data Breach Investigations Report",
   "u": "https://www.verizon.com/business/resources/reports/dbir/"
  },
  {
   "t": "SAP / Oracle segregation of duties control guidance (ISACA)",
   "u": "https://www.isaca.org/resources"
  },
  {
   "t": "NIST SP 800-53 Rev. 5 — access enforcement",
   "u": "https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final"
  }
 ],
 "related": [
  {
   "slug": "creator-binding-offboarding",
   "title": "The engineer left; the integration did not",
   "category": "Developer"
  },
  {
   "slug": "accountable-ownership-test",
   "title": "Eighty machine identities per human",
   "category": "Developer"
  },
  {
   "slug": "loadsheet-attribution",
   "title": "The loadsheet nobody signed",
   "category": "Definitional"
  },
  {
   "slug": "corporate-espionage-kill-chain-rogue-remote-contractors",
   "title": "Source code exfiltration by people who are supposed to have it",
   "category": "Future of Work"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Sponsor%20Accountability/1200_630/blog.jpg",
 "wordcount": 955,
 "url": "/blog/sponsor-accountability.html",
 "reading_time": "4 min read",
 "seo_title": "Contractors have no HR record: the lifecycle gap",
 "meta_description": "Employees are created and terminated by HR events. Contractors are created by a ticket and terminated by someone remembering to do it.",
 "hub": {
  "slug": "topics/access-governance",
  "title": "Access governance and certification"
 },
 "answer": "Nobody, structurally. Employees are created and terminated by HR events with a system behind them. Contractors, vendors, auditors and partners are created by a ticket and terminated by someone remembering, and the person who would remember has usually moved on themselves.",
 "answer_q": "Who owns a contractor's identity lifecycle?",
 "glossary": [
  {
   "term": "Non-employee identity",
   "def": "A contractor, vendor, auditor or partner account, created outside the HR lifecycle."
  },
  {
   "term": "Sponsor",
   "def": "The named individual accountable for a non-employee identity's existence and scope."
  },
  {
   "term": "Orphaned account",
   "def": "An identity whose sponsor or purpose no longer exists, which persists because nothing triggers its removal."
  }
 ],
 "checklist": {
  "title": "Implementing sponsorship",
  "id": "sponsor",
  "desc": "Four steps.",
  "steps": [
   {
    "name": "Require a named sponsor at creation.",
    "text": "A person, never a team or a ticket queue."
   },
   {
    "name": "Set expiry by default.",
    "text": "Ninety days is a reasonable starting point."
   },
   {
    "name": "Trigger review on sponsor departure.",
    "text": "The most common cause of orphaning."
   },
   {
    "name": "Make renewal a signed act.",
    "text": "So continued access has an owner."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav turns an access or elevation decision into an artefact: what the approver was shown, who they were, what authority they held, signed and verifiable without your systems.",
  "href": "../docs.html",
  "label": "See approval receipts"
 }
}