how we detect, contain, and communicate when something goes wrong. this is the working plan, not a brochure. it is published so the people evaluating us can see the operational discipline behind the architecture.
this plan governs how noctara responds to security incidents and personal-data breaches across its production surface. that surface includes the consumer applications on noctaracorp.com, the practitioner and partner products on takethemirror.com, the supporting APIs, and the data those systems hold in our sub-processor stack.
an incident is any event that compromises, or credibly threatens to compromise, the confidentiality, integrity, or availability of customer or participant data, or the systems that process it. that includes unauthorized access, data exposure, authentication bypass, payment-system failure, service outage, and the loss or corruption of data. the plan applies to every member of the team and to the way we coordinate with the third parties that process data on our behalf.
every incident is assigned a severity at triage. the severity sets the response speed, the escalation path, and the communication commitments. severity can be raised or lowered as facts come in.
every incident moves through the same six phases. small incidents pass through them quickly. a SEV1 walks through each one deliberately, with notes kept the entire way.
we are honest about scale. noctara is a small team, and during an incident a single person may hold more than one of these roles at once. that person is Cole Alkire. the roles below describe the functions that must be covered, not a staffed rota. what matters is that each function is owned and that escalation paths exist for when one person is not enough.
| role | owner | responsibility |
|---|---|---|
| incident lead | Cole Alkire | Owns the incident end to end. Sets severity, makes containment calls, decides when the incident is resolved, and convenes the review. Holds the final decision. |
| technical responder | Cole Alkire | Does the hands-on work. Investigates, contains, eradicates, and restores. Pulls in sub-processor support and outside specialists when the work exceeds the team. |
| communications | Cole Alkire | Drafts and sends customer and regulator notifications, keeps affected parties informed, and manages the message. Engages counsel for breach notification. |
we do not claim a staffed twenty-four-hour security operations center. we run a lean detection layer that leans heavily on the alerting our infrastructure providers already do well, plus our own logging and the people who use the product.
when an incident is confirmed to involve a personal-data breach, we notify affected customers without undue delay. our target is notification within seventy-two (72) hours of confirming a personal-data breach, consistent with the GDPR breach-notification standard. the notice is in writing to the customer's primary contact and includes, to the extent known, the nature and scope of the breach, the categories of data and people affected, the steps taken to contain and remediate, and a point of contact for follow-up.
where we act as a data processor on a customer's behalf, we notify that customer so they can meet their own obligations to regulators and to the people whose data was affected. where a notification obligation falls on noctara directly, we work with counsel to meet it within the applicable legal window. seventy-two hours is a target we hold ourselves to, not a ceiling on diligence. if confirmation takes longer, we say so, and we send a preliminary notice rather than wait for a complete picture.
during an incident, customer communication goes out by email from a named human, not from an unattended system address. for confirmed breaches affecting a specific customer, we contact that customer's primary contact directly. for broad service-availability events, we communicate through the channels the affected users already use to reach the product. internally, the incident lead keeps a single running timeline so that the facts, decisions, and timestamps live in one place from the first signal through the final review.
much of our infrastructure is operated by third parties, and each of them maintains its own incident response and breach-notification program. noctara's job is to coordinate. when an incident touches a sub-processor, we engage their support and security channels, consume their status and notification feeds, and fold their findings into our own timeline and our own notice to affected customers. we do not treat a provider's incident as someone else's problem. if it touches our customers' data, it is our incident to communicate.
| role | vendor | incident interface |
|---|---|---|
| database | Supabase | Platform status, security advisories, and support escalation for database and storage incidents. |
| hosting | Vercel | Deploy health, runtime alerts, and platform status for hosting and edge incidents. |
| payments | Stripe | Payment, fraud, and radar alerting, plus dispute and disruption notices. |
| authentication | Clerk | Authentication platform status and security notifications for the enterprise SSO path. |
| transactional email | Resend | Delivery status and incident notices for transactional and notification email. |
| compression engine | Anthropic | Service status and security notices for the model-inference layer. |
after a SEV1 or SEV2 is resolved, we run a blameless review. blameless means the question is what about the system let this happen, not who is at fault. the goal is to make the same failure harder next time, not to assign blame. the review captures a factual timeline, the root cause, what worked, what did not, and a concrete list of remediation items.
each remediation item gets an owner and a target date and is tracked to completion in our engineering queue, the same place all other work lives. an incident is not truly closed until its remediation items are done. recurring patterns across reviews drive larger changes to architecture, monitoring, and process. SEV3 issues are logged so that small signals can be read together over time.
we will not overstate what a small team can do. we do not run a twenty-four-hour staffed security operations center, and we do not pretend to. what we run instead is a disciplined, written process: clear severities, a defined lifecycle, owned roles with real escalation, provider-backed detection, and a firm breach-notification commitment. as the team and the customer base grow, this plan grows with them. it is reviewed at least annually and after any material incident.
to report a security incident or a suspected vulnerability: security@noctaracorp.com.
general or commercial questions: hello@noctaracorp.com.