Security

Built to keep your workspace yours

Matrix holds your projects, your people's records and your client information in one place, so it is built around a clear company boundary, secure authentication and access you control down to the individual screen.

Your data stays yours

Matrix is multi-tenant, and every record belongs to exactly one company. That boundary is enforced in the data layer itself, not left to the code that happens to be calling it.

Company scoping on every query

Each request carries the company it belongs to, and the data layer requires it before a query runs. Your workspace only ever returns your workspace's records.

Files belong to your company

Every upload — documents, CVs, project resources, attendance spreadsheets — is stored as a record owned by your company, and both download and delete confirm the requester belongs to it.

Separated administration

The platform operations console is a separate application with its own credentials, reached independently of your workspace and of the people working in it.

Storage you can host yourself

File storage runs against AWS S3 or any S3-compatible endpoint you operate, so you decide where your documents physically live.

Secure authentication

How people sign in, how long a session lasts, and how it is protected while it is open.

Passwords hashed with bcrypt

Passwords are stored as bcrypt hashes, so they are never held in a readable form by anyone.

Sessions carried in HttpOnly cookies

The session travels in cookies that page scripts cannot read. The application asks the server who you are rather than decoding a token in the browser.

Idle and absolute session limits

Sessions end after a period of inactivity and, separately, at an absolute maximum age. Both are configurable for your deployment, and the sign-in screen reflects the policy actually in force.

Device-bound session renewal

A session is renewed only from the device it was issued to, so a token lifted from one machine cannot be used to continue the session elsewhere.

People set their own passwords

New users receive an emailed invitation and choose their own password from the link. No administrator ever selects or handles someone else's credentials.

Sign-in attempt limits

Sign-in and renewal attempts are rate limited against both the client address and the named account, so neither a rotating address pool nor an attempt sprayed across many accounts gets a free run.

Account recovery in the product

Administrators can see locked accounts and unlock them from the Admin screens, so recovery is a supported action rather than a support ticket.

Role-based access control

One named permission catalogue decides what each person can reach, and it is enforced at every layer rather than in the interface alone.

A permission per screen and per report

Access is granted by named permission — Board, Hours Per Project, Leave Summary, Employees — grouped in the grid exactly as the product's own navigation is.

Roles you define

Every company starts with Admin, Manager and Guest, and you build as many roles of your own as your organisation needs from the same catalogue.

Enforced end to end

The same permission drives the navigation, the application route and the API. The API checks it independently, so access never rests on what the browser believes.

Per-project access

Role permissions decide which screens someone can use; project access decides which projects appear in them. A delivery lead can be given full project rights on their own engagements only.

Administration reserved

Company settings and billing are restricted to the Admin role specifically, so the most sensitive screens are granted deliberately.

Protected API and inputs

The same protections apply whether a request comes from the interface or from your own code.

One authenticated API

Everything the application does goes through a documented HTTPS API behind the same session, company scoping and permission checks as the screens.

Origin allowlist

Cross-origin access is granted only to origins you configure, and requests from anywhere else are refused before they are processed.

Cookie policy you control

SameSite, Secure and the cookie domain are configured for your deployment rather than left to defaults.

Bounded responses

Page sizes are capped, so a single request cannot be used to pull an unbounded volume of records.

Sanitised rich text

Descriptions and comments are written in a rich-text editor and sanitised before they are rendered anywhere in the product.

A record of what happened

Evidence for an access review, an investigation or a routine question about who changed something.

Field-level change history

User record changes are recorded as who changed which field, from which value to which, and when — scoped to your company.

Issue history

Issues keep their own audit trail, so a status or assignment change is attributable rather than merely visible.

Email delivery log

Every message Matrix sends is recorded in the Email Logs report, so a notification can always be traced.

Assistant actions recorded

Every action taken through the in-product assistant is written to the audit log, and anything destructive requires an explicit signed confirmation before it runs.

Careful telemetry

Operational metrics and audit records are written without question text, arguments, answers or identifiers, so diagnostics never become a second copy of your data.

Chat History

Questions asked of the assistant are available as their own permissioned report for companies that want oversight.

Working with your security team

Send us your questionnaire

Security reviews are part of every serious evaluation, and we would rather be in that conversation early. Tell us how your organisation assesses a supplier and the team will work through it with you — including storage location, session policy and access model for an Enterprise deployment.

Talk to the team

Or email sales@ginilytics.com

Security questions

How is our data kept separate from other companies?

Every record in Matrix belongs to exactly one company, and the data layer requires that company on each query before it runs. Uploaded files are stored as company-owned records whose ownership is confirmed on download and delete.

How are passwords stored?

As bcrypt hashes. New users set their own password from an emailed invitation link, so no administrator ever selects or handles someone else's credentials.

How do we control who can see what?

Through named permissions, one per screen and per report, grouped exactly as the product's navigation is. You build roles from that catalogue, and add per-project access on top so people see only the projects they work on.

Is access control enforced beyond the interface?

Yes. The same named permission drives the navigation, the application route and the API, and the API checks it independently of the browser. Access does not depend on what the interface displays.

How are sign-in attempts protected?

Sign-in and session renewal are rate limited against both the client address and the named account. Sessions are carried in HttpOnly cookies, have separate idle and absolute limits, and are renewed only from the device they were issued to.

Can we see who changed something?

Yes. User record changes are captured field by field with the old value, the new value, who made the change and when. Issues keep their own history, every email send is logged, and assistant actions are recorded in the audit log.

Can you complete our security questionnaire?

Yes — send it over and the team will work through it with you. Enterprise deployments are set up with the team directly, including storage location and session policy.

See the access model on your own team

Create a workspace, invite a few people and build the roles your organisation actually uses. It takes minutes, and it is the clearest way to judge whether the model fits.

Create your workspace Talk to the team

Already using Matrix? Log in, or compare the plans.