Master Security Reference

What is your legal entity, where is it incorporated, and when was it formed?

AscendCore, Inc. — Delaware C-Corporation, formed May 1, 2026 via Stripe Atlas. Headquartered in Pittsburgh, PA, USA. Tax ID and state filings available on request under NDA.

Who is responsible for information security at AscendCore?

Jacob Kelly (Founder & CEO) is the accountable owner for information security through the first technical hire (trigger: customer #3 OR $150K ARR). Security architecture decisions are documented in version-controlled markdown alongside the production codebase; significant changes require a documented threat-model entry before merge.

Do you have a written information security policy?

Yes — security policies live at three layers: (1) public-facing Trust Center at /security and Security Overview at /security/overview describing posture, (2) internal policy documents covering acceptable use, access control, change management, incident response, vendor management, BCP/DR — provided under NDA during procurement, (3) production codebase comments documenting architectural security choices (e.g., approval-first architecture, per-org credential isolation). Policies are reviewed annually and after any significant incident.

How often are policies reviewed and updated?

Annual review cycle minimum, with ad-hoc updates triggered by (a) audit findings, (b) significant incidents, (c) regulatory changes, (d) material product architecture changes. All policy changes are logged with date, author, and rationale.

Do you have a documented information security training program for employees?

Yes — every employee (currently founder only; first hire trigger documented above) completes security awareness training at onboarding and annually thereafter. Training covers phishing recognition, credential hygiene, secure development practices, customer data handling, and incident reporting procedures. SOC-2 Type I audit (Q3 2026) will formalize attendance tracking. Vanta is configured to track training compliance.

How do you classify data?

Four classification tiers: PUBLIC (marketing copy, deck content, runbook specifications), INTERNAL (engineering docs, internal metrics), CONFIDENTIAL (customer integration credentials, customer audit chains, customer user data, financial data), SECRET (encryption keys, master credentials, founder PII). Customer data is CONFIDENTIAL minimum; integration credentials and audit chain data are handled at SECRET-equivalent controls.

Do you maintain an inventory of information assets?

Yes — inventory is split across (1) application infrastructure (Netlify projects, Neon databases, Cloudflare R2 buckets, Doppler secrets) — managed and audited via vendor consoles, (2) customer integrations (per-org credential vaults in Doppler), (3) source code (GitHub, private repository). Vanta provides continuous inventory sync for SOC-2 evidence.

How is asset ownership tracked?

Every infrastructure asset has a documented owner (founder today; will expand with first hire). Vendor consoles enforce single-admin ownership; access changes require explicit reauthorization.

How are end-of-life or deprecated assets retired?

When customer integrations are deprovisioned (customer churn or feature removal), the per-org credential vault is purged within 24 hours and replaced with a tombstone audit record. Database tables for churned customers are soft-deleted with 90-day retention then hard-purged. Audit chain rows for churned customers remain (immutable by design) but are flagged for retention-policy compliance.

How do users authenticate to the AscendCore dashboard?

Production authentication is via OIDC SSO against the customer's own identity provider (Microsoft Entra ID or Okta supported today). Customers may optionally enable mandatory-SSO mode (env var ADMIN_REQUIRE_SSO=true) which disables the password fallback path entirely, forcing all admin auth through the IdP. The customer's conditional access policies — MFA, device trust, geo-fencing, FIDO2 — apply unchanged.

Is multi-factor authentication enforced?

Yes — MFA is enforced by the customer's identity provider rather than reimplemented on AscendCore. This is intentional architectural design: the IdP is the authoritative MFA authority, and AscendCore delegates rather than duplicating. Customers retain full control over MFA factors (TOTP, FIDO2, hardware tokens, push, SMS — per their IdP policy).

What role-based access controls are in place?

Three role tiers enforced server-side on every mutation route: (1) Owner — full read/write to org's data; can manage integrations, billing, team. (2) Demo — read-only access to fictitious data for prospect demos; cannot execute production actions (server-side denied at API layer). (3) Guest — limited read access for specific resources. Demo-vs-Owner enforcement was verified in audit commit 2411594.

How are privileged actions logged?

Every approve, deny, and execution event is appended to the per-org SHA-256 tamper-evident audit chain in Postgres. Records include timestamp, actor identity (email or namespaced channel ID), target resource (e.g., okta_user, entra_user), action verb (e.g., mfa_reset.approved), outcome, integration source (Slack/Teams/dashboard/API), mode (live/sandbox), and the prior-record hash linkage. Chain is customer-exportable for independent verification.

What is your password policy?

For customer-managed admin authentication (legacy password fallback path), passwords are validated against length and complexity requirements (12+ chars, mixed case, number, special) and rate-limited. However: we recommend and support OIDC SSO + mandatory-SSO mode, which eliminates the password attack surface entirely. Most customers will not use the password path; it exists as a fallback for owner emergency access.

How are administrative accounts protected?

All AscendCore-side admin accounts (founder, future employees) require: (1) MFA via Google Workspace SSO (we use Workspace as our internal IdP), (2) hardware FIDO2 keys preferred and enforced for production-environment access, (3) named-account auditing — no shared accounts. Customer-side admin accounts inherit the customer's IdP policy entirely.

How are integration credentials managed?

Per-org credential isolation: each customer's integration credentials (Okta API keys, Entra client secrets, M365 application credentials, Slack signing secrets, Teams bot credentials) live in a Doppler-managed vault scoped to that org. Doppler ↔ Netlify integration syncs to runtime. Credentials never appear in code, never appear in logs, and resolve only for the org's traffic via AsyncLocalStorage-backed scoping.

How do you handle credential rotation?

Per-customer integration credentials follow the customer's own rotation policy — we accept the rotation cadence the customer's IdP enforces. AscendCore-side platform credentials (Stripe webhook secrets, Anthropic API key, Doppler service tokens) are rotated annually or after any suspected compromise. Vanta tracks rotation evidence as part of SOC-2 Type I.

Do you implement principle of least privilege?

Yes — at every layer: (1) Customer-side IdP scopes limit AscendCore's reach into customer tenants to the minimum required for runbook execution (documented in /docs/onboarding service-account manifests). (2) AscendCore-side, every service has a scoped service token (Doppler), not master credentials. (3) Database access uses Neon's per-branch authentication so production credentials never appear on developer workstations.

How is data encrypted in transit?

TLS 1.3 minimum across all customer-facing surfaces. HSTS enforced with 1-year max-age and preload. Internal service-to-service traffic also TLS 1.3 (no internal plaintext bus). Slack and Teams webhooks verified at the edge before any application processing — HMAC-SHA256 timing-safe for Slack, JWT signature against Microsoft Bot Framework JWKS for Teams.

How is data encrypted at rest?

AES-256 at rest across all stored data: Neon Postgres (provider-managed encryption), Cloudflare R2 object storage (AES-256-GCM), Netlify Blobs (AES-256-GCM). Doppler secret vaults use AES-256 with envelope encryption.

Who manages encryption keys?

Today: provider-managed keys (Neon, Cloudflare R2, Netlify, Doppler). Roadmap H1 2027: customer-managed encryption keys (BYOK) for application-level data encryption — bring-your-own-KMS architecture for customers with regulatory requirements that mandate dedicated key custody.

What hash algorithms do you use?

SHA-256 for the audit chain (NIST FIPS 180-4 compliant). Password storage (legacy fallback path) uses bcrypt with cost factor 12. HMAC-SHA256 for outbound webhook signatures and inbound Slack webhook verification. Timing-safe comparison enforced via Node's `crypto.timingSafeEqual` to defend against timing-attack discovery.

Do you use any deprecated or weak cryptography?

No. We do not use MD5, SHA-1, DES, 3DES, RC4, or TLS < 1.2 anywhere in the production stack. Static analysis (npm audit + Snyk via GitHub Dependabot) flags weak crypto in dependencies.

What audit logging do you maintain?

Every approve, deny, and execution event flows into a per-org SHA-256 tamper-evident audit chain backed by Postgres. Each record contains: org_id, seq, timestamp (UTC), actor_email, action verb, resource_type, resource_id, integration source, outcome, mode (live/sandbox), prev_hash, this_hash. Records are immutable (append-only) — UPDATE/DELETE on the audit_events table is denied at the database role layer.

Can customers verify audit log integrity independently?

Yes. Customers can export the full audit chain via CSV from the dashboard. The export includes prev_hash + this_hash columns. Customers can re-run the verification routine (published in our open documentation) against the export to confirm the chain hashes correctly — providing cryptographic proof against later tampering. The verification logic is the same code AscendCore runs internally; we don't ship a verifier we don't dogfood.

How long do you retain audit logs?

Customer audit chain: retained for the lifetime of the customer relationship plus 7 years (default), or per the data retention term negotiated in the MSA. Application logs (request logs, error logs): 30 days minimum retention via BetterStack Logs. Security event logs (auth failures, anomalous access patterns): 90 days minimum, longer if part of an active investigation.

What anomalous-activity detection do you have?

Today: spike-in-5xx alerts via BetterStack, rate-limit hit alerts surfaced to the dashboard for owner review, audit-chain hash-verification failures fire P1 alerts. In progress (Step 5 of bootstrap roadmap): Sentry + Axiom integration for structured anomaly detection — pattern-based alerts on unusual API key usage, geographic anomalies, time-of-day deviation. SOC-2 Type I will formalize the detection rules and response runbooks.

How is log access controlled?

Customer audit chains are read-only to the customer's owner-role users (no AscendCore staff has casual read access; production data access requires named-justification entry to break-glass procedure, logged immutably). Application logs are limited to the founder today; will expand to named technical hires only. No log aggregation occurs in third-party tools without explicit sub-processor disclosure.

What time synchronization do you use?

NTP enforced at the provider layer (Netlify edge, Neon database, Cloudflare R2). All timestamps recorded in UTC at ISO 8601 format with millisecond precision. Clock skew is bounded by provider SLAs to <100ms across the stack.

Do you have a documented incident response process?

Yes. Our internal incident runbook covers five stages: detection, containment, eradication, recovery, post-mortem. Severity definitions and response targets are written into customer MSAs. P1 (production down, no workaround): 30-min acknowledgement, 4-hr resolution target. P2 (degraded, workaround exists): 2-hr ack, 1 business day resolution. P3 (minor): 1 business day ack, best-effort. SOC-2 Type I (Q3 2026) will formalize the runbook to audit standard.

How will customers be notified of security incidents?

Customer notification SLA is 1 hour for any confirmed data incident affecting customer-controlled data (subject to applicable legal counsel review). Notification channels: dedicated Slack Connect channel per customer (primary), email to the designated security contact on the customer account, and public status-page incident if the incident affects multiple customers. Customer notification will include: incident summary, affected scope, mitigation status, customer-action requirements (if any), and expected next-update window.

How are incidents escalated?

P1 alerts fire from synthetic monitoring (BetterStack) into the AscendCore Slack workspace + page the on-call (founder today). After-hours P1 paging is set up via BetterStack alert routing. P2 alerts route to Slack-only during business hours. Escalation from P2 → P1 happens if not acknowledged within target window OR if scope expands materially.

Do you have a documented breach notification process compliant with GDPR / CCPA / state privacy laws?

Yes — incident response runbook includes regulatory notification timelines: GDPR (72 hours from confirmed breach to supervisory authority + affected data subjects), CCPA (notification 'in the most expedient time possible and without unreasonable delay'), state-specific laws (Pennsylvania, California, New York, others as customer base expands). Counsel review precedes external regulatory notification.

Do you conduct incident response exercises / tabletop drills?

Quarterly tabletop exercises documented internally — first formal drill cycle begins Q3 2026 alongside SOC-2 Type I evidence window. Pre-formal, the founder runs ad-hoc walkthroughs of the runbook for the top-3 likely incident scenarios (credential compromise, integration outage cascading to customer impact, audit-chain corruption).

Do you have a documented BCP/DR plan?

Yes — documented internally and provided under NDA during procurement. The plan covers: (1) provider-level outages (Neon, Netlify, Cloudflare) and our failover posture, (2) data restoration from backup, (3) communication procedures during extended outages, (4) succession planning for the founder-only stage.

What is your RPO (Recovery Point Objective) and RTO (Recovery Time Objective)?

RPO 1 hour (Neon Postgres point-in-time recovery enables restore to any timestamp within the retention window with 1-hour-or-better granularity). RTO 4 hours for full production restore from cold backup (Neon backup restore + Netlify redeploy + Doppler secret resync). For most outages (provider-side issues), expected RTO is much shorter as recovery is automatic at the provider level.

How often do you back up customer data?

Continuous: Neon Postgres point-in-time recovery captures every write with 1-hour-or-better recovery granularity. Daily snapshots retained 30 days. Weekly snapshots retained 1 year. Customer audit chains have additional immutability protection at the application layer (SHA-256 chain breaks on any UPDATE/DELETE).

Do you test backups?

Quarterly backup-restore drills documented internally — first formal cycle Q3 2026 alongside SOC-2 evidence. Pre-formal: ad-hoc restore tests after any material schema change.

Is your infrastructure multi-region?

Single-region today: Neon Postgres US-East-1 + Netlify US edge. Multi-region failover is on the roadmap for 2027 once a customer's SLA requirement exceeds 99.5% (today's commitment). For customers with stricter availability requirements, a deployment architecture with active-active across regions can be scoped as a custom Enterprise tier engagement.

