the honest version. noctara is not currently soc 2 certified. here is exactly what that means, what controls are already in place, and the path to a certificate when a deal justifies the spend.
noctara is not presently soc 2 certified, and we are not in an active audit. we say that plainly because the alternative is to imply something untrue, and an enterprise security team will find that out in five minutes. what we have is an audit-ready posture: the controls a soc 2 audit examines are already operating today. the certificate is the part we have not yet bought, and we will buy it when an engagement makes the investment worth it.
soc 2 is not a checkbox or a badge you grant yourself. it is an independent examination performed by a licensed cpa firm, conducted against the aicpa trust services criteria. the firm tests an organization against five criteria: security, availability, confidentiality, processing integrity, and privacy. they issue an opinion. a type i opinion attests that the controls are designed appropriately at a point in time. a type ii opinion attests that the controls operated effectively over a period of months. neither is something a company can produce for itself. the value of soc 2 is precisely that we did not write it.
so when a vendor tells you they are soc 2 certified, the real question is which type, by which firm, covering which criteria, and over what window. we would rather show you our controls now and let you verify them than hand you a claim we cannot back.
below is how noctara's current, operating controls line up against each of the trust services criteria. these are the same control areas an auditor walks. nothing here is aspirational. it is what runs in production today.
tls 1.2 or higher in transit, aes-256 at rest via managed postgres. row-level security scopes every record to its owner. identity grant tokens are hmac sha-256 signed, scoped to the requesting application, and revocable by the user. background and scheduled jobs are gated on a bearer secret, never on a spoofable header. service credentials follow least privilege: each integration holds only the scope it needs, and payment and behavioral data never share a key. the consumer surface runs no third-party trackers.
noctara runs on managed cloud providers that each carry their own uptime commitments and their own soc 2 reports: vercel for hosting, supabase for the database, stripe for payments. we inherit their availability engineering rather than reinventing it on a small team. our application layer is stateless and horizontally scaled by the platform. we monitor a health endpoint and surface incidents through the same notification path used for security events.
the architecture is built to hold the least it can. keystroke timing is captured and reduced to behavioral aggregates on the device; raw text and raw timing streams are not shipped to or stored on our servers. noctara never touches a card number, because stripe handles payment data end to end and returns only a subscription status. confidential customer and participant data is access-controlled per user and per organization, and the separation between systems is structural, not a policy we promise to remember.
processing is deterministic and logged. inputs are validated at the api boundary, writes are idempotent where a retry could otherwise duplicate, and webhook events from stripe are verified by signature and timestamp age before they are allowed to change anything. each meaningful step emits an event record, so the path from input to result is reconstructable. customer-initiated deletion executes immediately and is recorded.
privacy is consent-gated and code-enforced. individual-level data is only exposed after an explicit, recorded consent, not an assumed one. data-subject rights are real and self-serve: a person can revoke a grant, export, or delete from their own dashboard, and deletion hard-removes the personal-data tables within the same request. we do not sell data, and we do not train models on private participant text without explicit consent. these refusals are written into the architecture, not just the policy.
we are not pretending the work is finished. a certificate requires steps we have deliberately sequenced behind real demand, so we spend the money when it returns the most value. the path is short and conventional.
the controls above are documented in more detail across our trust surface. these are the pages a security reviewer will want next.
security, compliance, or vendor-review questions during evaluation: hello@noctaracorp.com. send us your questionnaire and we will answer it against the controls above, honestly, including the rows where the answer today is "in progress."