An access review should establish who can perform approved tasks and who cannot perform incompatible or unnecessary ones. Removing permissions without testing can interrupt billing or fulfillment. Leaving every historical permission in place can expose data and actions beyond a person's current responsibilities.
Review NetSuite roles and permissions through a task-based matrix, representative users, and revoke-and-retest evidence. This gives administrators a practical way to reduce unnecessary access while preserving legitimate work. The business and security owners approve the intended boundary; testing establishes whether the configured account actually enforces it.
List active users, assigned roles, integration identities, privileged access, and relevant exceptions. Include contractors, temporary cover arrangements, and accounts used by automated processes. An employee's ordinary interactive role is only one possible route into the data.
For each assignment, identify the business owner, purpose, approved scope, and review date. Investigate orphaned identities and roles without a current owner. Do not assume that a role with few users is unimportant; it may support a critical month-end process.
Record custom roles separately from their original templates and inspect actual settings. Names such as “read only” or “finance analyst” are descriptions, not proof of capability. Consider other access mechanisms available in the account, including global permissions where enabled.
Preserve the starting configuration before making approved changes. The review needs a reliable record of what changed and a recovery plan if a legitimate task is disrupted.
Begin with tasks the business needs, then map them to permissions and restrictions. Avoid reviewing a long permission list without explaining why each permission is present.
A hypothetical finance team might propose this matrix:
| Task | Billing preparer | Finance reviewer | Reporting analyst |
|---|---|---|---|
| Prepare permitted invoices | Required | As approved for cover | Denied |
| Approve defined exceptions | Denied | Required | Denied |
| Maintain customer credit terms | Denied | Separate approved duty | Denied |
| View agreed finance reports | Required scope | Required scope | Required scope |
| Change role permissions | Denied | Denied unless separately authorized | Denied |
This is a discussion instrument, not a universal role design. The actual approval process, record types, and controls must be assessed in the account. A matrix row may require several settings and workflow conditions to enforce.
Give every necessary exception an owner, reason, duration, and review condition. Temporary cover should not become indefinite access merely because the task was urgent once.
A permission governs access to a record type or task. Restrictions narrow which records or values are available within relevant capabilities. Both layers matter. A role may have permission to view transactions while being restricted to certain subsidiaries or other organizational scopes.
In OneWorld accounts, subsidiary restrictions and cross-subsidiary viewing settings deserve explicit review. Also consider the effects of other applicable restrictions and account features. Do not assume that a single subsidiary selection determines every possible data path.
A personal session preference that narrows the visible view is not equivalent to a durable security boundary. Test the configured role's permitted reach rather than the user's preferred screen filter.
Check reporting, search, export, integration, and other relevant channels. A successful denial in one navigation path does not establish that the same data is unavailable through every authorized tool. Scope the tests to the routes used in the organization.
Create or select authorized test identities that represent the role combinations in use. Avoid testing only as an administrator. Include a user with one role, a user with several relevant roles, and an integration identity if the change affects automated work.
Build positive tests for normal tasks: prepare a permitted invoice, find the required customer, run the approved report, and complete a valid approval handoff. Include negative tests for a prohibited action and an excluded record scope.
Use synthetic or approved test data. A security review should not expose additional sensitive information to demonstrate that it is sensitive. Record the identifier of the test and the observed outcome without distributing unnecessary record contents.
For a hypothetical billing user restricted to Entity A, verify that the user can perform the approved billing task for Entity A and cannot perform the prohibited task for Entity B. Also test whether cross-entity reporting visibility matches the separately approved requirement. Viewing and editing are different capabilities and should have distinct expected results.
Once an unnecessary permission is identified, obtain the required approval and remove or reduce it in a suitable test environment first. Rerun both the denied-action test and the legitimate business-task tests.
Suppose the hypothetical billing role unexpectedly allows a customer credit-term change. The approved correction removes that capability. The retest must show that changing credit terms is denied while ordinary invoice preparation still works. If billing breaks, investigate the dependency rather than restoring broad access without understanding it.
Record the previous setting, approved change, test identity, timestamps, expected result, actual result, and reviewer. Keep the evidence with the access-review record. A screenshot of the new permission level alone does not prove enforcement or operational continuity.
Deploy approved changes through the organization's production process. Communicate any legitimate workflow change to affected users and provide a specific route for reporting problems. Emergency restoration, if necessary, should be approved, bounded, and followed by investigation.
Use recurring reviews for important roles and event-driven reviews for joiners, movers, leavers, new integrations, reorganizations, and new subsidiaries. A role appropriate last quarter may become too broad after an employee changes duties.
Review exceptions and temporary access separately so they do not disappear inside the ordinary role population. Confirm that expired needs have actually been removed. For integration identities, review the workload owner and credential lifecycle along with permissions.
Track unresolved findings by consequence and next action. Prioritize access that enables consequential changes or exposes sensitive information, while preserving a tested path for essential business operations.
The review is complete when decisions are approved, changes are verified, and remaining exceptions are explicitly accepted by accountable owners. A signed spreadsheet with no retest evidence leaves the most important question unanswered.
Not necessarily. Reusable roles can simplify governance when duties and data scope align. Use separate roles where meaningful responsibility or access differences require them, and avoid unnecessary variations that nobody can maintain.
No. Other roles or access mechanisms may still provide broad or incompatible capabilities. Review effective duties and relevant data paths, not only one role label.
No. They address different dimensions of access. Review permitted operations and record scope together, then verify the combination with positive and negative tests.
Document the business need, approver, duration, monitoring control, and retained evidence. Assess compensating controls with the relevant finance or security specialist. An exception should be visible and reviewed rather than treated as a permanent default.
CuriousRubik can help scope an access review around critical roles and business tasks. Begin with a role-task matrix and representative test users, then verify approved reductions without disrupting essential work.