What this is
What is an access request record?
What is an access request record?
It is the authorisation trail for one person gaining entry to one area or one system. It captures who asked, why the current role needs it, who owns the thing being opened, what level was granted, and the date the access stops. It is raised before the access is provisioned, not written up afterwards to satisfy an auditor.
What does least privilege mean in practice here?
Least privilege means granting the narrowest access that lets the person do the job, rather than the level their job title suggests. In practice it is the difference between read access to one folder and membership of a group that carries thirty permissions. The template forces the question at grant time because it is almost never asked later.
Why does an access request need an end date at all?
Because removal is nobody's job unless a date makes it one. Business need has a natural end — a project, a secondment, a cover arrangement — but access has no natural end. An end date converts revocation from a judgement call somebody must volunteer for into an event the system can raise on its own.
Scope
When is an access request record required?
This is the authorisation event for one person and one thing. It sits upstream of the register that tracks the device and downstream of nothing — it is the first artefact in the chain. Using it for the wrong step produces access trails that cannot be reconciled at review time.
Use this template when
- Somebody needs entry to a restricted area or a system account they do not currently hold
- An existing access level needs widening — the same request, raised again, at the new level
- A contractor, secondee or temporary worker needs access for a bounded piece of work
- A project starts and the team needs area or system access that ends when the project does
- An access review has found a grant with no authorisation behind it and you are reconstructing the decision deliberately
Do not use it for
- Key and Access Device Register, which tracks the physical fob or key itself — serial, holder, return — rather than the decision to authorise it.
- Access Control Review, which is the periodic sweep across all existing grants, not the authorisation of a new one.
- Visitor Log, which records escorted presence on site for a few hours and never grants standing access at all.
- Worker Equipment and System Provisioning, which is the day-one bundle for a new starter rather than a single targeted request.
- Worker Offboarding Checklist, which removes everything at the end; this record removes one thing at its own end date.
Compliance mapping
Which ISO 27001 cl.9.2 requirements does this satisfy?
ISO/IEC 27001 handles access through Annex A controls, with clause 9.2 providing the internal audit obligation that makes the trail necessary. The mapping below points each requirement at the section of the template that carries the evidence.
| Clause | Requirement | Where it lands |
|---|---|---|
| ISO/IEC 27001:2022 Annex A 5.15 | Rules for physical and logical access control are established and implemented based on business and security requirements | Before granting |
| ISO/IEC 27001:2022 Annex A 5.18 | Access rights are provisioned, reviewed, modified and removed in accordance with the access control policy | Controls |
| ISO/IEC 27001:2022 Annex A 5.3 | Conflicting duties and areas of responsibility are segregated | Before granting |
| ISO/IEC 27001:2022 Annex A 8.2 | The allocation and use of privileged access rights is restricted and managed | Before granting |
| ISO/IEC 27001:2022 Annex A 7.2 | Secure areas are protected by appropriate entry controls, including escort of visitors | Controls |
| ISO/IEC 27001:2022 Annex A 6.5 | Responsibilities and duties valid after termination or change of employment are defined and enforced | Outcome |
| ISO/IEC 27001:2022 Annex A 6.3 | Personnel receive appropriate awareness education and training relevant to their role | Before granting |
| ISO/IEC 27001:2022 clause 9.2 | Internal audits are conducted at planned intervals to determine whether the management system conforms and is effectively implemented | Outcome |
What it does not cover
- A ticket in the service desk, which records that access was actioned but rarely records who owned the thing being opened or why the role required it.
- The access control system's own log, which shows the state of a permission today but carries no justification, no approver and no intended end.
- A group membership inherited from a job title, which grants by category rather than by need and is the ordinary route to over-provisioning.
- An email approval thread, which cannot be reconciled against a register, cannot be reported on at review time, and disappears when the approver leaves.
- The annual access review itself, which is a detective control and can only find what was already wrong; it is not evidence that the grant was authorised.
Global
Access Request Record requirements by country
Access authorisation is regulated less as a standalone duty and more as a component of security of processing and of critical-entity resilience. Three regimes drive most of the real obligations.
UK GDPR Article 32 and the Data Protection Act 2018
Requires technical and organisational measures appropriate to the risk, including measures ensuring ongoing confidentiality of processing systems.
Where the area or system holds personal data, an access grant with no justification and no expiry is a weak point the ICO will read as an inadequate organisational measure after an incident.
Directive (EU) 2022/2555 (NIS2), Article 21
Names access control policies and human resources security among the minimum risk-management measures for essential and important entities.
For in-scope operators, access control is no longer a matter of internal policy — management bodies carry personal accountability for the measures, so the approval trail has to name a real owner.
NIST SP 800-53 Rev. 5, controls AC-2 and AC-6
Requires account management with defined authorisation, and enforcement of least privilege for authorised access necessary to accomplish assigned tasks.
Federal contractors and anyone flowing down FISMA or CMMC obligations are audited against exactly the fields this template captures: who authorised, at what privilege, for how long.
How to complete it
How to complete an access request record, step by step
Filling this in is quick. The four decisions below are what determine whether the record survives an access review two years from now.
Almost everyone wants permanent. Permanent is easier for the requester and invisible to the approver. If you answer Yes here, Review Date Set Where Permanent in the Controls section becomes the only thing standing between this grant and the next review's findings list — so set it and mean it, or refuse the permanence and issue a bounded grant instead.
The honest test is not whether you granted less than everything. It is whether you granted less than the standard bundle for that role. If the answer is that you added the person to the usual group because that is what exists, mark No. A No here is a legitimate finding about your access model, not a failure by the approver.
Escort Required Instead Where Possible exists because a standing grant is a permanent risk and an escorted visit is a bounded one. For infrequent access — quarterly maintenance, an audit walk, a one-off inspection — escort is almost always the right answer and almost never the one chosen, because it costs somebody an hour.
Two signatures on this record are only meaningful if they represent two distinct interests. The Area Owner accepts the risk to their asset; Security confirms the grant is consistent with the access model and that the end date is enforceable. If one person can supply both, the record documents a decision rather than testing it.
What auditors find
Most common access request record findings
These are the findings that recur across access reviews, with the field in this template that would have prevented each one.
| Finding | Clause | What fixes it |
|---|---|---|
| Access still active for a project that closed years ago | ISO/IEC 27001:2022 Annex A 5.18 | End Date Given and End Date Enforced By The System must both be Yes. A date recorded but not enforced is a note, not a control. |
| Grant approved by the requester's own line manager with no owner sign-off | ISO/IEC 27001:2022 Annex A 5.15 | Approved By The Area Or System Owner is a separate field from Requested By The Person's Manager for exactly this reason. Route the record, do not co-sign it. |
| Leaver retained system access weeks after their last day | ISO/IEC 27001:2022 Annex A 6.5 | Removal On Leaving Covered in Controls and Included In Offboarding in Outcome link the grant to the offboarding checklist so it is found at exit. |
| Privileged access granted at role level rather than task level | ISO/IEC 27001:2022 Annex A 8.2 | Least Privilege Applied plus What Access Is Requested in the Header — the free-text description forces the grant to be stated in specifics, not as a group name. |
| Person holds physical access to an area they were never inducted for | ISO/IEC 27001:2022 Annex A 6.3 | Induction Or Training Completed gates the grant. Where the induction is outstanding, the record should be held rather than closed with a No. |
| The same person can raise, approve and reconcile transactions in one system | ISO/IEC 27001:2022 Annex A 5.3 | Segregation Of Duties Considered in Before granting. This is the field most often marked Yes without anyone checking what the person already holds. |
Case in point
Case in point: the commissioning badge that outlived the contract
A specialist contractor was given badge access to a substation compound for a six-week commissioning package. The request was legitimate, the manager confirmed the need, and the badge was issued the same week. No end date was recorded because the contract end was 'obviously' the end date, and everyone involved knew it.
Three years later an access review pulled the door controller export and found the contractor's credential still live, having been used twice in the intervening period for unrelated call-outs by the same firm. Nobody had done anything wrong at any single step. The grant was defensible; the absence of an expiry meant nobody ever had to defend it again.
The template
The template, field by field
The form exactly as it installs. Every field, option, score and conditional rule is editable, and the links to other templates come with it.
4 sections
- Reference
- OPS-028
- Archetype
- Record
- Record ID
- ACC-2026-000
- Scoring
- Access with an end date
- Direction
- High is good
- Singleton
- Yes
- Basis
- ISO 27001 cl.9.2
- Links
- Links Access Review and Key Register
- Tags
- Access, Security
- Sections
- 4
- Fields
- 47
- Follow up fields
- 3
- Repeating sections
- 0
- Links out
- 5
Header
16 fieldsRequest ID*
Auto sequence. Format ACC-2026-000.
The record's own ID. Other templates point at this value.
Status*
Drives who this goes to next.
- Planned2 pts
- In progress2 pts
- Complete3 pts
- Deferred0 pts
- Open0 pts
- Closed3 pts
- Overdue0 pts
Date and Time*
Completed By*
Site*
Site ID*
Format SITE-000.
Links to FDN-001 Site ID
Person*
Person ID
Links to FDN-003 Person ID
Access Type*
Physical area, system, or both.
What Access Is Requested*
Justification Stated*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Needed From*
End Date*
End Date Given*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Permanent Requested*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Access For A Project That Ended
Every access review finds people who can open doors for work they stopped doing years ago. Access granted with an end date is access that removes itself.
Before granting
6 fieldsRequested By The Person's Manager*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Approved By The Area Or System Owner*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Justified By The Current Role*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Least Privilege Applied*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Induction Or Training Completed*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Segregation Of Duties Considered*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Controls
6 fieldsRecorded In The Key Or Access Register*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
End Date Enforced By The System*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Review Date Set Where Permanent*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Removal On Leaving Covered*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Escort Required Instead Where Possible*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Temporary Access Preferred*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Outcome
19 fieldsGranted*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Granted On
Removed On The End Date*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Key Register ID
Links to OPS-026 Register ID
Access Review ID
Links to SAF-147 Review ID
Included In Offboarding*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Items Assessed*
Excludes anything marked N/A.
Items Failed*
Score Percent*
Calculated on submission. High is good. N/A items leave the denominator.
Result Band*
- Pass3 pts
- Caution1 pt
- Fail0 pts
Completeness Percent*
How much of the template was actually answered. A high score on a half completed form is not a high score.
Action Required*
Raise the action record, then enter its reference here.
- No2 pts
- Yes0 pts
Priority
- High0 pts
- Medium1 pt
- Low3 pts
CAPA ID
Format CAPA-2026-00000.
Links to FDN-014 CAPA ID
Action Owner
Area Owner*
Signature*
Security*
Second Signature*
OPS-028 · record IDs look like ACC-2026-000 · Links Access Review and Key Register
Open in KnowellaRun it with agents
From a document you fill in to a programme that runs itself
The record is a five-minute job. Chasing owner approval, holding the end date until it arrives and proving the removal happened is where the control actually lives.
Routes each request to the named area or system owner rather than the nearest manager, holds the end date as a live obligation, and reconciles open grants against the key and access register.
Maps the population of grants back to Annex A 5.15 and 5.18, and surfaces the permanent-without-review-date cases before the internal audit under clause 9.2 finds them.
Confirms the induction or training behind Induction Or Training Completed is genuinely current, so a grant is never gated on a certificate that expired last quarter.
Watches for end dates falling due, drafts the removal and the offboarding link, and holds every write for your approval before it touches a record.
This template lives in KnowOps — frontline execution. Shift handover, production control, daily management, worker lifecycle and improvement.
Meet KnowOps→Glossary
Access Request Record definitions and key terms
- Least privilege
- Granting only the access required to perform a specific task, for the period it is required, rather than the access typical for a role.
- Segregation of duties
- Splitting a sensitive process so no single person can initiate, approve and conceal an action; a constraint on which access rights may be combined.
- Area or system owner
- The accountable person for a physical space or an application, who accepts the residual risk when access to it is granted to somebody new.
- Standing access
- A persistent grant that remains active until removed, as opposed to escorted, time-boxed or just-in-time access that lapses on its own.
- Access review
- A periodic reconciliation of active access rights against current roles and authorisations, intended to detect grants that outlived their justification.
FAQ
Frequently asked questions about access request record
Should every access request really carry an end date?+
Yes, including permanent-intent grants — for those the date becomes a review date rather than a revocation date. The template separates End Date Given from Permanent Requested so the two cases are visible in reporting. A population where ninety per cent of grants are permanent is a finding in itself.
Who should be the approver if the system owner is unclear?+
Resolve the ownership before granting, not after. An unowned system is the real defect, and the access request is where it surfaces. In the interim, the approval should sit with whoever accepts the risk of a breach of that system — usually the process owner, not IT.
Can this record cover both physical and system access at once?+
Yes. Access Type in the Header offers Physical area, System or Both. Use Both when the same justification and the same end date genuinely apply. Split them when the approvers differ or the durations differ, because a combined record will otherwise be closed on the wrong date.
How does this relate to the Key and Access Device Register?+
This record authorises; the register tracks the artefact. Recorded In The Key Or Access Register in Controls, and Key Register ID in Outcome, are the join. Without that join an access review can only see devices, not the decisions behind them.
What happens if the end date passes and nothing is removed?+
Removed On The End Date is answered No and the record fails, which is the correct outcome. The point is that the failure is visible and attributable rather than silent. Raise the action, capture the CAPA ID, and treat repeated Nos as evidence that enforcement is manual where it should be systemic.
Is a No on any Before granting question a hard stop?+
Treat No on owner approval, justification or induction as a stop. Treat No on least privilege or segregation as a finding you can grant against with an accepted risk, because those often reflect the maturity of the access model rather than the individual request.
Keep going
Related templates and programmes
Industries this is written for
Programmes this belongs to
Used together in Site Access and Facilities
Key and Access Device Register
Holds every key, fob and access device, who has it and what it opens
Visitor Log
Records who was on site, when, why and who was responsible for them
PPE and Locker Issue Record
Records what personal equipment was issued to whom, in what size, and when it is due for replacement
Facility Service Request
Raises a request for a building or facility issue that is not a maintenance work order: lighting, heating, welfare, cleaning or fabric
Temporary Works Approval
Approves a temporary structure, support, barrier or arrangement, with who designed it and when it comes down
Access Control Review
Reviews who holds access to which areas and whether that is still justified
More in Site Access and Facilities
Visitor Log
Records who was on site, when, why and who was responsible for them
PPE and Locker Issue Record
Records what personal equipment was issued to whom, in what size, and when it is due for replacement
Facility Service Request
Raises a request for a building or facility issue that is not a maintenance work order: lighting, heating, welfare, cleaning or fabric
Temporary Works Approval
Approves a temporary structure, support, barrier or arrangement, with who designed it and when it comes down
Written and reviewed by
Siddarth Singh
Founder & Chief Executive Officer, Knowella
Certified Safety Professional and industrial and systems engineer with more than a decade inside food supply chain, freight and manufacturing operations. This page was written against the current text of the standards it cites, not against secondary summaries of them.
- Certified Safety Professional (CSP), Board of Certified Safety Professionals
- MBA, University of Chicago Booth School of Business
- MS and BS, The Ohio State University, Industrial and Systems Engineering
- Six Sigma Black Belt
Sources and last review. Reviewed 16 August 2026 against:
- ISO/IEC 27001:2022 — Information security management systems, clause 9.2 and Annex A controls 5.3, 5.15, 5.18, 6.3, 6.5, 7.2, 8.2
- UK GDPR Article 32 — Security of processing, and the Data Protection Act 2018
- Directive (EU) 2022/2555 (NIS2), Article 21 — Cybersecurity risk-management measures
- NIST SP 800-53 Rev. 5 — AC-2 Account Management and AC-6 Least Privilege
This page is general guidance, not legal advice. Confirm requirements with your jurisdiction’s regulator.