Practical ERP guidance
ERP Vendor Assurance After Go-Live: A CIO's Go/No-Go Review of SOC 2 and ISO 27001 Claims
Most ERP security reviews happen once, during selection. A questionnaire is answered, a SOC 2 report or ISO 27001 certificate is filed, and the decision is recorded as made. Then the ERP goes live, modules are added, integrations multiply, the hosting arrangement shifts, and the filed document quietly stops describing the system you actually run.
An ERP vendor assurance review is the recurring, evidence-based check that what a vendor says about its security still applies to the service you use today. This article is written for the CIO or IT head who already chose an ERP and now has to keep that choice defensible. It explains what each assurance artifact does and does not prove, why reviews decay, and how to run a post-go-live review using mandatory go/no-go controls instead of a comfortable but meaningless score.
One boundary up front. A vendor's attestation is evidence about the vendor's controls. It is not proof that you are compliant with any law, contract, or customer requirement. Your legal obligations belong to you and your counsel. The review below helps you decide whether the vendor evidence is strong enough to rely on for a specific use of the ERP, and what you must own yourself.
The frameworks here are proposed designs for you to adapt. They are not certification schemes, and passing them does not certify that any system is production-ready or compliant.
Key Takeaways
- Assurance decays. A SOC 2 Type 2 report covers a past period. An ISO 27001 certificate covers a defined scope as assessed. Neither automatically describes your current modules, integrations, or hosting.
- Read scope before you read the logo. Check the legal entity, the service, the sites, the period, and carved-out subservice organizations against what you actually buy.
- Separate four things: vendor statements, independent attestations, compliance-support features, and your own legal obligations. Do not let one stand in for another.
- Own your half. SOC 2 reports list complementary user entity controls (CUECs) that the customer must operate. Unowned CUECs are the most common silent gap.
- Use all-required controls. Ten mandatory go/no-go controls below. Any unmet control blocks reliance for the affected use until it is closed or consciously accepted by a named executive.
- Integrations are your control surface. Verified acknowledgment, terminal failure handling, tenant-safe idempotency, and privacy ownership must be tested, not assumed.
Why Vendor Assurance Decays After ERP Go-Live
Key takeaway: The document you filed during selection describes a past period and a defined scope. Your ERP, your integrations, and your vendor's supply chain keep changing after that.
During selection, assurance evidence is a gate. After go-live, it becomes a dependency. The difference matters because the evidence does not update itself, and the organization usually stops looking at it the moment the contract is signed.
Three forces cause the drift. First, the evidence is time-bound. A SOC 2 Type 1 examination addresses the design of controls as of a point in time. A Type 2 examination also tests whether controls operated effectively across a stated period, per the AICPA SOC 2 guide as summarized by Deloitte's DART. Once that period ends, the report says nothing about what happened afterward.
Second, the evidence is scope-bound. An ISO/IEC 27001 certificate covers the information security management system as scoped, which may be a whole organization or one defined part of it. The ISO/IEC 27001 standard leaves the boundary decision to the organization, so a certificate is only as relevant as its scope sentence is to your service.
Third, your own estate changes. You add modules, turn on AI-assisted features, connect an eCommerce platform or a warehouse system, change who administers the tenant, and perhaps move a workload between deployment models. Each change can move you outside what the vendor's evidence covers.
How assurance ages: a quick map
| Evidence element | What changes after go-live | Review trigger |
|---|---|---|
| SOC 2 Type 2 report period | Period ends; new period may not yet be reported | Each report cycle, plus a written statement for any gap |
| ISO 27001 certificate | Scope, certifying body, edition, or validity can change | Annual certificate and scope re-check |
| Subservice organizations | Hosting provider or support partner changes | Any subprocessor change notice |
| Product scope | New modules, APIs, or AI features added to your tenant | Before enabling any new module |
| Your configuration | Roles, integrations, and admin access drift | Quarterly access and integration review |
If you want a deeper look at the integration side of this problem, our earlier guide on a post-go-live ERP integration security audit covers data integrity and architectural validation. This article focuses on a different question: how much you can rely on the vendor's own assurance evidence.
What Each Assurance Artifact Proves, and What It Does Not
Key takeaway: Sort every claim into one of four buckets before relying on it: vendor statement, independent attestation, compliance-support feature, or your legal obligation.
Most confusion in ERP security reviews comes from treating all of these as the same thing. They are not. A marketing page that says the platform is secure is a vendor statement. A SOC 2 report is an independent service auditor's opinion on a described system. A role-based access feature is a capability that can help you meet your own requirements if you configure and operate it correctly. A privacy or financial-reporting rule is an obligation that falls on you as the customer, regardless of what the vendor holds.
The artifact reference table
| Artifact | Bucket | What it can support | What it does not prove |
|---|---|---|---|
| SOC 2 Type 1 report | Independent attestation | Controls were suitably designed at a point in time | That controls operated effectively over time |
| SOC 2 Type 2 report | Independent attestation | Controls operated across the stated period, with test results | Anything after the period; anything in carved-out services; your own controls |
| SOC 3 report | Independent attestation (general use summary) | A public-facing summary of the examination conclusion | The detailed control tests and exceptions found in a SOC 2 report |
| ISO/IEC 27001 certificate | Independent certification | An information security management system met the standard at the stated scope when assessed | That the specific product or site you use is in scope, or that two certificate holders run identical controls |
| Statement of Applicability | Vendor document tied to certification | Which Annex A controls the vendor applies and why others are excluded | That every listed control works as intended in your tenant |
| Penetration test summary | Vendor statement (unless independently scoped to you) | That some testing occurred | Coverage of your integrations, custom code, or configuration |
| Product security features (SSO, audit logs, role design) | Compliance-support feature | Capabilities you can use to meet your own control objectives | That you have configured them, or that using them satisfies any law |
| Security questionnaire answers | Vendor statement | Intent and self-described practice | Anything unverified by evidence |
Three reading rules that catch most problems
Rule 1: Read the scope sentence against your order form. The Cyberuptive guide to ISO 27001 certificate scope recommends comparing the legal entity, the service, the sites, and any named exclusions against what you purchased, and asking whether the support team touching your data works at a certified site.
Rule 2: Ask for the Statement of Applicability. ISO/IEC 27001:2022 Annex A lists 93 controls across organizational, people, physical, and technological themes, and the Statement of Applicability records which are applied and why exclusions were made. Vendors may share it under a nondisclosure agreement. A vendor that refuses even a summary has told you something.
Rule 3: Read the SOC 2 opinion and the exceptions, not the cover page. A SOC 2 report is intended for users who understand the service, including complementary user entity controls and complementary subservice organization controls, as the AICPA comparison of SOC 1, SOC 2, and SOC 3 reports on PwC Viewpoint and the AICPA guide describe. If nobody on your side has that knowledge, the report is easy to misread.
Identifiers deserve a note here. Report numbers, tenant identifiers, customer or supplier codes, and named user lists in evidence packages can themselves be sensitive. Share evidence packages under the vendor's confidentiality terms, and do not paste them into tickets or chat tools that have broader access than the report's restricted use allows.
For a view of what ArionERP publishes on this topic, see the ArionERP security and compliance page and the certifications page. Treat those pages as vendor statements and apply the same requests described in this article: ask for the current certificate or report, its scope, and its period.
Why This Fails in the Real World: Common Failure Patterns
Key takeaway: Capable teams fail here because evidence ownership is split: procurement collects it, IT operates the system, and nobody owns the gap between them.
The scenarios below are composite and illustrative. They are not customer results. They describe how the review process breaks, and none of them requires anyone to be careless.
Failure pattern 1: The filed PDF that no longer matches the service
A mid-market manufacturer selects a cloud ERP and files the vendor's SOC 2 Type 2 report in the vendor folder. Eighteen months later, the company enables a new quality module and an AI-assisted forecasting feature. Nobody checks whether those features sit inside the description of the system in the report. They may not. The report was accurate for what it described. The company simply stopped asking what it was relying on it for.
Why intelligent teams still fail: The approval workflow had a step for "collect report" but none for "re-confirm scope when the product footprint changes." The gap is in governance, not in anyone's diligence.
Failure pattern 2: The certificate and the service are different things
A vendor shows a valid ISO 27001 certificate. The scope sentence covers a development center. Production support for the customer's tenant runs from another site and another legal entity. The certificate is real. It does not say what the buyer assumed it said.
Why it happens: Certificates are visually reassuring and easy to verify as authentic. Authenticity is not relevance. Review checklists often ask "does the vendor hold ISO 27001?" instead of "does the certified scope cover the service, site, and entity on my contract?"
Failure pattern 3: The orphaned user-control
The SOC 2 report lists complementary user entity controls: for example, customers are expected to manage their own user access, protect their own credentials, and review their own integration activity. The report is filed. No one is named owner of these items. A year later, an API credential belonging to a departed integration developer is still active.
Why it happens: The vendor's controls and the customer's controls are written in different documents, read by different people, at different times. The assurance only holds when both halves operate. Our guide on sustainable API governance for modular ERP shows how to give those integration credentials a lifecycle owner.
Failure pattern 4: The retry that duplicated a consequential posting
An integration times out while submitting a purchase order approval to the ERP. The calling system, having no answer, sends it again. The first request had actually succeeded. The second creates a duplicate commitment. The vendor's platform did what it was asked. The customer-side integration design lacked an operation identity and a reconciliation step.
Why it happens: A timeout is an unknown result, not a failure. Teams that treat unknown as failure retry blindly. Section five covers how to design against this.
Failure pattern summary
| Pattern | Root system gap | Preventive control |
|---|---|---|
| Stale scope | No re-check trigger on module or feature change | Scope re-confirmation before enabling anything new |
| Certificate mismatch | Checklist asks about existence, not scope | Entity, site, and service match against the contract |
| Orphaned CUECs | No named owner for customer-side controls | CUEC register with owner and evidence |
| Blind retry | Unknown results treated as failures | Operation identity and reconcile-first handling |
A Proposed Design: Ten All-Required Controls for the Post-Go-Live Review
Key takeaway: Every control below is mandatory for the use it protects. Do not add up points. A single unmet control blocks reliance for that use until it is closed or consciously accepted in writing by a named executive.
The following is a proposed review design, offered as a starting point. It is not an established ArionERP certification program, and it does not certify any ERP deployment as secure, compliant, or production-ready. Adapt it to your risk register, industry, and counsel's guidance.
Why not a score? Summed scores let a strong result in one area mask a fatal gap in another. A vendor with excellent documentation and a hosting carve-out nobody examined might score 85 out of 100 and still be unfit for regulated data. Mandatory controls remove that failure mode. Each one is pass, fail, or unknown. Unknown is not a pass.
The ten controls
| # | Mandatory control | Evidence to collect | If unmet |
|---|---|---|---|
| 1 | Entity and service match. The attested or certified entity and service are the ones on your contract and in your deployment model. | Contract party names, report system description, certificate scope sentence | No reliance on that artifact until matched or contractually extended |
| 2 | Module and feature coverage. Every module, API, and AI-assisted feature you actually use is inside the described system. | Your module inventory compared to the system description | Do not process regulated or sensitive data through uncovered features |
| 3 | Currency. Report period or certificate validity is current, the edition is current, and any gap has a written management statement. | Report period dates, certificate validity, ISO/IEC 27001:2022 reference, gap letter | Treat as unverified for the gap period; escalate |
| 4 | Opinion and exceptions read. A named reviewer has read the opinion, exceptions, and management responses, and mapped them to your risks. | Reviewer sign-off with mapped exceptions and remediation status | Reliance blocked until read and mapped |
| 5 | Subservice organizations understood. Hosting and key subprocessors are identified, with inclusive or carve-out treatment known and their own evidence or contractual coverage obtained. | Subservice list, method used, hosting provider evidence reference | Treat hosting layer as unassured for this review |
| 6 | CUEC register complete. Every complementary user entity control has a named owner and operating evidence. | Register with owner, frequency, last evidence date | Assurance holds only on paper; remediate before reliance |
| 7 | Change notification. The contract requires notice of subprocessor, data location, and material scope changes. | Contract clause and notice contact | You cannot detect drift; negotiate or add a compensating monitor |
| 8 | Personnel and support access. You know who can access tenant data, from which sites and entities, and under what controls. | Support access description, site and entity list, access approval process | Restrict sensitive data or require stronger access terms |
| 9 | Incident, restore, and exit. Incident notification terms exist, a restore has been tested, and data export has been exercised. | Contract terms, restore test record, export test record | Recovery and exit are assumptions, not capabilities |
| 10 | Integration invariants tested. Your integrations meet the acknowledgment, failure, idempotency, and privacy requirements in the next section. | Test results from controlled failure injection | Block consequential automated postings until fixed |
How to read outcomes
- Go for the stated use: all ten controls are evidenced for the data classes and processes in scope.
- Conditional hold: one or more controls are unmet or unknown. Each has an owner, a remediation, and a date. The affected use is restricted until closure, or a named executive records an informed risk acceptance with an expiry.
- No-go for the stated use: a control that protects a regulated or consequential use cannot be met, and no compensating control exists.
Note the phrase "for the stated use." The same vendor can be a go for general purchasing and a conditional hold for export-controlled engineering data, because control 2 and control 8 are evaluated against what the data demands. A go does not mean the system is compliant with any regulation. It means the vendor evidence is adequate for your reliance on it, and your own obligations still need to be mapped by qualified counsel.
The NIST SP 800-161 Rev. 1 guidance on cybersecurity supply chain risk management is a useful companion reference for treating a vendor and its subprocessors as a managed supply chain rather than a single trusted box.
The Part You Own: CUECs and Integration Controls
Key takeaway: Vendor assurance covers the vendor's half. Your integrations, credentials, and retry behavior are the other half, and they must be designed for unknown results, duplicates, and privacy.
Complementary user entity controls are, as Baker Tilly's SOC FAQ puts it, controls that are the responsibility of the user organizations themselves and must be implemented for the whole process to work. Integrations are where those obligations concentrate, because that is where your systems write into the ERP.
Scope note: the patterns below apply to message or request-based integrations such as order feeds, inventory updates, and approval calls. They are not a substitute for the vendor's actual API contract. The code is illustrative pseudocode, not an official ArionERP API, and you should confirm exact behavior against the vendor's documentation before implementing. The ArionERP API page is the place to start for platform specifics, and our guide to idempotent ERP integration goes deeper on retries and timeouts.
The five requirements to test
| Requirement | What it means in practice | How to test it |
|---|---|---|
| Verified acknowledgment | Acknowledge delivery only after the work is durably recorded and scheduled. An acknowledgment means "recorded," not "processed." No acknowledgment means unknown. | Kill the receiver between receipt and commit; confirm the sender sees no acknowledgment and redelivers |
| Terminal failure | After defined attempts or a non-retryable error, the operation moves to a terminal state with a named owner and a visible exception queue. | Send an invalid and a permanently rejected request; confirm neither retries forever nor disappears |
| Uncertain-input handling | Ambiguous or malformed input is quarantined for review. It is never guessed, auto-corrected, or posted. | Send missing identifiers and conflicting quantities; confirm quarantine |
| Tenant-safe idempotency | Operation identity is durable, scoped to the tenant, and bound to an immutable approved payload hash. Reusing a key with a changed payload is rejected. | Replay the same key with the same payload, then a changed payload, under two tenants |
| Privacy ownership | Payloads, logs, dead-letter queues, and operation keys have a named data owner, a retention rule, and access limits. Identifiers can themselves be sensitive. | Sample logs and queues for personal or commercial identifiers; confirm owner and retention |
Never blindly retry an ambiguous timeout
For a consequential mutation, such as posting an invoice, releasing a work order, or approving a payment, a timeout does not tell you whether the change happened. The result is unknown: completion could not be confirmed. It is not success and it is not verified failure. Before any resend, reconcile against the authoritative operation state using the operation identity. Resend only if that state shows the operation was not applied, and then resend the identical payload under the identical key.
An illustrative claim-and-record pattern
The sketch below shows the invariants as pseudocode. It binds a tenant-scoped operation key to a payload hash, rejects changed-payload reuse, claims work atomically so concurrent workers cannot both execute, and records inbox and outbox entries in the same transaction as the claim. Only after commit does the receiver acknowledge.
-- Illustrative pseudocode, not an official ArionERP API contract BEGIN; INSERT INTO operation_claim (tenant_id, operation_key, payload_hash, state, claimed_by, claimed_at) VALUES (:tenant_id, :operation_key, :payload_hash, 'claimed', :worker_id, now()) ON CONFLICT (tenant_id, operation_key) DO NOTHING; -- If zero rows inserted, read the existing row: -- stored payload_hash <> :payload_hash -> REJECT (changed-payload key reuse) -- state IN ('completed','failed_terminal') -> return the recorded outcome -- state = 'claimed' by another worker -> do not execute; reconcile -- state = 'unknown' -> reconcile against authoritative state first INSERT INTO inbox (tenant_id, operation_key, payload_ref, received_at) VALUES (:tenant_id, :operation_key, :payload_ref, now()); INSERT INTO outbox (tenant_id, operation_key, task_type, scheduled_at) VALUES (:tenant_id, :operation_key, 'apply_change', now()); COMMIT; -- Acknowledge the sender only after COMMIT succeeds. -- Target-side conditional mutation (not read-compare-then-write): UPDATE sales_order SET status = 'approved', version = version + 1 WHERE tenant_id = :tenant_id AND order_id = :order_id AND version = :expected_version; -- 0 rows affected = conflict or stale state, NOT success. Reconcile.Three details are easy to miss. First, a read followed by a compare followed by a write is not compare-and-swap. Two workers can read the same value and both write. The conditional update above lets the data store reject the stale write. Where the target system cannot do a conditional mutation, disclose that limitation and add serialization, for example a single-writer queue per order.
Second, legitimate later operations must not be swallowed by deduplication. A second partial shipment for the same order is a new business intent and needs its own operation identity, for example one that includes the shipment sequence. The rule is simple: same intent and same payload share a key; a new intent gets a new key; the same key with a different payload is always rejected.
Third, privacy ownership extends to the plumbing. Dead-letter queues and retry logs often hold full payloads. Our guide to ERP integration data privacy controls for payloads, logs, and dead-letter queues covers how to assign owners and retention to each.
Comparing Vendor Types and Deployment Models Through the Assurance Lens
Key takeaway: The same ten controls apply to every ERP vendor and every deployment model. What changes is who owns each control and how much of the evidence you must produce yourself.
The table below describes general patterns, not claims about any named vendor. Verify each point with each vendor's primary documents before relying on it. Large suites, lightweight ERPs, and mid-market platforms differ widely by product and by cloud service, so the useful question is what to request, not what to presume.
Tier-1 ERP vs mid-market ERP vs ArionERP: what to request
| Review dimension | Tier-1 suites (general pattern) | Lightweight or mid-market ERP (general pattern) | ArionERP (what to request) |
|---|---|---|---|
| Published attestations | Often several, scoped per cloud service or product line; check which one covers your service | Varies from none to a single report; confirm scope and period | Current certificate or report, its scope sentence, and its period, per control 1 and 3 |
| Hosting layer | Frequently a subservice or inclusive arrangement; read the method used | Often a third-party cloud with carve-out | ArionERP Cloud is described as hosted on AWS or Azure regions; ask how the hosting layer is treated in the evidence (control 5) |
| Module and AI feature coverage | Large footprint raises the chance an option sits outside the described system | Smaller footprint, but add-ons may be separate | Confirm each module and AI-assisted feature you enable is in scope (control 2) |
| Support access | Follow-the-sun support is common; ask which entities and sites | Often small, centralized teams; ask the same | Ask which sites and entities support your tenant and under what access controls (control 8) |
| Customer-side controls | Extensive user-control lists; ownership is yours | Fewer documented; you may need to define your own | Build a CUEC register regardless of vendor (control 6) |
| Deployment choice | Cloud, private, or hosted variants differ in evidence | Usually one model | Cloud and on-premises options exist with the same functional scope; assurance responsibilities differ by model |
SaaS vs on-premises: who owns what
In a SaaS deployment, the vendor operates infrastructure, patching, and much of the monitoring, so its attestation covers more of the runtime and your review focuses on scope, period, subservice organizations, and your user-side controls. In an on-premises deployment, the vendor's evidence may speak mainly to its development, release, and support practices, while the runtime environment, patching, backups, physical security, and network controls are yours to prove. That does not make on-premises less secure. It means the evidence has to come from you, and controls 8 and 9 shift toward your own restore and access records.
If you are still weighing the models, the ArionERP pages for ArionERP Cloud and ArionERP On-Premises describe each option, and our SaaS vs on-prem decision matrix for architectural control and security explains the architectural trade-offs.
Risks, constraints, and trade-offs of this review
- Effort cost. A rigorous review takes reviewer time, and a CUEC register needs maintenance. Scale effort to the sensitivity of data and the consequence of the processes involved.
- Restricted evidence. SOC 2 reports are intended for knowledgeable users, and vendors typically share them under confidentiality terms. Plan for NDAs and secure storage.
- False comfort in either direction. A clean report does not prove your configuration is safe. A report with exceptions is not automatically disqualifying; read the management response and map it to your use.
- Legal obligations stay with you. Privacy law, export controls, financial reporting duties, and sector rules apply to you based on your facts. A vendor's attestation can support your compliance work but cannot substitute for advice from qualified counsel.
- Vendor cooperation varies. A vendor unwilling to share scope, a Statement of Applicability summary, or a gap statement has given you information. Record it.
Running the Review: Cadence, Owners, the 2027 Update, and a Lower-Risk Path
Key takeaway: Tie the review to triggers, not memory. Assign each control an owner, and re-run it whenever the vendor's scope or your footprint changes.
Triggers, actions, and owners
| Trigger | Action | Suggested owner |
|---|---|---|
| New report or certificate issued | Re-run controls 1, 3, 4 | Security or IT governance lead |
| New module, API, or AI feature enabled | Re-run controls 2, 6, 10 before enabling | ERP platform owner |
| Subprocessor or data location change notice | Re-run controls 5, 7, 8 | Vendor management with security |
| Security incident at vendor or at you | Re-run controls 4, 8, 9 | CIO or delegate |
| New integration or credential holder change | Re-run controls 6, 10 | Integration owner |
| Fixed calendar cycle (at least annually) | Full ten-control review | CIO, with finance and legal input |
2027 Update: what to add to the checklist
This section anchors recency, then generalizes. Two developments are worth building into the review now, and both stay relevant beyond any single year.
- Edition currency. ISO/IEC 27001:2022 is the current edition and the 2013 edition has been withdrawn, so certificates should reference the 2022 edition and an updated Statement of Applicability. Evergreen rule: always confirm which edition or criteria version a certificate or report cites, and whether transition obligations have been met.
- AI-enabled features and model supply chains. AI-assisted forecasting, anomaly detection, and assistants can introduce additional subprocessors, new data flows, and new retention questions. Evergreen rule: treat each AI feature as a separate scope question under control 2 and a separate subprocessor question under control 5, and ask what data leaves the tenant boundary and how it is retained.
What a smarter, lower-risk approach looks like
The lower-risk approach is not more paperwork. It is fewer, better-owned checks. Keep one evidence register per vendor with the ten controls, the artifact behind each, the reviewer, and the next trigger date. Give every CUEC an owner. Test integration invariants through controlled failure injection before enabling consequential automation. And choose vendors and deployment models whose evidence you can actually read, scope, and re-verify.
This is also how we recommend evaluating ArionERP. Request the current evidence, read the scope sentences, map the exceptions, and test our integrations against your own failure cases. A modular platform helps here, since you can enable and review capabilities in phases rather than certifying everything at once. Our ERP comparison page sets out how ArionERP positions itself against other options.
Is your vendor evidence still describing the system you run?
Bring your current report, certificate, and module list. We will walk through scope, period, and customer-side controls with you.
Request an ArionERP assurance walkthrough for your deployment.
Contact UsConclusion: Five Actions to Take This Quarter
Vendor assurance is a living dependency, not a filed document. These actions turn that principle into practice.
- Build the evidence register. For each ERP vendor, list the artifact, entity, scope sentence, period or validity, and next review trigger. Mark any unknown as unknown, not as passed.
- Match scope to reality. Compare your module inventory, AI features, support sites, and hosting arrangement against each system description and certificate scope. Escalate every mismatch.
- Assign owners to every customer-side control. Create the CUEC register, name an owner for each item, and require operating evidence on a schedule.
- Test your integrations under failure. Inject timeouts, duplicates, and malformed input. Confirm verified acknowledgment, terminal failure handling, tenant-safe idempotency, reconcile-first handling of unknown results, and named privacy owners.
- Map legal duties separately. Ask qualified counsel to map your own privacy, export, financial reporting, and sector obligations. Do not let a vendor attestation stand in for that analysis.
None of this certifies a system as production-ready. It gives you an evidence trail you can defend to your board, your auditors, and your customers.
About ArionERP
ArionERP is a modular, AI-enhanced ERP platform available as Cloud (SaaS) and On-Premises deployments, launched in 2016 as a product of Cyber Infrastructure (CIS), an IT outsourcing and custom software development company operating since 2003. CIS states that it holds ISO and CMMI credentials and a SOC 2 attestation. These are vendor statements; as this article recommends for every vendor, request the current certificate or report and read its scope before relying on it. Learn more on the ArionERP security page.
Reviewed by the ArionERP Expert Team.
Frequently Asked Questions
What is an ERP vendor assurance review?
It is a recurring, evidence-based check that a vendor's security claims still apply to the service you use. It covers independent attestations such as SOC 2 reports and ISO 27001 certificates, the scope and period they cover, subservice organizations, and the controls you must operate yourself.
What is the difference between a SOC 2 Type 1 and Type 2 report?
A Type 1 report addresses whether controls were suitably designed at a point in time. A Type 2 report also tests whether controls operated effectively over a stated period and includes the auditor's test results. Neither covers time outside its examination date or period.
Does an ISO 27001 certificate mean the ERP product itself is secure?
Not by itself. ISO/IEC 27001 certifies an information security management system at a defined scope. You must check that the scope covers the legal entity, service, and sites relevant to your deployment, and ask for the Statement of Applicability. Two certificate holders can operate quite different controls.
What are complementary user entity controls (CUECs)?
CUECs are controls listed in a SOC 2 report that the customer is expected to operate for the vendor's controls to work as intended. Examples include managing user access and protecting credentials. They need named owners and operating evidence on your side.
What should I do if the SOC 2 report period ended months ago?
- Ask the vendor for a written management statement covering the gap period.
- Record the gap as an unverified period in your evidence register.
- Check whether a new examination is underway and when its report is expected.
- Restrict sensitive use if the gap cannot be addressed.
Does SOC 2 or ISO 27001 make my company compliant with privacy or industry regulations?
No. These are assurance artifacts about the vendor's controls. Your legal obligations depend on your facts and jurisdiction. Use the evidence to support your compliance program and ask qualified counsel to map your specific duties.
How should I handle an ERP integration timeout on a consequential posting?
Treat it as an unknown result. Do not resend blindly. Reconcile against the authoritative operation state using the durable, tenant-scoped operation identity. Resend only if the state shows the operation was not applied, using the same key and the identical approved payload. If state cannot be confirmed, escalate to a person.
Does the review change for on-premises versus SaaS ERP?
The ten controls are the same, but ownership shifts. In SaaS, more of the runtime evidence comes from the vendor and its hosting provider. On-premises, the runtime, patching, backups, and physical controls are yours, so you must produce that evidence yourself.