CISO Top-50

Do you support SSO via SAML or OIDC?

Partly. Approvers working in Microsoft Teams are authenticated by their own Microsoft 365 sign-in, so your Entra ID policies apply to them. AscendCore's own operator console uses OIDC single sign-on with Microsoft Entra ID. The customer web portal uses email and password today; SSO for it is planned. SAML is not supported today.

Is MFA enforced for admin access?

For approvers in Teams, yes, through your own Entra ID sign-in and Conditional Access policies: AscendCore accepts a card action only when Microsoft's Bot Framework service delivers it with a valid signed token. The customer web portal has no second factor today. AscendCore's operator console signs in through Entra ID single sign-on and does not implement MFA itself.

What authentication factors are supported?

AscendCore does not implement its own second factors. Where sign-in is delegated to an identity provider (Teams approvals, the AscendCore operator console), that provider's factors apply. The customer web portal uses a password only today.

Do you implement role-based access control?

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

How are privileged actions audited?

Each approval, denial, and outcome is appended to your organization's SHA-256 hash chain in Postgres, together with agent proposals, ITSM ticket intake, integration connect and disconnect, and switches between Sandbox and Live. Events are written after the action and do not block it, so a database outage can leave a gap. Sign-ins and API key changes are not recorded on the chain today.

What is your password policy?

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

How are service accounts and API keys managed?

Customer API keys are 256-bit random values stored only as SHA-256 hashes. Each key belongs to one organization, carries explicit scopes, is rate limited, and can be revoked. Integration credentials you enter are sealed with AES-256-GCM in a per-organization vault in Postgres. The Microsoft connection uses admin consent to AscendCore's multi-tenant application, so no Microsoft credential of yours is stored.

Do you support just-in-time access provisioning?

In your environment, the privilege elevation runbook adds a user to a privileged group for an approved window, and a scheduled job removes the access after the window ends, using your own connection and recording a system event on your audit chain. That job runs weekly today, so removal can lag the window; a shorter cadence is planned. AscendCore's own production access is limited to named administrator accounts; there is no just-in-time tooling for it today.

How is credential rotation handled?

Integration credentials follow your own schedule: rotate the secret in your system, then reconnect it in the portal, which replaces the stored value. AscendCore's platform credentials are held in Doppler and changed by hand; there is no automated rotation schedule. The vault encryption key cannot be rotated yet, although each stored value already carries a key version for it.

Do you support customer-managed encryption keys (BYOK)?

Not today. Customer-managed keys (BYOK) are planned.

How is data encrypted in transit?

ascendcore.ai accepts only TLS 1.2 and TLS 1.3; TLS 1.0 and 1.1 are refused. HSTS is sent with a one-year max-age, including subdomains. AscendCore's calls to Microsoft Graph, identity and ITSM APIs, Anthropic, Resend, Neon (through its HTTPS driver), and Netlify Blobs use HTTPS. Teams actions are verified with Microsoft Bot Framework tokens and Slack requests with HMAC-SHA256.

How is data encrypted at rest?

Neon encrypts stored data with AES-256 and Cloudflare R2 encrypts objects with AES-256, according to their documentation; Netlify encrypts Blobs at rest according to its documentation, without publishing the algorithm. Integration credentials are encrypted a second time by AscendCore with AES-256-GCM before storage.

What hash algorithms do you use?

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

Do you use any deprecated cryptography?

No MD5, SHA-1, DES, 3DES, or RC4 in application code, and TLS 1.0 and 1.1 are refused at the edge. Dependency vulnerabilities are tracked with GitHub Dependabot.

How are encryption keys managed?

Storage encryption keys are managed by each provider (Neon, Netlify, Cloudflare). The credential-vault key is managed by AscendCore in Doppler and supplied to the application as an environment secret. There are no per-organization keys and no customer-managed keys today; BYOK is planned.

Where is customer data stored geographically?

In the United States. The Postgres database (Neon) runs in AWS us-east-2 (Ohio), the Netlify Blobs operational store is in us-east-2, and the application runs 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.

Are you GDPR compliant?

AscendCore acts as a processor under its published DPA, which covers GDPR and UK GDPR, includes Standard Contractual Clauses (Module Two) for transfers, and commits AscendCore to notify the controller of a confirmed Security Incident without undue delay and no later than 72 hours, so the controller can meet its own duties. AscendCore has not been independently assessed for GDPR compliance.

Are you CCPA compliant?

