Restricting a sensitive client to named people
How partners restrict a sensitive client or a single engagement to named people in Achekam, who keeps access, and what colleagues see in the calendar.
By Achekam · · 4 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
Most client files in a practice should be open to the whole team. People cover for each other over leave, reviewers dip in, and work moves to whoever has capacity. Some files are different.
A partner's own family trust. A listed company whose results are price-sensitive until announced. A forensic engagement where the subject may know someone in the office. A client who is related to a junior member of staff. A well-known individual whose tax affairs would be gossip if they leaked. For these, "everyone can see everything" is the wrong default, and the firm needs a way to limit the file to the people who genuinely need it.
Achekam lets partners and administrators do exactly that, with a reason on record and a trail of who changed what.
Setting a restriction, with a reason
The control is under Settings > Users & roles > "Access to clients". A partner or an administrator can restrict either a whole client or one engagement to named people, and must give a reason.
Restricting a single engagement is often the better choice. A firm may be happy for the whole team to see a client's monthly bookkeeping, while a separate investigation or a transaction engagement for the same client is limited to a few people. Restricting the engagement keeps the routine work flowing.
The reason is not a formality. A year from now, someone will ask why a file was locked down, and "partner request" will not help them decide whether the restriction is still needed. A reason such as "staff member's close relative is a director; restrict to engagement team" answers the question for anyone who reads it later.
Who can always open it
Some people keep access regardless of the list. The client's account manager, and the engagement's partner and manager, can always open a restricted client or engagement.
That rule prevents the obvious accident: a restriction set up in a hurry that locks out the people responsible for the work. It also means that if the reason for restricting is a concern about one of those people, a restriction is the wrong tool. Change who holds the role first.
What others see in the calendar
Restrictions would leak if the diary gave the game away. A meeting titled with the client's name, visible to the whole office, can say as much as the file itself.
In Achekam, staff create meetings under HOME > Calendar, linked to a client or engagement, and invite colleagues. A meeting about a restricted client shows only as "busy" to people who are not on that client's access list. Colleagues can still see that the partner is unavailable at that hour, which keeps scheduling workable, but not who the meeting is with or what it is about.
Meetings in the calendar are cancelled with a reason, never deleted, so the record of what was planned survives even when plans change.
Lifting a restriction rather than deleting it
Restrictions end: the transaction is announced, the staff member leaves, the investigation closes. In Achekam a restriction is lifted, not deleted. The fact that the file was restricted, the reason, and when and by whom it was lifted all remain on record.
That matters when someone later asks who could see the file during a particular period. A deleted restriction leaves no answer. A lifted one does.
The record of who did what
Each restriction records who did what and when. Separately, QUALITY & GOVERNANCE > Record Governance keeps a log of changes to governed records showing who did what, when and with what result. It can be filtered and checked for an unbroken chain. Viewing it needs the AUDIT_LOG_VIEW permission, and it covers records under record governance, not every screen in Achekam.
For quality reviews, that combination gives a partner a straightforward way to show that access to a sensitive file was limited and that changes to the limit were deliberate.
Restrictions and role permissions are different tools
It is easy to confuse two controls.
| Control | What it decides | Where it lives |
|---|---|---|
| Role permissions | What a role or person may do across the firm, such as approve time or manage collaboration | SETTINGS > Permissions & RBAC |
| Client access restriction | Who may open one particular client or engagement | Settings > Users & roles > Access to clients |
| Team membership | Who is a member of the firm at all, with which role | TEAM > People |
Under Permissions & RBAC a firm can allow or deny what each role may do, check why a member may or may not act, and grant named time and collaboration permissions per role or per person. Under TEAM > People an administrator invites, suspends, reactivates or removes members. A restriction sits on top of both: it narrows who may open a particular file, whatever their role allows elsewhere.
Before you restrict, a short checklist
- Decide whether the whole client or only one engagement needs protecting.
- Confirm the account manager, partner and manager are people who should have access, since they always will.
- Name everyone else who needs the file, including the reviewer.
- Write a reason a stranger could understand.
- Tell the people on the list, and remind them that restricted meetings show as "busy" to others.
- Diary a date to review whether the restriction is still needed.
Restrictions work alongside, not instead of, the firm's independence and conflict processes. For those, see independence declarations today and quality registers and consultations. Behind both sits the IESBA's International Code of Ethics for Professional Accountants, with its five fundamental principles and its conceptual framework for addressing threats.
Start with the files your partners already treat as sensitive by habit, and put each one behind a recorded restriction with a reason.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
