SOX & IPO Readiness Review

1. iExecutive Summary & Readiness Scorecard§ i
2. iiVerified Strengths§ ii
3. iiiFindings Register§ iii
4. 1Access Governance§ 1
5. 2Segregation of Duties§ 2
6. 3Privileged Access§ 3
7. 4Emergency (Break-Glass) Access§ 4
8. 5Change Management§ 5
9. 6Managed Bundles§ 6
10. 7Integrations & External Surface§ 7
11. 8SOC Report Reviews & CUEC Mapping§ 8
12. 9Remediation Roadmap§ 9
13. 10Operating Rhythm — the Evidence Calendar§ 10
14. AAppendix A — Methodology & Assumptions§ A
15. BAppendix B — Reproduction Queries§ B
16. CAppendix C — Disclosed Limitations & Dead Ends§ C
17. DAppendix D — Source Materials§ D

This review assessed the NetSuite production environment against the information-technology general controls (ITGC) an external auditor will test in a first-year SOX 404 engagement, and against the operational practices expected of a company preparing for public-market scrutiny. The assessment was conducted by direct, read-only interrogation of the live system — role and permission tables, login audit trails, script and deployment inventories, change-history records — rather than by questionnaire or interview.

The conclusion is straightforward: the account has a strong technical audit surface but operating practices that would not survive a SOX 404 walkthrough today. The audit trail exists; the discipline around it does not yet. None of the deficiencies identified are structural, and all are remediable within one to two quarters. Section 9 sequences that work.

The five most material gaps

Readiness reviews conventionally lead with deficiencies. The following affirmative findings were verified with the same rigor and materially reduce the remediation surface.

All findings carry stable identifiers for tracking through remediation. Severity reflects a combination of audit impact and exploitability; effort estimates assume the current team.

Verified facts

• 109 roles exist (108 active; 76 custom). 21 employees hold enabled login access; all are active employees.
• Role assignments are held in employeerolesforsearch (columns role, entity); grants in rolepermissions (permission levels 1 = View through 4 = Full).
• Login activity, 90 days: 199 events; 196 successes, 3 failures. All access is interactive UI login — zero OAuth or token-based sessions were observed.

Findings

AG-1 (High). Sixteen inactive employees retain Administrator role assignments. Their access flag is off and the employees are inactive, but the role row persists — a single reactivation restores full administrative control. The population is largely legacy demonstration staff (e.g., A. Rymarquis, E. Goyena, P. Cutler, R. Rote, T. Cabral; predominantly @netsuite.com addresses). Under SOX this is a terminated-access deficiency regardless of the disabled flag, because the compensating state (inactive + no access) is not itself a controlled, attested condition.

AG-2 (High). Fifteen enabled accounts with no login in ninety days. Dormant enabled access is a standard ITGC deficiency: it widens the credential attack surface and demonstrates the absence of a periodic access review.

AG-3 (Medium). A role named TEST_DELETE_ME (internal id 2087) is active and assigned to a user — direct evidence that role lifecycle management is informal.

Operating practices to adopt

1. Quarterly user access review (UAR). Export users × roles × last-login; route to functional owners for attestation; retain the signed evidence. The account's existing permissions-audit process definition can be productized into this quarterly run. The first review should be executed immediately to clear AG-1 through AG-3.
2. Joiner / mover / leaver procedure. Access removal within 24 hours of termination; role re-approval on transfer; documented approval for every grant. NetSuite provides the evidence surface natively: systemnote on employee records and rolepermissions.datemodified / modifiedby.

The permission grants below were read directly from rolepermissions and represent conflicting duties concentrated in single roles. Levels: 1 View · 2 Create · 3 Edit · 4 Full.

Remediation approach

1. Define a formal SoD conflict matrix. Ten to fifteen rules suffice at this scale: vendor create/edit vs. vendor payment; journal posting vs. bank reconciliation; credit memo vs. cash receipt; item cost edit vs. inventory adjustment; user administration vs. any posting.
2. Remediate by role redesign, not user shuffling. Split the A/P Analyst role into "A/P Entry" (bill entry, no vendor-master edit) and "Vendor Master Maintenance" (vendor edits, no payments).
3. Accept and compensate where separation is impractical. For executive roles (CFO, CEO), formally accept the conflict and operate a monthly detective control — a documented review of journals and vendor-master changes made by those users. External auditors routinely accept well-evidenced compensating controls in small teams; what they do not accept is silence.
4. Re-scan quarterly using the queries in Appendix B and retain the diff as evidence of a functioning monitoring control.