What is your status page URL?

https://status.ascendcore.ai — hosted by BetterStack with synthetic monitoring from 4 global regions at 3-minute cadence. Subscribers can receive incident notifications via email, SMS, Slack, or webhook. 90-day uptime history publicly visible per service.

Do you maintain a list of sub-processors?

Yes — current list of sub-processors is published at /security/overview. Customers receive 30-day advance notice of any addition or change via DPA-mandated notification. Major sub-processors today: Neon (database), Netlify (hosting/edge), Cloudflare R2 (object storage), Doppler (secrets), Anthropic (LLM intent classification), Stripe (billing), BetterStack (uptime monitoring), Sentry (error tracking with PII scrubbing), Resend (transactional email), Vanta (SOC-2 evidence).

How do you evaluate sub-processor security posture?

Every new sub-processor is evaluated against: (1) public security posture (SOC-2 / ISO certifications), (2) DPA availability and quality, (3) data residency, (4) ability to limit data exposure (minimum required scope), (5) ability to revoke at the customer level if a customer opts out. Selection prefers vendors with completed SOC-2 Type II + EU/US data-flow compliance.

What data do you share with the LLM provider (Anthropic)?

AscendCore sends Anthropic the natural-language intent classification prompts ONLY — the unprocessed ticket text from Slack/Teams. The LLM returns a runbook classification (e.g., 'mfa_reset' with target user 'jacob@example.com'). The LLM is air-gapped from execution: no credentials, no database connections, no integration access. Anthropic ZDR (Zero Data Retention) is enabled for Enterprise tier — Anthropic does not retain prompts post-completion. For lower tiers, standard Anthropic data-handling applies per their DPA.

