AMBA security architecture.

AMBA's security posture rests on four principles. Defence in depth. No single control is the last line. Segregation of duties. No single actor can complete a high-impact action alone. Audit everything. Nothing important happens without a traceable record. Fail closed. When a control is uncertain, the system denies rather than permits.

These principles are opinions, not policies. They shape the architecture, which is why they are stated here. Institutions with a security policy that disagrees on one of these should raise the difference during implementation. Most conflicts have a configuration answer.

Passwords are hashed with bcrypt at cost factor 12 (4,096 iterations per verification). Plaintext passwords are never persisted, never logged, never included in any API response. Password hashes are stored in the users table and are readable only by the authentication service.

Failed login attempts increment a per-account counter. Five failures in succession lock the account for 30 minutes. The lock counter is per-user, tracked in the database, so it survives across server restarts and horizontal scaling. Successful login resets the counter to zero.

Multi-factor authentication is supported via TOTP (Google Authenticator, Authy, 1Password . Anything RFC 6238 compliant). Enforcement can be per-role or organisation-wide. Recovery codes are generated at enrolment and stored one-way-hashed.

Six primary roles: Super Admin, HR Admin, Finance Approver, Manager, Employee, Executive. Every API endpoint carries an @Roles() decorator that runs before any handler logic. Frontend UI is filtered to match, but the server check is authoritative.

Role checks include row-level context where applicable. A Manager sees only employees in their reporting line; an Employee sees only their own record. This is not a UI filter. The database query is scoped, so even a raw API call cannot exfiltrate data outside the user's scope.

Session tokens are JWTs signed with an HS256 key held in the server-side environment. The signing key is rotated periodically per operational policy. Tokens are stored in httpOnly, Secure, SameSite=Lax cookies. Invisible to JavaScript and safe from basic CSRF vectors.

Token lifetime is configurable per organisation, default 8 hours. Long-lived refresh tokens are not used. A user session lasts for the token lifetime, after which the user is prompted to log in again. This trades slight user friction for a bounded exposure window on any stolen token.

Data in transit uses TLS 1.3 with strong cipher suites only. Certificates are validated on every connection; downgrade attempts are refused. HTTP is redirected to HTTPS at the edge; HSTS is preloaded.

Data at rest is encrypted at the database layer using Postgres native encryption. Sensitive columns (bank account, national ID, TIN) additionally carry application-level field encryption with per-organisation keys held in a KMS. This means a raw database dump does not reveal these values without also compromising the KMS.

Document uploads to the vault are stored encrypted at the object-storage layer with per-organisation keys. Signed URLs for retrieval expire after a short window (default 10 minutes) and are single-use where the underlying storage supports it.

Every mutating action writes to the audit_logs table. That table is INSERT-only at the database role level. The application role has GRANT INSERT but not GRANT UPDATE or GRANT DELETE. A compromised application cannot rewrite audit history because it lacks the permission to do so.

Audit rows include: actor user ID, action type, resource type and ID, before value (for updates), after value, timestamp, IP address, user agent, and any additional contextual payload the action provides. Your organisation should define retention requirements based on its policies and applicable law.

Review the personal data your organisation needs, who may access it, and how long it should be retained. Confirm your deployment and operational policies against the data-protection requirements that apply to your organisation.

Employee records contain personal information. Your organisation should establish a process for handling access requests, verifying identity and reviewing the data before disclosure.

Your organisation is responsible for assessing breach-notification obligations. Record the applicable deadlines and owners in the compliance calendar; do not assume that AMBA automatically determines or fulfils legal obligations.

AMBA IT tracks tickets with priority, ownership and status. Use these records to coordinate operational work and retain the history of actions taken.

Regulatory incident reporting requirements vary. Confirm any required reporting format, recipient and deadline with your compliance team; a ticket record alone does not constitute a statutory filing.