Security

This page describes how we protect the platform and the data entrusted to us. It is written without overstatement: we say what we do, and also what we do not do yet.

Isolation between organizations

This is the single most important measure in a product where many companies share the same infrastructure.

Each organization has its own data space, and that isolation does not depend on application code remembering to filter: it is enforced in the database with PostgreSQL row-level security. Every query runs in the context of a user who can only see rows belonging to the organizations they are a member of; if a query forgot its filter, the database still would not return anyone else’s data.

That isolation is tested automatically: the test suite includes cases that try to reach another organization’s data and are expected to fail.

Encryption

• In transit: all traffic runs over TLS, both the application’s and the third-party integrations’.
• At rest: the database and stored files are encrypted.
• Files uploaded by users — attachments, recordings, signed documents — are served through temporary signed links, not from permanent public addresses.

Identity and access

• Identity is handled by Amazon Cognito: passwords never pass through our servers and are never stored in our database.
• Two-factor authentication is available on every account, using time-based codes.
• Inside each organization, permissions are role-based, and sensitive sections are restricted to administrators.
• Sessions expire and can be revoked.

Third-party credentials

Connected-platform tokens, artificial intelligence keys and telephony credentials are stored encrypted in AWS Secrets Manager, separated by organization and environment, and resolved at the moment of use. They are not kept in the database or in the code.

Backups

We take regular backups with rotation. Backups are encrypted too and roll off within 90 days, which is where that deadline in the data deletion policy comes from.

Development

• Code is reviewed before reaching production.
• There are automated tests, including the cross-organization isolation tests above.
• Infrastructure is defined as code, so changes are versioned and reviewable.
• Dependencies are updated regularly.
• Public forms are protected against automated submissions.

Our team’s access

Access to customer data is limited to the people who need it to operate the service or handle a support request, with least privilege and under a duty of confidentiality. Access is logged.

Incidents

We have a response procedure covering detection, containment, analysis and communication.

If a security breach affecting personal data were to occur, we will notify the affected organizations without undue delay, with the information they need to meet their own obligations, and within the deadlines applicable law requires.

Reporting a vulnerability

If you found a security problem, write to info@meruma.app with “Security” as the subject. We appreciate responsible reports: please give us reasonable time to fix it before going public, and do not access third-party data or degrade the service while investigating.

We do not run a bounty programme at this time.

What we do not have yet

We would rather say it before you ask: meruma does not currently hold SOC 2 or ISO 27001 certification, nor published external security audits. It is a young company and those certifications are a goal, not a fact. Everything described on this page is implemented and can be verified in a technical conversation.