Security

You trust estype with your content, your leads and your figures. This page explains how we look after them: where the data lives, who can reach it, how it is encrypted and backed up, and what we do when something goes wrong. It also says plainly what we do not offer yet.

• Hosting Google Cloud, Belgium (europe-west1). Backups in Finland.
• Isolation Each customer workspace in its own database.
• Credentials Encrypted with XChaCha20-Poly1305. API keys stored as hashes.
• Backups Continuous, 7-day point-in-time restore. Restore drills run.
• History Every content change logged with who made it. Any version restorable.
• Monitoring External uptime checks every 3 minutes, heartbeats on every job.

estype is provided by ELIM GROUP LLC. Questions about anything on this page go to security@estype.com.

1. Reporting a vulnerability

If you find a security problem in estype, write to security@estype.com. We acknowledge every report within 3 business days. What is in scope, how to test safely and the safe harbour we give researchers are in our Responsible Disclosure Policy. Our contact details are also published in machine-readable form at /.well-known/security.txt.

We do not run a paid bug bounty programme.

2. Compliance

Data protection (GDPR and UK GDPR)

For the content and records you keep in estype, you are the controller and we are your processor. Our Data Processing Addendum sets out what we may do with that data, the security measures we keep, how we tell you about a breach and how we use subprocessors. Our Privacy Policy covers the data we handle as a controller, such as your account and billing contacts. The current list of subprocessors is on the Subprocessors page.

Certifications

estype does not hold SOC 2, ISO 27001 or any other security certification today, and we have not commissioned a third-party penetration test. We would rather say so than imply otherwise. If your organisation needs a security questionnaire answered, write to security@estype.com and we will answer it in writing.

Our infrastructure provider

estype runs on Google Cloud. Google's infrastructure is independently audited against a range of standards, including ISO 27001, ISO 27017, ISO 27018 and SOC 2; the list and the reports are on Google Cloud's compliance page. Those audits cover Google's data centres and platform. They do not certify estype.

Payments

Every order is processed by Paddle.com, our Merchant of Record. Paddle takes the payment and holds the card details; we never receive or store card numbers. Paddle's own security and compliance are described in its privacy notice and its documentation.

3. Infrastructure and hosting

• Where. The service runs on Google Cloud in the europe-west1 region (Belgium). The data disk is a regional disk, written synchronously to two zones of that region, so the loss of one zone does not lose data. Continuous backups go to a second EU region, europe-north1 (Finland), and a weekly off-site copy is kept outside Google Cloud in Cloudflare R2 storage under its EU jurisdiction. Files uploaded to your content library are stored in Google Cloud Storage in Belgium. Files that applicants attach through a job-application form, where you use that module, pass through Cloudflare R2 storage on their way to your recruiting system.
• Physical security. We have no data centre of our own and no physical access to Google's. Google's controls for its buildings, hardware and network are described in its infrastructure security overview.
• Network. The host accepts web traffic only: HTTP and HTTPS over TCP 80 and 443, and HTTP/3 over UDP 443. Every other port is closed by the firewall. Administrative SSH is not open to the internet at all; it is reachable only through Google's Identity-Aware Proxy, which requires a signed-in Google identity with permission on the project.
• Operating system. The host runs Google's Container-Optimized OS, a minimal read-only system built to run containers. It updates itself, and we reboot into each update in a monthly maintenance window.
• Secrets on the host. Service secrets are kept in Google Secret Manager and handed to the service when it starts. They are not in the code, the container image or the repository. The service account the host runs as has access only to the storage buckets and secrets it needs.
• DNS and certificates. Our DNS is hosted by Cloudflare. TLS certificates are issued by Let's Encrypt and renewed automatically.

4. Customer isolation

Each customer workspace has its own database. Your content, leads, financial records and analytics settings are stored in that database and in no other customer's. A workspace has its own address (for example yourname.app.estype.com), and a signed-in session or an API key issued by one workspace means nothing to another.

Separate databases also keep backups and restores per customer: we can restore one workspace to an earlier point without touching anyone else's data.

5. Encryption

In transit

Every connection to estype, its API and every workspace is encrypted with TLS. Plain HTTP requests are redirected to HTTPS, and modern clients are served over HTTP/2 and HTTP/3. Our web server accepts TLS 1.2 and 1.3 only. The marketing site sends a Strict-Transport-Security header so browsers never fall back to an unencrypted connection.

At rest

Google Cloud encrypts the disks, snapshots and storage buckets we use at rest by default. On top of that, the credentials you give estype for your other services (bank and payment connections, API tokens, webhook secrets) are encrypted inside your database with XChaCha20-Poly1305, an authenticated cipher. The key that decrypts them is held outside the database and outside every backup, so a copy of a backup on its own does not reveal them. A stored credential is never printed back, not even to our own operators through the admin tools.

6. Authentication, keys and access control

Passwords and sessions

Passwords are stored only as argon2id hashes. A signed-in session is tied to the workspace that issued it.

API keys

• A key is shown once, when it is created. We store only its SHA-256 hash, so we cannot show it again and a database copy does not contain it.
• There are four classes of key, and the prefix says which: public (read published content), private (also drafts and exports), write (also changes, files and schema), and preview links that expire after 15 minutes. A key can never do more than its class allows.
• Each key can be limited to the website origins allowed to use it.
• Rotating a key issues a new one and keeps the old one working for 24 hours, so you can swap it without downtime. Revoking a key ends that overlap at once.
• Every API response is rate limited.

