Master Security Reference

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

AscendCore, Inc. is a 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?

Information security is owned at the executive level by a single named, accountable officer. Security design decisions are recorded in version-controlled architecture documents and in pull requests alongside the code.

Do you have a written information security policy?

Not as a formal policy set yet. Security practices are documented in the public Trust Center at /security and the Security Overview at /security/overview, in an internal on-call and incident runbook, and in architecture documents in the codebase. A written policy set (access control, change management, incident response, vendor management, business continuity) is part of the planned SOC-2 Type I work.

How often are policies reviewed and updated?

There is no formal policy review cycle yet; it is part of the planned SOC-2 Type I work.

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

Not yet. There is no formal security awareness training program or attendance record today.

How do you classify data?

There is no formal data classification policy yet. In practice, integration credentials receive application-layer encryption and the audit chain is hash-chained.

Do you maintain an inventory of information assets?

The service runs on a small set of provider accounts (Netlify, Neon, Cloudflare, Doppler, GitHub, and the sub-processors listed at /security), recorded in an internal vendor and account inventory. There is no automated asset inventory tool today.

How is asset ownership tracked?

Provider accounts are administered by AscendCore and listed in the internal vendor and account inventory. There is no formal asset ownership register beyond it.

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

Disconnecting an integration deletes its stored credentials immediately and records the disconnect on the audit chain. Organization data is not deleted automatically today; at termination the DPA's 30-day export window and deletion apply.

How do users authenticate to the AscendCore dashboard?

Customer users sign in to the web portal with email and password (salted scrypt hashes; accounts are created by invitation only). Approvers working in Teams are authenticated by their own Microsoft 365 sign-in, so your Entra ID policies apply to them. AscendCore's own operator console uses Microsoft Entra ID single sign-on for named addresses. SSO for the customer portal is planned.

Is multi-factor authentication enforced?

For Teams approvals, yes, through your own Entra ID policies. For the customer web portal, not today: there is no second factor yet. AscendCore does not implement MFA factors itself.

What role-based access controls are in place?

Customer portal: administrator (settings, integrations, team, Sandbox or Live mode, approval routing) and approver (approve and deny). AscendCore's own console: owner, plus demo and guest roles that see only fictitious data and are refused on every route that changes data. Roles are enforced on the server. In Teams and Slack, the people in the approval channel you designate can decide cards.

How are privileged actions logged?

Each approval, denial, and outcome is appended to the organization's SHA-256 hash chain with the time, the actor's platform identity (Teams or Slack user ID, portal email, or a system actor), the action, the target, the integration, the result, and the Sandbox or Live mode. Events are written after the action, so a database outage can leave a gap. Sign-ins and API key changes are not on the chain today.

What is your password policy?

Portal passwords need at least 12 characters with upper case, lower case, and a digit, are stored as salted scrypt hashes, and are compared in constant time. Users set them through a single-use invitation link that expires after 14 days.

How are administrative accounts protected?

AscendCore's operator console uses Entra ID single sign-on for named addresses, a server-enforced 5-minute idle timeout, and session cookies that are HTTP-only, Secure, and SameSite=Lax. Customer administrators use the portal's email and password today.

How are integration credentials managed?

Credentials you enter (for example ServiceNow, Jira Service Management, Freshservice, Okta, or your own Microsoft app registration) are sealed with AES-256-GCM in a per-organization vault, bound to your organization, decrypted only inside the server function that uses them, never returned to a browser or API response, and deleted when you disconnect. With one-click Microsoft consent, no credential of yours is stored. AscendCore's own platform secrets are held in Doppler.

How do you handle credential rotation?

Integration credentials follow your own schedule: rotate in your system, then reconnect in the portal. AscendCore's platform credentials are held in Doppler and changed by hand, with no automated rotation schedule. The vault encryption key cannot be rotated yet.

Do you implement principle of least privilege?

