Last updated: 2026-09-11. Governing law: Israel.

Security and Technical & Organizational Measures

This page describes the technical and organizational measures EyalSec applies to the EyalSec / es2 Service. It is the public statement of our security posture, and it is incorporated into the Data Processing Agreement (/legal/dpa) as Annex II, satisfying GDPR Article 32 and Clause 8.6 of the Standard Contractual Clauses.

Published by Eyal Gabay, trading as "EyalSec", sole proprietor (osek murshe) no. 211868450, Israel. Security contact: security@eyalsec.com.

Honest framing. EyalSec is a small, independent business. The measures below are real and are described accurately, including where they are limited. We hold no third-party security certification (no ISO 27001, no SOC 2), and we do not claim one. If your procurement process requires a certification, tell us before you buy rather than after.

---

1. Data residency and hosting

• The Service runs on Amazon Web Services in the il-central-1 (Israel) region: the application, the database, and the artifact store.
• Israel benefits from an EU adequacy decision, so personal data can flow from the EEA to the Service without additional transfer safeguards. See Section 6 of the Privacy Policy.
• Transactional email is delivered through an Amazon SES endpoint in the EU.
• The full list of sub-processors is at /legal/subprocessors.

2. Encryption

| Where | Measure | |-------|---------| | In transit | TLS for every connection to the dashboard, the public site, the API and the agent ingestion endpoint. Certificates are issued and renewed automatically. Plain HTTP is redirected. | | At rest | The storage volume holding the database, artifacts and application state is encrypted. | | Backups | Automated database backups are encrypted before they leave the host, and are only ever stored encrypted. | | Credentials | Account passwords are stored with bcrypt. API keys are stored only as hashes. Two-factor secrets are encrypted at rest under a key held independently of the session key. |

3. Access control and authentication

• Dashboard: session-based authentication with optional two-factor authentication and backup codes. Sessions are revocable, and a change to an account's access revokes its stored sessions.
• Authorization: every capability is enforced on the server, not hidden in the page. Access is role-separated, and forensic and administrative surfaces are restricted to EyalSec staff accounts.
• Agents: each monitored machine carries its own credential. There is no shared master key in any distributed binary, so compromising one machine does not expose any other, and any single credential can be revoked without affecting the rest.
• Cross-tenant isolation: every query for event data is scoped to the owning account.
• Least privilege: administrative access to production is limited to what is necessary and is not shared.

4. Network and platform controls

• IP access control: an optional allow/block list can restrict which client addresses may reach the dashboard and the API. It is enforced on the connecting address and is hot-reloaded without a restart.
• Rate limiting and admission control on the event ingestion path, applied both globally and per credential, so one misbehaving agent cannot degrade the Service for others.
• Anti-CSRF protection on state-changing requests, and standard protections against injection through consistently parameterized database access, enforced by an automated build-time check.

5. Host and production hardening

• The application runs as an unprivileged service account under a sandboxed system service with no ability to gain new privileges.
• Program binaries are root-owned and not writable by the service account. The service can write only to its own data directory and to the database socket it connects through.
• The database is reached through operating-system-level authentication with no stored password, using a runtime role restricted to data operations only: it cannot alter or drop the schema. Schema changes run separately, as a distinct owner role, as an explicit deployment step.
• The production host carries no source code and no build toolchain. Only built artifacts are shipped to it.
• Hardening is re-applied and then re-verified on every deployment, and a failed verification fails the deployment. It is not a one-time setup step.

6. Secure development and release

• Every release is gated on automated checks that must pass before deployment: static analysis, the full test suite, a database-injection linter, and a known-vulnerability scan of all dependencies. A failing scan blocks the deployment.
• Changes are reviewed before release.
• Security-relevant configuration is generated from code and applied on every deployment rather than maintained by hand, so a host cannot drift away from its intended state.

7. Logging, monitoring and resilience

• Security-relevant events, authentication anomalies and captured application errors are recorded and reviewed, and are retained for a configurable period before automatic deletion.
• Uptime and health are monitored continuously.
• Automated encrypted backups are taken on a rotation cycle. Restores are exercised.
• Limitation, stated plainly: the Service runs on a single hosted instance. There is no multi-region failover and no contractual uptime commitment or recovery time objective unless one is agreed in a signed order (Terms, Section 11). Plan accordingly.

