Most production access is not an emergency, yet it is often recorded with less care than break-glass use: a chat message, a role left assigned, no record of what was touched. This template gives you a standard record for every planned or operational grant of human access to production systems and data: who asked, why, exactly what scope, for how long, who approved it and what happened during the session. It is a companion to our guide to Production Access for SREs and On-Call Engineers, which explains the design, and to the Break Glass Access Procedure Template, which covers emergencies. Use it as-is with your own placeholders, or as the field list for a form in your ticketing or privileged access tool.
How to use this template
- Replace the placeholders: [Organisation], [Production access owner], [PAM or elevation tool], [Ticketing system], [Log platform] and the durations in square brackets.
- Decide what counts as production: complete section 2 first. Disputes about scope are the most common reason records are skipped.
- Build the record into your tooling: section 5 is the field list. Where your elevation tool already captures a field (requester, duration, approver), link the tool's record rather than retyping it, but keep the fields it does not capture in the ticket.
- Keep emergencies separate: break-glass use follows its own procedure and is reviewed with this record format afterwards, so all production access ends in one evidence set.
- Treat durations and thresholds as ours: the figures below are NHI Mgmt Group recommendations. Set your own where regulation, contracts or your auditors require.
1. Purpose and scope
1.1 This procedure sets how [Organisation] grants, records, supervises and closes human access to production systems and production data, so that every access is attributable, justified, limited in scope and time, and reviewed.
1.2 It applies to employees, contractors and third-party support staff, and to every access path: cloud consoles and APIs, shell and remote desktop sessions, Kubernetes clusters, databases, SaaS administration consoles and support tooling that can read customer data.
1.3 Automated access by pipelines, service accounts and agents is out of scope of this record. It is governed by [NHI or workload identity standard]. A human who borrows a service account credential is in scope and must be recorded as such.
2. Definitions
| Term | Meaning in this procedure |
|---|---|
| Production | [List: environments, accounts, subscriptions, projects, clusters and databases that serve customers or hold live data, including disaster recovery copies and restored copies of live data] |
| Standing access | A production permission that remains assigned when not in use |
| Elevated access | A time-limited grant through [PAM or elevation tool] that ends automatically |
| Access class A | Read-only access to metadata, logs and metrics, with no customer data |
| Access class B | Read access to customer or regulated data, or operational actions (restart, scale, failover) |
| Access class C | Change to configuration, code, data, permissions or security controls |
| Emergency access | Access under the break-glass procedure |
3. Roles and responsibilities
- Requester: completes the record, uses only the approved scope, records actions, closes the record.
- Approver: [Service owner or delegate] for the system concerned. Must not be the requester. Confirms need, scope and duration.
- Second approver: required for class C on [critical systems list] and for any access to [regulated data sets].
- [Production access owner]: owns this procedure, the eligibility lists and the monthly review.
- Security operations: monitors elevation events and session alerts against open records.
4. Access standards
4.1 No standing class B or class C access is held by humans, except for named exceptions recorded in section 8 and reviewed [quarterly].
4.2 Every elevation is through [PAM or elevation tool] or an approved equivalent that records requester, start, end and scope. Shared administrator credentials are not used for planned access.
4.3 Maximum durations (our recommended defaults):
| Access class | Default duration | Maximum without re-approval | Approval | Session recording or command logging |
|---|---|---|---|---|
| A: read metadata and logs | [8 hours] | [1 working day] | Pre-approved by eligibility | Audit log only |
| B: read data or operate | [2 hours] | [4 hours] | One approver | Required |
| C: change | [1 hour] | [4 hours] | One approver, two for critical systems | Required |
4.4 Access is from [managed admin devices] only, with phishing-resistant MFA at elevation time.
4.5 Class C access must reference an approved change or an open incident. Access is not a substitute for the change process; see the Change Management Policy Template.
5. The production access record
5.1 One record is created per access grant. Fields marked * are mandatory before approval; fields marked ** are mandatory before closure.
| # | Field | What to enter |
|---|---|---|
| 5.1.1 | Record ID* | [Ticketing system] ID, linked to the elevation tool's request ID |
| 5.1.2 | Requester* | Named individual account (never a shared or service account), team, employer if third party |
| 5.1.3 | Reason* | Plain description of the task and the outcome needed; "investigation" alone is not enough |
| 5.1.4 | Linked change or incident* | Change ID or incident ID; mandatory for class C |
| 5.1.5 | Systems in scope* | Named accounts, projects, clusters, namespaces, databases or tenants; no wildcards |
| 5.1.6 | Role or permission set* | The exact role requested and why a narrower role is not enough |
| 5.1.7 | Access class* | A, B or C |
| 5.1.8 | Data touched* | Data categories that may be viewed or changed (customer, payment, health, employee, none) |
| 5.1.9 | Start and end time* | Requested window, within section 4 limits |
| 5.1.10 | Access path* | Console, CLI, bastion, database client, vendor support tool |
| 5.1.11 | Approver(s)* | Name, time of approval, confirmation they are not the requester |
| 5.1.12 | Customer or regulator commitments | Contractual notice, customer consent or data residency conditions that apply |
| 5.1.13 | Actual start and end** | From the elevation tool, not self-reported |
| 5.1.14 | Actions taken** | Summary of what was done, with session recording or log reference |
| 5.1.15 | Artefacts created** | Keys, role bindings, debug pods, firewall rules, data extracts created during the session, and confirmation each was removed or handed to an owner with a ticket |
| 5.1.16 | Deviations** | Anything outside approved scope or time, and why |
| 5.1.17 | Closure confirmation** | Requester statement that access has ended and artefacts are handled; reviewer sign-off for classes B and C |
6. Approval rules
6.1 The approver checks: the reason matches a real task; scope names specific systems; the role is the narrowest that works; the duration is within limits; the linked change or incident exists and is open.
6.2 The approver must not be the requester, and must not approve their own team's class C request for [critical systems list] without the second approver. See Dual control and four-eyes approval for privileged and agent actions.
6.3 Approvals are valid for [2 hours] after they are given. Unused approvals expire and need a new request.
6.4 Extensions need a new approval recorded against the same record, with the reason for the extension.
6.5 Where a ticket number field in the elevation tool is free text, the approver checks the referenced ticket exists; the tool may not validate it.
7. During access
7.1 The requester works only within the recorded scope. If the task needs more, they stop and raise an extension or a new record.
7.2 Customer data is viewed only as needed and is not copied to local devices, chat, email or tickets.
7.3 Security operations correlate elevation and session events with open records in [Log platform]. Elevation with no open record, or activity outside the recorded systems, is raised as a security event.
7.4 Access ends automatically at the recorded end time. Early completion ends access immediately.
8. Closure, review and exceptions
8.1 The requester completes fields 5.1.13 to 5.1.17 within [1 working day] of access ending.
8.2 For classes B and C, a reviewer other than the requester checks the record against session evidence within [5 working days] and confirms no deviation, or opens a finding.
8.3 Standing access exceptions are recorded with the person, the role, the reason, compensating controls and an expiry no later than [90 days], and are re-approved by [Production access owner].
8.4 Findings (access with no record, scope exceeded, artefacts left behind) are tracked to closure and reported in the monthly review.
9. Records, retention and metrics
9.1 Records, approvals and session evidence are retained for [retention period agreed with legal and audit] and protected from change by the requester.
9.2 [Production access owner] reports monthly:
- Number of production elevations by class, and the percentage with a complete record.
- Number of elevations or production sessions with no matching record.
- Median duration granted versus median duration used.
- Number of open standing access exceptions and their age.
- Number of records with artefacts not removed by closure.
10. Approval and review of this procedure
10.1 This procedure is approved by [Approving authority] and reviewed at least [annually], after any significant incident involving production access, and when the elevation tooling changes.
| Version | Date | Author | Approved by | Summary of change |
|---|---|---|---|---|
| [1.0] | [date] | [name] | [name] | [Initial issue] |
Implementation guidance
- Start with the record, then remove standing access: run the record for one month alongside existing access so teams learn it, then remove standing class B and C roles system by system. Keep a rollback list of the removed assignments for the first two weeks.
- Automate correlation early: the control that catches problems is the match between elevation events and records (7.3). Without it, the record becomes paperwork.
- Make the narrow role easy: if the only eligible role is administrator, every record will ask for administrator. Build task-sized roles for the common requests first. See the JIT Access Guide.
- Cover vendor support: third-party engineers often have the broadest and least visible access. Put them on the same record and the same tool.
- Feed reviews: use the records in your periodic privileged access reviews, for example the Database Privileged Access Review Template.
- Framework fit: the procedure supports NIST SP 800-53 AC-2 (Account Management), AC-5 (Separation of Duties), AC-6 (Least Privilege), AU-6 (Audit Record Review) and CM-5 (Access Restrictions for Change), NIST CSF 2.0 PR.AA-05, and the NCSC's secure system administration principles to use privileged access management and to log and audit administration activities.
Related NHI Mgmt Group resources: Production Access for SREs and On-Call Engineers, Break Glass Access Procedure Template, JIT Access Guide, ChatOps Security.