Password and access control policy: accounts, MFA, reviews and revocation

A sales executive leaves on a Friday. On the following Wednesday, a client receives a quote request reply from her email address, because her login to the shared sales mailbox was never closed. Nothing malicious happened. But nobody could say who had been able to see that mailbox for the last six months. A password and access control policy exists to make that question answerable.

The purpose is simple: keep systems, data and customer information reachable only by the people who need them, for as long as they need them. It covers employees, interns, consultants, vendors and any machine that logs in on its own. Pair it with the IT and internet usage policy, which governs what people do once they are inside.

• User account: one named identity for one real person, created through an approved request.
• Privileged account: any login that can change settings, create users or read everyone's data.
• Service account: a login used by software, such as an API key or a scheduled job, with no human behind it.
• Guest account: time-limited access for a visitor, candidate or vendor engineer.
• Access review: a scheduled check that every account and permission is still justified.

Each person gets a unique account. Shared logins such as a common admin user or a team mailbox password are the usual cause of untraceable actions, so the policy should forbid them and offer delegated access instead. Access is granted by role. A role matrix, one sheet listing each job family against each system, lets a manager request a bundle rather than argue for single permissions.

Least privilege means the starting point is the minimum, and extra rights are requested with a reason and an end date. Decide whether the manager, the system owner or both approve a grant. Two approvers slow things down but stop a manager from granting access to a friend.

Longer passphrases beat short complex strings that people write on sticky notes. State a minimum length, forbid reuse across work and personal accounts, and say that sharing a password with anyone, including a colleague or IT staff, is a breach. Consider providing a company password manager so people have a safe place for what they cannot memorise.

Multi-factor authentication adds a second proof, such as an app prompt or a hardware key. The decision for management is scope. Mandatory MFA on email, code repositories, cloud consoles, finance tools and all remote access is a sensible floor; whether it applies to every internal tool is a cost and friction trade-off. Also decide what happens when a phone is lost, because the recovery route is where attackers push.

• Administrator rights sit on a separate account, never on the daily login, and are held by a short named list.
• Vendor accounts are created per person, expire on a set date and are tied to the contract owner who sponsors them.
• Service accounts and API keys have a named owner, are stored in a secrets vault rather than in code or chat, and are rotated on a schedule.

Session rules matter too. Set an automatic lock after a period of inactivity, a limit on failed login attempts before temporary lockout, and a rule for how long a remote session may stay open. Each of these is a number the company chooses and tests, not a number to copy.

1. 1

   Request

   The employee or manager raises an access request form naming the system, the role needed, the reason and any end date.

2. 2

   Approve

   The line manager and the system owner approve or reject, and record the reason.

3. 3

   Provision

   The administrator creates or changes the account and notes the ticket reference in the access register.

4. 4

   Confirm

   The employee acknowledges the rules on first login, with the date and policy version.

5. 5

   Review

   Each quarter, system owners sign off their user list or mark accounts for removal.

6. 6

   Revoke

   On exit, transfer or suspected compromise, the administrator closes access within the time the policy sets.

A transfer is the case most often missed. Someone moves from support to finance and keeps both sets of rights. The policy should say the old role's access ends on the move date. For exits, HR gives IT the last working day in advance, and IT closes accounts, retrieves tokens and phones, and forwards the mailbox to a manager. For a suspected compromise, anyone may report to the security contact, and the account is frozen first and investigated afterwards.

Emergency access, sometimes called break-glass, is a sealed credential for a real outage. Decide who may use it, how its use is logged and who reviews each use the next day.

Decide how breaches are treated. Sharing a password once might call for a warning and retraining. Deliberately bypassing MFA or using another person's account might call for formal disciplinary action under the disciplinary action policy. The company sets the ladder, with HR involved so similar cases get similar outcomes. Suspected misuse that involves a colleague's conduct is a confidential case: restrict who can see it.

Keep an access register, the access request forms, review sign-offs, the exit checklist and the signed acknowledgement. Link the policy to the data privacy and security policy for what happens after a breach, and to the asset and laptop usage policy for device return. Review the policy yearly and after any incident, and keep a version number. The order in which to write these is set out in the 30 policies a growing company needs.

1. Purpose: limit access to systems and data to those who need it.
2. Scope: employees, interns, consultants, vendors, service accounts.
3. Definitions: user, privileged, service and guest accounts.
4. Accounts: one named account per person; no sharing.
5. Roles: access by role matrix; extra rights need a reason and end date [date].
6. Passwords: minimum length [number]; company password manager for [systems].
7. MFA: required for [list of systems]; recovery route [description].
8. Privileged access: separate admin account; named holders [list].
9. Vendors and service accounts: sponsor, expiry [date], rotation every [number] days.
10. Reviews: every [number] months by system owners.
11. Revocation: within [number] hours of exit or compromise.
12. Logging and violations: [consequence ladder]; confidential cases restricted.
13. Acknowledgement: read, understood, accepted; name, date, version.
14. Review: owner [role]; version [number].