The DPA includes CCPA service-provider terms: AscendCore does not sell or share personal information or use it outside the business purpose. A request AscendCore receives from a data subject is forwarded to the customer as controller, and deletion requests sent to legal@ascendcore.ai are actioned within 30 days.

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, the action, outcome, timestamps, and any ITSM ticket number and link); your audit chain; encrypted integration credentials; and, transiently, the text of chat requests and of ITSM ticket subjects and descriptions, which is sent for classification.

What 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. In Teams it receives only messages addressed to the AscendCore app. Request records do not hold chat text or ticket descriptions.

What is your data retention policy?

Organization records, request records, and the audit chain are kept for the life of the account; there is no automatic deletion job today. Integration credentials are deleted as soon as an integration is disconnected. Request text appears in function logs, which our hosting provider keeps for 24 hours to 7 days depending on plan. After termination the DPA (Section 9) provides a 30-day export window, then deletion of Customer Data, confirmed in writing on request.

How is data deleted 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 30-day post-termination export window set by the DPA (Section 9); that deletion is not automated today.

What data is sent to the LLM provider?

The text of a request as typed, which can include names and email addresses, and for ITSM tickets the subject and description. If the optional IT help assistant is used, also the conversation, the requester's device details, and an attached screenshot. Prompts contain no credentials and model calls carry no tools. Anthropic's Commercial Terms state that it may not train models on customer content, and Anthropic states that API inputs and outputs are deleted within 30 days, except where needed to enforce its usage policy or comply with law.

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.

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 to each provider's terms are available on request.

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 audit logging do you maintain?

A SHA-256 hash chain per organization in Postgres. Each event records the time, the actor (Teams or Slack user ID, portal email, or a system actor), the actor type, action, target type and ID, integration, details, the Sandbox or Live mode, and the previous and current hashes. The application only ever appends to the chain, and the hash chain makes an edit to any earlier event detectable.

Can customers verify audit log integrity independently?

Yes. Portal users can export their organization's full chain as CSV, and AscendCore supplies on request a standalone verifier (one Node.js file using only built-in modules) that recomputes every hash and link from the CSV with no call to AscendCore. Verification exposes edits to or deletion of earlier events; detecting removal of the most recent events needs countersigned checkpoints, which are built but not yet switched on.

How long are audit logs retained?

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?

Limited. 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?

Your audit chain and its exports are visible in the portal only to your organization's users. AscendCore's own administrator accounts can view request records and receive copies of approval notifications in order to operate and support the service.

Do you have a documented incident response process?

Yes. An internal on-call and incident runbook covers severity levels, detection sources, acknowledgement and response steps, communication, and post-incident review. Targets in business hours: P1 (production down) 30-minute acknowledgement and a 4-hour resolution target; P2 (degraded) 2 hours and 1 business day; P3 1 business day, best effort. The runbook has not been externally audited.

What's your customer notification SLA for security incidents?

The DPA (Section 10) commits AscendCore to notify you without undue delay and no later than 72 hours after becoming aware of a confirmed Security Incident affecting Personal Data. The notice covers the nature of the incident, the categories and approximate number of data subjects and records affected, and the measures taken or proposed. It goes to your designated security contact, or to the primary account email if none is designated.

Are you GDPR-compliant for breach notification?

As processor, AscendCore notifies you, the controller, under DPA Section 10, so that you can meet your own 72-hour duty to the supervisory authority and any duty to data subjects. AscendCore cooperates with the investigation and remediation.

Do you conduct tabletop exercises?

Not yet. No tabletop exercise has been run or recorded.

Do you have an after-hours on-call rotation?

Not today. Monitoring alerts are delivered by email and Slack at any hour, but response outside business hours is best effort, and there is no formal after-hours rotation or paging service yet. After-hours paging is planned.

What is your RPO and RTO?

AscendCore has not committed to RPO or RTO targets. What is configured: the Postgres database is managed by Neon with point-in-time restore over a 6-hour window, and any earlier application deploy can be restored on Netlify. The Netlify Blobs operational store has no separate backup today.

How often do you back up 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), and 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 have a secure SDLC?

Every change lands through a pull request in a private GitHub repository. 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 gets a deploy preview that is checked before merge, and production deploys are atomic with rollback. Branch protection, a required second reviewer, and static application security testing are not in place today.

Do you perform security code review?

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

What dependency vulnerability scanning do you have?

GitHub Dependabot alerts and automated security-update pull requests, plus grouped weekly dependency updates. npm audit is not run in CI.

When do you conduct penetration testing?

An independent penetration test is planned and has not been performed, so there is no report to share yet. The report will be shared under NDA for active procurement conversations once complete.

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 certifications do you hold today?

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

Are you HIPAA / PCI / FedRAMP compliant?

No. AscendCore holds none of these attestations and does not process payment card data.

When will you have 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 share 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.