Seven identities hold active Administrator access: A. Traynor (141), B. Morgan (149), C. Schmitz (3900), J. Bailey (3871), K. Glass (−5), T. Dietrich (158), T. Dietrich (3894).

Findings

PA-1 (High). Two admin identity pairs share a single mailbox (K. Glass and C. Schmitz → partner-admin@example.com; A. Traynor and B. Morgan → partner-admin@example.com). Shared mailboxes on privileged identities break attribution: an auditor cannot tie an administrative action to a person, which undermines every downstream control that relies on the audit trail. Additionally, partner-admin@example.com appears in the admin login audit but matches no listed admin identity — this must be reconciled.

PA-2 (High). A 33% administrator ratio. The enterprise norm is two to three named administrators plus a sealed break-glass account (§ 4).

PA-3 (Medium, folded into PA-2 remediation). Day-to-day work is being performed under the Administrator role (549 admin sessions across the two primary identities in 180 days). Routine work belongs in scoped roles; administrator sessions should be rare, purposeful, and individually explainable.

Operating practices

1. Reduce to two or three named administrators; migrate the remainder to purpose-built roles (after § 2 remediation, the Controller-family roles cover most finance needs).
2. One person, one identity, one unique email — no exceptions on access-enabled accounts.
3. Establish a scoped "IT Operations" role for routine platform work, reserving Administrator for genuinely administrative tasks.
4. Monitor monthly: loginaudit filtered to role 3. Every administrator session should have an explanation; most months, the correct count is near zero.

Current state (EA-1, Medium): no break-glass account exists — no employee record matches emergency-access naming patterns, and no procedure is documented. In practice, "emergency access" today means one of seven administrators logs in, which is indistinguishable from routine use and therefore provides neither control nor evidence.

Recommended design

1. Provision a dedicated employee record ("Emergency Access — Break Glass") holding the Administrator role with login access disabled by default and credentials sealed under dual control in the password vault.
2. Activate only upon documented approval by a named approver, with the reason recorded; deactivate within 24–72 hours.
3. Review every action taken during the activation window (systemnote and loginaudit filtered to the break-glass user id) and file the review.
4. Test twice a year and retain the test evidence. Auditors ask for proof the procedure works, not merely that it is written down.

Verified facts

• Change channels observed in systemnote.context over 365 days: UIF (interactive UI changes — dominant at roughly 6,193 events), SWF, MPR, SCH, SLT, RST, SDF (a single ~25-day window), OTR. No sandbox-copy context is discoverable in this table.
• 769 script deployments run at DEBUG log level in production; 18 deployments in TESTING status are live; 91% of scripts carry no description.
• A File Cabinet folder literally named "DE Department Hotfix" contains customscript_de_dept_hotfix_ss — direct evidence of in-production hotfixing, authored under a developer identity that duplicates another identity.
• Key financial approval workflows are in NOTINITIATING status (not executing).
• Several script files carry future modification dates (2026-09 through 2027-04) — almost certainly bundle-publisher timestamps, but the anomaly should be documented before an auditor discovers it independently.

Findings and operating practices

CM-1 (High) — Adopt a change-management SOP. Every production customization change requires: a request record, an approver who is not the developer, testing evidence from sandbox, and a deployment record. At this team size, a lightweight change register (a custom record type suffices) is adequate — the control is the discipline, not the tooling. The register must reconcile to systemnote; that reconciliation, performed monthly, is itself the detective control that proves completeness.

CM-2 — Standardize on SDF / SuiteCloud CLI with git as the only path for script and object changes. The single verified SDF window proves the pipeline already works. Git history plus pull-request approvals then generate change-control evidence as a by-product of normal work — the cheapest evidence a control can produce.

CM-3 — Production hygiene sweep (approximately one afternoon): reduce the 769 DEBUG deployments to ERROR or AUDIT level; release or remove the 18 TESTING deployments; migrate and retire the hotfix folder; add descriptions to all locally-owned scripts.

CM-4 — Reinstate the financial approval workflows, or formally retire them and document the replacement control. A documented-but-dormant automated control is a finding waiting to be written; the auditor's question — "was this control operating during the period?" — currently has an unfavorable answer.

CM-5 — Document the future-dated file timestamps so the anomaly carries a written explanation rather than surfacing unexplained during fieldwork.

The customization footprint — 437 custom record types, 151 custom lists, and a script population of roughly 1,100 — is majority bundle-owned. Attribution by scriptid prefix (the customsegment.frombundle column is empty account-wide and cannot be relied upon):

