Security overview

Draft for legal review. iCall has not launched. Controls marked "built and tested" exist in our code and pass our automated tests on test systems. They will be confirmed in production before the service is sold. Items marked "planned" are not built. Nothing here is a certification or an audit result.

1. Our approach

We design iCall so that one customer can never see another customer's data, so that call content is handled as little and as briefly as possible, and so that every sensitive access leaves a trace. We say plainly what is done and what is planned.

2. Where data is processed

• Database, sign-in and file storage (including recordings): Supabase in the AWS region eu-central-1 (Frankfurt, Germany).
• Live call audio, telephony and the campaign dispatcher: a dedicated voice host at Hetzner in Helsinki, Finland.
• Website, workspace and control API: Vercel, with server functions in the Frankfurt region.
• AI speech model: Google Gemini API. Processing location and contract terms are set out in the DPA.

The full list of subprocessors is in the DPA.

3. Separation between customers and access control

Status: built and tested.

• Every table exposed to the application is protected by row level security with default deny. A user sees only the rows of the company they belong to.
• Roles inside a customer account are viewer, manager and owner. Access to recordings and export are separate permissions.
• Permissions are read from the database on every request, never cached in a sign-in token, so removing a person takes effect at once.
• KCall support can see a customer's data only through a named, scoped access grant that expires after at most 30 days and is written to the audit log. The customer owner can issue and revoke a grant at any time. Today the database also lets a KCall platform administrator issue a grant without the customer's confirmation, so a grant does not always show the customer's consent [decide whether a platform administrator may issue a grant only after the customer agrees · to be confirmed].
• Platform administrator accounts need a second sign-in factor and have no standing permission to read customer data.
• The server-side privileged key is used only by code that first checks the caller's right to the specific company, and a test lists every module that is allowed to use it.

4. Recordings and files

Status: built and tested.

• Recordings sit in a private storage bucket with no direct client access. They reach a browser only through a short-lived signed link (60 seconds by default, never more than 5 minutes).
• Each link is issued only after a permission check against the database, and each issue is written to the audit log first. If the audit write fails, no link is issued.

5. Audit log

Status: built and tested.

Sensitive actions are written to an append-only audit log that cannot be edited or truncated by application users. Support access and recording access are recorded.

6. Encryption

• In transit: connections to the website, workspace and API use TLS [confirm TLS configuration and HSTS before launch · to be confirmed].
• At rest: data is stored on the hosting providers' encrypted storage [confirm provider encryption settings for the production project · to be confirmed].

7. Secrets and environments

Secrets are kept in a password manager and in the hosting provider's secret store. They are never committed to code. Production secrets are never placed on developer machines or test systems. Test systems use separate test data, and production data is never used in tests.

8. Voice and AI safeguards

Status: partly built. The first two items are implemented for the sandbox tools of the demo voice runtime and tested on test systems. For real customer integrations, and for every other item below, the safeguard is planned.

• The AI model can only call a fixed set of tools that we define. The server, not the model, checks the company, the caller's identification, the fields and the confirmation before any tool changes data.
• The assistant does not say that something was done without a confirmed receipt from the system it changed.
• Planned: a caller's phone number alone will never be enough to release private information. Each integration will state which information is public and which needs extra identification.
• Planned: spending limits, call length limits and concurrency limits will be enforced by the platform, not by the AI instructions.
• Technical logs must not contain call content or full personal details.
• Planned: phone verification codes will be rate limited per number, per browser and per address, will expire after 5 minutes, and will never be written to telemetry.

9. Engineering practices

We require independent review and automated tests for changes before they are released, with extra review for changes to sign-in, permissions, payments and telephony. We validate all external input, sign and verify webhooks, and use idempotency keys so that a repeated message cannot repeat an action.

10. Backups and recovery

Our internal recovery targets are a restore time of 4 hours and data loss of no more than 24 hours for the first customers. These are targets that we will measure, not commitments. Regular backup and restore tests are planned [confirm the backup plan and test schedule before launch · to be confirmed].

11. Incidents and vulnerability reports

We follow the incident notification commitment. To report a vulnerability, write to [security contact email · to be confirmed]. Please give us reasonable time to fix a problem before you publish it, and do not access other people's data. We will not take legal action against good faith research that follows these rules [confirm the vulnerability disclosure promise with counsel · to be confirmed].

12. Certifications and audits

iCall holds no security certification today. It does not have ISO 27001 or SOC 2 certification and we do not claim it does. An external penetration test and a certification path are planned but not scheduled [decide whether to commit to a date · to be confirmed].

13. What is planned

• Item

  Row level security, role model, audit log, short-lived recording links

  Status

  built and tested on test systems, to be confirmed in production

• Item

  Second factor for customer owner accounts

  Status

  planned

• Item

  Phone verification limits, platform-enforced spend and call limits, mandatory AI statement in greetings

  Status

  planned

• Item

  Public status page and incident history

  Status

  planned

• Item

  Regular backup and restore tests

  Status

  planned

• Item

  External penetration test

  Status

  planned, not scheduled

• Item

  Security certification such as ISO 27001

  Status

  not held, no date set

• Item

  Staff security training and access reviews

  Status

  planned