Describe the job before choosing a role
Start with an action the business has approved: publish an article, reconcile an order, manage a mailbox or maintain one website. Identify the system, data and environment needed for that action. A job title such as developer or office manager is too broad to establish whether a person needs payment settings, customer exports or organization-wide administration.
The NCSC NZ guidance describes least privilege across people, applications and processes. For a small business, a useful working record is the approved task, required capability, owner and review point. The record explains why access exists. It also helps separate a permanent requirement from a one-off task that finished months ago.
Read permissions, scope and duration together
A permission describes an allowed action; scope identifies where it applies; duration identifies how long it is needed. Reading a project report is different from exporting all company records. Editing one website is different from administering every customer account. A narrowly named role can still be broad when assigned across an entire organization or inherited through a group.
Microsoft Entra role guidance explicitly considers permissions, scope and time. Its available controls belong to that platform and may depend on the subscription. The wider decision remains useful elsewhere: compare the actual capability with the approved job, then choose a supported narrower arrangement where possible. Record an exception when the platform cannot express the boundary you need.
| Dimension | Business question | Evidence to retain |
|---|---|---|
| Identity | Which person or application uses the access? | Named owner and account or service identity. |
| Action | What must that identity be able to do? | Approved task and effective permissions. |
| Scope | Which assets or records are necessary? | Specific site, project, tenant or data boundary. |
| Duration | When should the access end or be reviewed? | Expiry or review owner and date. |
| Exception | What cannot yet be narrowed safely? | Reason, compensating control and next decision. |
Distinguish authentication from authorization
Authentication establishes a basis for trusting a sign-in; authorization decides the permitted actions. MFA or a passkey can strengthen authentication while the signed-in account still has unnecessary administrative powers. Conversely, limiting permissions does not make a weak or compromised login safe. Review both questions rather than treating one product setting as a substitute for the other.
The distinction matters during a supplier review. A contractor may use a well-protected account but still control all hosting subscriptions when only one site is in scope. Ask which capability is needed and how it is verified. Do not use a successful login as evidence that every subsequent action is appropriate, or a denied login as a complete test of application permissions.
Include inherited access, automation and recovery owners
Effective access can come from direct assignments, groups, shared credentials, delegated administration and application permissions. An account removed from a visible staff list may retain a separate route through an integration or supplier console. A single screenshot of one role page is a starting observation, not a full account of every effective privilege.
Inventory automation and recovery alongside staff. A backup job, mail integration or deployment task needs an accountable owner even if nobody signs in manually. Protect the business's recovery route before removing broad access. Least privilege should preserve authorized work and recovery; disabling the only administrator is an outage, not a successful access review.
Check allowed work and an agreed restricted action
A useful access test checks both sides of the intended boundary. Confirm that the approved task still works, then check a harmless, explicitly authorized action that should be unavailable. Use synthetic records or a test environment when an action could reveal customer data or alter operations. Record the identity, scope and conditions so the result can be understood later.
A successful test supports the tested path. It does not prove that every inherited role, cached session or alternative application route is restricted. If a result differs from the expectation, pause the rollout and investigate the effective access. Do not remove additional permissions at random until the workflow happens to work.
Keep the boundary current as the business changes
Review access when duties change, a supplier finishes work, a new application is connected or an incident exposes an unexpected capability. Keep the approved task and exception record beside the review result. A permanent administrator assignment should have a current reason, and a temporary assignment should not depend on everyone remembering to remove it informally.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide, specializing in websites and digital infrastructure. Our practical Israeli technical knowledge connects account permissions with the work the business needs to perform. We agree which systems and access routes to review, the supported changes and the business checks needed for handover.