Operating practices

1. Bundle register: for each installed bundle — owner, business purpose, publisher, update policy (auto vs. managed), financial-statement relevance, last-reviewed date. Bundles are third-party code executing inside the financial system; the register treats them with vendor-management rigor.
2. Update policy decided deliberately. Managed bundles can auto-update in production; each publisher-pushed update should land in the change register (§ 5) when it occurs. For financially significant bundles (FAM, EBP, SuiteTax), review release notes before or immediately after updates.
3. Retirement review. Demo-era bundles (Atlas starter content, Benchmark 360) may no longer justify their attack surface. The account's existing bundle-impact-review process should be run per bundle ahead of an IPO-readiness cleanup.

Verified inventory

† Future-dated creation timestamps as returned by integrationapp.createddate — the same timestamp anomaly noted in CM-5. Zero OAuth or token logins were observed in the 90-day login audit; the integration layer is configured but dormant.

External script surface

• 183 deployed RESTlets — none available without login (verified strength S-6).
• 392 deployed Suitelets, of which 33 are available without login (isonline='T') — finding IN-1.

Findings

IN-1 (Medium-High). Thirty-three anonymous-access Suitelets are live production entry points requiring no authentication. Each requires individual review: business justification, data exposed, input validation. Any that cannot justify their exposure should be taken offline. The enumeration query is in Appendix B.

IN-2 (Medium). The ChatGPT and Claude AI integration records are enabled with no observed usage and no documented owner. Enabled-and-unused is the least defensible state — attack surface without accountability. Block them until an owner claims them, and document the organization's AI-access policy in either case; IPO diligence questionnaires now routinely probe AI data flows.

IN-3 (Medium). No dedicated service accounts exist. When integrations activate, each must run under a dedicated integration user holding a minimum-permission, web-services-only role (iswebserviceonlyrole='T') — never under a person's credentials, and never under Administrator.

Operating practices

Maintain an integration register (name → owner → purpose → auth method → token → role → review date); recertify tokens quarterly alongside the UAR; adopt a standing rule that no access token is ever minted against the Administrator role. Token inventory is not query-exposed (Appendix C) — the quarterly recertification uses Setup → Users/Roles → Access Tokens.

NetSuite is a SOX-relevant outsourced service organization; management's control set must include an annual, evidenced review of Oracle NetSuite's SOC 1 Type 2 report (and SOC 2 where relevant to security commitments).

1. Obtain the current SOC 1 Type 2 via SuiteAnswers or the Oracle account team. Reports are issued on a roughly semi-annual cycle.
2. Review and memorialize: the auditor's opinion (any qualification), exceptions noted and whether they touch controls the organization relies on (access, change management, availability, job scheduling), and the bridge letter covering the stub period between the report's coverage end and the fiscal year-end.
3. Map the CUECs. The report enumerates Complementary User Entity Controls — controls NetSuite explicitly assumes the customer operates: user provisioning and deprovisioning, role configuration, authentication policy, data input controls. Each CUEC must map to a control this document establishes (§§ 1–7). This mapping is the artifact external auditors always request and companies most often lack.
4. Repeat for every other financially relevant service organization — payroll processor, banking / EBP counterparties, tax engines, any middleware in the financial data path.

Phase 1 — This month · hygiene (hours, not weeks)

• Revoke the 16 stale Administrator assignments (AG-1); disable the 15 dormant enabled accounts pending owner attestation (AG-2); delete role TEST_DELETE_ME id 2087 (AG-3).
• Eliminate shared-email admin identities; reconcile the unmatched jterneus@ admin logins (PA-1).
• Production hygiene sweep: DEBUG→ERROR log levels, resolve the 18 TESTING deployments, triage the 33 anonymous Suitelets, block the unused AI integration records (CM-3, IN-1, IN-2).
• Reinstate or formally retire the financial approval workflows (CM-4).

Phase 2 — This quarter · control design

• SoD matrix ratified; A/P Analyst role split; compensating detective controls documented for executive roles (SD-1, SD-2).
• Administrator population reduced to 2–3; break-glass account provisioned with procedure (PA-2, EA-1).
• Change-management SOP adopted; SDF/git established as the sole deployment path (CM-1, CM-2).
• Bundle register and integration register created; bundle list exported manually and reconciled to the prefix analysis (§ 6, § 7).

Phase 3 — Next quarter · operating rhythm

