Security

Version 1.2 · 04.10.2026

This page describes how we protect data in Quanty. We state only what we can point at in the system. We hold no security certification and we do not claim to be "GDPR compliant", because compliance also depends on how the controller uses the system. What follows is a description of measures, not a declaration.

1. Where Quanty runs

The application and database run in Amazon Web Services, eu-central-1 Region (Frankfurt, Germany), since 13.09.2026. Customer files are stored in the same Region.

The system previously ran on a server in Poland. The claim "servers in Poland" is out of date and has been removed from the site.

Server access is only through AWS Systems Manager Session Manager. There is no open SSH access.

AI features in the application run on Amazon Bedrock. AI Secretary calls are handled in Amazon Web Services in the EU: Amazon Transcribe, a Claude model on Amazon Bedrock and Amazon Polly. Details and transfer safeguards are at /subprocessors.

2. Encryption

Traffic between the browser and the server is encrypted with TLS.

Database data, object storage files and backups are encrypted at rest.

Integration access tokens and mailbox passwords are stored encrypted and are never shown again after entry.

We do not claim end-to-end encryption. Data has to be decrypted for the system to process it.

3. Separating customer data

Every organization has its own data space. The separation is enforced by the application layer on every database query.

The organization identifier comes from the signed-in user’s session, not from request parameters, so data belonging to another organization cannot be reached by swapping an identifier in a URL or request body.

The separation is covered by automated tests run before every deployment.

Sign-in is handled by Amazon Cognito. Passwords are stored only as hashes.

A second factor is required for admin accounts and for sensitive operations such as changing security settings or deleting an account. It comes in two forms and a person can hold both at once.

An authenticator app (TOTP): a one-time code valid within a narrow time window. A code that has been used cannot be used again, and after a run of wrong attempts the factor is locked out for a cooling-off period.

An SMS: a six-digit code sent to a phone number the user registered themselves. The code is stored hashed, expires after 5 minutes, works once, and sending is limited by a cooldown between codes and a daily cap. The number is shown back to the user only masked. The messages are sent by AWS End User Messaging SMS in the eu-central-1 Region (Frankfurt).

The authenticator app is stronger than SMS and it is the one we recommend. An SMS crosses the mobile operator’s network and is exposed to number takeover (SIM swap) and to interception in the signalling network. We offer SMS because it is better than no second factor, not because it matches the app.

When a second factor is switched on, the user is given recovery codes. Each works once, they are stored hashed, and generating a new set invalidates the previous one.

If someone loses their phone or their authenticator app, a platform administrator can unlock a locked factor, revoke sessions, reissue recovery codes or reset the factor so it can be set up again. We do that only after confirming the person’s identity through a channel other than the account in question. Every such action is written to the record described in section 9, which cannot be changed or deleted from inside the application.

Sessions expire, and they are invalidated immediately on sign-out and on a password change.

5. Our staff access

Our staff have no standing access to customer data.

Support access is granted for a fixed period, 7 days by default and 30 days at most. It expires automatically.

The customer sees active support access in the organization panel and can revoke it at any time.

Everyone with access holds a written authorisation and a confidentiality undertaking. We keep a register of authorised people.

6. Backups

The database runs on Amazon RDS with automated backups. Backups are encrypted and stay in the same EU Region.

We have not yet carried out a documented restore test. We plan one and will publish the result in the customer pack, rather than claim a test that has not happened.

7. Retention and deletion

Deleting an account moves it to an archived state for 180 days so it can be restored after a mistake, after which the data is permanently deleted.

The processing copy of a message fetched from a connected mailbox is deleted after 14 days.

The AI Secretary does not record call audio. The transcript is kept in Quanty for the period the organization sets, 30 days by default.

Call data can be deleted item by item from the application.

After the contract ends we delete data from production systems, and from backups as they are overwritten, within no more than 90 days.

8. Integrations and webhooks

Incoming messages from external systems, including payment events and post-call events, are signed, and we verify the signature before processing. A message without a valid signature is rejected.

Outgoing and incoming mail goes through Amazon SES in the EU Region.

9. Audit of platform actions

Platform admin actions are written to a separate record: who did what and when.

The record also covers account recovery: unlocking a second factor, revoking sessions, reissuing recovery codes and resetting a factor.

Sign-in events and permission changes are logged. Logs are kept for up to 12 months, longer only where they relate to an incident under investigation.

Extending the record to events on call data, with an export for the customer’s data protection officer, is planned.

10. Software development

Code changes go through review and a set of automated tests run before deployment.

Production and test environments are separate, with separate databases and separate credentials.

Secrets are kept outside the code repository.

11. What we do not claim

We hold no ISO 27001, ISO 27701, ISO 42001 or SOC 2 certificate, and no certification under art. 42 GDPR. Our infrastructure providers hold certificates; those are not ours.

We are not "HIPAA compliant" and we do not sign BAAs. That is US law and it is not relevant to Polish clinics.

We do not claim that data never leaves the European Union. The cases where it does are described in the privacy policy and at /subprocessors.

We do not claim that we keep no transcripts or recordings. Transcripts are kept for 30 days by default.

12. Reporting a vulnerability

If you found a vulnerability, write to dawid@pluscode.io with a description, steps to reproduce and the impact. We acknowledge within 3 business days and keep you posted.

Please do not disclose a vulnerability publicly before we fix it, do not download or delete anyone else’s data, and do not run load tests or denial-of-service attacks.

We run no bug bounty. We are grateful for reports and, with the reporter’s consent, credit them.

The same information is available in machine-readable form at /.well-known/security.txt.