Application overview
A security approach built around responsibility
The inspected application includes authenticated sessions, password verification, role and permission checks, company module gates and company-scoped access in protected workflows. This page describes those application mechanisms. It is not an independent security audit or a guarantee about the hosting environment.
Employee and payroll information needs deliberate access, accurate records and a reviewable history. Authentication identifies the account; authorization determines what the account may do. These are distinct checks. The controls described here are verified in selected application workflows, while infrastructure and operational assurances require deployment evidence.
Implemented application mechanisms
Authentication and account protection
The web application verifies password hashes using bcrypt and uses sealed cookie sessions through iron-session. Session cookies are configured as HttpOnly and SameSite=Lax, with the Secure flag enabled for production. Mobile API requests use the supported bearer-token authentication path.
Protected request helpers validate active user/company access and applicable subscription or approved demo status against current records. Production operation requires appropriately managed unique server secrets; this source review does not establish how the live deployment manages them.
Password verification uses a stored hash rather than comparing a saved readable password. Web sessions are sealed and the cookie settings limit access from browser scripts, constrain cross-site sending and require secure transport in production. Mobile authentication verifies its supported token and current account context.
A valid session is only the first step. Protected helpers also check whether the user and company remain active and whether the applicable subscription or approved access period is valid. Administrators still need strong credentials, account review and a response process for suspected misuse. Multi-factor authentication is not claimed as a verified capability here.
Implemented in protected workflows
Role-based access control
The application distinguishes platform administration, company administration and employee access. Company module gates and employee-specific permissions provide additional control over workflows. Sensitive access is checked by server-side APIs rather than relying only on whether a menu is visible.
Role and permission checks distinguish company administration from employee self-service. Company-enabled modules and employee-specific HR permissions add workflow-level boundaries. Access should reflect an actual responsibility, rather than being granted solely because someone belongs to a department or has a senior job title.
These checks matter for employees who need their own attendance or payslip, and for HR users responsible for a defined administrative task. Company administrators should review the resulting workspace and permissions whenever a person joins, changes responsibilities or leaves.
Application-level company scope
Multi-tenant data isolation
Selected payroll, expense and employee workflows use company and employee scope when loading records and authorizing changes. The reimbursement regression checks include scoped query and authorization cases. This does not certify that every route has received an independent security assessment.
Company context is used in the reviewed data queries and authorization decisions. Employee self-service adds employee ownership where appropriate, so a request must satisfy the relevant company and employee scope before records are returned. Knowing a record identifier is not sufficient authorization in those protected flows.
This describes logical isolation in the application. It does not establish a separate physical database for each customer, a database row-security policy, or the outcome of an independent assessment of every route. Those requirements should be evaluated explicitly during procurement.
Verified payslip and reconciliation controls
Employee and payroll data protection
Protected payslip downloads validate employee ownership or authorized company access before rendering the saved payroll record. Protected company-logo loading also checks the company storage context. Employee-document visibility and HR permissions should be reviewed when uploading sensitive files.
Payroll access checks the authenticated company and, for employee self-service, the employee owner before loading the saved payslip. Authorized company access is subject to the applicable role/module checks. The browser preview and downloaded PDF use the same authorized financial record rather than a public employee search.
Reimbursement reconciliation preserves the saved payroll total and records evidence-backed allocations or authorized adjustments. A claim status is not treated as proof that a payment occurred. Important financial changes carry actor and period context so HR and finance can review how a record was produced.
Implemented controls with review-dependent coverage
Application and API security
Reviewed protected APIs authenticate the request and apply relevant permission, company and module checks on the server. A hidden menu is a user-interface choice; server authorization is the boundary that determines whether a request may access or change the record.
Selected workflows validate input structure, required fields, ownership and allowed transitions before saving. Authenticated session-status responses are configured not to be cached. Validation and caching behavior are workflow-specific, so this review does not claim uniform controls on every endpoint.
Browser security headers, traffic protection and rate-limiting coverage should be assessed against the actual deployment. No universal rate-limit policy, automated abuse-monitoring service or comprehensive security-header guarantee is established by this page.
Deployment evidence required
Database, infrastructure and recovery
The application uses Prisma with PostgreSQL. This alone does not establish database-network restrictions, encryption at rest, hosting region, backups or recovery objectives. Confirm the actual infrastructure, restore procedure and operational responsibilities with Mentrox before relying on a deployment.
No ISO 27001, SOC 2, healthcare certification, completed penetration test, uptime SLA or guaranteed recovery time is claimed. Request evidence for any security requirement that forms part of your purchasing decision.
Prisma provides the application’s database-access layer; the reviewed business services apply their company context when querying PostgreSQL records. Database connections and application validation are part of the implementation, but the hosting team must separately verify network restrictions, credentials, patching and operational access.
Before relying on backup or recovery arrangements, request the actual operating procedure, a restore-test record and agreed responsibilities. No backup frequency, recovery point, recovery time, hosting region, encryption-at-rest guarantee or disaster-recovery commitment is invented here.
Workflow controls; storage assurance requires review
Documents and file handling
The document-listing workflow checks authenticated company context and supports employee ownership and visibility settings. Selected uploads require an authorized company/employee context and apply file-size or file-category constraints. These controls help the business organize records and prevent some invalid submissions.
Document visibility in a listing and protection of the underlying file contents are separate questions. Storage and download arrangements differ by workflow and need deployment-specific review. This page does not claim uniformly private storage, malware scanning, content inspection or encryption for every uploaded file.
Customers should collect only necessary employment documents, assign visibility deliberately and verify the full upload-to-download process against their requirements before storing sensitive information.
Selected audit trails are implemented
Auditability and operational monitoring
The application records selected actions in audit logs, including payroll processing, expense status transitions and reconciliation evidence. Audit coverage is workflow-specific; universal event logging, tamper-proof storage and a published audit retention term are not established here.
Selected payroll and expense workflows record the acting user, related records, timestamps and financial or status context. Reconciliation requires a reason and evidence confirmation, and financial record changes and relevant audits share the applicable transaction. This supports review of a decision without silently replacing the old record.
The application also records selected operational errors. That does not establish a staffed security operations center, centralized incident monitoring, tamper-proof audit storage or continuous alerting. Ask for the actual monitoring and incident-response arrangements required by your organization.
Contract and legal review required
Data lifecycle and privacy
The company determines which employee information is necessary for its lawful HR processes and who should use it. Access expiry, employee separation and data deletion are different events. Financial history, documents, conversations and backups may need different retention decisions.
The published Privacy and Terms pages are review drafts. They describe data categories and the arrangements that still need business/legal approval; they do not establish an approved retention schedule, deletion deadline, data-residency promise or certification. Confirm export, closure, privacy requests and backup treatment in the applicable agreement.
Customer operating responsibilities
Responsibilities of company administrators
Maintain accurate account ownership and grant the access needed for each person’s responsibilities. Re-review module and employee permissions when roles change, and use the supported account/access process when employment ends. Do not share an administrator account to make an employee workflow easier.
Validate payroll settings with qualified reviewers, review sensitive document visibility and keep evidence for important financial corrections. Protect credentials and devices, and contact the support team when an account or record appears to have been used unexpectedly. These operating practices complement application controls; software configuration alone cannot establish an organization’s entire security program.
Published contact channel
Discuss requirements or report a concern
Contact support@mentrox.in with a description, affected workflow and the information needed to reproduce the issue safely. Do not include passwords, session tokens or unnecessary employee data. A published response-time or disclosure SLA has not been established by this page.
Procurement and IT reviewers can request a demonstration of the supported access workflows and discuss the evidence needed for their hosting, file-handling and recovery requirements. Keep specific deployment assumptions separate from the application controls shown on this page.