8. Data handling, retention and deletion

• All event data is scoped to the account that owns it.
• Customers control what is captured through monitoring configuration, filters and suppression. Event data is kept until the customer deletes it: deleting a machine deletes its events. A service-wide event retention window can also be applied, after which events are deleted automatically.
• Analytics, security incidents, captured errors and operational records each have their own configurable retention window, after which they are deleted automatically.
• Self-serve deletion: deleting an account cascade-deletes its machines, events and filters. Deletion is irreversible.
• Data may persist in encrypted backups for a short period after deletion, until the backup rotation purges it.
• Retention detail is in Section 7 of the Privacy Policy; deletion and return obligations are in Section 10 of the DPA.

9. Personnel

• Anyone authorized to process personal data is bound by confidentiality obligations.
• Administrative access follows least privilege.
• Limitation, stated plainly: EyalSec is operated by a very small team. There is no separate 24/7 security operations function, and there is a key-person dependency. We say so rather than imply otherwise.

10. Personal data breach response

If we become aware of a personal data breach affecting a customer's data, we notify that customer without undue delay, with the information available to us: the nature of the breach, the categories and approximate volume of data and data subjects affected, the likely consequences, and the measures taken or proposed. We provide further information as it becomes available and assist the customer with its own notification obligations. See Section 6(f) of the DPA.

Where we are the controller, we notify affected individuals and the competent supervisory authority as the law requires.

11. Vulnerability management and disclosure

We operate a coordinated vulnerability disclosure policy at /legal/vulnerability-disclosure, with a safe harbour for good-faith research. Report suspected vulnerabilities to security@eyalsec.com.

Dependencies are scanned for known vulnerabilities as a release gate (Section 6). Where a published release of an agent has known issues, we may publish them; customers are responsible for running the current published version (Terms, Section 9).

12. Security of the agents on your systems

The agents run inside your environment, and its security is yours (Terms, Section 6(d)). This applies to every agent: es-python, es-chromium, es-c, es-cpp, es-rust, es-node, es-solidity, es-bash and es-php. What we do on our side:

• Each machine is provisioned with its own credential at install time; no two machines share an identity and no shared secret is baked into a distributed binary.
• Installs use single-use, time-limited tokens tied to a specific machine and owner.
• Artifacts are delivered over TLS and verified against a published checksum before they are unpacked. Verification fails closed: an artifact with no published checksum is not installed.
• Credentials can be revoked at any time, and clone or tamper indicators are recorded.

What stays on your machine. Your source code, your project files, and the data your programs process are not uploaded. What travels to your dashboard is the detection event: the operation that fired, where it happened, where the data came from, and the value that triggered it. That value can itself be sensitive, which is why Section 6(b) of the Terms and Section 2 of the Privacy Policy say so explicitly and why the configuration controls exist.

13. Regulatory posture

• GDPR / UK GDPR: Article 28 processor terms and the SCCs are at /legal/dpa; Article 32 measures are this page.
• Israel: we comply with the Privacy Protection Law, 5741-1981 and the Privacy Protection (Data Security) Regulations, 5777-2017, and assess our obligations under Amendment 13 (in force 14 August 2025) on an ongoing basis. See Section 11 of the Privacy Policy.
• EU Cyber Resilience Act (Regulation (EU) 2024/2847): we are preparing for its obligations, including the reporting of actively exploited vulnerabilities and severe incidents that applies from 11 September 2026, and the wider requirements that apply from 11 December 2027. The coordinated vulnerability disclosure policy at /legal/vulnerability-disclosure is part of that preparation.
• No certification: as stated at the top of this page, we hold no ISO 27001 or SOC 2 attestation.

14. Questions, questionnaires and audits

Send security questionnaires and due-diligence requests to security@eyalsec.com. Audit rights, and their limits, are at Section 6(i) of the DPA.

15. Changes

We may update this page as the Service evolves. Material reductions in the measures described here will be notified to affected customers in advance, as the DPA requires.