Access control policy: deciding who gets in and who stops being in

An access control policy states who may reach which systems and data, on what basis access is granted, who approves it, and — the part that matters most — how it is removed. Granting is easy and happens under pressure, because somebody needs something today. Removing is nobody's urgent problem, which is why most small companies have accounts belonging to people who left last year.

The policy exists to make removal as routine as granting. Everything else in it is supporting detail.

What an access control policy covers

• The principle: least privilege — people get what the job needs and nothing beyond it.
• How access is requested and who approves it, by system rather than in general.
• How access is granted for a role rather than person by person, so a new starter is one decision instead of fifteen.
• Which systems require additional protection — multi-factor authentication, restricted networks, separate approval.
• The joiner, mover and leaver process. Movers are the forgotten one: people who change roles and keep both sets of access.
• How shared and administrative accounts are handled, if they exist at all.
• Third-party and contractor access, with an expiry date on it.
• How often access is reviewed, by whom, and what evidence of that review is kept.

The mover case causes more accumulated risk than the leaver case in a growing company. Someone moves from support to finance and keeps their support permissions because removing them was not part of anyone's job. Repeat over three years and a handful of people can reach almost everything, which is exactly the situation an attacker needs after one successful phish.

Models, briefly

Formal terminology distinguishes discretionary access control, where the owner of a resource decides who can use it, from mandatory access control, where a central policy decides and individuals cannot override it. Most business software sits in between: role-based access, where permissions attach to roles and people are assigned to roles.

Role-based is the practical target for a small company, and the reason is administrative rather than theoretical. When permissions are granted individually, nobody can answer what a support agent can see, because the answer differs per agent. With roles, that question has one answer, a new starter takes minutes, and a leaver is one removal instead of a search through fifteen systems.

Making it real

1. List every system holding company or customer data, including the small subscriptions.
2. For each, write down who has access today. This step is uncomfortable and is where the value is.
3. Define three or four roles that cover most people, and map permissions to them.
4. Write the approval rule: who signs off access to what, and where that is recorded.
5. Write the leaver checklist, tie it to the day someone leaves, and give it an owner.
6. Add the mover step: on a role change, remove the old access explicitly rather than adding the new.
7. Set an access review — twice a year is realistic — and keep a note of what was checked.
8. Put an expiry date on every contractor and third-party account when it is created.

The uncomfortable audit

The first review usually finds three things: accounts of people who left, permissions granted for a one-off task years ago, and at least one shared login whose password several people know and nobody has changed. None of these are unusual, and all of them are the mechanism by which a small incident becomes a large one.

Shared accounts deserve a specific note. They defeat every audit trail — nobody can say who did what — and they cannot be revoked for one person without disrupting everyone. Where a tool genuinely does not support individual accounts, record who has the credential and change it whenever anyone on that list leaves.

Where it lives

Ettex Teams is the practical side of this within our own tools: members, roles and what each role may do, so access in the workspace is a role decision rather than fifteen individual ones, and removing someone is a single action. The policy document itself is a document, and belongs with your other policies.

What it does not do is govern anything outside Ettex. There is no single sign-on integration, no directory sync, no automated joiner-mover-leaver provisioning across your other systems, and no access-review report to hand an auditor. The checklist covering your email, banking, hosting and everything else is one you maintain yourself.

Grant by role, approve deliberately, treat a role change as a removal followed by a grant, and put an expiry date on every account you create for someone outside the company.