Team Systems template
Team Access Register Template
Published 3 August 2026 · Last reviewed 22 August 2026 · By Kayley Hart
What this template is for
Use this register to record who has access to each system, why they need it, who owns the system and when access must be reviewed or removed. Keep it current whenever someone joins, changes role or leaves.
Use this template your way
Copy it into your own workspace, print it, save it as a PDF from your browser, or download a DOCX file to edit offline.
How to use this template
- Start with systems that hold customer data, money, credentials or operational knowledge, then add the smaller tools.
- Give each row one named system owner who can confirm whether access remains necessary.
- Review the register on a fixed cycle and as part of every joiner, mover and leaver process.
Reusable document
Working template
Replace the bracketed prompts with facts about your own team. Keep the completed version in the shared place where the relevant people can use it.
1. System and business purpose
Name the actual system, not a vague category, and explain the work it supports so an approver can judge whether access is necessary.
System: [name] Business purpose: [what work it enables] Data or money sensitivity: [low / medium / high]
2. User, role and access level
Record the named user and the smallest role that lets them do their work. Avoid shared logins and vague labels such as ‘full access’.
Named user: [name] Role: [job role] Access level: [read / create / approve / admin]
3. Approver and system owner
Separate who approved the access from the person who maintains the system where possible, so a review does not rely on one memory.
Access approved by: [name and date] System owner: [name] Business owner: [name]
4. Review date and evidence
Set the next review date at the time access is granted and record where a reviewer can see evidence of the current role or need.
Next review: [date] Review evidence: [role change, project end or access log] Review outcome: [retain / reduce / remove]
5. Leaver or change action
Specify the removal trigger, owner and proof. A register is not useful if it records access but not how to close it.
Removal trigger: [leave date / role change] Removal owner: [name] Evidence recorded in: [ticket / register / log]
Illustrative only
Filled example
This example shows the level of specificity to aim for. Replace it with your own names, limits, dates and evidence rather than copying the facts.
1. System and business purpose
System: Xero accounting. Business purpose: Reconcile transactions and prepare monthly management accounts. Data or money sensitivity: High — banking and supplier information.
2. User, role and access level
Named user: Morgan Lee. Role: External bookkeeper. Access level: Create and reconcile transactions; no payment approval or user administration.
3. Approver and system owner
Access approved by: Priya Shah, 1 September 2026. System owner: Finance lead. Business owner: Managing director.
4. Review date and evidence
Next review: 1 December 2026. Review evidence: Quarterly finance close and current contractor agreement. Review outcome: Retain create access only while the agreement remains active.
5. Leaver or change action
Removal trigger: Contract end or end of finance-close support. Removal owner: Finance lead. Evidence recorded in: Access-removal ticket linked from this register.
Before you share it
Check one live row against the system itself. If the register says read-only but the user can approve a payment, correct the access rather than merely correcting the document.