Guide: Security Review Pack

This page is the short-form security review material for design partners and controlled pilot customers. It is not a certification report, SOC 2 report, DPA, or legal promise. It is the current technical baseline, the known limits, and the workloads Syllecta is willing to accept before broader enterprise compliance work is complete.

Summary

Syllecta is built around webhook and retryable-operation reliability. The security model is metadata-first: routine recovery should work from provider, event id, status, timing, retry state, failure reason, callback result, and correlation ids. Payload content is treated as sensitive debug/replay data with explicit storage policy and retention boundaries.

Current production baseline:

Supported provider signatures are verified before forwarding.
Tenant users are scoped to tenant data.
API keys are one-time reveal and stored as hash-backed records.
Webhook provider secrets are masked in APIs/UI and encrypted at rest for new writes.
Dashboard payload views are redacted.
Tenant payload policy can be metadata_only, redacted_payload, or raw_debug_window.
Raw replay is blocked when raw payload is not stored or the debug window expired.
Production callback URLs must be public HTTPS and cannot resolve to private, loopback, link-local, or reserved IP ranges.
Public webhook ingress has body caps, content-type checks, malformed JSON handling, rate limits, and structured security events.
API traffic has a baseline app-level shield: scanner-path fast rejection, body/timeouts, security headers, private surface no-index headers, replay throttles, and dashboard query bounds.
Retention jobs scrub operational debug data but do not delete financial ledgers, audit logs, users, tenants, API keys, webhook secrets, settings, or plans.

Questionnaire Answers

Topic	Current answer
Data stored	Tenant/account records, users, API key metadata, webhook secret metadata, webhook operational metadata, optional webhook payload/debug data depending on tenant payload policy, callback delivery status, job history, audit logs, usage/billing records, and operational security events.
Payload storage	`metadata_only` stores no payload body. `redacted_payload` stores a redacted payload/header view. `raw_debug_window` stores raw payload/headers temporarily for replay/debug and exposes redacted views to the dashboard.
Data minimization	Product workflows are designed to work from operational metadata first. Customers should avoid sending card data, passwords, tokens, session cookies, long-lived secrets, full customer profiles, or unnecessary personal data.
Encryption in transit	Browser, API, provider webhook, and callback traffic should use HTTPS/TLS in production.
Encryption at rest	Production database, queue, volume, and backup encryption posture must be confirmed as part of production readiness and customer agreement. Webhook secrets are encrypted at the application layer for new writes.
Secret handling	API keys are one-time reveal and hash-backed after creation. Webhook secrets are masked in tenant/admin APIs, rejected when obviously weak, encrypted for new writes, and exposed only to the internal verification path.
Access controls	Tenant users are scoped to their tenant. Admin/super-admin access is reserved for operational, billing, and security work. Support access should be tenant-scoped, reasoned, time-limited, and audit logged.
Audit logs	Credential changes, tenant/user changes, replay actions, support access, retention changes, and sensitive operational actions should be audit evidence. Generic retention cleanup does not delete audit logs.
Retention	Raw webhook payloads default to a short debug window. Webhook metadata, synthetic events, simulations, job history, reconcile diagnostics, and financial/audit records have separate retention classes documented in the data-retention guide.
Traffic protection	Security throttles are separate from plan quotas. Obvious scanner routes are rejected before app routing, invalid webhook traffic is dropped before queue/storage, valid high-volume traffic should use tenant/provider sizing and queue/backpressure rather than one global cap.
Incident reporting	Vulnerability reports use the public vulnerability disclosure page. Customer-impacting incidents use the agreed pilot/support channel until binding support terms are finalized.
Subprocessors	Current subprocessor/data-flow baseline is documented under Legal > Subprocessors. Customer-specific notice periods, regions, and DPA exhibits require written agreement.
Compliance status	Syllecta does not currently claim SOC 2, ISO 27001, HIPAA, PCI, or GDPR compliance certification. Compliance packaging and formal DPA review are contract work for larger regulated deployments.
Production limitations	No public claim is made for customer-managed keys, static outbound IPs, audited backup isolation, formal restore SLA, regulated workload certification, or unlimited traffic capacity. These must be reviewed before accepting those workloads.

