Security and Trust

Last updated: 2026-04-28. Effective from: 2026-04-25.

Operator. The Service is operated by ФОП Даценко А.В. (A.V. Datsenko, sole proprietor registered in Ukraine), РНОКПП 3339403456 ("CallPing", "we", "us"). Mailing address: Plytkova str. 65/106, Kharkiv, Kharkivska oblast, 61047, Ukraine. Security reports: [email protected]. For everything else, see the Contact page.

Our Approach

CallPing places phone calls on your behalf when something goes wrong with a system you operate. That means we sit on the alerting path between your monitoring and the people you trust to respond. We take the responsibility seriously.

This page is a plain-English summary of how we protect your data and account. It is not an exhaustive technical specification.

Encryption

• In transit. All traffic between your browser, our API, and our infrastructure is encrypted with TLS. The same applies to traffic between our backend and our SIP trunk providers.
• At rest. User data is stored in Cloudflare D1 with platform-managed at-rest encryption.
• Passwords. Account passwords are hashed with PBKDF2 before storage. We do not store plaintext passwords. We have no way to recover a lost password — only to reset it via your verified email.

Authentication

• JSON Web Tokens (JWT). Sessions are represented as custom JWTs signed with HMAC-SHA256. The JWT secret is held server-side and never leaves the API.
• HttpOnly cookies. JWTs are delivered to the browser as HttpOnly, Secure cookies with the __Host- prefix. They are not accessible to JavaScript and cannot be exfiltrated by a successful XSS without compromising the cookie itself.
• CSRF protection. Mutating endpoints require a CSRF token in addition to the session cookie.
• Optional TOTP two-factor authentication. Users can enable RFC 6238 TOTP. The QR code is generated client-side; the TOTP secret is never sent to a third-party rendering service. Brute-force protection limits TOTP challenges to a small number of attempts before the challenge token is invalidated.
• Session caps. Sessions last up to 24 hours by default, or 7 days if "Stay logged in" is selected at login. There is an absolute 90-day cap based on the session's creation timestamp.
• Step-up reauthentication. Destructive operations (password change, removing a team member, deleting a project, toggling phone numbers, etc.) require a recent password reauthentication, even on a valid session.

Infrastructure

CallPing runs on Cloudflare's global edge network:

• Cloudflare Workers for the API and core logic.
• Cloudflare Pages for the user portal, admin panel, and status page.
• Cloudflare D1 (SQLite) for persistent data, in two isolated databases (user data and admin data).
• Cloudflare KV for caches, rate limits, and short-lived session state.
• Cloudflare Queues for asynchronous call delivery.
• Cloudflare R2 for object storage (used by the email worker).

Cloudflare provides global DDoS protection and runs the network on which our application executes. We additionally apply Content Security Policy (CSP) headers, restrictive CORS defaults, and security headers across all responses.

Multi-Region SIP Failover

Phone calls are placed via a fleet of self-hosted Asterisk PBX servers, geographically and providerwise diverse:

• PBX-1 / PBX-2 — Oracle Cloud (EU regions), Zadarma SIP trunk.
• PBX-3 — AWS (us-east-1), Twilio SIP trunk.
• PBX-4 — Google Cloud (us-east1), Intertelecom SIP trunk.
• PBX-5 — Azure (Korea Central), Telnyx SIP trunk.

A health-aware registry routes each call to a healthy PBX in round-robin order. If a SIP trunk fails, the call is automatically retried on a different PBX with a different trunk. This is intended to reduce the impact of any single provider or region outage on alerting.

SLA framing.

We operate the Service on a commercially reasonable best-effort basis. No specific uptime target is guaranteed and no service credits are issued for downtime on the Solo or Team self-serve plans, consistent with Terms of Service §7a. A commercial SLA with service credits and a defined uptime target is available for Enterprise tier customers — contact us to discuss.

Public uptime data is available at status.callping.app.

Audit Logging

User-facing actions that affect account or organization state are recorded in an audit_log table:

• Organization switching, joining, and leaving.
• Project creation and deletion.
• Phone-number toggling (active/inactive).
• Membership changes.

Rows are retained for 90 days, then deleted by an automated cron job.

Network and PBX Hardening

