TL;DR
- Every clause must be testable. If a clause cannot be turned into a query against your systems, it is a statement of intent and will not survive an audit.
- Nine sections. The ones most often missing are exceptions and retirement, and their absence produces the two most common findings.
- Put thresholds in the policy, not in a standard nobody reads. A policy that says "credentials shall be rotated regularly" is unenforceable.
- Invert the default: expiry automatic, extension requiring justification. This single choice does more than any other clause.
The design principle
A policy clause is worth writing only if you can answer two questions about it: what query proves compliance, and what happens when the answer is no. Clauses that fail either test are decoration, and an auditor will treat them as such.
The template below is deliberately terse. Adapt the numbers; keep the testability.
1. Scope and definitions
This policy applies to every credential used by software to authenticate to a system, including service accounts, API keys, OAuth clients and grants, cloud IAM roles and access keys, Kubernetes service accounts, workload identities, certificates, SSH keys, and AI agent credentials, whether issued by this organisation or granted to a third party for access to our systems.
Why this wording: the enumeration prevents the most common scoping failure, where "service accounts" is read narrowly and OAuth grants, CI/CD tokens and agent credentials fall outside. The final clause brings third-party grants in scope, which they otherwise are not.
2. Creation and approval
Non-human identities may be created only through an approved issuance path that records requester, purpose, owner, systems to be accessed, and expiry. Creation outside an approved path is a policy violation and the resulting identity will be revoked on discovery.
Testable by: comparing discovered identities against issuance-path records. The gap is your violation rate. Precondition: the approved path must be faster than the workaround, or this clause converts engineers into violators rather than users.
3. Ownership
Every non-human identity has a single named individual owner. Team names, distribution lists and role titles are not valid owners. On an owner's departure, ownership transfers before their access is removed; identities without a transferred owner are suspended within 30 days.
Testable by: joining the inventory to the HR leaver feed. Why individuals: a team cannot be accountable, and offboarding never triggers on a mailbox.
4. Credentials
Credentials must be attested from the runtime where the platform supports it. Where a static credential is unavoidable it must carry an expiry not exceeding 90 days for standard identities and 30 days for identities able to write to production. Credentials must not appear in source code, container images, configuration files, logs, or any context supplied to an AI model. Extension of a credential lifetime requires documented justification; expiry does not require approval.
Testable by: lifetime distribution query, plus secrets scanning across repositories, images and logs. The important sentence is the last one: inverting the default from "expiry needs approval" to "extension needs justification" changes behaviour more than any other clause in this document.
5. Privilege
Permissions are granted according to observed need. Permissions granted but not exercised within 90 days are removed unless a documented exception applies. No non-human identity holds standing administrative privilege.
Testable by: the granted-versus-exercised diff. Note the framing: "observed need" rather than "least privilege", because least privilege is unfalsifiable and an exercised-permissions diff is not.
6. Review
Non-human identities are reviewed on a cycle determined by reach: quarterly where the identity can write to production data or crosses a third-party boundary, annually otherwise. Reviews are conducted against exercised permissions rather than by attestation. A review is complete when resulting revocations have been executed, not when decisions have been recorded.
Testable by: review records with executed-change evidence. The last sentence is the one auditors care about: a review that decided to remove access and did not is a finding, not a control.
7. Retirement
An identity is retired when its credential expires without justified renewal, when it has not authenticated for 90 days, when its owner departs without transfer, or when the system it serves is decommissioned. Retirement includes revoking artefacts the identity created, including OAuth grants, webhooks and derived credentials.
Why the second sentence: deleting an identity while the grants it created continue working is the most common way retirement leaves a live remnant.
8. Exceptions
Any identity that cannot meet this policy requires a registered exception recording the clause, the reason, a named approver, a compensating control, and an expiry not exceeding 12 months. Exceptions expire; they do not renew automatically.
The most commonly omitted section, and the most valuable. Without it every deviation is a violation, which makes the policy unusable and drives deviations underground. With it, a documented deviation is a governance decision an auditor can accept.
9. AI agents
AI agents are non-human identities and are subject to all clauses above. In addition: an agent must not hold or use a human's credential; where an agent acts on behalf of a person, that authority is carried as a separate credential and both identities are recorded in logs; agents with the ability to take irreversible or externally visible actions require human approval for those actions; and every agent has a documented interruption procedure with a measured effect time.
Four clauses, each mapping to a specific failure. Credential borrowing destroys attribution permanently. Separate delegation is what makes chains reconstructable. Approval on irreversible actions is the Article 14 obligation in operational form. A measured interruption time is the only evidence the kill path exists.
Using this
- Adapt the numbers to your risk appetite, then hold them. A threshold you will not enforce is worse than a longer one you will.
- Check each clause against your systems before publishing. If a clause cannot be queried, either build the capability or remove the clause. Publishing an unenforceable policy creates findings without improving anything.
- Publish the exception register alongside the policy. Visible exceptions are how a policy stays credible under pressure.
- Map clauses to the frameworks you are held to. Section 6 evidences ISO 27001 A.5.18 and SOC 2 CC6.3; section 9 evidences ISO 42001 clauses 8 and 9.
Frequently asked questions
What should a non-human identity policy contain?
Nine sections: scope with an explicit enumeration of credential types, creation and approval through a recorded issuance path, ownership by named individual, credential requirements including maximum lifetimes, privilege granted according to observed need, review on a cycle determined by reach, retirement triggers including derived artefacts, a registered exception process with expiry, and a section covering AI agents specifically. Every clause should be testable as a query against your systems.
Why should a policy require an individual owner rather than a team?
Because a team cannot be accountable and offboarding never triggers on a mailbox. When ownership is recorded as a team name, nobody acts on review requests, nobody is asked when the identity should be retired, and the leaver process has nothing to match against. Requiring a named individual with mandatory transfer on departure makes the inventory joinable to your HR feed, which is what turns ownership from a field into a control.
What is the most commonly omitted section of an NHI policy?
Exceptions. Without a registered exception process, every deviation is a violation, which makes the policy unusable in practice and drives deviations underground where nobody can see them. With one, recording the clause, reason, named approver, compensating control and an expiry, a documented deviation becomes a governance decision an auditor can accept rather than a finding.
What credential lifetime should an NHI policy set?
As a starting point, 90 days for standard identities and 30 days for identities able to write to production, with attested runtime credentials preferred wherever the platform supports them. The specific numbers matter less than the default: expiry should be automatic and extension should require documented justification. Inverting that default changes behaviour more than any other clause.
How should an NHI policy treat AI agents?
As non-human identities subject to every other clause, plus four additions: an agent must not hold or use a human's credential; where it acts for a person that authority is carried as a separate credential with both identities logged; agents able to take irreversible or externally visible actions require human approval for those actions; and every agent has a documented interruption procedure with a measured effect time. Each maps to a specific failure mode rather than a general principle.
Want this run against your estate rather than read about?
HumanAudit runs NHI discovery and ownership attribution alongside your platform team, producing the inventory, the ownership map and a staged remediation plan rather than a findings list.