Partly. Customer API keys carry explicit scopes, and integration credentials are used only for their own organization. The standard Microsoft connection requires five Graph application permissions (User.Read.All, User.ReadWrite.All, Group.ReadWrite.All, GroupMember.ReadWrite.All, Organization.Read.All), which apply tenant-wide; runbooks that need more are not part of the standard connection.

How is data encrypted in transit?

ascendcore.ai accepts only TLS 1.2 and TLS 1.3 and sends HSTS with a one-year max-age including subdomains. Outbound calls to Microsoft Graph, identity and ITSM APIs, Anthropic, Resend, Neon, and Netlify Blobs use HTTPS. Teams actions are verified against Microsoft Bot Framework tokens (signature, issuer, audience) and Slack requests with HMAC-SHA256 in constant time within a 5-minute window.

How is data encrypted at rest?

Neon and Cloudflare R2 encrypt stored data with AES-256, and Netlify encrypts Blobs at rest, according to each provider's documentation. Integration credentials are additionally encrypted by AscendCore with AES-256-GCM.

Who manages encryption keys?

Each storage provider manages its own encryption keys. AscendCore manages the credential-vault key in Doppler. Customer-managed keys (BYOK) are not supported today and are planned.

What hash algorithms do you use?

SHA-256 for the audit chain, API key hashes, and invitation tokens; scrypt for passwords; HMAC-SHA256 for webhook signatures and Slack verification. Signatures and password hashes are compared in constant time.

Do you use any deprecated or weak cryptography?

No MD5, SHA-1, DES, 3DES, or RC4 in application code, and TLS 1.0 and 1.1 are refused. GitHub Dependabot tracks vulnerable dependencies.

What audit logging do you maintain?

A SHA-256 hash chain per organization in Postgres. Each event carries the time, actor, actor type, action, target type and ID, integration, details, Sandbox or Live mode, and the previous and current hashes. The application only appends; any edit to an earlier event breaks verification. The Sandbox or Live label is stored but not covered by the hash.

Can customers verify audit log integrity independently?

Yes. Export the organization's chain as CSV from the portal and run AscendCore's standalone verifier, a single Node.js file using only built-in modules, which recomputes every hash and link with no call to AscendCore. AscendCore supplies the verifier and the algorithm description on request. Removal of the most recent events is not detectable by the chain alone; countersigned checkpoints (built, not yet switched on) address that.

How long do you retain audit logs?

For the life of the account; nothing is purged automatically today. After termination the DPA's 30-day export window and deletion apply. Application function logs are kept by our hosting provider for 24 hours to 7 days depending on plan.

What anomalous-activity detection do you have?

Better Stack monitors availability, Sentry captures application errors, and operator alerts go to email and Slack. There is no anomaly detection, SIEM, or user-behavior analytics today, and no automated audit-chain verification runs today.

How is log access controlled?

Portal audit views and exports are limited to the signed-in user's organization. AscendCore's own administrator accounts can view request records and receive copies of approval notifications in order to operate and support the service. Application function logs are accessible only through AscendCore's hosting account.

What time synchronization do you use?

Timestamps come from the provider-managed servers that run the application and database and are recorded in UTC. AscendCore operates no servers or time sources of its own.

Do you have a documented incident response process?

Yes, an internal on-call and incident runbook covering severity levels, detection, acknowledgement and response steps, communication, and post-incident review. Targets in business hours: P1 (production down, no workaround) 30-minute acknowledgement and a 4-hour resolution target; P2 (degraded, workaround exists) 2 hours and 1 business day; P3 (minor) 1 business day, best effort. Outside business hours, response is best effort. SOC-2 Type I (planned) will formalize the runbook to audit standard.

How will customers be notified of security incidents?

Under DPA Section 10: without undue delay and no later than 72 hours after AscendCore becomes aware of a confirmed Security Incident affecting Personal Data, with the nature of the incident, the categories and approximate number of data subjects and records affected, and the measures taken or proposed. Notice goes to your designated security contact, or to the primary account email if none is designated. Service-wide incidents are also posted at status.ascendcore.ai.

How are incidents escalated?

