A support engineer at a security services firm leaves for another employer on a Friday. On Monday, the client's administrator notices that a login from the firm's account was still active over the weekend. Nothing was misused. But the client now asks a fair question: how many other accounts are open?
Engineers who work inside client networks hold a kind of trust that most staff never do. The client gave your firm that trust, and your firm lends it to individuals. The rules below help you manage that loan in a way you can explain to the client.
Know what you are protecting
Start with a simple list per client. What systems does your team touch? What data can they see on them? Who at the client approves access? What did the contract say about confidentiality, subcontractors and audits? You are not rewriting the contract. You are making sure your internal rules are at least as strict as the promises you made.
Rules to write down
- 1
Name an access owner for each client
One person in your firm decides who gets access for that client, and keeps the list. The client's own approver is recorded next to it.
- 2
Grant the least access needed
Read-only where the work allows, time-limited where the work is a project. Separate accounts for each engineer, with no shared logins.
- 3
Store credentials in one controlled place
A password vault with logging and a named owner. Credentials do not travel in chats, emails, notes or screenshots.
- 4
Control the devices
Decide which laptops may connect, what must be installed on them, and what happens to client data held on them. Personal devices need a clear yes or no.
- 5
Log and review
Keep access logs where the client allows, and review the list of active accounts on a fixed schedule with the client's approver.
- 6
Remove on exit or change
When an engineer leaves the account, moves teams or resigns, access is removed the same day and the client is informed in writing.
The password and access control policy page shows how GullyHR drafts the policy side of these steps, so the rules sit in a document that engineers and managers can both read.
Confidentiality that engineers will actually follow
A long legal paragraph in the appointment letter is not enough. Engineers need to see, in plain words, what counts as client information: configurations, diagrams, user lists, ticket content, even the fact that a client is a customer. They need examples of what is not allowed, such as pasting a log into a public forum to ask for help, or keeping a copy of a client's network diagram to show a future employer.
- Do not copy client data to personal devices, personal cloud storage or messaging apps.
- Do not discuss one client's setup with another client or with colleagues who have no need to know.
- Do not use client access for learning, testing or side work.
- Report a mistake or a suspected leak straight away to the access owner. Early reporting is treated differently from hiding it.
- Treat screenshots and photos of screens as client data.
Onboarding and acknowledgement
On day one, new engineers should read the policy, ask questions and sign an acknowledgement. Do not give any client access until this is done. For each client account, add a short briefing: what the client expects, who to call, and what to do in a mistake. Record the date. Many security-minded clients ask to see these records during reviews, and having them ready saves an uncomfortable search.
The hiring step matters too. If you are growing the team, check the references and the person's own handling of past employers' information during interviews, as the post on hiring cloud and DevOps engineers suggests. Background verification itself is a service GullyHR does not offer, so use a specialist provider if the client contract calls for it.
Engineer name, last working day and manager.
List of client accounts the engineer could access, from the access owner's register.
Each account disabled or the credential rotated, with date, time and person who did it.
Vault entries the engineer could see: rotated or confirmed unchanged.
Devices returned and client data removed, with confirmation.
Remote tools, VPN and ticket system access removed.
Client approvers informed in writing for each affected account.
Reminder of the confidentiality duty given to the engineer, with acknowledgement.
Access owner's sign-off.Consequences and fairness
Write down what happens if the rules are broken, and keep it proportionate. A careless mistake that was reported at once is handled differently from deliberate copying of data. The disciplinary steps should follow your normal conduct process. Decisions of this kind should go through your legal adviser before action is taken.
Where this fits in the larger picture
Access rules sit alongside rosters, pay and handovers. Night engineers often hold broad access and work with little supervision, so the points in the post on shift rosters for security and network operations centres matter here too. For the wider HR picture in firms like yours, see the cybersecurity firms hub.
