ERP upgrades and patches are essential for keeping systems secure and up to date, but they can also introduce hidden risks amongst standard / seeded roles. One of the most overlooked issues is the way vendor-delivered, or “standard,” roles can change after a patch. When a vendor releases new functionality, it often assigns those permissions directly to standard roles. While this is convenient for broad usability, it can create sensitive access and SoD risks where roles suddenly hold permissions that your organization never reviewed, approved, or documented.
NetSuite follows a continuous delivery model built around two major semi-annual releases. Release 1 (R1) occurs in the first half of the year and Release 2 (R2) in the second. These releases introduce new features, enhancements, and compliance updates across the platform. In addition to the major releases, SuiteApps and bundles may also receive their own independent updates outside the core release cycle, giving NetSuite a flexible, always-current delivery model. With every major release, there is a possibility NetSuite makes a change to a standard role either by removing permissions or adding new permissions.
Consider NetSuite adding a new financial reporting feature or workflow configuration option. To make adoption easier, they may automatically assign that feature to roles like Administrator or A/P Manager. Overnight, those roles contain new privileges that may grant configuration or transactional capabilities beyond what was intended. Because this happens silently in the background, users can gain access to sensitive functions without anyone realizing it.
This unmonitored permission creep creates serious risk. A user could suddenly gain the ability to change configurations, process high-value transactions, or access sensitive data — none of which was authorized through your formal provisioning process. In some cases, these newly added permissions may also create a segregation of duties (SoD) conflict when combined with access the user already has in another role. Left unchecked, these changes can result in fraudulent postings, data leakage, or compliance violations, often going unnoticed until they surface in an audit.
Mitigating this risk requires a disciplined approach to role and access management if standard roles are being used:
Cloned or custom roles are far less likely to be modified by vendor patches. This stability means your organization maintains control over when and how new permissions are added, always through a formal review and approval process. By relying on custom roles, you can prevent inappropriate access and protect against compliance failures.
Every NetSuite release or update should be treated as a potential security event, not just a routine technical change. When it comes to roles, relying on customized roles combined with proper oversight transforms patch updates from a significant access risk into a controlled process that requires minimal remediation. By proactively managing role design, organizations can ensure that new releases enhance functionality without introducing hidden security risks or compliance exposures.
Let us know what questions you have by emailing support@erpra.net.