• ARI ports on all five PBXes are restricted to Cloudflare's published IP ranges only.
• fail2ban runs on all PBXes to throttle SIP scanning and brute-force attempts.
• systemd hardening addresses a stale-PID-file failure mode that previously caused a PBX outage.

Vulnerability Disclosure

We welcome responsible disclosure of security issues from researchers and users.

Reporting. Send vulnerability reports to [email protected]. The mailbox is provisioned via Cloudflare Email Routing and routed to a monitored support workflow. We acknowledge security reports within two (2) business days and aim to provide an initial assessment within five (5) business days for credible reports. We do not currently publish a PGP key.

In scope:

• Production CallPing API endpoints (api.callping.app)
• User portal (my.callping.app)
• Admin panel (admin.callping.app)
• Public status page (status.callping.app)
• Marketing website (callping.app)
• The CallPing email worker that handles support@, privacy@, security@, abuse@, and catch-all delivery

Out of scope (these are operated by third parties; please report directly to them):

• Cloudflare's own infrastructure (Workers, D1, KV, Queues, R2, edge network) — Cloudflare's HackerOne program is the right channel.
• Third-party SIP trunk providers (Zadarma, Intertelecom, Twilio, Telnyx) — report to the relevant provider directly.
• Paddle's checkout flow and payment processing — Paddle's own security disclosure handles their domains.
• Self-hosted Asterisk PBX servers run on Oracle Cloud, AWS, GCP, and Azure: the cloud-provider layer (hypervisor, host OS) is out of scope; the Asterisk configuration we control is in scope.

When you report:

• Please give us a reasonable time to investigate and remediate before any public disclosure. The default expectation is 90 days from confirmed receipt of your report, with extensions on request for complex remediation.
• Please do not access, modify, or delete data belonging to other users. If you encounter such data accidentally during testing, stop and report it.
• Please do not perform denial-of-service testing, social-engineering attacks against our staff or vendors, or physical attacks against any infrastructure.

Safe-harbor commitment. When you act in good faith and within this policy, we will not pursue legal action, civil claims, or law-enforcement referral against you for your research. We treat your good-faith research as authorised access for the purposes of computer-misuse laws in the jurisdictions in which we operate (including, without limitation, the Law of Ukraine on Information Protection in Information and Telecommunications Systems and equivalent rules in EU member states and the UK). If you are uncertain whether a particular activity is authorised, ask first via [email protected].

We do not currently operate a paid bug-bounty program. We may launch a coordinated program (HackerOne, Intigriti, or equivalent) once paid plans are stable; until then, public credit and a thank-you in our security acknowledgements page are the recognition we offer for substantive reports.

Payment Data Security

Paid Plans are processed by Paddle.com Inc. ("Paddle") as the merchant of record. The security boundary for payment data is the same as the data boundary described in the Privacy Policy §2.3:

• CallPing does not store, view, or have access to your full payment card details. Card number, CVV, and full expiry never traverse CallPing infrastructure. Card data is collected and processed by Paddle on its own checkout domain.
• CallPing receives only limited transactional metadata from Paddle, used solely for invoicing, fraud-prevention, tax determination, and dispute-handling: the last 4 digits of the card number, expiry month/year, card brand, billing country, billing postal code, VAT/tax ID (where applicable), subscription status, and Paddle transaction identifiers.
• PCI-DSS scope. Because we do not process or store full card data, CallPing is not in scope for PCI DSS. Paddle is a PCI-DSS Level 1 service provider; their compliance status is published at paddle.com/security.
• Webhook signature verification. Paddle's webhook events that drive subscription state changes are verified by HMAC signature before any account state mutation. Replay protection is enforced through an idempotency table, so re-delivered webhooks do not double-grant access or double-charge.

Compliance and Certifications

CallPing does not currently hold any external compliance certifications (such as SOC 2 or ISO 27001). Because Paddle handles the PCI-DSS-protected card data, CallPing remains out of scope for PCI DSS. We will revisit a SOC 2 readiness program once Enterprise-tier demand justifies the investment; Enterprise customers requiring attestation should contact us to scope timing.

Data Privacy

Security is one part of how we protect your data. The other part — what we collect, why, and how it can be deleted — is covered in the Privacy Policy.

Updates to This Page

We will update this page as our security posture evolves and as new controls or certifications are added. The "Last updated" date at the top of this page reflects the most recent revision.