• First quarterly UAR, SoD re-scan, and token recertification executed with retained evidence.
• First NetSuite SOC 1 review memo with completed CUEC mapping.
• First semi-annual break-glass test.
• Recurring scans folded into the existing permissions-audit and bundle-impact-review process definitions so each run produces evidence automatically.

Method

The review was executed entirely read-only on 2026-08-24 against the live production account, using SuiteQL queries, record-catalog introspection, and login/system audit tables. Three parallel research investigations covered (i) access governance and SoD, (ii) integrations and privileged access, and (iii) change management and customization footprint; their outputs were then independently spot-verified with direct queries before inclusion. No records, roles, permissions, scripts, or files were modified in the course of this review.

Assumptions — stated explicitly

1. Bundle attribution by prefix. With bundleinstallation unavailable and customsegment.frombundle empty account-wide, bundle ownership of objects was attributed by scriptid prefix convention. Confidence is high for well-known suites (FAM, EBP, SuiteTax) but the manual bundle export (§ 6) remains the authoritative source.
2. Dormancy window of 90 days was used for the stale-access analysis; organizations may reasonably choose 60 or 120. The finding survives any conventional threshold.
3. Channel-mix proportions in the § 5 chart are indicative aggregates; exact per-object change velocity was unrecoverable due to a mass-touch event on object timestamps circa 2026-08-12 (Appendix C).
4. Future-dated timestamps on files and integration records were treated as publisher/platform artifacts, not evidence of tampering; CM-5 recommends documenting them rather than ignoring them.
5. Severity ratings reflect the reviewer's judgment of audit impact and exploitability at current scale; they are not a substitute for management's own risk assessment.
6. 2FA enforcement was inferred from observed second-factor challenge failures and challenge URIs; no queryable per-user enrollment table exists, so universal enrollment should be confirmed in Setup → Users/Roles → Two-Factor Authentication.

All queries below were verified working in this account on the review date. They are the substrate of the quarterly monitoring controls in § 10 — re-running them and retaining the diff is the control.

B.1 — Role assignments and enabled users

-- The role-assignment table (two columns only)
SELECT role, entity FROM employeerolesforsearch;

-- Users with enabled login access
SELECT id, entityid, email, giveaccess, isinactive
FROM employee
WHERE giveaccess = 'T';

B.2 — Segregation-of-duties scan

-- Sensitive grants at Edit level or above, per role
SELECT role, permkey, permlevel
FROM rolepermissions
WHERE permkey IN ('TRAN_JOURNALENTRY','TRAN_PAYBILLS','LIST_VENDOR',
                  'TRAN_BANKRECONCILIATION','ADMI_MANAGEUSERS','ADMI_MANAGEROLES',
                  'LIST_EMPLOYEESSN','LIST_VENDOR_ACH',
                  'ADMI_VIEW_PAYMENT_CARD_TOKENS','ADMI_VIEW_GENERAL_TOKENS')
  AND permlevel >= 3;

B.3 — Administrator session monitoring

-- Admin-role logins by email address
-- NOTE: COUNT(DISTINCT user) combined with date filters fails on loginaudit
-- in this account; group by emailaddress instead.
SELECT emailaddress, COUNT(*) AS logins
FROM loginaudit
WHERE role = 3
GROUP BY emailaddress
ORDER BY COUNT(*) DESC;

B.4 — Anonymous-access Suitelets (the 33)

SELECT s.name, s.scriptid, d.scriptid AS deploymentid
FROM scriptdeployment d
JOIN script s ON s.id = d.script
WHERE d.isdeployed = 'T'
  AND d.isonline  = 'T'
  AND s.scripttype = 'SCRIPTLET';

B.5 — Integration applications and production hygiene

-- Integration application inventory
SELECT id, name, state, createddate FROM integrationapp;

-- DEBUG-level deployments live in production
SELECT COUNT(*) FROM scriptdeployment
WHERE loglevel = 'DEBUG' AND isdeployed = 'T';

-- External deployment surface by script type
SELECT s.scripttype,
       COUNT(*) AS deployments,
       SUM(CASE WHEN d.isonline = 'T' THEN 1 ELSE 0 END) AS available_without_login
FROM scriptdeployment d
JOIN script s ON s.id = d.script
WHERE d.isdeployed = 'T'
  AND s.scripttype IN ('RESTLET','SCRIPTLET')
GROUP BY s.scripttype;

In the interest of full transparency, the following could not be verified programmatically. Do not re-attempt these query paths; use the manual verification listed.