Security

The application and API are served over HTTPS (TLS). Session cookies are marked Secure.

Database and file storage encryption at rest is provided at the hosting layer; details are being confirmed with our infrastructure provider before we publish specifics.

Passwords are hashed with PBKDF2-SHA256 (200,000 iterations, per-user salt). Sessions use httpOnly, Secure, SameSite cookies. Google sign-in is supported. Email verification is required for new accounts.

Login, application, upload and other public endpoints are rate-limited.

Credentials and API keys are stored as environment secrets, never in source code or client bundles.

Uploads are checked for type, size and file signature; documents are parsed as data only — macros and embedded scripts are never executed.

Dependency updates and security reviews are performed as part of development. A formal vulnerability-management program is being documented.

An independent penetration test has not yet been completed.

Code review, automated tests and type-checking run before release. Formal SDLC policy documentation is in progress.

Organization roles (Owner, Admin, Recruiter, Hiring Manager, Interviewer, Viewer) and permission settings restrict who can view, export or act on candidate data. Internal MTestHub staff roles are separate and least-privilege.

Every customer record is scoped to its organization; APIs only return data for the signed-in organization. Candidates' applications are never shared with other employers.

MTestHub staff access to a customer workspace requires an authorized support session with a reason, is time-limited, visibly bannered and audit-logged.

SAML SSO for enterprise identity providers is planned.

Security-relevant actions — sign-ins, role and permission changes, exports, deletions, settings changes, support access — are recorded in an audit log available to organization administrators.

Application errors, latency and failed requests are monitored and grouped into issues for triage.

Organizations can export data and configure retention. Candidates can withdraw and request deletion from their portal.

Backup frequency, retention and restore testing are being documented. We do not publish RPO/RTO targets until they are defined and tested.

Incidents are tracked internally with severity, containment, investigation, notification assessment and post-mortem. Notification follows the obligations of the applicable law and contract.

A business continuity and disaster recovery plan is being defined.

Subprocessors are tracked in a registry with purpose, data categories, DPA status and review dates.