Monitoring alerts (Better Stack, Sentry, and operator alerts) go to email and Slack, and escalation follows the severity levels in the internal runbook. There is no paging service or after-hours rotation today; after-hours paging is planned.

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

AscendCore notifies customers under DPA Section 10 and, as processor, supports the customer's own notifications under GDPR, CCPA, and state breach laws. A standalone breach-notification procedure with regulator timelines is not yet written.

Do you conduct incident response exercises / tabletop drills?

Not yet. No exercise has been run or recorded.

Do you have a documented BCP/DR plan?

Not as a standalone plan. The internal incident runbook covers outage response and communication, and recovery relies on what the providers offer (Neon point-in-time restore, Netlify deploy rollback).

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

AscendCore has not committed to RPO or RTO targets. What is configured: managed Postgres (Neon) with point-in-time restore over a 6-hour window, and restorable earlier application deploys on Netlify. The Netlify Blobs operational store has no separate backup today.

How often do you back up customer data?

The Postgres database has continuous point-in-time restore over a 6-hour window; no scheduled snapshots are configured. The Netlify Blobs store, which holds organization and request records, is not separately backed up today.

Do you test backups?

Not yet. No restore test has been performed or documented.

Is your infrastructure multi-region?

No. The database and operational store run in one US East region (Ohio); static assets are served from Netlify's global CDN. Multi-region failover is planned. AscendCore is not in your sign-in path, so an outage pauses requests without affecting your users' access.

What is your status page URL?

https://status.ascendcore.ai, run on Better Stack, with 90-day uptime history for the site, the application, the database, and the integrations aggregator.

Do you maintain a list of sub-processors?

Yes, published at /security in the categories of DPA Section 7: cloud infrastructure (Netlify, Neon, Cloudflare R2, Doppler), AI/ML services (Anthropic), email delivery (Resend), security monitoring (Sentry), and product analytics (PostHog, only after cookie consent). AscendCore gives at least 14 days' notice before adding or replacing a sub-processor, with an opportunity to object.

How do you evaluate sub-processor security posture?

The current providers are established cloud vendors that publish their own security documentation. AscendCore does not yet run a formal vendor risk review program.

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

The request text as typed, which can include names and email addresses; for tickets from ServiceNow, Jira Service Management, or Freshservice, the subject and description; and, if the optional IT help assistant is used, the conversation, the requester's device details, and an attached screenshot. The model returns a runbook intent and a target, which are checked against a fixed list. Model calls carry no tools, and prompts contain no credentials. Anthropic's Commercial Terms bar training on customer content; Anthropic states that API inputs and outputs are deleted within 30 days, with exceptions for usage-policy enforcement and legal requirements.

Where is customer data stored geographically?

In the United States: Postgres (Neon) in AWS us-east-2 (Ohio), the Netlify Blobs store in us-east-2, and the application on Netlify in the US. Export and uploaded files in Cloudflare R2 are not pinned to a region. EU-only data residency is not available today.

Do you sign DPAs with sub-processors?

