Security & Compliance Architecture

1. How the Architecture Works

Suite Utils tools install as native SuiteScript 2.1 SuiteApps directly into your NetSuite account, built and distributed through Oracle's SuiteCloud Development Framework. There is no middleware server, no cloud gateway, and no external data pipeline. The script runs inside NetSuite's own JavaScript engine, inside your tenant, under your access controls.

When a script reads a Vendor Bill or queries a Saved Search, that data never leaves NetSuite. It's processed in-memory, within the script execution context, and discarded when the execution ends. The only outbound call a Suite Utils SuiteApp ever makes is a license verification ping. That ping sends only your NetSuite Account ID and the installed version number.

2. Authentication

Suite Utils tools authenticate using NetSuite's built-in OAuth 2.0, the method NetSuite requires for all new integrations (legacy TBA closes to new integrations in NetSuite 2027.1). Credentials are stored encrypted inside NetSuite's own credential vault. We never ask you to provide credentials outside of NetSuite's standard setup flow, and we have no way to retrieve them after setup is complete.

• Access is tied to a specific Integration record in your NetSuite account. Deleting that record immediately revokes the tool's access.
• OAuth 2.0 scopes are declared in the Integration manifest. You can see exactly what permissions are requested before authorizing.
• No credentials are stored outside your NetSuite account or on Suite Utils infrastructure.

3. Role-Based Access Control

Each SuiteApp declares only the permissions it needs. Administrators can lock down script roles to the specific record types and transaction types the tool actually uses. Nothing extra.

Each SuiteApp ships with a recommended Role setup document specifying the minimum permission set. Your NetSuite administrator can create a restricted role and assign it to the tool's Integration user. This prevents the script from accessing any records outside its functional scope, even if someone attempts to pass unauthorized parameters.

4. Governor Limit Compliance

NetSuite enforces execution time, memory, and API call limits (governor limits) on all SuiteScript runs. Suite Utils tools are tested against these limits at both the standard and high-governance thresholds. We use runtime.getCurrentScript().getRemainingUsage() checks to exit gracefully rather than fail hard when a large dataset approaches limits.

All queue-based operations (batch jobs, Slack notifications, scheduled syncs) use the N/task module to run asynchronously. They never block a user-facing record save.

5. External Integrations (Invoice Intake & Sanctions Sentinel)

Here is how Invoice Intake and Sanctions Sentinel handle external data and file processing:

6. Security Disclosure

If you find a bug or vulnerability, email us directly. We respond within 4 hours and keep you in the loop until it's resolved.

We ask that you give us reasonable time to investigate and patch before making a public disclosure. We don't pursue legal action against good-faith security researchers. We thank them.

7. NetSuite Upgrade Compatibility

Oracle releases two major NetSuite updates per year (typically March and September). Before each release, we run every Suite Utils tool against NetSuite's Release Preview environment. If an API changes or a SuiteScript method is deprecated, we update the SuiteApp before the release hits production accounts.

Active subscribers get updates distributed through NetSuite's SuiteApp update mechanism. You don't need to do anything: the compatible version installs on the next update check.

8. Questions for Your IT Team

If your InfoSec team needs a vendor security questionnaire, penetration test results, or a formal architecture diagram, email [email protected]. We'll respond with the documentation your team needs.