Where is customer data stored geographically?

Primary data store: Neon Postgres in US-East-1. Object storage: Cloudflare R2 (US region). Edge caches: Netlify global CDN (cache only — no customer data persisted at edge). Customer integration credentials: Doppler US. Email delivery: Resend US. For EU customers requiring EU-only data residency, multi-region deployment is a custom Enterprise engagement (currently quoted on request).

Do you sign DPAs with sub-processors?

Yes — DPA in force with every sub-processor handling customer data. Sub-processor DPAs are reviewed during procurement-grade legal review and disclosed in our master DPA template upon request.

Describe your software development process

Source code lives in private GitHub repositories. Branch-based development with required reviews on critical paths (audit chain, auth, multi-tenancy, billing). 705+ unit tests run on every commit (Vitest); production deploys gated on passing tests. Static analysis (TypeScript strict mode + ESLint) enforced. Drizzle ORM migrations follow expand-then-contract patterns; never rename columns in one step. Deploy pipeline: GitHub → Netlify atomic deploy (instant rollback available). Doppler ↔ Netlify integration syncs secrets at deploy time.

Do you perform security code review?

Every change touching auth, audit chain, customer data flow, or integration credentials gets reviewed against the threat-model docs and security architecture guides. Static analysis runs on every commit (TypeScript, ESLint, npm audit). Security-relevant tests are pinned in the test suite (705+ tests including auth bypass tests, demo-mode enforcement tests, audit-chain integrity tests, signature verification tests).

