Know who has access, who approves changes and what you receive at handover.
Before working in a live system, we agree the people, permitted access, tests, approval and handover. This sample shows the records we use. They are tailored and approved for each real project.
One part of the business · your team approves important decisions · written instructions included
Documented operating standard—not certification or independent audit.
Fictional sample records—not evidence that a client engagement used them.
The client must still approve access and any decision to go live.
We confirm that the project is suitable and agree the exact work before accepting it.
In plain English
Agree the people, access, tests and handover before work begins.
This reduces confusion, limits access and makes it clear who can approve a live change. The detailed sample records appear below.
01
Name the people
Record who owns the business decision, the process, the software and the delivery.
02
Limit access
State exactly who may access each system, why they need it and when access ends.
03
Agree the tests
Write down what should happen in normal cases, when information is missing and when a service fails.
04
Hand over clearly
Give the client current instructions, test results, known limits and a record that access was removed or transferred.
What this sample shows
Useful documents are not proof that the controls have been used.
This blank pack shows how we intend to document the work. It does not prove that a client has used it, that the controls work in every system, that security has been independently tested or that any service level has been promised.
Designed to record
Who is responsible and who can make each decision.
Why access is needed, what is allowed, who approves it and when it ends.
Test results kept separate from the client’s decision to go live.
Known limits, manual alternatives, handover and removal of access.
Not demonstrated by this pack
No client has adopted this blank sample.
No certification, independent audit or penetration test.
No uptime, response or resolution guarantee.
No universal suitability for every system or data type.
Who is responsible
Every important decision has a named person.
The proposal replaces these example roles with real names before anyone starts work or receives access.
01
Client
Senior client decision-maker
Approves the business goal, the agreed work and the decision to go live.02
Client
Person responsible for the process
Agrees how the process should work, what happens when there is a problem and whether it passes the agreed checks.03
Alternate Machines
Alternate Machines delivery lead
Is responsible for the agreed delivery plan, records, coordination and raising problems.04
Alternate Machines
Technical lead
Designs and tests only the agreed work. They cannot decide to change a live system without approval.05
Client
Person responsible for the software
Approves accounts, access permissions and any change to the live software.06
Staff or approved delivery partner
Specialist
Performs only the agreed task after confidentiality, access and supplier approval are recorded.
Example access list
Record who has access, why and when it ends.
The real list uses account names and an access process approved by the client. Passwords and other login details never belong here.
A-01
CRM test account
What is allowed and why
Read approved test records and create the agreed test item.
Who has access
Named technical lead
Who approved it
Client software owner
When it ends
Build end + two days
A-02
Microsoft 365 test area
What is allowed and why
Make changes only in the agreed test area, list or automation.
Who has access
Named technical lead
Who approved it
Client software owner
When it ends
Build end + two days
A-03
Permission to make the change live
What is allowed and why
No standing access; time-bound access only when explicitly approved.
Who has access
Named person making it live
Who approved it
Senior client decision-maker
When it ends
Same-day expiry
A-04
Partner access
What is allowed and why
None until the named specialist and task pass the client’s vendor-approval process.
Who has access
Named specialist
Who approved it
Client person responsible for supplier approval
When it ends
Task completion
Test before going live
Agree what a pass looks like, then prove it works.
Finishing the build does not make it live automatically. The client keeps the final decision.
T-01
Expected input
Expected behaviour
The process creates the agreed record once.
How we prove it passed
System log and test record.
T-02
Missing required input
Expected behaviour
The process stops and shows the reason, responsible person and next action.
How we prove it passed
Missing-information record.
T-03
Same request received twice
Expected behaviour
The process does not create a duplicate result, and the problem is visible.
How we prove it passed
Test record and log.
T-04
Connected service unavailable
Expected behaviour
The process stops safely, does not claim success and shows how to continue manually.
How we prove it passed
Failed-test record.
T-05
Person approves
Expected behaviour
No important action happens without the agreed person approving it.
How we prove it passed
Who decided and when.
Before going live
We need written test results, the name of the person approving the change, a list of known limits, a manual alternative and a current access list. Fixing a fault follows the agreed tests. A new request needs a separate written decision.
Handover and finish
Leave the client with clear ownership and current instructions.
The signed contract decides how long information is kept, what is returned or deleted, and who is responsible for software licences and hosting. This sample does not decide those points.
01
Operating guide
What starts the process, each step, who is responsible, what happens when something goes wrong and who to contact.02
Record of what changed
The software used, where the change was made, what was approved and anything it depends on.03
Remove or transfer access
Every account is removed, transferred or kept with a recorded responsible person and reason.04
Test record
The checks run, evidence, result, known limits and the client’s decision to go live.05
Return or delete information
Information is kept, returned or deleted as agreed in the signed contract.06
Continuity plan
Who provides cover, where the current instructions are, any open problems and who to contact.
Before work begins
Confirm the project before asking for access.
The free call confirms the problem, intended result and people responsible.
No access to live software is requested until responsibilities and safeguards are agreed.
Anything outside the agreed work requires a separate written decision.
This page is the accessible reading version. The downloadable print PDF is not tagged for screen-reader navigation.
