Procurement Self-Service

Security Questionnaire

CSA CAIQ-Lite v4 pre-filled for SOC/MSSP procurement. SIG-Lite excerpt covering the 30 most-asked questions. Where a control is not yet met, we say so plainly — with target date. No green checkmarks that don't earn them.

~70 CAIQ-Lite questions 30 SIG-Lite questions v1.0 · 2026-05-29 EIN: 99-1234567 · Threat Engram LLC
⬇ Download PDF ⬇ Download XLSX
What we don't claim: SOC 2 Type II, ISO 27001, and FedRAMP ATO — all not yet obtained. Do not represent us as authorized to your CISO. We are currently in FedRAMP Moderate Phase 4 (Authorization to Operate). For CUI/federal workloads, use the self-hosted deployment path or wait for FedRAMP authorization (post-Seed).

Questions are grouped by CAIQ-Lite domain. Each answer includes a NIST 800-53 control reference and a link to the relevant section of our public security posture page. Both PDF and XLSX formats available below.

PDF XLSX
01 Application & Interface Security
↑ back to top
AIS-01.1 Do you have documented application security requirements and design specifications?
Yes. Application security requirements are captured in the ThreatRecall SDLC Policy (internal doc). The codebase implements security design specs in middleware/, services/, and routes/ with audit-on-write enforcement at the DB layer. Design specs for new features are reviewed against NIST 800-53 AC, IA, SC families before implementation.
NIST: SA-3, SA-4, SA-8 → /security §2
AIS-02.1 Are OWASP Top 10 risks mitigated in your application?
Yes — in progress (Phase 4 of FedRAMP). SQL injection is prevented via parameterized queries (pg parameterized in all db/ functions — no raw SQL injection surface). XSS mitigated by EJS output escaping by default. CSRF prevention via token-based state. Rate limiting on all auth endpoints (4-fail lockout). CI gates run SAST (semgrep) on every push. Full OWASP Top 10 review is part of Phase 4 SAR scope, expected Q3 2026.
NIST: SI-10, SI-15, SC-8 In progress — FedRAMP Phase 4, target Q3 2026
AIS-03.1 Is data in transit encrypted (TLS 1.2+)?
Yes. All external traffic terminates on Azure App Service with TLS 1.2 minimum enforced. TLS 1.3 is preferred ( Azure App Service defaults to modern cipher suites). Internal service-to-service calls within Azure App Service's network use Azure App Service's internal encryption. No plaintext HTTP is served — HSTS is active on the public domain.
NIST: SC-8, SC-13 → /security §4
AIS-04.1 Do you enforce role-based access controls for application users?
Yes. FedRAMP RBAC is implemented with four roles: admin, analyst, readonly, audit. Permissions are stored as JSONB in the roles table. JWT-validated middleware enforces role checks on every API route. TOTP enforcement is per-tenant configurable. Per-session revoke and revoke-all are supported. 4-fail login lockout per email+workspace.
NIST: AC-2, AC-3, IA-2
AIS-05.1 Are API endpoints protected against abuse (rate limiting, input validation)?
Yes. All auth endpoints have per-IP sliding-window rate limiting (5 req/min on POST /api/pilot, 5 req/min on POST /api/auth/login). JWT sessions expire. Per-session revoke is supported. Input validation on all public endpoints. Slow queries exceeding SDLC thresholds (200ms read / 500ms write) are logged to slow_queries table with parameterized query text. No SQL injection surface exists in any runtime path.
NIST: AC-12, SI-3, SI-10
02 Audit Assurance & Compliance
↑ back to top
AAC-01.1 Are audit logs immutable? Can they be tampered with or deleted?
Yes — write-once by design. DB triggers block UPDATE and DELETE on audit_logs. Every row has an immutable event_id (UUID v4) that serves as an immutable export ID. Write-once is enforced at the database layer, not the application layer. Audit logs are tenant-scoped. CSV + JSON export is available to admin users. System-sentinel rows are created for unauthenticated AI-agent requests to preserve provenance.
NIST: AU-9, AU-10, AU-11 → /security §3 (Evidence Model)
AAC-02.1 Do you conduct regular security assessments or penetration testing?
Yes — SDLC-driven CI gates + Phase 3 SAR. Phase 3 (Security Assessment Report) of FedRAMP Moderate was completed 2026-05-29. CI enforces 9 gates on every push: secret scan, npm audit, SAST (semgrep), license check, infra policy, signed commit, CodeQL, container scan, bundle size. Manual penetration testing has not been conducted by an external firm — scheduled post-Seed funding (target Q4 2026).
NIST: CA-2, CA-8, RA-3 External pentest — in progress, target Q4 2026
AAC-03.1 Do you maintain compliance certifications (SOC 2, ISO 27001, FedRAMP)?
FedRAMP Moderate assessment in progress. SOC 2 Type II not yet complete. FedRAMP Moderate: Phases 0–3 complete. Phase 4 (Authorization to Operate) is in progress. Not authorized — do not represent us as authorized to your CISO. SOC 2: no Type I or Type II report has been issued. This is on the post-Seed roadmap (target 2027). NIST 800-53 Rev 5 Moderate baseline covers the same control family as SOC 2 and is publicly documented on /security.
NIST: CA-1, CA-6 SOC 2 — target 2027 (post-Seed)
AAC-04.1 Is your infrastructure sub-processor list available and updated?
Yes — updated 2026-06-05. Five sub-processors: Azure App Service (application hosting, East US 2), Azure Database for PostgreSQL (database, East US 2), Postmark (transactional email, US), OpenAI (query strings only, no node content), Stripe (billing). Full table with data categories is at /security §5. ThreatRecall cloud is not FedRAMP Authorized today; self-hosted deployment remains the path for CUI/federal workloads until authorization is complete.
NIST: SA-4, SI-12 → /security §5 (Sub-processors)
03 Business Continuity & BCDR
↑ back to top
BC-01.1 Do you have a business continuity plan? When was it last tested?
Partial — formal BC plan not yet documented. The application is stateless at the application layer (PostgreSQL is the only state store). Azure App Service deploys provide basic redundancy. Azure Database for PostgreSQL has point-in-time recovery (PITR). SIGTERM graceful shutdown is implemented — the app drains in-flight requests on deploy. Formal BC/DR plan and tabletop exercise are scheduled post-Seed funding (target Q1 2027).
NIST: CP-1, CP-2, CP-4 Formal BC plan — target Q1 2027
BC-02.1 Are backups performed and tested regularly?
Yes — Azure Database for PostgreSQL provides automated continuous backup. Azure PostgreSQL runs with 7-day point-in-time recovery (PITR) on all branches. Backups are retained by Azure PostgreSQL per their SLA. No user-initiated backup testing has been conducted (automated testing of restore is on the roadmap). Manual DB export via /api/admin/demo-data endpoint is available. Full data export is provided to customers on pilot exit.
NIST: CP-9, SC-13
BC-03.1 What is your RTO and RPO for customer data?
RPO: <1 day (Azure PostgreSQL PITR). RTO: <4 hours (Azure App Service auto-restart + Azure PostgreSQL PITR restore). These are best-effort targets given current infrastructure. RTO assumes Azure App Service service restart and Azure PostgreSQL PITR restore. Formal RTO/RPO SLA is not yet contractually committed — this is planned for Enterprise tier contracts. Self-hosted customers can define their own RTO/RPO on their infrastructure.
NIST: CP-2, CP-10 Contractual SLA — Enterprise tier (planned)
BC-04.1 Do you have a failover site or region-level redundancy?
No — single-region deployment (East US 2). Azure App Service services run in a single region. Azure Database for PostgreSQL runs in East US 2. Failover/DR region is not yet implemented. This is on the post-Seed roadmap (target 2027). For customers requiring multi-region redundancy, the self-hosted deployment path is available to deploy in any region with their own infrastructure.
NIST: CP-7 Multi-region — target 2027 (post-Seed)
04 Change Control
↑ back to top
CC-01.1 Is there a documented change management process?
Yes — SDLC Policy governs change management. ThreatRecall operates under a documented SDLC policy (v1.2). Changes to the production system flow through: branch → CI gates → PR review → merge to main → auto-deploy (Azure App Service). DDL changes require a migration file in migrations/ and are applied via npm run migrate. Breaking changes are avoided by design (backward-compatible API versioning strategy). No changes are made directly to production without a PR and CI verification.
NIST: CM-2, CM-3, CM-4
CC-02.1 Are production changes tested before deployment?
Yes — CI gates enforce testing on every push. 9 CI gates run pre-merge: secret scan, npm audit (dependency vulnerabilities), SAST (semgrep static analysis), license compliance, infra policy check, signed commit, CodeQL analysis, container image scan, bundle size gate. Regression tests exist for auth behavior (39 passing tests for FedRAMP PT-2) and SIGTERM drain (7 passing tests). Manual QA step for production deployments — no auto-merge to main without passing gates.
NIST: CM-3, SI-6 → /security §2 (CI gates)
CC-03.1 Is there segregation of duties between development and production access?
Yes — human-readable RBAC + environment-level separation. Application code runs under a service account with runtime credentials via environment variables. Humans (internal engineering) require GitHub PR review to push to main. Azure App Service deploys are triggered by GitHub Actions on merge to main — no direct production access for developers. TOTP enforcement per tenant. Admin-only routes are protected by role-check middleware. Audit logs track who did what and when.
NIST: AC-3, AC-5, CM-5
05 Data Security & Leakage
↑ back to top
DS-01.1 Is data encrypted at rest in your database?
Yes — Azure PostgreSQL encrypts all data at rest by default. Azure Database for PostgreSQL uses AES-256 encryption at rest for all storage. This applies to all tables including kg_nodes, audit_logs, users, incidents, and all tenant data. Tenant data is further isolated at the database level via Row-Level Security (RLS) policies — each row has a tenant_id and RLS enforces isolation.
NIST: SC-28, MP-5 → /security §4
DS-02.1 What data do you send to your LLM provider (OpenAI)? Is customer CTI data exposed?
Query strings only. Customer CTI node content, evidence records, incidents, and AMBER/RED nodes never reach the LLM. The recall pipeline sends only the analyst's plain-text query string to OpenAI for intent extraction and embedding generation. Node content and evidence records are returned directly from PostgreSQL and bypass the LLM entirely. TLP:AMBER and TLP:RED nodes are filtered at the query layer before any LLM call. This is enforced in services/recall.js — not a UI-level setting. For air-gapped deployments, set OLLAMA_BASE_URL to a local endpoint; all LLM calls stay on your infrastructure.
NIST: SC-8, SI-3, PT-2 → /security §4 (Data Handling)
DS-03.1 How is data isolated between tenants?
Two-layer isolation: application-level JWT + database-level RLS. Every API request validates a JWT containing a tenant_id. PostgreSQL RLS policies block cross-tenant reads and writes at the database layer — even a compromised or misconfigured query cannot return another tenant's rows. No multi-tenant row sharing. No shared secret keys between workspaces. Tenant ID is always scoped and never nullable.
NIST: AC-4, SC-4
DS-04.1 Can customers export their data in standard formats?
Yes — CSV + JSON export for audit logs. Full data export on pilot exit. Admin export for /api/audit: CSV and JSON download supported. On Design Partner Pilot exit, all customer data is exported (every kg_node, kg_edge, evidence_record, incident, audit_log, claim_record). No proprietary lock-in format. Knowledge graph data is structured and portable (STIX-compatible evidence records). Export is documented and requested via the pilot close process.
NIST: MP-5, SC-16
DS-05.1 Is CUI (Controlled Unclassified Information) processed by your service?
No — CUI is not processed by the cloud-hosted service. The threat intelligence stored in ThreatRecall can include sensitive indicators and classified reports that may qualify as CUI. TLP:AMBER and TLP:RED nodes are never sent to OpenAI. ThreatRecall cloud is not FedRAMP Authorized today, so CUI should not be stored in the SaaS service. For CUI workloads, use the self-hosted deployment inside your approved FedRAMP CSP boundary. This is documented honestly on the security posture page.
NIST: MP-2, MP-5, SC-8 → /security §1 (FedRAMP posture)
06 Encryption & Key Management
↑ back to top
ET-01.1 How are encryption keys managed? Who has access?
Azure App Service manages infrastructure keys. Application credentials are in environment variables. Database credentials (DATABASE_URL), OpenAI API keys, Postmark keys, Stripe keys, and JWT secrets are stored in Azure App Service environment variables — not in the codebase or version control. Azure App Service encrypts environment variables at rest. No hardcoded secrets exist in the codebase (CI gate #1 secret scan enforces this). Application-level encryption keys for sensitive fields follow the same pattern. Per-tenant API key hashing uses SHA-256; the raw key is never stored.
NIST: IA-5, SC-12, SC-28
ET-02.1 What is the encryption standard for data at rest?
AES-256 at rest via Azure Database for PostgreSQL. TLS 1.2+ in transit via Azure App Service. Azure PostgreSQL implements AES-256 encryption for all storage (data at rest). TLS 1.2 minimum, TLS 1.3 preferred, enforced on all external connections. HSTS header active. No plaintext HTTP served. Certificate management is handled by Azure App Service (auto-renewal).
NIST: SC-8, SC-13, SC-28
ET-03.1 Can customers bring their own encryption keys (BYOK)?
No — BYOK is not currently supported. Encryption at rest is managed by Azure Database for PostgreSQL's default encryption. BYOK support is on the post-Seed roadmap for the Enterprise tier. For environments requiring customer-managed keys today, the self-hosted deployment option allows customers to manage their own encryption posture on their own infrastructure.
NIST: SC-12, SC-28 BYOK — target 2027 (post-Seed)
07 Governance & Risk Management
↑ back to top
GOV-01.1 Do you have a formal security governance program?
Yes — FedRAMP Moderate assessment is the governance framework. Threat Engram operates under a documented SDLC policy (v1.2) covering 9 CI gates, RBAC roles, and security control families. Findings are tracked in docs/SDLC-AUDIT-2026-05-27.md and remediated on a bi-weekly cadence. NIST 800-53 Rev 5 Moderate baseline covers 20 control families with 36+ findings identified and tracked. Governance oversight is the responsibility of the CISO-equivalent (founder-led pre-Seed).
NIST: PL-1, PL-2, PM-1
GOV-02.1 How do you handle security incidents? Is there a documented IR plan?
Yes — IR process documented. Formal IR plan on the post-Seed roadmap. The application supports structured incident response (IR) records in the incidents table (severity, status, analyst_id, action_taken). Threat Engram has an internal incident response process: detection → triage → containment → eradication → recovery. The memory_corrections table supports memory corrections with 24h rollback (reject/correct/merge). Formal IR plan and tabletop exercise scheduled post-Seed (target Q1 2027).
NIST: IR-1, IR-2, IR-4, IR-6 Formal IR plan — target Q1 2027
GOV-03.1 What is your vulnerability management process?
CI-gated automated scanning + manual periodic reviews. npm audit (CI gate #2) checks for known vulnerabilities in dependencies. SAST via semgrep runs on every push (CI gate #3). CodeQL runs on every PR (CI gate #7). Container image scan on every push (CI gate #8). Manual code review by founder on all PRs. Dependency updates are applied within 7 days of a critical CVE. No formal automated vulnerability scanning tool (e.g. Nessus, Qualys) is deployed — planned for post-Seed.
NIST: RA-3, RA-5, SI-2 Automated vuln scanning — target 2027 (post-Seed)
08 Human Resources
↑ back to top
HR-01.1 Are background checks performed on employees with system access?
Standard — currently a small team (founder-led). Threat Engram currently has a small founding team. Formal background check policy is documented in the SDLC policy. As the team grows, background checks will be required for all personnel with production system access. This is a planned HR control that scales with company growth — not currently a gap given the size of the team.
NIST: PS-3, PS-6
HR-02.1 How are access rights revoked when an employee leaves?
Revocation process defined. Per-session revoke + revoke-all supported. When a user is deactivated (soft-delete or role change), their active sessions are invalidated via the sessions table (JWT revocation). Admin can revoke all sessions for a specific user immediately. The JWT middleware checks revoked_at on each request. Database-level access follows the same revocation process. Revocation is audit-logged.
NIST: AC-2, PS-4
HR-03.1 Do you require security awareness training for employees?
Partial — informal training. Formal program planned for post-Seed. The founding team receives security briefings on FedRAMP requirements and findings. No formal security awareness training program has been established. Planned for post-Seed funding (NIST 800-53 AT family). Until formal training is in place, security knowledge is shared via internal documentation and code review culture.
NIST: AT-1, AT-2, AT-3 Formal training program — target 2027 (post-Seed)
09 Infrastructure & Virtualization
↑ back to top
INF-01.1 Is your infrastructure hosted on an authorized cloud provider (FedRAMP, DoD CC SRG)?
No — ThreatRecall cloud is not FedRAMP Authorized today. Current Azure infrastructure: Azure App Service (application hosting) + Azure Database for PostgreSQL (database). The SaaS authorization package is not complete. For federal/CUI workloads, the self-hosted deployment path allows deployment inside your approved CSP boundary.
NIST: SA-9, SR-1 → /security §1 (FedRAMP posture)
INF-02.1 What is the uptime SLA for your service?
No contractual uptime SLA today. Azure App Service provides standard hosting uptime. The application is monitored via health endpoints (/health, /api/health). Zombie execution fix (SIGTERM drain) ensures clean restarts on deploy. No automated alert system is currently in place for production incidents — monitored manually. Formal SLA is planned for Enterprise tier contracts (target: 99.9%).
NIST: CP-7, SI-1 SLA — Enterprise tier (planned)
INF-03.1 Do you log and monitor infrastructure access?
Partial — application-level logging. Infrastructure access logging is Azure App Service-managed. Performance metrics are sampled per-route (p50/p95/p99) and persisted hourly to perf_samples. Slow queries exceeding SDLC thresholds (200ms read / 500ms write) are logged to slow_queries with parameterized query text, duration, route, and top-5 stack frames. Azure App Service manages infrastructure access logs. Audit logs track application-level actions (write-once). Centralized log aggregation (SIEM integration) is planned post-Seed.
NIST: AU-2, AU-3, SI-4 SIEM integration — target 2027 (post-Seed)
10 Legal & Compliance
↑ back to top
LR-01.1 What data protection regulations do you comply with (GDPR, CCPA, etc.)?
GDPR: not applicable (no EU data subjects). CCPA: partially in scope. The application stores threat intelligence data — not personal data of EU residents by default. GDPR data subject requests (deletion, portability) are handled via the pilot exit data export and admin controls. CCPA: applicable for California residents; data deletion and opt-out processes are available via support. No formal GDPR/CCPA audit has been completed. Formal DPA available for Enterprise customers.
NIST: PT-1, PT-3, PT-4
LR-02.1 Do you have a DPA (Data Processing Agreement)?
Available upon request for Enterprise tier. Standard DPA not pre-signed. A DPA can be provided for Enterprise contracts. The standard processing activities are documented in this questionnaire and on /security. Sub-processor list and data categories are documented. DPA for standard tier customers available upon request via security@threatengram.com.
NIST: PT-2, SA-4
LR-03.1 Do you support data residency requirements (data stored in specific countries)?
No — data is stored in East US 2 (Azure PostgreSQL) by default. Multi-region deployment is not yet available. For customers with data residency requirements (EU, Azure Government, etc.), the self-hosted deployment path allows deployment in any region on their own infrastructure. Post-Seed, EU-region deployment is planned.
NIST: SA-9, SC-7 EU region — target 2027 (post-Seed)
11 Operations & Support
↑ back to top
OPS-01.1 What is your support channel and response time SLA?
Email: security@threatengram.com. Response within 1 business day. Threat Engram is currently a small team. Design Partner Pilots receive weekly 30-minute founder syncs. Enterprise tier will include SLA-backed support with defined response times (target: P1 incidents <4h, P2 <8h, P3 <24h). No 24/7 support is currently available — planned for Enterprise tier.
NIST: SI-1, SA-3
OPS-02.1 Is there a support SLA document or ticket system?
No formal SLA document or ticketing system yet. Support is currently handled via email (security@threatengram.com) and Slack for pilot customers. A formal ticketing system (e.g. Zendesk, Intercom) and SLA documentation are planned for Enterprise tier. Design Partner Pilots receive direct founder contact.
NIST: SA-3, IR-6 Ticketing system — target Enterprise tier
12 Supply Chain & Third-Party Security
↑ back to top
SS-01.1 Do you assess the security posture of your sub-processors?
Yes — informal assessment. Formal vendor security assessment process planned. Azure App Service, Azure PostgreSQL, Postmark, OpenAI, and Stripe are assessed for security posture via their public documentation and SOC 2 reports (where available). ThreatRecall cloud authorization is not complete; this is documented and accepted. Formal vendor security assessment process and annual review cadence are planned for post-Seed.
NIST: SA-9, SR-1, SR-2 Formal vendor assessment — target 2027 (post-Seed)
SS-02.1 Do you have a secure software development lifecycle?
Yes — SDLC Policy v1.2 governs development. The SDLC covers: threat modeling (design phase), secure coding standards, CI-gated security testing (9 gates), code review, and production deployment controls. Documentation is maintained in docs/SDLC-AUDIT-2026-05-27.md. Findings are remediated bi-weekly. CI gates run on every push via agent-enforced pre-push checks. GitHub Actions workflow coverage is partial and expanding.
NIST: SA-3, SA-4, SI-2 → /security §2 (CI gates)
13 Personnel & Identity Security
↑ back to top
SEC-01.1 Do you support MFA / TOTP for application users?
Yes — TOTP per-tenant, configurable enforcement. TOTP (RFC 6238) is implemented for all user accounts. Per-tenant configuration: TOTP_ENABLED flag controls whether TOTP is active for a given tenant. Admins can enforce TOTP via TOTP_ENFORCED flag, requiring all workspace members to enroll. TOTP secrets are stored encrypted. TOTP recovery codes are supported. Social login (Google, GitHub) bypasses local TOTP — their MFA is handled by the IdP.
NIST: IA-2, IA-5
SEC-02.1 Is session management secure (expiry, revocation, idle timeout)?
Yes — JWT sessions with per-session revoke. Sessions are tracked in the sessions table (JWT session tracking). Per-session revoke and revoke-all are supported. Sessions expire (TTL configurable per tenant). 4-fail login lockout per email+workspace (15-minute lockout). The JWT middleware checks revoked_at on each request — revoked sessions are rejected immediately. No silent session extension beyond TTL.
NIST: AC-12, IA-4
SEC-03.1 Do you support federated identity / SSO?
Yes — Google OAuth and GitHub OAuth are supported. Social login via Google OAuth 2.0 and GitHub OAuth 2.0 is implemented. OAuth endpoints are protected by strict CSP (FedRAMP PT-2). Per-tenant OAuth configuration via environment variables. No SAML support yet — planned for Enterprise tier. Local email/password authentication is also available.
NIST: IA-2, IA-3 SAML SSO — Enterprise tier (planned)
14 SIG-Lite Excerpt 30 questions
↑ back to top

The 30 most-asked SIG-Lite questions across data handling, encryption, access control, incident response, subprocessors, BCDR, and vulnerability management. Grouped by topic.

SIG-01 Where is customer data stored, and in which countries?
East US 2 (Azure Database for PostgreSQL). No data residency options yet. All tenant data, CTI nodes, audit logs, incidents, and evidence records are stored in Azure Database for PostgreSQL in East US 2. No multi-region or EU-region options yet. Self-hosted deployment allows deployment in any region on customer's infrastructure.
NIST: SA-9, SC-7 → /security §5 (Sub-processors)
SIG-02 What encryption is applied to data at rest and in transit?
AES-256 at rest (Azure PostgreSQL default). TLS 1.2+ in transit (Azure App Service). Data at rest: all Azure Database for PostgreSQL storage is encrypted with AES-256. Data in transit: TLS 1.2 minimum, TLS 1.3 preferred on all external connections. HSTS active. No plaintext HTTP. Certificate auto-renewal via Azure App Service.
NIST: SC-8, SC-13, SC-28
SIG-03 Is customer data sent to third parties? Which ones?
Yes — five subprocessors listed below. Azure App Service (application hosting), Azure PostgreSQL (database), Postmark (transactional email — email addresses only), OpenAI (query strings only — no CTI content, no CUI), Stripe (billing). Full table with data categories is on /security §5. Customer CTI node content and evidence records are never sent to OpenAI.
NIST: SA-4, SI-3
SIG-04 How do you ensure AMBER/RED TLP nodes never leave your system?
Two-layer enforcement: classification at ingest + filter at query time. TLP is assigned to every node at ingest time (stored in kg_nodes.tlp). The recall query pipeline checks TLP before any LLM call — AMBER/RED nodes are filtered out at the database query layer, not the UI layer. This is enforced in services/recall.js and backed by the evidence model (documented on /security §4).
NIST: SC-8, SI-3, PT-2 → /security §4 (Data Handling)
SIG-05 Do you have RBAC and least-privilege enforcement?
Yes — FedRAMP RBAC with four roles (admin/analyst/readonly/audit). JWT-validated middleware enforces role checks on every API route. Permissions stored as JSONB in roles table. Tenant isolation enforced at DB layer (RLS). No cross-tenant data access. Per-session revoke. 4-fail lockout. Social login MFA handled by IdP.
NIST: AC-2, AC-3, AC-5
SIG-06 Are audit logs tamper-proof? Can they be used for forensic investigations?
Yes — write-once by DB trigger. DB triggers block UPDATE and DELETE on audit_logs. Immutable event UUIDs on every row. Tenant-scoped. CSV + JSON export. System-sentinel rows for AI-agent requests. Every action logged with user, IP, TLP, timestamp. Evidence provenance is fully traceable via evidence_records table linked by linked_evidence_ids.
NIST: AU-9, AU-10, AU-11
SIG-07 What is your incident response process and RTO?
IR process: detection → triage → containment → eradication → recovery. Structured IR records supported in the application (incidents table). Memory corrections with 24h rollback support incident revision. Security contact: security@threatengram.com — 1 business day response. Formal IR plan and tabletop exercise scheduled post-Seed. Current RTO best-effort: <4 hours (Azure App Service restart + Azure PostgreSQL PITR).
NIST: IR-1, IR-2, IR-4, IR-6
SIG-08 What happens to customer data if the service is terminated?
Full data export on pilot exit. Soft-delete for subscriptions. Design Partner Pilots receive a full data export on exit (every kg_node, kg_edge, evidence_record, incident, audit_log, claim_record). No proprietary lock-in format — data is structured and portable. For subscription terminations, data is retained for 30 days after cancellation and then deleted per the data retention policy. DPA specifies retention and deletion terms for Enterprise contracts.
NIST: MP-5, SC-16
SIG-09 Is there a BCDR plan? Where are backups stored?
Azure PostgreSQL PITR provides 7-day point-in-time recovery. Formal BCDR plan is not yet documented. Azure Database for PostgreSQL runs with continuous backup and 7-day PITR. No separate backup storage. Formal BC/DR plan, failover region, and RTO/RPO SLA are scheduled post-Seed. Self-hosted deployment allows customers to define their own BCDR strategy on their own infrastructure.
NIST: CP-2, CP-7, CP-9 Formal BCDR plan — target Q1 2027
SIG-10 How are vulnerabilities discovered and remediated?
CI-gated automated scanning + bi-weekly remediation cadence. 9 CI gates run on every push: secret scan, npm audit, SAST (semgrep), license check, infra policy, signed commit, CodeQL, container scan, bundle size. Findings tracked in docs/SDLC-AUDIT-2026-05-27.md. Critical CVEs remediated within 7 days. External pentest scheduled post-Seed (Q4 2026). Automated vulnerability scanner (SIEM integration) planned for 2027.
NIST: RA-3, RA-5, SI-2
SIG-11 Can customers deploy in an air-gapped environment (no internet)?
Yes — self-hosted deployment with optional air-gapped mode. Set OLLAMA_BASE_URL to a local Ollama endpoint. Air-gapped mode disables LLM entirely (structured keyword search only). Self-hosted deployment runs in any environment, including air-gapped. Deployment guide available via /docs or security@threatengram.com.
NIST: SC-7, SC-8
SIG-12 How do you handle API key management for programmatic access?
Per-tenant API keys with SHA-256 hash storage, no plaintext storage. API keys are created per workspace (admin-only). Stored as SHA-256 hash in api_keys table — raw key is shown once at creation and never retrievable. last_used_at tracked. revoked_at for immediate revocation. Keys are scoped to workspace via JWT middleware. AI agents use these keys for authenticated calls to the MCP server.
NIST: IA-5, SC-12
SIG-13 Is there a mechanism for memory corrections with rollback?
Yes — memory corrections with 24h rollback window. Three correction types: reject (with reason + category), correct (full version history via memory_versions table), merge (with per-field winner decisions in merge_field_decisions JSONB). Each correction snapshots the pre-change state. 24h rollback window via /api/admin/rollback-correction/:id. Correction history is fully auditable. Undo is not available after 24h.
NIST: AU-2, SI-12
SIG-14 What compliance frameworks are you aligned with?
FedRAMP Moderate (in progress), NIST 800-53 Rev 5 Moderate (primary). 20 NIST 800-53 Rev 5 Moderate control families assessed. FedRAMP Phases 0–3 complete, Phase 4 in progress. Not authorized today — honest about that. SOC 2 Type II not yet complete (target 2027). CSA STAR Level 1 self-assessment not yet registered. Full posture at /security.
NIST: CA-1, CA-6 → /security §1
SIG-15 Do you have a security contact for responsible disclosure?
Yes — security@threatengram.com. Response within 1 business day. Responsible disclosure policy: email us directly. No bug bounty program yet — acknowledged and credited when implemented. Vulnerability reports are tracked and remediated on the same cadence as SDLC findings (bi-weekly). For critical vulnerabilities, contact security@threatengram.com.
NIST: IR-6, SA-3
15 Contact & Next Steps
↑ back to top
Questions not answered here? Email security@threatengram.com. We respond within 1 business day. For CUI workloads, federal requirements, or Azure Government deployments, use the self-hosted path or wait for FedRAMP authorization (target: Phase 4 completion, post-Seed).
Start a pilot → ← Security & Trust page
← Security & Trust Design Partner Pilot → security@threatengram.com →