Do you use third-party security scanning?

GitHub Dependabot + npm audit run on every commit for dependency vulnerabilities. Snyk integration is on the roadmap for Q3 2026 (alongside SOC-2 evidence collection). Container scanning is not applicable — we do not run our own containers in production (Netlify serverless runtime handles container management).

Do you have a documented change management process?

Yes — every production change is in source control with author, reviewer, rationale documented. Database schema changes follow expand-then-contract migration patterns. Deploys are atomic via Netlify; rollback is single-click. Customer-side deploy notification is on the roadmap as part of Step 6 of the bootstrap critical path (zero-downtime deploy hardening).

When do you conduct penetration testing?

Independent third-party penetration test is scheduled for Q3 2026, after multi-tenancy Phase 3 and the production observability story is complete. Reports will be available under NDA for active procurement conversations. Pre-formal: internal threat-modeling exercises documented as architectural decision records (ADRs); the 5-pillar security audit (April 2026) covered security, integration resilience, architecture, brand, and strategic surfaces.

Do you have a vulnerability disclosure / bug bounty program?

Coordinated disclosure invited via security@ascendcore.ai. Acknowledged within 1 business day. Formal bug bounty program is on the roadmap for H2 2026 (post-SOC-2 Type I cert).

What customer data do you process?

We process: (1) Customer admin identity (email, name, role) for AscendCore platform users, (2) Customer end-user identity (email, name) when a runbook targets a specific user, (3) Customer integration credentials (per-org vault in Doppler), (4) Runbook approval metadata (timestamps, actors, target resources, outcomes — written to audit chain), (5) Natural-language ticket text routed to LLM for intent classification (transient).

What customer data do you NOT process?

