Least Privilege

A salesperson needs customer records to follow up leads, but not payroll files or the ability to change company-wide user permissions, and granting broad administrative access for convenience creates a larger path for error or compromise. NIST defines least privilege as restricting access of users and processes to the minimum necessary for assigned tasks, and CISA's identity and access guidance discusses account governance, role changes and monitoring.

These are operational controls, not a promise that malware stays on one device. Identify tasks by asking what a role actually needs to read, create, approve, change or delete, since a broad job title alone is not an access specification.

Map resources, because finance systems, shared drives, customer data and cloud infrastructure have different sensitivities and permissions should follow actual need. Separate read and write, as someone may need to inspect a report but not alter its source data or approve a payment, and check data exports, because read-only access can still permit bulk download or sharing.

Control administrative rights, because admin accounts can change permissions and systems and should be used only for appropriate tasks with stronger oversight, and use separate accounts where needed so a system administrator has ordinary daily access and a distinct privileged account for controlled work. Avoid shared credentials, since a shared admin password makes it hard to know who acted and complicates revocation.

Consider service accounts as well, because automated processes also need scoped permissions and a script that only reads data should not have account-owner privileges. Grant temporary access with an expiry and owner for project or emergency permissions, review role changes so an employee moving teams loses access the old role required rather than accumulating more rights, and close leaver accounts promptly, since former-worker access can persist in applications even after payroll departure and HR and IT must coordinate.

Check third parties, because contractors and vendors may need narrow, time-bound access and contract completion should trigger review. Handle exceptions with a reason, approver and expiry, and plan break-glass access for emergencies that is protected, logged and tested rather than leaving permanent broad rights.

Test permissions, because a policy document saying 'limited' does not prove the system enforces it, and keep a permissions inventory recording owner, purpose and approving manager, since unknown grants are hard to justify or revoke. Apply role-based groups carefully, as a group can simplify management but an overly broad role replicates the same problem at scale.

Monitor privileged activity and use multifactor authentication, since logs help detect unusual changes and support investigation, narrow rights reduce the blast radius, strong sign-in protects the account itself, and least privilege alone cannot show what happened. Protect approval separation, since a payment preparer and approver may need different rights, and least privilege supports but does not replace segregation of duties.

Avoid operational paralysis, because too little access can delay legitimate work, so provide a documented request route and timely approval, and prioritise high-risk systems such as identity management, payment, production and sensitive customer data, measuring exposure as well as account counts. Do not rely on one ratio, since an admin account share of 3% says little if those accounts are widely used or one can reach everything, so audit periodically after major organisational or system changes; for owners, least privilege limits what a mistake or compromised account can touch and works when permissions reflect real work and are kept current.