Data Flow

text

Provider
  -> Cloud API webhook ingress
  -> signature verification, body/content-type/rate checks
  -> dedupe and normalized event
  -> queue: log job + forward job
  -> Backoffice storage: metadata + payload according to tenant policy
  -> forward worker callback delivery
  -> tenant application
  -> dashboard: event status, redacted payload view, retry/replay controls

Step	What exists there	Raw payload?	Redaction?	Secrets used?
Provider request to Cloud API	HTTP headers/body, provider signature	Yes, in request memory	No	Provider signing secret is fetched for verification
Ingress validation	Body cap, content-type, malformed JSON, rate-limit and signature checks	Yes, only while processing	No	Webhook secret used by adapter verification
Queue log job	Event metadata, headers/body required for persistence	Depends on tenant policy and suspended state	Policy-aware persistence happens in Backoffice	No customer secret should be exposed to queue payloads
Queue forward job	Normalized event and delivery target context	Yes when forwarding a real stored event	No, callback receives normalized provider payload	Callback URL config used for delivery
Backoffice storage	Event metadata and optional payload/debug record	`metadata_only`: no. `redacted_payload`: no raw. `raw_debug_window`: yes until expiry	Redacted payload copy is stored/exposed for UI	Webhook secrets are encrypted/masked outside verification path
Callback delivery	Normalized JSON sent to tenant callback endpoint	Provider payload may be included inside normalized event	No customer-side redaction is applied at delivery	No signing secret is sent
Dashboard	Status, timing, reason, correlation id, payload tabs	No raw payload by default dashboard API	Yes, routine views use redacted payload/header data	Secrets are masked
Manual replay	Stored raw payload is re-normalized and re-enqueued	Only if raw debug window is active and not expired	Replay uses raw data internally; UI remains redacted	Internal service auth protects replay endpoint

Suspended tenants are a special path: valid signed webhooks are acknowledged with 2xx, no callback delivery is enqueued, and raw provider payload is not stored. Syllecta records only minimal metadata/status evidence.

Pre-Pilot Checklist

Control	Status	Pilot requirement
Callback URL validation and SSRF protection	Done	Required before any production callback traffic.
Session hardening	Done for current baseline	Required before tenant console access.
Provider verification matrix	Done	Customer must use supported provider modes only.
Retention matrix	Done	Customer must choose payload policy and retention expectations before launch.
Public security and data-protection docs	Done	Must be shared during onboarding.
Credential hardening	Done for current baseline	API keys must be one-time reveal/hash-backed; webhook secrets masked/encrypted for new writes.
Webhook ingress abuse controls	Done for current baseline	Body caps, content-type validation, rate limits, and security events must be enabled.
Traffic protection baseline	Done for current baseline	Scanner-path fast rejection, app body/timeouts, private no-index headers, replay rate limits, and query caps must remain enabled.

Decision Log

Ready for controlled pilot:

Webhook reliability workloads using supported provider signatures.
Retryable/idempotent API operation workloads that do not require regulated-data certification.
Payload policies of metadata_only, redacted_payload, or short raw_debug_window after customer review.
Production HTTPS callback delivery to public endpoints that pass callback URL safety checks.

Known limitations:

No SOC 2, ISO 27001, HIPAA, PCI, or GDPR compliance certification claim.
No customer-managed key feature.
No guaranteed static outbound IP feature in the first production baseline.
No public formal restore SLA or audited backup-isolation report.
Dual-secret overlap for smoother webhook secret rotation is still planned.
Traffic capacity must be sized and tested for the specific customer workload before high-volume launch.

Not accepted for early customers without a written review: