Start with a bounded system and an authorized business owner
Choose one website, email tenant or other defined system for the first review. Agree who can approve access decisions and which business functions must remain available. List staff, suppliers and application identities in scope. Separate routine review from a live compromise: an unexpected administrator or suspicious activity may require an incident process before ordinary role cleanup.
Write the work in concrete verbs: publish content, answer enquiries, reconcile orders or maintain the server. Ask the accountable owner which systems and records the task requires. This is more useful than accepting a broad role because someone is called a developer or manager. Keep unresolved ownership visible, especially where a former supplier controls the only route into an essential service.
Build the effective-access register before making changes
Inspect direct roles, group membership, inheritance, delegated access and relevant shared credentials. Include integrations that can read or write business data without an interactive employee login. A removed staff entry may not remove a separate service account or supplier route. Record where the evidence came from and which systems could not be inspected.
NCSC NZ guidance includes ongoing permission review because responsibilities change and obsolete rights accumulate. Apply that principle to the actual accounts rather than treating its government framework as a worldwide legal requirement. The working register should explain who uses each identity, what it can do, the approved reason and the next decision when the observed capability exceeds the task.
| Field | Record before changing | Acceptance after changing |
|---|---|---|
| Identity and owner | Person, supplier or application and accountable owner. | The intended identity still performs the task. |
| Business task | Approved action and necessary data. | The business owner accepts the actual workflow. |
| Effective capability | Direct, inherited and delegated access. | Supported boundary matches the approved scope. |
| Time and exception | Required duration and unresolved broad rights. | Expiry or review has a named owner. |
| Recovery | Protected administrator and rollback authority. | Recovery remains usable without the affected identity. |
| Evidence | Scope, observation time and test conditions. | Allowed and restricted checks are recorded. |
Choose the narrowest supported change that preserves the task
Compare effective access with a narrower built-in role, resource scope or time-limited arrangement where the platform supports it. Microsoft Entra guidance considers permissions, scope and duration; its privileged-management features have their own availability conditions. Do not assume a named premium feature is present in a small-business subscription or that a custom role is always necessary.
Start with a documented proposal rather than bulk revocation. Identify integration dependencies, the approved change window and the person who can restore the previous supported assignment. If the platform cannot express the desired boundary, record a justified exception and other controls. A transparent limitation is more useful than claiming least privilege from an assignment the system cannot enforce.
Test both the legitimate workflow and a safe boundary
Use the agreed identity to complete the approved business task after the change. Then check a harmless operation that should be unavailable, using synthetic records or a test environment where appropriate. Obtain explicit authority for the target and action. Do not probe real customer records or attempt destructive actions merely to produce an impressive access-review result.
Record the expected and observed behavior, scope and relevant session conditions. One tested boundary does not establish every alternative route. If the ordinary workflow fails, pause and trace the missing capability instead of restoring broad administration permanently. Keep rollback as an authorized operational action and document the reason for any temporary exception.
Handle shared secrets, departures and emergency access separately
Where named accounts are supported, review whether shared administrator credentials remain necessary. Removing a person from a password vault does not invalidate a secret they already knew. Coordinate underlying account removal or rotation with the integrations that use it, and review relevant sessions under the provider's supported controls. Do not treat these as interchangeable actions.
Preserve a protected emergency administrative route with a known owner. Restricting routine access should not leave a supplier's personal email as the only account-recovery method. Include new hires, changed duties and departures in the process so the register stays useful after the initial review. Service identities need the same ownership discipline even when no employee uses their password directly.
Close the review with decisions, not an unexplained score
Give the business owner a record of completed changes, accepted tests, remaining broad rights and uninspected systems. Assign a person and next step to every exception. Recheck after a significant platform, supplier or duty change and at the agreed review point. The result should be understandable without the reviewer present: what access exists, why it exists and how it will be maintained.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with practical Israeli website and digital-infrastructure knowledge. We can scope an access review, supported implementation and handover around the systems your business uses. The review does not become a full penetration test, a legal certification or a promise that every application and session has been exhaustively examined.
