Roles and permission matrix
Business roles for enterprise users and supplier users; a data-driven permission matrix defines what each role can see and do, capability by capability.
RBACSecurity & Compliance
Security & Trust
ESS Hub is designed for enterprise supplier collaboration across procurement, logistics, quality and finance. Security controls are applied across supplier access, user permissions, application data and enterprise integrations.
Authenticated accessRole-based access controlSupplier-level separationAudit trailHTTPSEU company
Written for due diligence, not for marketing.Controls visible in the platform today are described as facts; everything else is confirmed during enterprise technical due diligence. Provider certifications are never presented as ESS Hub certifications.
ESS HubCurrent security controlsProvider assuranceCustomer-specific complianceEnterprise due diligence
Introduction
How ESS Hub is secured
ESS Hub operates as a supplier-facing collaboration layer around the customer's existing enterprise systems, helping keep supplier interaction separated from direct access to backend SAP, ERP and integration environments.
Security, compliance and assurance requirements can vary between customers and industries. ESS Hub therefore combines implemented platform security controls with an enterprise due-diligence process in which customer-specific requirements can be evaluated before production deployment.
This page keeps three things apart, and never mixes them:
- Current security controls — what is implemented in the platform today
- Infrastructure-provider certifications — assurance held by the providers for their own services, not certifications of ESS Hub
- Customer-specific compliance requirements — what can be evaluated and planned before a deployment
Security architecture
Security architecture
Suppliers interact with ESS Hub. They do not require direct access to the customer's SAP / ERP environment. ESS Hub exchanges relevant business information through the implemented integration architecture. A logical view: network-level mechanisms, protocols and encryption details are part of the due-diligence review, not of this diagram.
Web sign-inEDIAPISFTP
AuthenticationRoles & permissionsSupplier workspacesEnterprise workspaceAudit trailApprovals
EDIAPISFTP / filesIntegration middleware
SAP ECCSAP S/4HANA
OtherOther ERP systems
Logical architecture. Supplier channels terminate in ESS Hub; the integration layer exchanges business information with the enterprise systems.Logical view · infrastructure details in due diligence
Identity
Identity and authentication
The authentication capabilities documented here are those visible in the ESS Hub application today. Multi-factor authentication and single sign-on with enterprise identity providers are not documented on this page as implemented controls; their current status is confirmed during enterprise technical due diligence.
- E-mail and password sign-in
- Implemented. Users sign in at app.esshub.ai with e-mail and password; the account is linked to a supplier or enterprise profile, and an account without a linked profile cannot enter the portal.
- Invitation-based onboarding
- Implemented. A supplier registers only from a valid invitation sent by the customer; the account is created for the invited e-mail address.
- Account activation
- Implemented. The supplier is activated on the enterprise side once its required onboarding documents are approved; supplier administrators invite and manage their colleagues.
- Passwords
- A minimum password length is enforced at registration. Password policy, reset and session details are confirmed during enterprise technical due diligence.
- Multi-factor authentication (MFA)
- Not documented on this page as an implemented control. Current status confirmed during enterprise technical due diligence.
- Single sign-on / identity provider
- Not documented on this page as available. Current status confirmed during enterprise technical due diligence.
Access control
Role-based access control
ESS Hub uses role-based access control (RBAC) to restrict access according to the user's role and assigned permissions. Who sees what is defined by business roles, by a permission matrix and by the supplier organization a user belongs to. The enterprise administers the portal; suppliers administer their own teams.
Enterprise roles
Enterprise users work in the enterprise workspace with business roles for their function — procurement, logistics, quality, finance; enterprise administrators use Portal Administration (invitations, roles, approvals, audit trail).
Customer usersSupplier roles
Supplier users hold roles within their organization — administrator, logistics, quality, finance — and see only the data and processes authorized for that organization.
Supplier usersScoped invitations
Suppliers are invited into defined process scopes (for example shipments, call-offs, packaging, returnables, EDI) and plants; invitations can be revoked.
OnboardingSupplier onboardingTeam & invitations
Supplier administrators invite colleagues and manage their roles within the supplier workspace.
Supplier adminApproval-controlled changes
Supplier bank-detail changes are requested by the supplier and approved on the enterprise side (Bank Approvals); an ESS operator role exists for platform operation.
Approvals · operationAccess model
Roles: customer users and supplier users
A simple model of the two user populations. Customer users work in the enterprise workspace according to their business role; supplier users work in the workspace of their own organization and see only the data and processes authorized for it. Plant-level access is not a separate control in the current product; plants appear as attributes of demands, shipments and invitations.
ProcurementLogisticsQualityFinanceAdministrators
Authorized supplier data and processesAdministrator · logistics · quality · finance roles
PermissionsData-driven permission matrix per roleSupplier-level separationScoped invitations
Conceptual access modelSupplier workspace in navy
Separation
Supplier data access
Supplier users are restricted to the supplier organization and data they are authorized to access. In the application, a supplier user's account is linked to exactly one supplier profile; the supplier workspace shows that organization's demands, shipments, documents, quality records and invoices, and nothing belonging to another supplier. Within the organization, roles decide which modules and actions a user has. The enterprise workspace sees all suppliers; enterprise administrators manage invitations, roles, approvals and the audit trail.
The isolation mechanism behind this behaviour, the environment setup and other implementation-sensitive details are not described on a public page; they are part of the due-diligence review.
Auditability
Audit trail and traceability
ESS Hub maintains traceability for supported business-process activities, allowing authorized users to review relevant process history. This is business-process history recorded by the application; technical security logging of the infrastructure is a separate topic covered during enterprise technical due diligence.
Audit trail
An audit trail for enterprise administrators records status changes across suppliers — timestamp, supplier, event, record reference and the old and new status — for ASNs, call-offs, complaints, packaging data sheets and support tickets; it can be filtered by supplier and event and exported.
Read-and-confirm receipts
Supplier letters and documents track who has read and confirmed them, and when.
Approval records
Bank-detail changes go through an approval step on the enterprise side; onboarding documents carry their review decision and reviewer note.
Document status history
Shipments (packed, dispatched, acknowledged), invoices (received, posted, paid) and payments carry status and dates.
Invitation and onboarding status
Supplier invitations show invited, accepted or revoked with the date sent; onboarding documents show requested, submitted, approved or rejected with submission and review dates.
Quality workflow state
Each 8D discipline shows its state and what was done.
Confirmations and read-and-confirm tracking per supplierEnterprise view · real product UI
Data protection
Data protection
The data-protection controls documented here are those visible in the platform and in the company context. Encryption at rest, key management, backup arrangements, hosting region, data residency, retention and deletion procedures are confirmed during enterprise technical due diligence and are not asserted on this page.
Encrypted in transit
The application is served over HTTPS; supplier and enterprise sessions are encrypted in transit.
HTTPSAccess controls
Role-based permissions and supplier-level separation govern who can see and change which business data.
RBAC · separationSupplier data separation
Supplier workspaces are separated; a supplier sees only its own organization's business documents.
SeparationMasked sensitive data
Supplier bank details are masked in the interface; changes go through an approval step on the enterprise side.
Masking · approvalBusiness documents, not files
Orders, shipments, quality notifications and invoices are structured records with status; onboarding documents and evidence are uploaded into the application, not passed around by e-mail.
StructuredEU company
ESS Hub is developed and operated by EDI & SAP Solutions SRL, Brașov, Romania, a company in the European Union.
EUAbout ESS HubIntegration
Enterprise integration security
Suppliers do not need direct credentials or direct technical access to the customer's SAP / ERP system in order to use ESS Hub. ESS Hub fits into the enterprise architecture as the supplier-facing layer: what crosses the boundary between ESS Hub and the enterprise systems is structured business information, exchanged through the customer's implemented integration architecture over the channels defined for the landscape — EDI, API or SFTP / file exchange. Integration security therefore depends on the implemented connection architecture; specific mechanisms and protocols are described per implementation and in the due-diligence review, not asserted here. SAP Integration · EDI & B2B Integration · Technical architecture
01SupplierWeb portal or machine-to-machine channel
02ESS HubAuthenticated, role-based supplier collaboration
03Controlled integrationStructured business documents only
04Integration layerThe customer's implemented integration architecture
05SAP / ERPSystem of record inside the enterprise
Logical boundary · mechanisms per implementationESS Hub in navy
Two channels
EDI and supplier portal separation
ESS Hub allows portal suppliers to participate in the structured supplier process without receiving direct backend-system access, while EDI-capable suppliers keep their existing B2B integration. Both channels end in the customer's integration layer and backend process. This architectural separation is a design principle, not an absolute security guarantee; the controls that apply to each channel are reviewed per implementation.
EDI suppliers
01EDI suppliersOwn EDI systems
02Existing B2B integrationThe customer's established connections
03SAP / ERPSystem of record
Portal suppliers
01Portal suppliersWeb portal · authenticated users
02ESS HubSupplier-facing collaboration layer
03Integration layerThe customer's integration architecture
04SAP / ERPSystem of record
Two supplier channels, one enterprise processESS Hub in navy
Environments
Application environments
ESS Hub distinguishes environments per customer: a production environment and a quality environment used for integration and process testing before changes reach production. The quality environment is where interfaces to the customer's landscape, process configuration and supplier flows can be tested with the customer's teams; production is the environment suppliers use in daily operation. Demo environments used for product demonstrations are separate from customer environments.
The exact environment setup — separation, data, access, refresh and the degree of infrastructure isolation — is described during enterprise technical due diligence; no claim of complete physical infrastructure isolation is made on this page.
Hosting
Infrastructure and hosting
ESS Hub is developed and operated by EDI & SAP Solutions SRL, Brașov, Romania, a company in the European Union. The production application uses two established platform providers, each in a verified role:
- Vercel — hosts and serves the ESS Hub web application (app.esshub.ai)
- Supabase — provides the application's authentication service, database, serverless functions and file storage
This describes the role of each provider in the current architecture and nothing more. Hosting regions, the data location of each component — application, database, storage, backups and logs — the encryption implementation and subprocessor details are provided during enterprise technical due diligence. This page deliberately does not state that all ESS Hub data remains in a single country or that ESS Hub provides EU-only data residency: that statement is made only for a specific customer environment, with its components verified, in the due-diligence review.
Provider assurance
Third-party infrastructure and provider assurance
ESS Hub uses infrastructure and platform services from established technology providers — Vercel for the web application, Supabase for authentication, database, functions and storage. Relevant provider certifications and assurance documentation can form part of the overall technical due-diligence review, always as provider-level assurance.
- Provider certification
- Security certifications or independent assurance reports held by Vercel or Supabase for their own services (for example a provider's ISO/IEC 27001 certification or SOC 2 report) are provider-level certifications. They can form part of the overall technical due-diligence review.
- ESS Hub / EDI & SAP Solutions certification
- A certification would apply to the ESS Hub platform or to EDI & SAP Solutions SRL itself and is a separate matter from provider assurance; customer-specific certification requirements are handled as described under Customer-specific compliance requirements.
- Not inherited
- A provider's SOC 2, ISO/IEC 27001, PCI DSS, CSA or any other certification is not a certification held by ESS Hub or EDI & SAP Solutions SRL, is not inherited by ESS Hub, and is not presented as such; no provider logo is used to imply capability.
Customer requirements
Customer-specific compliance requirements
Enterprise customers may have security or compliance requirements specific to their organization or industry. These requirements can be evaluated during the pre-implementation phase and, where feasible, incorporated into the implementation and compliance plan. Where a specific certification or independent assurance is required for production deployment, the applicable scope, assessment requirements and certification plan can be agreed as part of the implementation process. Certification and assurance activities remain subject to the applicable scope, required remediation and successful independent assessment.
01Customer requirementSecurity or compliance requirement of the customer
02Scope assessmentWhich standard, which scope
03Gap assessmentCurrent controls against the requirement
04Remediation where requiredAgreed measures
05Independent assessment / certificationBy the independent assessor or certification body
06Production readinessSubject to completion of any mandatory assurance requirement
Requirement → assessment → remediation → independent assessmentESS activities in navy
Planning
Certification as part of implementation planning
If a specific certification is mandatory for the customer's production environment, the requirement can be evaluated as part of the implementation planning rather than discovered only at the end of the project. The certification timeline depends on the applicable standard, certification scope, current control environment, required remediation and the independent certification body. No timeline is published on this page. Implementation and certification activities may run in parallel when agreed with the customer, with production deployment subject to completion of any mandatory assurance requirements.
01Customer security requirementIdentified early
02Pre-implementation assessmentRequirement evaluated before the project
03Scope definitionStandard, scope, environment
04Gap assessmentCurrent control environment
05Required remediationAgreed measures
06Independent audit / certificationCertification body
07Production readinessDeployment conditional on the required assurance
Planning approach · not a guarantee of certificationESS activities in navy
Examples of customer requirements
Examples of customer-specific assurance requirements
Examples of assurance requirements a customer may set for a deployment — not a list of ESS Hub certifications. Each is evaluated as described above when it is a prerequisite for a deployment, and remains subject to the applicable assessment.
- ISO/IEC 27001
- Information security management system certification — an example of a requirement a customer may set for a deployment.
- TISAX
- Automotive information security assessment — an example of a requirement an automotive customer may set.
- Customer security assessments
- The customer's own security assessment of the platform and the implementation.
- Supplier security questionnaires
- Standard or customer-specific questionnaires answered with current information.
- Penetration-testing requirements
- Customer requirements for independent testing of the environment in scope.
- Architecture reviews
- Review of architecture, data flows and integrations by the customer's security and IT teams.
- Data-protection assessments
- GDPR-related assessments and documentation for the processing in scope.
Review
Security reviews before production
An enterprise implementation may include a customer security review before production deployment. The areas such a review typically covers, and for which ESS provides current, specific information:
- architecture and data flows
- authentication and authorization — roles, permissions, supplier separation
- integrations — channels, interfaces and the integration boundary
- infrastructure and data protection
- operational controls — environments, monitoring, continuity
- required certifications and assurance requirements
ESS provides the documentation and answers that exist for the environment in scope and takes part in the review; the customer's security approval is the customer's decision and is not implied on this page.
Operations
Monitoring and operational security
What is documented here as operational monitoring in the product today:
- business-level monitoring on the enterprise side — the Control Tower with inbound shipments, unconfirmed and overdue call-offs, open tickets and read-and-confirm tracking, plus logistics and finance monitoring views
- document and message status on both sides — packed, dispatched, acknowledged; EDI sent; received, posted, paid — and the message behind an ASN or an invoice
- audit trail of status changes for enterprise administrators
- support tickets raised by suppliers from the portal
Operational monitoring of the platform and of the message exchange is part of ESS operations; its scope, alerting and incident handling are described during enterprise technical due diligence. No 24/7 security operations centre, SIEM or automatic threat detection is claimed on this page.
Continuity
Backups and recovery
Backup and recovery arrangements for the ESS Hub environment — including retention, recovery objectives and continuity planning — are described during enterprise technical due diligence for the environment in scope. No backup frequency, retention period, RTO, RPO or recovery guarantee is published on this page.
Onboarding
Secure supplier onboarding
The security-relevant aspects of onboarding as implemented: access starts with the customer's invitation, the account is tied to one supplier organization, roles and permissions apply from the first sign-in, and the supplier is activated once its required onboarding documents are approved. No identity-verification service is part of the current product. Supplier Onboarding
01InvitationSent by an authorized enterprise user to the supplier's e-mail address, with the process scope
02Account activationThe supplier registers from the invitation; the account is created for the invited address
03Organization associationThe account is linked to the supplier's organization and workspace
04Role assignmentThe supplier administrator manages colleagues and their roles
05Onboarding documentsRequested, submitted, reviewed and approved before activation
06PermissionsThe permission matrix applies per role
Onboarding as implemented in ESS HubSupplier steps in navy
Processes
Security across supplier processes
Access controls apply across the enabled supplier processes: the same roles, permission matrix and supplier-level separation govern procurement, logistics, quality and finance, and each area's records carry their status history. Which processes a supplier sees depends on the modules and process scopes enabled in the implementation.
ESS Hub
ProcurementPurchase orders, RFQs
LogisticsCall-offs, ASN, packaging, labels
QualityComplaints, 8D, certificates, audits
FinanceInvoices, payment status
Access control + traceabilityRoles, permissions and supplier separation apply to every enabled process; business records carry their status history
Product context · modules per implementation
Backend separation
Data minimization and backend separation
ESS Hub is designed to expose supplier users only to the information and processes authorized for their organization and role. The supplier works with business information — a call-off, a shipment, a quality notification, an invoice status — inside ESS Hub, rather than with direct SAP / ERP access, technical objects or integration mappings. How business information is selected and synchronized between the enterprise systems and ESS Hub is defined per implementation.
01SupplierAuthenticated user of one supplier organization
02ESS HubRoles, permissions, supplier separation
03Authorized supplier-facing informationThe organization's own demands, shipments, quality records, documents and invoices
Supplier-facing information only · no direct backend accessESS Hub in navy
Due diligence
Enterprise security due diligence
Some enterprise security information should not be published in full on a public website. Additional technical and security information can be provided during a qualified customer due-diligence process. The areas below describe what that review covers: they are topics, not claims, and nothing on this list is asserted as implemented on this page.
Area
Topics covered
Architecture & data flows
Detailed architectureData-flow documentationIntegration-security detailsEnvironment setup
Identity & access
SSO / SAML / OIDC statusMulti-factor authentication statusPassword policyProduction access controls
Infrastructure & data
Providers and regionsData locationEncryption at restSecrets managementRetention and deletionSubprocessor information
Operations & continuity
Backups and recoveryMonitoring and loggingVulnerability managementPenetration testingIncident handling
Compliance & assurance
GDPR documentationData processing agreementCustomer security questionnairesProvider assurance documentationCertification planningData export and exit
Topics, not claims · answered with current, specific information for the environment you would useDue diligence, not marketing
Architecture
Security in the ESS Hub architecture
The security architecture in one picture, limited to the controls documented on this page. Multi-factor authentication, encryption at rest and infrastructure-level logging are not shown because they are confirmed in due diligence rather than asserted here.
Web portalMachine-to-machine channels
E-mail + passwordInvitation-based accounts
Roles & permission matrixSupplier data separation
Audit trail of status changesEncryption in transit (HTTPS)Approval-controlled changes
EDIAPISFTP / files
SAP ECCSAP S/4HANAOther ERP systems
Not shownMFA · encryption at rest · infrastructure logging: confirmed in due diligence
Logical view · controls documented on this pageESS Hub in navy
Principles
Security and compliance principles
Authenticated supplier access
Every supplier user signs in with an account created from the customer's invitation and linked to one supplier organization.
AccessRole-based permissions
Business roles and a data-driven permission matrix define what each user can see and do.
RBACSupplier data separation
Each supplier works in its own workspace and sees only its own business documents.
SeparationBackend-system separation
Suppliers interact with ESS Hub, not with the customer's SAP / ERP or integration environment.
BoundarySecure integration
Structured business documents cross the boundary through the customer's implemented integration architecture; mechanisms per implementation.
IntegrationTraceable supplier processes
Business records carry their status history; enterprise administrators have an audit trail of status changes.
TraceabilityData protection
Encryption in transit, masked sensitive data, approval-controlled changes; further controls confirmed in due diligence.
ProtectionTransparent assurance
Provider certifications are stated as provider-level assurance and never presented as ESS Hub certifications; customer-specific certification requirements are planned openly, subject to independent assessment.
TransparencyCustomer-specific compliance planning
Certification and assurance requirements are evaluated before implementation and, where feasible, planned into it — subject to independent assessment.
PlanningFAQ
Security and compliance FAQ
How do suppliers access ESS Hub?
Through the ESS Hub web portal at app.esshub.ai, with an account created from the customer's invitation and linked to the supplier's organization. Supplier users sign in with e-mail and password and work in their supplier workspace; EDI-capable suppliers can additionally exchange messages through the implemented machine-to-machine channels. Suppliers do not connect to the customer's SAP / ERP.
Does ESS Hub support MFA?
Multi-factor authentication is not documented on this page as an implemented control. Its current status for the ESS Hub environment is confirmed during enterprise technical due diligence.
Does ESS Hub use role-based access control?
Yes. ESS Hub uses role-based access control: business roles for enterprise and supplier users, a data-driven permission matrix that defines what each role can see and do, and supplier-level separation of workspaces and data.
Can one supplier see another supplier's data?
No. Supplier users are restricted to the supplier organization and data they are authorized to access; each supplier works in its own workspace and sees only its own business documents. The enterprise workspace sees all suppliers.
Do suppliers have direct access to SAP?
No. Suppliers interact with ESS Hub; they do not need direct credentials or direct technical access to the customer's SAP / ERP system. Business information is exchanged between ESS Hub and the enterprise systems through the implemented integration architecture.
How does ESS Hub connect securely with SAP and ERP systems?
Through the customer's implemented integration architecture: ESS Hub exchanges structured business documents with the integration layer over the channels defined for the landscape — EDI, API or SFTP / file exchange — and the integration layer connects to SAP or another ERP. The specific mechanisms and protocols of a deployment are part of the integration design and the due-diligence review.
Does ESS Hub maintain an audit trail?
Yes. Enterprise administrators have an audit trail of status changes across suppliers — timestamp, supplier, event, record and old / new status for ASNs, call-offs, complaints, packaging data sheets and tickets — with filters and export. Business records also carry their own status history, read-and-confirm receipts and approval records.
Is ESS Hub data encrypted?
In transit, yes: the application is served over HTTPS and sessions are encrypted in transit. Encryption at rest and key management are confirmed during enterprise technical due diligence and are not asserted on this page.
Where is ESS Hub hosted?
ESS Hub is developed and operated by EDI & SAP Solutions SRL, a company in the European Union. The web application (app.esshub.ai) is hosted and served by Vercel; authentication, database, serverless functions and file storage are provided by Supabase. Hosting regions and the data location of each component are provided during enterprise technical due diligence.
Where is ESS Hub data stored?
The application's database and file storage are provided by Supabase; the exact data location for the application, database, storage, backups and logs, and any subprocessors, is provided during enterprise technical due diligence. No EU-only data-residency statement is made on this page.
Does ESS Hub have separate staging and production environments?
ESS Hub distinguishes environments per customer: a production environment and a quality environment used for integration and process testing before production. The exact environment setup and its isolation are described during enterprise technical due diligence.
What if our organization requires a specific security certification?
Customer-specific certification or assurance requirements can be evaluated during the pre-implementation phase. Where feasible, the applicable scope, gap assessment, remediation and independent certification process can be incorporated into the agreed implementation and compliance plan.
Can security certification be part of the implementation plan?
Yes. Where a certification or independent assurance requirement is mandatory for production deployment, it can be addressed as part of implementation planning. Completion remains subject to the applicable assessment and successful independent review.
Can certification requirements be addressed before production implementation?
Yes. Customer-specific certification requirements can be evaluated during the pre-implementation phase, and requirements that are mandatory for production deployment should be identified and agreed before implementation or sufficiently early in the implementation program — subject to scope, feasibility, remediation and successful independent assessment.
Can certification activities run in parallel with implementation?
Where appropriate and agreed with the customer, implementation and certification activities can run in parallel. If certification is mandatory for production use, production deployment can be made conditional on successful completion of the required certification or assurance process.
What security documentation is available during enterprise due diligence?
Current, specific information for the environment you would use: architecture and data-flow documentation, integration-security details, identity and access status (including MFA and SSO), infrastructure, provider and data-location information, subprocessor information, operations and continuity information, answers to customer security questionnaires and, where required, certification planning. Only documents that exist are provided.
Enterprise due diligence
Request the ESS Hub security and compliance information for your review.
Tell us which topics your assessment covers — architecture, identity, data, operations, certification requirements. We answer with the current, specific information for the ESS Hub environment you would use.