AI + ERP security checklist: 18 questions to ask
An AI and ERP security checklist: 18 questions on access, retention, tenancy, writes, audit and model hosting — with good and bad answers for each.
An AI and ERP security checklist should cover eight areas: access and least privilege, data residency and retention, tenancy, write governance, audit, model hosting and training, sub-processors, and incident response and exit. Ask each question in writing. The strongest signal is not a certification — it is whether the vendor can show you the exact query behind every answer.
Key takeaways
- Eighteen questions across eight areas — access, residency, tenancy, writes, audit, model hosting, sub-processors, incident response and exit — cover the whole surface of an ERP AI evaluation.
- Ask what is off by default, not what is possible. Every vendor can be configured securely; the default configuration is what you will actually run.
- Get the answers in writing. Vague verbal answers become specific written ones or they disappear.
- The most useful technical control is the least glamorous: the exact query shown with every answer, and a log of every query your admins can read.
- has no SOC 2 report today. We would rather you read that here than discover it in week three of an evaluation.
Connecting an AI tool to your ERP puts a language model next to your general ledger, your customer list and your pricing. That is not a reason to refuse — it is a reason to run a real evaluation. This is the AI and ERP security checklist we think IT and security teams should use on any vendor in this category, including us. Each question comes with what a good answer sounds like, and what a bad one sounds like.
Two rules first. Ask what is off by default, not what is possible: any product can be configured securely, but the default is what you will be running in six months when nobody remembers the settings conversation. And get every answer in writing — verbal answers in a demo are consistently more generous than the same answers in a document with a name on it.
The AI and ERP security checklist, in eight groups
Eighteen questions. Nothing here needs a security team to interpret it — a controller or ERP admin can ask all eighteen and recognise a weak answer.
Access and least privilege
| Ask | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| Which ERP permissions does the integration need, and who creates the role? | An itemised permission list, read-only to start, and a guided flow where your admin creates the role inside your ERP. | "Administrator is easiest." Or full access "so we can map your account properly". Mapping metadata needs no write permissions. |
| Does the AI act as the person asking, or as one shared service role? | Either per-user permission scoping, or a plain statement that all users see what the integration role sees, plus controls you can add. Either is fine; being unclear is not. | "Everyone in the workspace can ask anything." That is a data-access decision being made for you, by a vendor. |
A narrow role also narrows what the system can answer. A per-account data dictionary built on a restricted role describes a restricted account, and the right behaviour is to refuse rather than quietly under-report. Ask which one it does.
Data residency and retention
| Ask | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| Where is my ERP data processed, and where is it stored? | Named region or named infrastructure, plus the option to run it on your own cloud or hardware. Processing and storage answered separately, because they are different questions. | "In the cloud." "On secure servers." Neither is an answer, and both usually mean the vendor has not decided. |
| What is retained after an answer is produced, and for how long? | Zero retention of record data by default; only inspectable metadata such as query logs. Retention by opt-in, with a stated period, committed contractually rather than in a blog post. | "We keep it to improve the service." "Anonymised and aggregated." Ask what is retained, for how long, and how deletion is confirmed — all three, or none of them count. |
Tenancy and isolation
| Ask | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| Is any layer of my instance shared with other customers? | A dedicated instance, with any shared component named explicitly — telemetry, billing, a hosted model endpoint. Naming the exceptions is what makes the claim credible. | "Logically isolated" with no further detail. It may be true and well built, but as an answer it means "shared" until someone describes the mechanism. |
| How are my ERP credentials stored, and who can decrypt them? | Encrypted at rest, no human read access, rotation supported, and revocation from your side without asking the vendor. That last part matters most. | "Stored securely." Also worrying: any support process needing your credentials in plain text. |
Write governance
Reading data wrongly produces a bad decision. Writing data wrongly produces a bad ledger. Treat write access as a separate product with its own approval.
| Ask | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| Can it write to my ERP, and what is enabled by default? | Read-only by default. Writes enabled explicitly by an admin, scoped per record type and per field, with the scope visible in a console. | "Yes, it can do anything you ask it to." Enthusiasm about write capability, with governance described as "coming soon". |
| What happens immediately before and after a write? | A preview of exactly what will change, explicit human confirmation, an audit entry with the user and the query, one-click undo, and a cap on records per action. | "The AI is careful." A confirmation without a diff is not a control — you are approving a sentence, not a change. |
| How do you handle instructions embedded in my own ERP data? | An acknowledgement that a memo field can contain text resembling an instruction, and that field content is data, never a command. Read-only defaults and human write confirmation bound the damage structurally. | A blank look, or "the model knows to ignore that". This is a real path in any system that reads free-text fields and can act. |
Audit and observability
| Ask | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| Can my admins see every query the system ran, including failed ones? | A complete log — query text, user, timestamp, rows returned, outcome — visible to admins and exportable. Failures included, because refusals and errors are the interesting entries. | "We log usage." Usage counts tell you how much the tool was used, not what it looked at. |
| Is the query shown to the user with every answer? | Always, in full, re-runnable by a person with database access. This is what makes every number checkable and every answer traceable. | "We show the reasoning steps." "The query logic is proprietary." If the query is invisible, neither you nor your auditors can reconstruct a number. |
When a vendor does show you the query, read it rather than admiring it. Almost every wrong answer is wrong in the WHERE clause: the wrong date field, a status value that matches nothing, a missing subsidiary. Paste it into the SuiteQL formatter and check the filters — that review takes under a minute and is the highest-value thing a technical evaluator can do in a demo.
Paste the query a vendor shows you, make it readable, and check the filters before you believe the number.
Model hosting and training
| Ask | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| Which models are used, where do they run, and can everything stay local? | Named models and named hosting, plus a genuine self-hosted option with local models and no external calls. A vendor that can run inside your network has answered most residency questions at once. | "We use the best available model." Unnamed and changing means your data path changes without notice. |
| Is my data used to train models — yours or a third party's? | Never, stated contractually, covering both the vendor's own training and any upstream model provider's terms. Those are two commitments. | "Only anonymised data." "Only to improve your experience." Both are compatible with your ERP data leaving your boundary. |
In a regulated or air-gapped environment this section decides the evaluation — the trade-offs of local models are covered in self-hosted AI for ERP. Hosting also moves the cost model, so run both scenarios through the ERP TCO calculator before assuming self-hosting is the expensive option.
Sub-processors and supply chain
| Ask | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| List every sub-processor that can touch my data. | A maintained list with each one's role, and notification before it changes. Short lists are good; a maintained list is what matters. | "We don't share your data with anyone." Almost nobody runs with zero third parties, so an answer avoiding the list is avoiding the question. |
| What if your model provider has an outage or changes terms? | Swappable models, a described degraded mode, and a self-hosted path that removes the dependency. | No answer, or one that treats the model provider as infrastructure that cannot fail. |
Incident response, assurance and exit
| Ask | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| What is your incident notification process and window? | A stated window, a named contact route, and a written post-incident report. If no window is published yet, a vendor should say so and agree one in the contract. | "We'd tell you straight away." Good intent, no obligation, nothing to hold anyone to. |
| Which certifications do you hold today, and which are in progress? | Precise: the certification, its scope, its date, the auditor. Or an honest "none yet — here is what we do instead, and the timeline". | "SOC 2 aligned." "Compliance-ready." "Built to SOC 2 standards." None of these is a report, and the phrasing is chosen because it isn't. |
| How do I revoke access and remove my data within the hour? | You disable the integration role or token inside your own ERP — instant, unilateral, no ticket. Then export and deletion of anything vendor-side, with confirmation. | "Contact support and we'll process it." If your only exit runs through the vendor's queue, you do not control your exit. |
Three answers that should end the evaluation
- 1."We need administrator access." Reading metadata and running read-only queries does not require it. This answer says the product was built without a permission model.
- 2."We can't show you the query." Then no number is verifiable and no auditor can reconstruct anything — see why AI hallucinates on ERP data for what that costs.
- 3."Your data may be used to improve our models." Your general ledger, customer list and pricing are not training material. If this is in the terms, the terms are the product.
How to weight the answers
Not every question carries equal weight. Three principles for scoring:
- Structural beats promised. "Writes are impossible because the role has no write permission" is a stronger control than "our software will not write". Prefer controls enforced by your ERP over controls enforced by vendor code.
- Defaults beat capabilities. A read-only default is worth more than a configurable permission model, because defaults survive staff turnover and configuration drift.
- Verifiability beats accuracy claims. A vendor who shows every query gives you a way to catch their mistakes. The four properties of grounded ERP AI are as much an audit story as an accuracy one.
Finally, weigh the risk against the cost of doing nothing, because the status quo is not free. Hand-assembled reports consume real hours — the reporting time savings calculator puts a figure on those — and exported spreadsheets in inboxes are their own governance problem. If you are taking a proposal to a finance committee, the ERP ROI calculator keeps the benefit side as concrete as security has forced the risk side to be.
Our answers, including the uncomfortable one
It would be dishonest to publish a checklist and dodge it. Plainly: has no SOC 2 report today, and no third-party audit report to hand you. We are pre-launch. If a certification is a hard gate for your organisation, we do not clear it yet, and you should know that in week one rather than week three.
What we do have is architecture you can verify yourself. connects through a least-privilege, read-only integration role that your admin creates in NetSuite, and cannot write until you enable it per record type and per field — with a preview, your confirmation, an audit entry and one-click undo on every write. Every customer runs a dedicated instance: self-hosted on your own cloud or hardware, or hosted by us on infrastructure serving only you. A full instance including local models runs on a single 16 GB server, so a zero-external-call deployment is supported rather than a special project. We retain none of your record data by default, never pool it and never train on it. Queries run live rather than against a copy, so your ERP stays the system of record, and every query and change is visible to your admins in a governance console.
Where we would rather say "not yet" than something reassuring: we do not publish an incident notification window, and we will agree one contractually rather than invent one here. For a hosted instance we will name every sub-processor in writing during an evaluation; there is no published list today. Revocation, though, is deliberately in your hands — disable the integration role in your own NetSuite account, without contacting us, and the connection stops.
Frequently asked questions
Is it safe to connect AI to my ERP?
It can be, and the safety comes from configuration rather than the model. The conditions worth insisting on: a least-privilege read-only role that you create, no writes until you explicitly enable them per field, zero retention of record data by default, a query log your admins can read, and the exact query shown with every answer so numbers are checkable.
What permissions should an AI tool have in NetSuite?
Start with a dedicated integration role with read-only permissions on only the record types you need, created by your own administrator. Reading metadata to map your account requires no write access at all. Add write permissions later, per record type and per field, and only where a business process needs them — never at the administrator level.
Should I require SOC 2 from an ERP AI vendor?
It is a reasonable gate for a large organisation, but treat it as one signal rather than the answer. A SOC 2 report tells you a control environment was audited against a stated scope on a stated date. It does not tell you whether the product is read-only by default, whether it shows its queries, or what it retains. Ask both.
Can an AI tool change data in my ERP by mistake?
Only if it has write permissions. The structural protection is your ERP's own role model: with read-only permissions, no software error or bad instruction can write anything. Where writes are needed, require a preview of the exact change, an explicit human confirmation, an audit entry and an undo — and a cap on how many records one action can touch.
Does AI need to copy my ERP data into its own database?
No. A system can query your ERP live and keep no copy, which means your ERP stays the system of record and there is no second dataset to secure, sync or delete. Warehouse copies have legitimate uses for long-history analytics, but they are a choice with governance consequences — ask which model the vendor uses.
What does zero data retention actually mean?
That your record data is used to produce the answer you asked for and is not stored afterwards. Test the claim with three specific questions: what exactly is retained, for how long, and how is deletion confirmed. Metadata such as query logs is usually retained deliberately, because you want that audit trail — it should be inspectable and exportable.
Calculators for this
Format SuiteQL and SQL in your browser: keyword casing, clause line breaks, indented joins and subqueries, plus a one-line minify mode.
Model 5-year ERP total cost of ownership: subscription or licence, implementation, internal FTE, infrastructure, upgrades and support. Cloud vs on-prem.
Reporting time savings calculator — price the hours your team spends building reports, the annual cost, hours recovered and the FTE equivalent.
Build an ERP ROI case from your own numbers: hours saved, inventory and receivables released, rework avoided. Get ROI %, payback months and 3-year NPV.
Keep reading
Grounded ERP AI defined: four testable properties — per-account dictionary, schema validation, shown queries, refusal — and how to test a vendor on each.
Why AI hallucinates on ERP data: the mechanism behind confident wrong numbers, and the four controls that stop it — grounding, validation, shown queries.
What a data dictionary is in ERP terms: record types, custom fields, join paths, observed status values — and why AI answers need a per-account one.
Who genuinely needs self-hosted AI for ERP, what local models give up against frontier models, what fits on modest hardware, and the air-gapped case.