Roles

People in a workspace have one of four roles: owner, editor, viewer or restricted share. For each content type, the workspace's own rules decide which roles may create, read, update, delete and publish. Only an owner can change the content model. Access to analytics can be granted per dataset or per view, with an optional row filter. Shared report links are stored as hashes and can be revoked.

Agents and the command line

estype has no AI model inside it. When you connect your own agent through the command line or MCP, it acts with the keys you give it and within their class and role, and its changes are logged like anyone else's.

7. Audit trail and version history

Every change to content is written to a change log in the same transaction as the change itself, together with who made it: a person, an API key, the scheduler or an automated pipeline. Any earlier version of a document can be compared and restored. The individual saves are kept for 180 days, after which runs of older saves by the same person are folded into one entry; notes are kept for good.

8. Backups and recovery

Your workspace database is protected by four independent copies, each for a different kind of loss:

Every nightly copy is opened and checked after it is written; a failed or missing copy raises an alert. The weekly off-site copy is encrypted, checked against checksums, and readable only by our operators. Uploaded files are versioned: an overwritten or deleted file can be recovered for 30 days. Files do not yet have a copy in a second region.

We test restores rather than assume them. The latest drills, on 1 October 2026, restored every database from the continuous replica and a full disk from a snapshot, and checked each restored file for integrity and against the live data.

9. Availability

estype runs as a single service on one host. The disk survives the loss of a zone, and a failed deploy rolls back to the previous version automatically, but we do not offer a high-availability setup or a service level agreement unless one is agreed in writing. During an outage your data is safe in the backups above; the service is unavailable until the host is back.

10. Monitoring

• An external uptime service checks the API and the admin interface every 3 minutes from the EU, and warns us before a TLS certificate expires.
• The scheduler, the nightly backup, the continuous replica and the operating system updates each send a heartbeat. If one stops, we get an alert.
• Google Cloud Monitoring alerts us when the host stops responding or runs short of CPU, memory or disk.
• Inside the service, a failing connection to one of your sources, a delivery that keeps failing or a backup that did not complete raises an incident for us to act on.

11. Application security

• Written in Rust. The service is written in Rust, which rules out whole classes of memory-safety bugs such as buffer overflows and use-after-free.
• Pinned dependencies. Every library version is fixed in a lockfile, and third-party tools in the container image are pinned by version and checksum, so a build cannot pick up a changed dependency silently. Dependency updates are deliberate changes that go through the same checks as our own code.
• Checks before release. Every change must pass formatting, a linter with warnings treated as errors and the full test suite before it is deployed. A deploy waits for the new version to report healthy and puts the previous one back if it does not.
• Secrets out of logs. Credentials are never written to logs; command-line flags that carry one are redacted before logging, and a test fails the build if a new such flag is not covered.
• Signed webhooks. Webhooks we send are signed with HMAC-SHA256 and a timestamp, and webhooks we receive from connected services are verified before they are accepted, with a time window that rejects replays where the service signs its requests.
• Read-only analytics. Every analytics query runs in a transaction that is rolled back, so a report cannot change data.
• Website headers. This website ships a strict Content Security Policy built at deploy time, and refuses to be framed by other sites.

12. Our people and access to your data

Production is operated by a small team. Access is limited to the people who run the service, through their individual Google accounts; there are no shared administrator passwords, and SSH goes only through the Identity-Aware Proxy described above. We do not look at the content of your workspace except to provide support you asked for, to keep the service running or secure, or where the law requires it.

13. Incident response

When we detect or are told about a security incident, we:

1. contain it first: revoke keys, block access, take an affected part offline if needed;
2. find out what happened, which data and which customers are affected, using our logs;
3. tell affected customers without undue delay, and within 48 hours of becoming aware of a personal data breach affecting data we process for you, as our Data Processing Addendum requires, with what we know and what we are doing;
4. notify the relevant authorities where the law requires us to;
5. fix the cause, and share a written summary with the customers affected.

14. Data retention and deletion

You can export your content at any time. When you delete data, or when your subscription ends and the export window in our Terms of Service has passed, we delete it from the live service. Copies remain in the backups described above until they age out: up to 7 days in the replica and nightly copies, 14 days in disk snapshots and 8 weeks in the off-site copy. Old versions of uploaded files are removed after 30 days. If you need your data removed sooner, write to privacy@elim.io.

15. What we do not offer yet

So that you can plan around them, these are the things estype does not have today:

• no SOC 2, ISO 27001 or other certification, and no third-party penetration test report;
• no single sign-on (SSO) and no two-factor authentication;
• no high-availability setup and no standard uptime commitment;
• no second-region copy of uploaded files;
• no custom roles beyond the four described above;
• no paid bug bounty programme.

If one of these blocks you from using estype, tell us at security@estype.com. It helps us decide what to build next.

16. Your part

Security is shared. On your side, please:

• use a strong, unique password for every person in your workspace;
• give each person and each agent the lowest role and the narrowest key class that does the job;
• keep API keys out of code repositories and front-end bundles, except public keys;
• rotate a key when someone who had it leaves, or when it may have leaked;
• remove people who no longer need access, and check what your connected agents and integrations may do.

17. Contact

Security questions and vulnerability reports: security@estype.com. Privacy and data protection: privacy@elim.io. Legal notices: legal@estype.com.