Incident response

Incident response plan and support targets

EntryLayer maintains an incident response process for security reports, Marketplace review follow-up, package issues, and support requests. These published targets describe acknowledgment timing, escalation, customer communication, and post-incident review.

Intake

How to report an issue.

Security, support, and Marketplace review issues can be sent to the support and security contact below. Existing customers may also use the established Snowflake Marketplace or direct support case path.

Support and security contact [email protected]

Include the product surface, severity, package version if known, affected account or listing context, reproduction steps, timestamps, and any redacted Snowflake outputs that help triage the issue.

Published response targets

Severity levels and acknowledgment targets.

These are acknowledgment and communication targets, not guaranteed remediation times. Actual remediation depends on severity, affected scope, customer-controlled configuration, Snowflake review requirements, and whether a package update is required.

Severity
Category
Examples
Acknowledgment
Update cadence
Sev 1
Critical security incident
Confirmed or strongly suspected unauthorized access to EntryLayer-controlled systems, active exploitation of a critical vulnerability, or an issue that materially affects multiple customers.
4 business hours
At least once per business day while active, or more often when material facts change.
Sev 2
Material security or availability issue
A high-risk vulnerability, degraded Marketplace package behavior, or issue that blocks important product workflows for an affected customer.
1 business day
At least every 2 business days while active.
Sev 3
Standard support issue
Configuration questions, access diagnostics, documentation clarification, or non-critical product defects.
2 business days
As investigation milestones are reached.
Sev 4
General request
Procurement, product questions, enhancement requests, and non-urgent review follow-up.
3 business days
As needed.

Response process

How incidents are handled.

The process is designed for a Snowflake Native App model where the reviewed package is provided by Formless Logic, while runtime and customer data remain in the customer Snowflake account.

1. Triage

Confirm the report, assign severity, identify affected surfaces, and preserve relevant evidence such as package version, deployment state, support artifacts, and customer-provided Snowflake outputs.

2. Containment

Reduce immediate risk through configuration guidance, code changes, package updates, Marketplace communication, or customer-side mitigation steps when applicable.

3. Investigation

Determine root cause and affected scope using internal development records, CI/CD evidence, package artifacts, support communications, and Snowflake-visible evidence shared by the customer.

4. Recovery

Validate the fix, publish or coordinate any required package update, and confirm that affected customers have a clear path back to normal operation.

5. Review

Document root cause, customer impact, corrective actions, and prevention work. Track follow-up work through the same engineering workflow used for product changes.

Covered surfaces

Incident response scope

  • EntryLayer Snowflake Native App package, manifest, setup SQL, SPCS service specification, and container images.
  • EntryLayer application code, CI/CD evidence, dependency posture, and security-review artifacts.
  • Marketplace listing, support communications, and paid billing event logic.
  • Customer-provided Snowflake outputs that are intentionally shared for diagnosis.

Boundary

Customer and third-party scope

  • Customer-owned Snowflake account administration, warehouses, roles, databases, tables, masking policies, row access policies, or network configuration outside EntryLayer setup guidance.
  • Third-party incidents in Snowflake, GitHub, Stripe, email providers, or other independent service providers, except where coordination is needed for EntryLayer support.
  • Customer source data that remains inside the customer Snowflake account and is not shared with Formless Logic for support.

Customer notification

Affected customers are notified when impact is confirmed.

  • Customers are notified without undue delay after Formless Logic confirms an EntryLayer security incident and determines that the customer may be affected.
  • Notifications are sent through the available customer contact path, which may include direct email, Snowflake Marketplace support communication, or the channel already established for the review or support case.
  • Notifications include known impact, affected product surface, recommended mitigation steps, current status, and expected next update when those facts are available.

Zero-access context

Normal product use does not create a provider-side source-data store.

EntryLayer's incident response process reflects the Native App architecture: application runtime and customer source data stay inside Snowflake. Formless Logic investigates provider-controlled code, package, dependency, billing, listing, support, and release evidence, plus any redacted customer evidence that is intentionally shared for diagnosis.

View architecture diagram

Questionnaire answer

Published incident response plan URL

For security questionnaires, EntryLayer can answer that it maintains an incident response plan with published acknowledgment targets and customer notification practices.

https://entrylayer.ai/security/incident-response