What Nestarc Webhooks does to keep your data safe and what it does not yet promise.

Nestarc Webhooks is operated as an individual sole proprietor based in Republic of Korea. The legal entity, billing arrangement (Paddle.com Market Ltd as Merchant of Record), and forward incorporation roadmap are described in the Operating model section of the Reliability & Support Policy.

Data residency, backup encryption, and the EU-Korea adequacy basis are documented in the Data residency section.

The following controls are in place in the current production deployment. Each item below corresponds to a verifiable configuration in source or infrastructure code.

• Transport security: TLS 1.2 and 1.3 are the only protocols accepted by the public ingress (nginx). Cloudflare sits in front and terminates the edge TLS session; the origin termination is enforced separately with a long-lived origin certificate.
• Outbound webhook signing: Every payload delivered to a customer endpoint is signed with HMAC-SHA256 using the per-endpoint signing secret. The signature is placed in the request headers so that subscribers can verify authenticity before processing the payload.
• API key handling: Customer API keys are stored as SHA-256 hashes only; the plaintext key is shown once at creation time and never persisted. Authentication hashes the presented key and looks up the matching stored hash rather than comparing against a stored plaintext secret.
• Internal admin authentication: Dashboard access requires a Google or GitHub account plus organization membership. There is no separate password store and no shared-credential admin path.
• Backups: Database backups are written to an Amazon S3 bucket in the same AWS region (ap-northeast-2 / Seoul) with AES-256 server-side encryption applied by default. Public access to the backup bucket is blocked at the account and bucket-policy level.
• Application secrets: Production secrets (database credentials, third-party API tokens, signing keys) live on the EC2 instance filesystem with restricted permissions. They are not committed to source control and are not embedded in container images.
• Network ingress restriction: The EC2 security group accepts public traffic only from Cloudflare IP ranges, so direct origin access from the open internet is dropped at the network layer before nginx sees it.
• Open-source delivery engine: The webhook delivery engine (@nestarc/webhook (opens in new tab)) is published under the MIT license. Its retry, signing, and transport behavior is auditable in source so subscribers can verify the contract independently of the hosted platform.

Nestarc Webhooks does not currently hold any third-party security attestation. Pursuing formal certifications during public beta is intentionally deferred so that audit cost is not absorbed before paying customers exist to justify it.

The current intent for each common attestation:

• SOC 2 Type II: Planned. Will be initiated when the paying customer base warrants the audit cost (typically once revenue covers ~USD 15K per year of compliance-automation tooling and audit fees).
• GDPR Data Processing Agreement (DPA): Planned. A signable DPA template will be available before paid plans launch to support EU customer procurement.
• ISO 27001: Under consideration for the post-PMF roadmap, contingent on EU and APAC enterprise demand.
• HIPAA Business Associate Agreement (BAA): Not currently pursued. Nestarc is not positioned for U.S. healthcare workloads at this time. A BAA would require additional administrative, contractual, and operational controls; if a qualified prospect requires it, the request would be evaluated on a case-by-case basis.
• PCI DSS: Not applicable. Nestarc does not store, process, or transmit cardholder data. Payment-card data is handled exclusively by Paddle (PCI Service Provider Level 1) for paid plans; see the Privacy Policy for the processor relationship.

When a milestone above is reached, this section is updated to reflect the current state rather than the planned state.

The full vulnerability-disclosure policy, including the notification window, scope, and safe-harbor commitments for good-faith research, lives in the Security incidents section of the Reliability & Support Policy.

Reports may be sent to [email protected]. Machine-readable contact metadata is published at /.well-known/security.txt.

Live system health, scheduled maintenance, and resolved incident history are published at status.nestarc.dev (opens in new tab). Independent third-party uptime measurement is performed by an external monitor so that an outage in the primary application path cannot suppress its own reporting.

The Reliability & Support Policy documents response targets, incident-communication procedures, and the bus-factor and continuity posture during the current single-operator phase.