We do NOT store: customer email body content (only the routing metadata for runbook intent classification), customer endpoint device data, customer financial records, customer health records, customer source code. We are not in the data-warehouse business — we are a workflow orchestrator.

Do you process EU resident data?

Customer-defined — if the customer's user directory contains EU residents, AscendCore processes that data on the customer's behalf as a data processor. Standard Contractual Clauses (SCCs) are part of the master DPA. EU-only data residency requires custom Enterprise engagement; not part of the standard tier as of 2026-05-14.

What are your data retention policies?

Customer audit chain: lifetime of customer relationship + 7 years (or per MSA). Application logs: 30 days minimum. Security event logs: 90 days minimum (longer if part of an active investigation). Customer integration credentials: deleted within 24 hours of customer churn or integration deprovisioning. Customer admin identity records: 30 days post-churn then purged unless legal-hold applies. PII in transient LLM prompts: not retained beyond completion (Anthropic ZDR for Enterprise tier).

How do you handle data subject requests (GDPR/CCPA)?

Customer is the data controller for end-user data; AscendCore is the processor. Data subject requests (access, deletion, portability) are routed to the customer's admin team, who use AscendCore's user-management runbooks to fulfill on their end. AscendCore-side DSR for customer admin identity data (the platform's own user accounts): 30-day SLA for response, fulfilled via security@ascendcore.ai.

Do you have a privacy policy?

Yes — published at /privacy. Reviewed for accuracy against actual data flows during the v5.11 cycle (May 2026). Updates published with 30-day advance notice via dedicated Slack Connect customer channels.

How do you handle data deletion on customer offboarding?

Customer integration credentials: purged from Doppler within 24 hours of churn or explicit deprovisioning request, with tombstone audit record. Customer admin identity records: 30 days then hard-purged. Customer audit chain: retained per MSA term (default 7 years post-churn for compliance evidence; customer can request shorter retention by contractual amendment).

Where is your infrastructure physically located?

Customer data is hosted entirely in vendor data centers (Neon — AWS US-East-1, Netlify — AWS multi-region edge, Cloudflare R2 — Cloudflare global with US default). AscendCore does not operate physical data centers. Vendor data center physical security inherits from the providers (AWS SOC-2 + ISO 27001, Cloudflare SOC-2 + ISO 27001).

Do you have employees working from physical office?

Today: founder-only, working remotely from a home office in Pittsburgh, PA. AscendCore does not maintain a physical office. Workstations enforce: full-disk encryption (FileVault on macOS), screen-lock < 5 min idle, automatic OS patching, password manager mandated for personal/work secrets separation. Production access requires hardware FIDO2 keys.

How do you protect against malware?

Workstation level: macOS XProtect + Gatekeeper + Notarization enforcement + Little Snitch for outbound monitoring. No production access from compromised endpoints (FIDO2 hardware key + named-account ensures any unauthorized session is detectable). Production runtime: serverless functions on Netlify with no persistent shell or filesystem (per-request execution model resistant to persistent malware).

Do you maintain a clean desk policy?

Standard work-from-home posture: no physical sensitive documents in unsecured locations; printed materials are shredded after use. Screens lock within 5 minutes of inactivity. Visitors do not have access to workstations or papers.

What certifications do you currently hold?

As of 2026-05-14: SOC-2 Type I path locked (Vanta enrolled this week, audit window open, Type I certification targeted Q3 2026). No other formal certifications today. ISO 27001 is on the roadmap for 2027 alignment.

Are you HIPAA compliant?

HIPAA is demand-driven — BAA template is ready, and full HIPAA controls activate when the first healthcare-vertical customer signs. Today no HIPAA-covered entity is a customer; we do not advertise HIPAA-aligned posture in marketing materials until activated.

Are you PCI compliant?

AscendCore is not in scope for PCI DSS — we do not process cardholder data. All payment processing is delegated to Stripe (PCI DSS Level 1 compliant). Customer payment surfaces do not pass through AscendCore infrastructure.

Are you FedRAMP authorized?

No. FedRAMP is out of scope for current target market (mid-market commercial IT, not federal government). If federal government customers enter the pipeline, FedRAMP scope would be evaluated then.

Do you support SOC-2 Type II?

On roadmap H2 2027 — after Type I cert (Q3 2026) + standard observation period (~12 months) for the Type II window.

Can you provide your latest SOC-2 report?

Type I is in progress as of 2026-05-14 (Vanta enrollment kicked off this week; audit window now open; cert targeted Q3 2026). When the cert lands, the report will be available under NDA for active procurement conversations. In the interim: the SOC-2 evidence collection underway via Vanta is itself reviewable under NDA for customers who want to verify the controls being assessed.