AscendCore uses each provider under its standard terms and published data processing terms (Anthropic's Commercial Terms, for example, incorporate its Data Processing Addendum). AscendCore has not negotiated custom agreements with its sub-processors. Links are available on request.

Describe your software development process

Code lives in a private GitHub repository, and every change lands through a pull request. CI runs on every pull request to the main branch and on every merge: a clean install from the lockfile, a TypeScript type check, the automated test suite (2,800+ tests), and checks on public copy and branding. Each pull request builds a deploy preview that is checked before merge; production deploys are atomic and can be rolled back. Branch protection and a required second reviewer are not in place today.

Do you perform security code review?

Security-relevant behavior is pinned by automated tests (tenant-isolation source scan, approval-path invariants, signature verification, sandbox guards), and security fixes ship as tested pull requests. A second-person review is not required before merge today.

Do you use third-party security scanning?

GitHub Dependabot alerts and automated security updates cover dependencies. There is no static application security testing today, and npm audit is not run in CI. Container scanning does not apply: the service runs on Netlify's serverless runtime, not on containers AscendCore operates.

Do you have a documented change management process?

Every production change is a pull request with CI and a deploy preview; merging deploys to production through Netlify, and any earlier deploy can be restored. There is no formal change-approval board or customer change notification today.

When do you conduct penetration testing?

An independent third-party penetration test is planned and has not been performed; the report will be available under NDA for active procurement conversations once complete. An internal review in April 2026 covered security, integration resilience, and architecture, and internal reviews since have found and fixed issues through tested pull requests.

Do you have a vulnerability disclosure / bug bounty program?

Report vulnerabilities to security@ascendcore.ai. There is no published disclosure policy, security.txt file, or bug bounty program today.

What customer data do you process?

Organization settings and Microsoft tenant ID; portal users' names, emails, roles, and password hashes; request records (requester and approver identities, the target user's name, email, and directory ID, action, outcome, timestamps, ticket number and link); the audit chain; encrypted integration credentials; and, transiently, request text and ticket subjects and descriptions for classification.

What customer data do you NOT process?

AscendCore does not read mailboxes, calendars, Teams chats, or files, does not set, see, or store your users' Microsoft passwords, and does not handle payment card data. Request records do not hold chat text or ticket descriptions.

Do you process EU resident data?

If your directory includes EU residents, AscendCore processes their data as your processor under the DPA, which includes Standard Contractual Clauses (Module Two). All AscendCore data stores are in the United States; EU-only residency is not available today.

What are your data retention policies?

Organization records, request records, and the audit chain are kept for the life of the account, with no automatic deletion today. Integration credentials are deleted on disconnect. Request text appears in function logs that our hosting provider keeps for 24 hours to 7 days by plan, and the optional triage and assistant features keep some conversation text in session records. After termination, the DPA provides a 30-day export window and then deletion.

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

You are the controller for your users' data. AscendCore forwards to you any request it receives from a data subject (DPA Section 8) and assists you in responding. Requests about AscendCore's own records go to legal@ascendcore.ai and are answered within 30 days.

Do you have a privacy policy?

Yes, published at /privacy. Data that AscendCore processes for you is governed by the DPA at /dpa rather than the privacy policy.

How do you handle data deletion on customer offboarding?

Disconnecting an integration deletes its credentials immediately and records the disconnect on the audit chain. Removing the AscendCore enterprise application in Entra ID ends Microsoft access at once. Account data is deleted after the DPA's 30-day post-termination export window; that deletion is not automated today.

Where is your infrastructure physically located?

AscendCore runs entirely on cloud providers and operates no data centers. The database (Neon, on AWS) and the operational store (Netlify Blobs) are in the us-east-2 region (Ohio); physical security is provided by those providers.

Do you have employees working from physical office?

AscendCore operates remote-first and does not maintain a physical office. There is no formal endpoint security policy or device management program today.

How do you protect against malware?

The production service runs as serverless functions on Netlify, with no long-running servers or shells of AscendCore's own. There is no managed endpoint protection product on workstations today.

Do you maintain a clean desk policy?

There is no formal clean desk policy. AscendCore has no physical office.

What certifications do you currently hold?

None. SOC-2 Type I is planned, with a ~90-day audit window once enrollment begins. ISO 27001 is planned after SOC-2.

Are you HIPAA compliant?

No. AscendCore does not hold a HIPAA attestation, does not offer a BAA today, and does not process protected health information for any customer.

Are you PCI compliant?

AscendCore does not process cardholder data and is not in scope for PCI DSS. When paid billing is enabled, card payments are handled by Stripe.

Are you FedRAMP authorized?

No. FedRAMP is outside AscendCore's current scope (mid-market commercial IT).

Do you support SOC-2 Type II?

Type II is planned and follows Type I and its observation period. There is no SOC-2 report of either type today.

Can you provide your latest SOC-2 report?

There is no SOC-2 report today. In the interim, our documented security controls are reviewable under NDA, including your audit-chain export with the offline verifier.