Security & compliance

Every function requires a user, a role and a privilege

No one operates ESAAB anonymously. Access to each screen and each action depends on the user's assigned role, not on a blanket permission.

• Per-user authentication Each person signs in with their own account. Credentials are not stored in plain text: passwords are kept using a hashing mechanism, so the original key is never legible within the system.
• Roles and privileges Each user's capabilities are defined through centrally administered roles and privileges. Enabling a function for someone is an administrator's configuration decision, not something the user can force.
• Access according to role The menu and available actions are built from the role: a user only sees and runs what they are authorized for. Someone who receives goods cannot necessarily adjust inventory, and someone who checks balances cannot necessarily dispatch.
• Validated session Each screen validates the active session before operating; if the session is invalid or has expired, the system redirects to the sign-in screen instead of exposing data.

Each warehouse and each company in its own lane

ESAAB is multi-warehouse and multi-company by design. One organization's or one warehouse's information is not mixed with another's within the same platform.

• Isolation by warehouse Operations are scoped to the user's warehouse: balances, receptions, dispatches, counts and movements are shown and executed within the authorized warehouse, not across the institution's entire inventory.
• Isolation by company or organization When several organizations coexist in the same installation, each operates on its own data set. Segregation by company keeps one tenant's operational information separate from another's (operational multi-tenancy).
• Scoped reach, not global privilege The warehouse and company scope is set when the session starts and travels with every operation. Access begins confined to the user's lane; widening it is, again, an administered decision, not a default.

Who did what, when, and on which lot

Traceability is not a report generated at the end: it is the continuous record of the operation. Every movement is logged and queryable.

• Movement logging Receptions, dispatches, transfers, location changes, adjustments and counts are recorded in the inventory history (kardex). The movement that happens on the floor is the same one that gets logged.
• Event attribution Because every action occurs under an authenticated user session, events are tied to who performed them and when. This makes it possible to reconstruct the sequence of an operation when it needs to be reviewed.
• Lot and expiry traceability Stock is controlled by lot and expiry date across the whole cycle — reception, storage, picking and dispatch — so a lot can be followed from the moment it enters until it is consumed.
• Visibility and alerts On top of that record, ESAAB delivers reports, dashboards and notifications that provide operational visibility and anticipate situations such as stock-outs or upcoming expirations.

Data handling aligned with Law No. 19,628

ESAAB operates within Chile's regulatory context and handles the personal data it processes with criteria of purpose, proportionality and safeguarding.

• Applicable legal framework Personal-data handling adheres to Chile's Law No. 19,628 on the Protection of Private Life. Data is collected and used for legitimate operational supply purposes, not for ends unrelated to that purpose.
• Consistency with the Privacy Policy Data handling in ESAAB is consistent with the Privacy Policy published on this site, which describes what data is processed, for what purpose, and the rights of data subjects.
• Prudence with clinical data In healthcare settings, ESAAB applies the minimization principle: it works with the information needed for supply and traceability operations, avoiding the collection or exposure of sensitive clinical data beyond what the operation requires.
• Sector standards as a goal Frameworks such as ISO/IEC 27001 or, where applicable, practices aligned with HIPAA are addressed as continuous-improvement goals and assessed per deployment. ESAAB does not claim to hold those certifications today; what this page does describe are controls the product implements effectively.

What this page claims — and what it does not

To make this section useful to IT and compliance teams, it is worth being explicit about the scope of each statement.